problems with 1126b

[witpqs]

ORIGINAL: PaxMondo

ORIGINAL: RichardAckermann

Today I had the same issue again south of Changsha. All units were infantry, and yet there was a detour. Unit speed difference seems to be a major factor, but there may be more behind this behavior.
I might add the issue to my list. In case michael thinks this might be worth taking a look on.

Not all infantry are equal ... check devices ... some can have mot support ...

As noted, these are player errors, nothing to do with the code.

You are playing a game that has been played now for quite a few years. You are not likely to find a bug in your first few days, and definitely not with something as fundamental as movement. These are all player issues ... as suggested before, open this is a more appropriate sub-forum, you will get more assistance.

Devices have no effect on movement, except for devices that make a unit "static" so it cannot move at all. An infantry unit with motorized support devices is still infantry and moves as such.

[RichardAckermann]

ORIGINAL: PaxMondo
As noted, these are player errors, nothing to do with the code.

You are playing a game that has been played now for quite a few years. You are not likely to find a bug in your first few days, and definitely not with something as fundamental as movement.
...

And yet I did so in the past. I discovered I could use just 1 air HQ to have ordnance supplied all over the map using it's fragments.
Along with automatic replacement of the torpedoes using the TOE of the fragments.
A bug michael kindly corrected after my finding with a new beta.
My methods might be distastefull, but occasionally I actually find something. And the fix is benefiting all. (Although I do not dare to estimate if the community believes this to be worth enduring my presence...)

I do not believe it is a player error if the LCU screen tells me:
moving NE direct - and all units arrive in the hex East, but used the travel cost of NE movement.

[witpqs]

ORIGINAL: RichardAckermann

ORIGINAL: PaxMondo
As noted, these are player errors, nothing to do with the code.

You are playing a game that has been played now for quite a few years. You are not likely to find a bug in your first few days, and definitely not with something as fundamental as movement.
...

And yet I did so in the past. I discovered I could use just 1 air HQ to have ordnance supplied all over the map using it's fragments.
Along with automatic replacement of the torpedoes using the TOE of the fragments.
A bug michael kindly corrected after my finding with a new beta.
My methods might be distastefull, but occasionally I actually find something. And the fix is benefiting all. (Although I do not dare to estimate if the community believes this to be worth enduring my presence...)

I do not believe it is a player error if the LCU screen tells me:
moving NE direct - and all units arrive in the hex East, but used the travel cost of NE movement.

It is a known issue but will not likely be changed. I had that discussion with Michael, I believe in the forums here but it was a while ago and I can't swear to whether it was in the forums or in email.

Basically, calculating the movement paths is very intensive. The developers try to keep interactive response as fast as they can, and so do not recalculate things all the time. When a unit has accumulated enough miles to move to the next hex then such a recalculation does occur. And so, it sometimes will look like a unit is moving E but winds up moving SE, or some such. My apologies to Michael if I have too badly butchered his much more cogent explanation.

Now, something else you might notice when you give a unit orders to move only 1 hex. You will see a "(Direct)" indicator. If you then click on the button to make all units to march to the same destination, you will *not* see (Direct) on those units' screens. So if you want all units to move directly into an adjacent hex, it sometimes will be better to give each unit the orders individually. But that should only matter with particular terrain and road configurations that make it less cost for some units to go a different route.

[RichardAckermann]

I have no problem with the fact that there is an issue, or if micheal decides the potential gain is not worth a fix. I experienced that with many, many, games where I found bugs before.
(I did find unknown bugs in famous games more than 16 years after their release)
I do program computer games myself, and I know tiny fixes can take enormous reworking, or increase CPU usage extraordinary. Besides you can introduce 3 new bugs fixing the first - happens to me all the time.
But it's funny how often I read XY was a player error with WITP. It's pretty unique.

[witpqs]

ORIGINAL: RichardAckermann

I have no problem with the fact that there is an issue, or if micheal decides the potential gain is not worth a fix. I experienced that with many, many, games where I found bugs before.
(I did find unknown bugs in famous games more than 16 years after their release)
I do program computer games myself, and I know tiny fixes can take enormous reworking, or increase CPU usage extraordinary. Besides you can introduce 3 new bugs fixing the first - happens to me all the time.
But it's funny how often I read XY was a player error with WITP. It's pretty unique.

Sometimes things are just that, though. [:)]