RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (Full Version)

All Forums >> [New Releases from Matrix Games] >> War in the Pacific: Admiral's Edition >> Tech Support



Message


michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 2:57:46 AM)

If both the hexes that the attacker is moving from and to, are controlled by the attacker, and the river hexside is also controlled by the attacker, then wouldn't the attacker be free to move into the hex.

Or stepping thru the process.
1. Attacker crosses river hexside into the enemy controled hex - shock  attack
2. Hex control stays with defender as he was not forced out of hex. River hexside controled by attacker.
3. Attacker moves more units into hex over river hexside - possible shock attack based on AV comparison (1/3)
4. Defender forced out of hex - hex control goes to attacker. [Hex control stays with a player until no-one in hex (nuetral) or just one player left]
5. Defender moves back into hex.
6. Attacker moves units into hex across river hexside - no attack forced as attacker controls both hexes and river hexsides (NEW).

Can anyone see any flaw in this logic? All steps but (#6) is how it is now.

[edit]
Just changed 'ownership' to 'control'




USSAmerica -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 3:13:32 AM)

Sounds reasonable to me, Michael.  




Alfred -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 4:21:39 AM)

quote:

ORIGINAL: michaelm

If both the hexes that the attacker is moving from and to, are controlled by the attacker, and the river hexside is also controlled by the attacker, then wouldn't the attacker be free to move into the hex.

Or stepping thru the process.
1. Attacker crosses river hexside into the enemy controled hex - shock  attack
2. Hex control stays with defender as he was not forced out of hex. River hexside controled by attacker.
3. Attacker moves more units into hex over river hexside - possible shock attack based on AV comparison (1/3)
4. Defender forced out of hex - hex control goes to attacker. [Hex control stays with a player until no-one in hex (nuetral) or just one player left]
5. Defender moves back into hex.
6. Attacker moves units into hex across river hexside - no attack forced as attacker controls both hexes and river hexsides (NEW).

Can anyone see any flaw in this logic? All steps but (#6) is how it is now.

[edit]
Just changed 'ownership' to 'control'


#6 as currently worded would not require the additional unit to cross the river at the same hexside. The specific hex captured by the attacker as a result of steps 1-5 inclusive, could be on a river bend and therefore have more than one of its hexsides anchored on a river. In theory the defender could repeat step 5 many times (from the land side thereby bypassing the auto shock attack trigger) before the new owner (aka the "attacker" who has really been transformed into the defender) does step 6. However if the hex has 2 or more hexsides anchored on a river, one of the multiple steps 5 could be the defender (aka now really the attacker) moving units in from a river hexside, thus depriving that hexside from being controlled by the controller of the hex. With sufficient force already in the hex, this new river crossing need not necessarily trigger an auto shock attack.

In that eventuality, the hex controller does not really control all river hexsides.

Hence I would modify step #6 to be the controller of the hex will launch no shock attack if the reinforcements corss at a river hexside also controlled. But then we really have the same practical outcome which we currently have.

Essentially your six steps will slightly simply the process if there is only one hexside anchored on a river. It introduces a new potential "loophole" if there are 2 or more river hexsides.

Alfred




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 4:30:44 AM)

quote:

ORIGINAL: Alfred

quote:

ORIGINAL: michaelm

If both the hexes that the attacker is moving from and to, are controlled by the attacker, and the river hexside is also controlled by the attacker, then wouldn't the attacker be free to move into the hex.

Or stepping thru the process.
1. Attacker crosses river hexside into the enemy controled hex - shock  attack
2. Hex control stays with defender as he was not forced out of hex. River hexside controled by attacker.
3. Attacker moves more units into hex over river hexside - possible shock attack based on AV comparison (1/3)
4. Defender forced out of hex - hex control goes to attacker. [Hex control stays with a player until no-one in hex (nuetral) or just one player left]
5. Defender moves back into hex.
6. Attacker moves units into hex across river hexside - no attack forced as attacker controls both hexes and river hexsides (NEW).

Can anyone see any flaw in this logic? All steps but (#6) is how it is now.

[edit]
Just changed 'ownership' to 'control'


#6 as currently worded would not require the additional unit to cross the river at the same hexside. The specific hex captured by the attacker as a result of steps 1-5 inclusive, could be on a river bend and therefore have more than one of its hexsides anchored on a river. In theory the defender could repeat step 5 many times (from the land side thereby bypassing the auto shock attack trigger) before the new owner (aka the "attacker" who has really been transformed into the defender) does step 6. However if the hex has 2 or more hexsides anchored on a river, one of the multiple steps 5 could be the defender (aka now really the attacker) moving units in from a river hexside, thus depriving that hexside from being controlled by the controller of the hex. With sufficient force already in the hex, this new river crossing need not necessarily trigger an auto shock attack.

In that eventuality, the hex controller does not really control all river hexsides.

Hence I would modify step #6 to be the controller of the hex will launch no shock attack if the reinforcements corss at a river hexside also controlled. But then we really have the same practical outcome which we currently have.

Essentially your six steps will slightly simply the process if there is only one hexside anchored on a river. It introduces a new potential "loophole" if there are 2 or more river hexsides.

Alfred


Step 6 already is "same player as the moving units owns the hexes AND the river hexside (both ways) being crossed."

[edit]
in my step by step I was referring to the same river hexside in all steps. If more than one river hexside, each would apply independently until step 4, where attacker would take control of all hexsides on his side of the hex. The river hexsides on the other hexes could still be controled by enemy.
Don't forget that a river hexside can be controlled by either or both player as each of the 2 hexes has a 'side' towards that river.




witpqs -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 5:13:16 AM)


quote:

ORIGINAL: michaelm

To be honest, I am having trouble trying to make sense of the river crossing rule:  "50. Gameplay Change: Change to river assault – reversion to original rule - when crossing a river into a hex all units entering should shock attack in the turn they cross, unless 1/3 of the unmodified AV of the defenders has already crossed from that hex side in a previous turn."

It is written from the perspective of an attacker crossing a river to assault a defender. And I assume that the last part means that 1/3rd of the defender AV is already in the hex.

I need to go back and see how this was  in old WITP. [Well that was no use. Old code just assaults if a river hexside]



As best I recollect the discussions held by developers at the time it means that the player crossing the river (AKA "Attacker") already has in the hex AV equal to or greater than 1/3 of the Defender's AV ("Defender" meaning the other player). The rationale being that friendly forces equal to 1/3 of the enemy forces, while still inferior, is enough to have established a bridgehead and thereby negate the bloody river-crossing shock attack.

I am not suggesting what way is best at this point in time, just trying to help by clarifying what people communicated that they meant way back when.




witpqs -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 5:15:27 AM)

quote:

ORIGINAL: michaelm

If both the hexes that the attacker is moving from and to, are controlled by the attacker, and the river hexside is also controlled by the attacker, then wouldn't the attacker be free to move into the hex.

Or stepping thru the process.
1. Attacker crosses river hexside into the enemy controled hex - shock  attack
2. Hex control stays with defender as he was not forced out of hex. River hexside controled by attacker.
3. Attacker moves more units into hex over river hexside - possible shock attack based on AV comparison (1/3)
4. Defender forced out of hex - hex control goes to attacker. [Hex control stays with a player until no-one in hex (nuetral) or just one player left]
5. Defender moves back into hex.
6. Attacker moves units into hex across river hexside - no attack forced as attacker controls both hexes and river hexsides (NEW).

Can anyone see any flaw in this logic? All steps but (#6) is how it is now.

[edit]
Just changed 'ownership' to 'control'


Looks good to me.




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 5:21:12 AM)

quote:

ORIGINAL: witpqs


quote:

ORIGINAL: michaelm

To be honest, I am having trouble trying to make sense of the river crossing rule:  "50. Gameplay Change: Change to river assault – reversion to original rule - when crossing a river into a hex all units entering should shock attack in the turn they cross, unless 1/3 of the unmodified AV of the defenders has already crossed from that hex side in a previous turn."

It is written from the perspective of an attacker crossing a river to assault a defender. And I assume that the last part means that 1/3rd of the defender AV is already in the hex.

I need to go back and see how this was  in old WITP. [Well that was no use. Old code just assaults if a river hexside]



As best I recollect the discussions held by developers at the time it means that the player crossing the river (AKA "Attacker") already has in the hex AV equal to or greater than 1/3 of the Defender's AV ("Defender" meaning the other player). The rationale being that friendly forces equal to 1/3 of the enemy forces, while still inferior, is enough to have established a bridgehead and thereby negate the bloody river-crossing shock attack.

I am not suggesting what way is best at this point in time, just trying to help by clarifying what people communicated that they meant way back when.

Ah..Thanks
That makes sense to what I read in the code. As written that change was NOT quite clear.




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 7:19:12 AM)

Here is the build with the change to river crossing as described.

Let me know what you think and it may stay for the weekend build

[p9d]
Tweaked River crossing




viberpol -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 8:38:11 AM)

quote:

ORIGINAL: michaelm
quote:

ORIGINAL: viberpol

Attacking force Assault Value = 652
Defending force Assault Value = 1752
Japanese adjusted assault: 0
Allied adjusted defense: 3490
Japanese assault odds: 1 to 99


True, there may be not enough troops to met the 1/3 AV rule (although the 652 vs 1752 AV seems ok).
I'm perfectly ok with shock attacks when crossing the river without enough AV.
But maybe, just maybe, a shock attack should not be triggered regardless of who own the hex?

I owned the hex. I own it for months! Not from the previous turn.
Why the crossing trigger shock attack if the hex is mine?

Based on (my) ;) simple logic, IMHO its seems a bit weird that the forces crossing into friendly hex well secured for months suffer such terrible losses. I think that if I own the hex, I've got total control of the place and the crossing is secured.

Creating bridgeheads and getting into an enemy occupied hex is one thing, normal troops movement in secured hex is something different. Should it trigger the shock attack if my troops are simply moving on a bridge to fill the long owned trench line somewhere 40 miles away?
Some losses from long range enemy bombardment attack ok, but a shock attack and annihilation of a whole division? [&:]

If in your view hex control doesn't matter during river crossing, maybe there should be some check of who owns more hexsides of the contested hex? (in metaphore -- who has more land secured, check if the forces there are not encircled etc.; like 0 - 2 shock attack, 3 bombardment attack, 4 - 6 no punishing attack at all)?

Do you still have the save when this assault happened???


Yup.
Attaching.
The terrible results IMHO were because of the division operation mode. But it was in such a operation mode because I didn't even think crossing from friendly into a friendly hex would/should trigger the shock attack. [:)]

I'll check now if this turn works differently with the latest beta.


quote:

ORIGINAL: michaelm
To be honest, I am having trouble trying to make sense of the river crossing rule: "50. Gameplay Change: Change to river assault – reversion to original rule - when crossing a river into a hex all units entering should shock attack in the turn they cross, unless 1/3 of the unmodified AV of the defenders has already crossed from that hex side in a previous turn."

It is written from the perspective of an attacker crossing a river to assault a defender. And I assume that the last part means that 1/3rd of the defender AV is already in the hex.


quote:

ORIGINAL: witpqs
As best I recollect the discussions held by developers at the time it means that the player crossing the river (AKA "Attacker") already has in the hex AV equal to or greater than 1/3 of the Defender's AV ("Defender" meaning the other player). The rationale being that friendly forces equal to 1/3 of the enemy forces, while still inferior, is enough to have established a bridgehead and thereby negate the bloody river-crossing shock attack.


Yup.
As said that part of the code has been written from perspective of an attacker crossing a river to assault the defender not moving troops between two 'friendly/owned/controlled" hexes.
That rule was somehow misleading because an owner of the hex had to become an attacker once again, though he didn't aimed at creating or strenghtening a bridgehead. From old WITP days when any crossing triggered shock attack with no ZOC/hex & hexside control, seems as if there was no alternative foreseen that one side can control both hexes and a hexside.




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/25/2011 9:52:46 AM)

Running the save on the new build didn't trigger the attack when the unit moved into the hex.
Real test will be to see what happens in a proper opposed river crossing. It should behave as originally designed.




BigDuke66 -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/25/2011 9:44:41 PM)


quote:

ORIGINAL: michaelm


quote:

ORIGINAL: BigDuke66

quote:

ORIGINAL: michaelm
I was looking at the individual icon type popups. Didn't think you were referring to the lists.
I have had several attempts at getting that popup right.

[edit]
okay. I have tweaked this messages further for next time.

Hey thanks!


One question I have is, are the messages of the different phases during turn processing in anyway needed?
If not I would recommend to remove them as it would considerably speed up the processing of the turn if those messages don't even appear, some phases are so fast done that the message of the phase is longer on screen than the phases itself took to be calculated, sure you can turn off message delay but then all messages are skipped what is not helpful at all.

You can suppress almost all messages by hitting the space bar during the turn. It minimizes the message delay and flies thru any that are displayed.

Well that is the problem it simply rushed thru without giving the player a chance to see the interesting messages and even if he turns it back on the rest of the message bar when entering combat phases or when the processing is thru will clear them all so he can't even scroll back to check what he missed.


Besides that, would it be possible to give air groups and LCUs a text field similar to the name field on the TF screen?
Personally I use that field only to specify the job/target of the TF, making that possible for air groups and ground units would also be quite handy.




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/26/2011 3:08:10 AM)

quote:


Besides that, would it be possible to give air groups and LCUs a text field similar to the name field on the TF screen?
Personally I use that field only to specify the job/target of the TF, making that possible for air groups and ground units would also be quite handy.


The TF name field was never originally used so using it to put in a name was simple.
The name field for the others is already used; it shows currently the name of the group/LCU. It would not be a simple matter to add an additional name and display it.

This is like the original request that we add a Notes field to units. For whatever reason I can't recall, it was not done.




medicff -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/26/2011 7:34:27 PM)

I am very appreciative of the Betas making game so much easier, squashing bugs, and getting some tweaks in.

Idk if you are working on the AI at all or if simple fix but speaking of river hex crossings.

The AI is continually throwing units two and three at a time at singers river crossing but easily destroyed in the combat and then retreating with no bridgehead established.

Can you get the AI to coordinate the attack better waiting for a large group to attack at once? At least after the first recon attempt. This is on scenario two with Betas updated.

Thanks
Pat




Alfred -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/26/2011 11:23:00 PM)


quote:

ORIGINAL: medicff

I am very appreciative of the Betas making game so much easier, squashing bugs, and getting some tweaks in.

Idk if you are working on the AI at all or if simple fix but speaking of river hex crossings.

The AI is continually throwing units two and three at a time at singers river crossing but easily destroyed in the combat and then retreating with no bridgehead established.

Can you get the AI to coordinate the attack better waiting for a large group to attack at once? At least after the first recon attempt. This is on scenario two with Betas updated.

Thanks
Pat


That is Andy Mac's territory.

Alfred




medicff -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 10:45:39 AM)


quote:

ORIGINAL: Alfred


That is Andy Mac's territory.

Alfred


Thanks

I have one interface request.

Viewing the Ground Units list screen where you can either switch from hard info to soft info (Exp, Mor, etc).

When you toggle the hard/soft it always resorts the units to a predefined filter. I would like to see that the unit sort stays as pretoggle so that if you want to see who is the most fatigued unit and sort in that manner when you switch back to hard they will stay at the top and you can change their ops/combat status easily.

Just a thought if easily possible.

Thanks




PaxMondo -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 12:07:46 PM)


quote:

ORIGINAL: medicff


I have one interface request.

Viewing the Ground Units list screen where you can either switch from hard info to soft info (Exp, Mor, etc).

When you toggle the hard/soft it always resorts the units to a predefined filter. I would like to see that the unit sort stays as pretoggle so that if you want to see who is the most fatigued unit and sort in that manner when you switch back to hard they will stay at the top and you can change their ops/combat status easily.

Just a thought if easily possible.

Thanks

Michael addressed this previously. It has to do with the fact that sorts occur based upon the columns. When you toggle back and forth the sort criteria is applied. He looked into it and I beleive there is nothing further he is able to do.

This is really old code by today's game standards. It miraculous some of the things Michael is able to achieve.




seille -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 1:40:24 PM)

Michael,

I use this thread to report a bug since i use 1108p08 beta.

In my game i changed some late war R&D facs (still repairing, no producing) to mid war models.
I got some facs with 0(1) which is ok. But these factories i was NOT able to expand from industry screen
even HI and supply were available.
Sent a turn to Damian since he seem to be THE expert for R&D and economy and he figured out that you can expand these new 0(1) factories over
the base-factory screen, but not over industry screen.
After the initial 0(1) factory was expanded by the base-fac sreen expansion was possible over the "normal" way, the industry screen.
So obviously a bug.




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 1:54:28 PM)

Can you please post a save for me to look at quickly?

[EDIT]
Never mind it is already fixed in next build.




n01487477 -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 2:13:06 PM)

Michael -
I'm sending on behalf of Seille ... PM sent with other details...

[edit] That was quick ...[;)]




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 2:23:30 PM)

Issue was that it didn't handle a industry of size 1 on the IM screen.
It has logic now to work out what the maximum increase can be, and starts checking from 2 to that value to see what the real max value is before it can't expand.
And then subtracts one from the number it failed on.

So in this case it didn't need to do the test as 1 was the starting maximum, but it still did the minimum test (max = min(max, 1-1)) which made it zero.






seille -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 2:29:58 PM)

You guys are both VERY fast. Many thanks.

@Damian
Pls do not forget to look at my economy.
R&D is important to me.
AND maybe you can explain why the global tab of tracker shows other HI surplus than the Chart tab.
There is always a big difference. Actually about 2500 Hi plus the turn in "Chart" vs. about 1700 in "Global"
Shouldn´t be both values the same ? Where do i "lose" the difference in HI points ?




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 2:35:06 PM)

I just ran the save and those factories along with a number of other (1)0 factories are all showing the expand buttons.




PaxMondo -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 4:02:56 PM)


quote:

ORIGINAL: michaelm

I just ran the save and those factories along with a number of other (1)0 factories are all showing the expand buttons.

THANKS!!

I never even had a chance to post the error! <again>

[&o][&o][&o]




cantona2 -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/27/2011 10:30:25 PM)

Hi  A few questions if I may

Hoplosternum and I are playing a Babes game under 1108p7 version and I/We have several questions.

1) No matter what settings Hoplo or myself put for the speed of messages (the ones detailing the air searches and spotting ones) whizz through at 0.1 speed. Any change in the settings results in changes in game at all. Is this patch related?
2) I no longer have a bombing accuracy % for my bomber units, again is this patch related?

Thanks




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p9b updated 23 August (2nd part) (8/28/2011 3:58:42 AM)

quote:

ORIGINAL: cantona2
1) No matter what settings Hoplo or myself put for the speed of messages (the ones detailing the air searches and spotting ones) whizz through at 0.1 speed. Any change in the settings results in changes in game at all. Is this patch related?


Not due to patch.
The "Message Delay" setting (2nd one in the list in the in-game preferences) controls these. The Japanese player's setting controls this from memory in a PBEM. The Allied player should, I think, be able to set his during his orders turn to take affect in the replay.
quote:


2) I no longer have a bombing accuracy % for my bomber units, again is this patch related?


Not due to patch.
The % shows up after turn 30 and if the unit has dropped bombs. Not sure if fragments have this, though.





FatR -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/28/2011 11:10:36 AM)

I've encountered a strange thing during resolution of the turn attached to this post - mines at Bataan that just damaged my LSD seems unsweepable. At least, the minesweeper TF that hangs there tried to find them for over a week. Is this a bug?

Also, is it intentional that "Show ships due upgrade button" now shows only ships in port with upgrades set to "Yes"?




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108q1 updated 28 August (2nd part) (8/28/2011 11:23:45 AM)

[1108q1]
Fixed Bug not letting land based groups see all plane upgrades [MEM]
Tweaked River crossing for total hex control [MEM]
Added Stacking limit check to army lists - RED location for overstacked [MEM]
Added Show current stacking level if max stack value applies to player on mouseover [MEM]
Fixed Industry Management not expanding (1)x0 size industry [MEM]
Fixed Carry over withdraw type to editor subunits [MEM]




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/28/2011 11:28:51 AM)


quote:

ORIGINAL: FatR
Also, is it intentional that "Show ships due upgrade button" now shows only ships in port with upgrades set to "Yes"?


The upgrades has another set of filters ("Allowed to upgrade/Not allowed to upgrade) that show those set to Yes, or those set to No.




michaelm75au -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/28/2011 11:32:15 AM)


quote:

ORIGINAL: FatR

I've encountered a strange thing during resolution of the turn attached to this post - mines at Bataan that just damaged my LSD seems unsweepable. At least, the minesweeper TF that hangs there tried to find them for over a week. Is this a bug?

Also, is it intentional that "Show ships due upgrade button" now shows only ships in port with upgrades set to "Yes"?


I have tried to download this file 4 times, but it can't be found for some reason.
Can you try attaching again?




Theages -> RE: Patch 06 - Public Beta - Build 1108p3 updated 10 July (2nd part) (8/28/2011 12:43:10 PM)

Using latest beta (q1).
There seems to be display bug on the task force creation screen.
Adding previously converted APDs (standard DDs or CL, CA are OK) to a fast transport TF doesn't increase the shown troop and cargo capacity.
When you try to load troops on the created TF, the correct values are shown.


[image]local://upfiles/24088/955828972A7242629A29F12FD904DE6F.jpg[/image]




Page: <<   < prev  14 15 [16] 17 18   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.421875