Minor bugs I've noticed

[Curtis Lemay]

ORIGINAL: ColinWright
As I said, on turn one they will be -- either that or something remarkable is happening in my 'Storm over Holland' scenario. It only happens if the game opens and immediately discovers hexes have to have their ownership changed -- to give an imaginary example, there's a force 1 unit in hex (0,0) and hex (0,1) was set to force 2 ownership in the editor. If there's a railway in hex (0,1) it'll be destroyed when the game starts regardless of the rail damage setting. Could be a matter of the program carrying out rail destruction using the default setting first and looking at the event list second.

If you mean patrols on turn one, I checked that. Remember that patrols are conducted after the events are effected. Any chance you're doing that 50% guerrilla thing? Then you might need to make sure the guerrilla event is later in the event list than the event that sets RR destruction.

[ColinWright]

ORIGINAL: Curtis Lemay

ORIGINAL: ColinWright
As I said, on turn one they will be -- either that or something remarkable is happening in my 'Storm over Holland' scenario. It only happens if the game opens and immediately discovers hexes have to have their ownership changed -- to give an imaginary example, there's a force 1 unit in hex (0,0) and hex (0,1) was set to force 2 ownership in the editor. If there's a railway in hex (0,1) it'll be destroyed when the game starts regardless of the rail damage setting. Could be a matter of the program carrying out rail destruction using the default setting first and looking at the event list second.

If you mean patrols on turn one, I checked that. Remember that patrols are conducted after the events are effected. Any chance you're doing that 50% guerrilla thing? Then you might need to make sure the guerrilla event is later in the event list than the event that sets RR destruction.

There are patrols -- but they're going the wrong way. The Dutch have no guerilla effect -- and it's their units gaining control of adjacent hexes at the start of the scenario that causes rail destruction. I'll be sending Jamiam a test scenario or the original if this turns out to be one from the journal of irreproducible results. I'd have to undo my fix in the original anyway, as I already dealt with the problem by setting all unoccupied rail hexes adjacent to Dutch units to Dutch ownership.

[ColinWright]

Emailed test to Jamiam.

[JAMiAM]

I need to get Ralph to confirm this, but it looks like he had switched the order of event resolution, and local patrols, in 3.1.0.9. This was to fix the problem with events not firing properly when they were supposed to be triggered by ownership changes and those changes were the result of hex conversions. However, it's clearly broken in this case, since the RR destruction event (setting it to 0) doesn't fire until after the adjacent hexes are converted in turn one and the hexes are converted into broken rail.

Thanks for finding this, Colin.

[Curtis Lemay]

ORIGINAL: JAMiAM

I need to get Ralph to confirm this, but it looks like he had switched the order of event resolution, and local patrols, in 3.1.0.9. This was to fix the problem with events not firing properly when they were supposed to be triggered by ownership changes and those changes were the result of hex conversions. However, it's clearly broken in this case, since the RR destruction event (setting it to 0) doesn't fire until after the adjacent hexes are converted in turn one and the hexes are converted into broken rail.

Thanks for finding this, Colin.

He must have switched it back in 3.2.1.0 then, because I'm not seeing it. I specifically asked him if he had done just that on the dedicated board - no answer.

[JAMiAM]

ORIGINAL: Curtis Lemay

ORIGINAL: JAMiAM

I need to get Ralph to confirm this, but it looks like he had switched the order of event resolution, and local patrols, in 3.1.0.9. This was to fix the problem with events not firing properly when they were supposed to be triggered by ownership changes and those changes were the result of hex conversions. However, it's clearly broken in this case, since the RR destruction event (setting it to 0) doesn't fire until after the adjacent hexes are converted in turn one and the hexes are converted into broken rail.

Thanks for finding this, Colin.

He must have switched it back in 3.2.1.0 then, because I'm not seeing it. I specifically asked him if he had done just that on the dedicated board - no answer.

Ralph's in post-patch recuperation mode, and is scarce. I emailed him on it, too. Forwarded Colin's test scenario to you, to verify under 3.2.1.0. Thanks.

[ralphtricky]

ORIGINAL: JAMiAM

I need to get Ralph to confirm this, but it looks like he had switched the order of event resolution, and local patrols, in 3.1.0.9. This was to fix the problem with events not firing properly when they were supposed to be triggered by ownership changes and those changes were the result of hex conversions. However, it's clearly broken in this case, since the RR destruction event (setting it to 0) doesn't fire until after the adjacent hexes are converted in turn one and the hexes are converted into broken rail.

Thanks for finding this, Colin.

I'm pretty sure you're right. I've isolated the code, and I should be able to disable that for turn 0

[ralphtricky]

ORIGINAL: JAMiAM
Ralph's in post-patch recuperation mode, and is scarce. I emailed him on it, too. Forwarded Colin's test scenario to you, to verify under 3.2.1.0. Thanks.

It's more post-taxes recuperation, plus we had a major virus outbreak at work so I had to re-install my work computer, plus all the post-mortems, etc. Things are finally dying down again.

[JAMiAM]

ORIGINAL: ralphtrick

ORIGINAL: JAMiAM
Ralph's in post-patch recuperation mode, and is scarce. I emailed him on it, too. Forwarded Colin's test scenario to you, to verify under 3.2.1.0. Thanks.

It's more post-taxes recuperation, plus we had a major virus outbreak at work so I had to re-install my work computer, plus all the post-mortems, etc. Things are finally dying down again.

Whatever the storm, it's still good to see your head above water.[:)]

[Shawmut]

There are no minor bugs if they kill the game enjoyment. [:@]
The homing back to a unit that starts the ping pong syndrome going no place; click for a next unit and it goes back to some insignificant dorfling and never getting out of the trap.
Airborne units that won't land. Oh yes, my pet peeve the Transport Helo's. [:(]

Enclosed my recent moaning regarding the problems I encountered in Market Garden.
(Note that I tried to neutralize my intemperant tone at its end) [8|]

Airborne Failure seems to be my boo-hoo! I've allowed you guys (developers, I guess) the laughs regarding my issue with the "Transport Helo's, etc.". So I just can't use about 10 - 15% of the program. Who gives a damn about that.
So today, using "Market Garden" I found a few airborne units won't land. (Someone during the scrimmaging over the hehlos cited the plane that flew around the world for a few days.) Oh yes, the mouse is clean, all wires are connected and most of the checklist someone will run the damn consumer through has been checked. Even the scenario's weather was checked.
Maybe, I'm missing a patch that has corrected this in the months I've had it. Maybe it's just contempt for the consumer. I'd be more than pleased to find I'm wrong about that.
But, add on the tendency of this game to have little hidden agenda clusters. One game I stopped because of each effort to go to the next item, it homed back to a do-nothing unit whenever I tried to go beyond it; great for ping-pong.
I have read and re-read the manual (in English from whatever the originanl language was) and these issues are not accounted for.
I must submit that I love this game (lest my cynicism obscure the respect I have for all of you who have made the effort to provide and advise), but nothing ruins the joy than to have settled in and then BLAATTT.

[JAMiAM]

Manual section 9.1.8 Replacements, reads in part:

Reconstituted Airborne and Glider units will keep their special icons, but are no longer eligible for Airborne Movement.

Note that if one, or more, sub-units of a parent unit have been destroyed and reconstituted, then recombining them will ruin the airborne movement capability for the parent units, as well as all subsequent split sub-units from that parent unit.

[ralphtricky]

ORIGINAL: Shawmut
There are no minor bugs if they kill the game enjoyment. [:@]
...
The homing back to a unit that starts the ping pong syndrome going no place; click for a next unit and it goes back to some insignificant dorfling and never getting out of the trap.
...

Actually, the next Unit functionality is fairly new. It cycles though the formations and their assiciated units. If you keep the formations together it works better. A lot of people don't use it, but like to move the units individually. A later patch may try to modify this behavir to something else, although to do it the way I want is going to take a while, it's going to require some modifications to the save file, etc.

Airborne units that won't land.

I hadn't heard about this one???

[Shawmut]

Thanks Ralph.
Encouraging to know its being worked on.  I appreciate just knowing that.  In the meantime, there's a reality to it.  I guess I'll just be alert and think to myself, like in real life, "Now what's he (what're they) doing here and jump to where I know I should be.
 
As to the ever-airborne, airborne units:  It's occurring in Market Garden 44`, Turns 3 and 4, an 82'd unit and a Polish unit just won't land.
 
On the human side I can understand it.  I kept fighting with a Sgt.Maj. (10thSF) telling him the idea of me going Airborne was nonsense and that I was afraid of heights.  After a few months we were on a mountain routine (I was MI, not SF), he caught me up and said, "Look around you Schultzi.  It's not the heights, it's the depths you're afraid of." [X(]

[JAMiAM]

ORIGINAL: Shawmut
As to the ever-airborne, airborne units:  It's occurring in Market Garden 44`, Turns 3 and 4, an 82'd unit and a Polish unit just won't land.

In case it gets spam blocked, this is cut and pasted from the email reply I sent in response to your file submission:

Hi David,

I'm suspecting that perhaps the problem that you were
having with being unable to drop units was due to
trying to drop an artillery or HQ unit into an
uncontrolled hex. You must first control one of those
hexes before you can drop those two unit types. In
short, anything with a ranged capability listed in the
unit panel, i.e., an "R:num" value.

Regards,
James

[ralphtricky]

ORIGINAL: Shawmut
Thanks Ralph.
Encouraging to know its being worked on.  I appreciate just knowing that.  In the meantime, there's a reality to it.  I guess I'll just be alert and think to myself, like in real life, "Now what's he (what're they) doing here and jump to where I know I should be.

I went ahead and applied the same next combat logic that's in the combat planning dialog to the next unit logix. It was surprisingly difficult to get right. Unless the beta testers finds some flaw in it[:(] it should be in the next patch.

Ralph