Calculation of TUs for movement - erroneous (sometimes)

[Duke]

About revisiting the prob:

First, I noticed that sometimes spots appear to be "un-walkable" - the movement cursor appears in blue - even though they're walkable.
(These spots are 100% walkable - If the actor moves a bit first, the problematic spots become a valid destination again - so it's a bug).

I thought this statement of yours was referring to situations without a 2nd soldier standing in the way ie. just reaching the edge of the pre-calculated table.
And 'revisiting' translates to 'watch while playing'.

[Duke]

I'd add a re-calculation upon the event of "an actor stopped moving", just to cover this particular "bug".
If such an event already exists and triggers other events, then the fix should be rather trivial (just a hunch).
It makes sense also because sometimes actors would stop short of their destination, due to "surprisingly" impassable spots (occupied by a newly spotted civilian\enemy).

There is such an event, at least for regular completion of the move. I have yet to figure out if it also covers those interrupted moves. atm I can't even link the game

However, this solution would also not solve the following problem:
If a player selects a 2nd actor while the 1st is still moving, he probably does that to figure out where to send the 2nd to. Even with the suggested fix, the TUs displayed for the 2nd actor are wrong while the 1st is still moving.

Re-calculating after every single step of the moving actor is not really an option. TUs displayed would be perfectly correct, but might change with every step of the moving actor, confusing the player. Not to mention performance.

The only *clean* solution imho is to disallow 'new selection while moving'.

[PurpleCaterpillar]

There is such an event, at least for regular completion of the move ...

Good, then an additional call to "calculateMovingCostInRange(actor[k])" (or what's-its-name), somewhere inside the method which handles this event, would suffice IMO.
See below why I think so.
Also, it would be wise to use this opportunity to verify the correctness of behavior for interrupted moves.

If a player selects a 2nd actor while the 1st is still moving, he probably does that to figure out where to send the 2nd to. Even with the suggested fix, the TUs displayed for the 2nd actor are wrong while the 1st is still moving.

That's right, but:

• We're talking about a very short period of time, during which the player is merely misinformed, and not always, even.
• The moment the first actor stops moving, the (preview) calculation will be corrected, the numbers updated, and we're good to go.
• There's much gain in still allowing the selection:
  1. When the first actor starts moving, you select the other.
  2. You move the cursor to the intended destination, or roughly at its vicinity.
  3. The moment the first actor stops moving (all in all, takes less than 5 seconds from start to stop) you make the minor change and click away.
  IMO it still speeds up gameplay considerably, and feels more polished in terms of user-friendliness.
• This proposed solution is probably the easiest to implement, if my guesses are correct. (I'm really holding myself from opening the sourcecode myself now... so much other stuff to do  =/)

Re-calculating after every single step of the moving actor is not really an option. TUs displayed would be perfectly correct, but might change with every step of the moving actor, confusing the player. Not to mention performance.

Agreed, ten time over. Never even crossed my mind.

The only *clean* solution imho is to disallow 'new selection while moving'.

But here, sir, we have a disagreement...  See bullet #3 in the list above. =)
If you're leaning heavily towards disallowing it altogether, I urge you to first post a poll, asking your players for their preferences.
Something simple, such as "Do you usually select the next soldier you intend to move, while the current one is still moving?" -- "Yes\No".
(and give it 2-3 weeks to gain enough answers)

I don't presume to speak for "the people", but for me, not being to do so would be like an unnecessary handicap.

[mor2]

i would like to point out that right now its possible to queue movements, by selecting the next actor and giving him an order and it will execute and it saves a lots of time during the deployment phase (first few turns) , so please lets avoid the technical solution of disabling this feature.

also, i would like to stress that mostly it shows the amount of TU's or at least i never noticed that i actually lost TU's, with the only exception, when one wide square path involved, soldier may take the scenic route around when fat clicking.

If a player selects a 2nd actor while the 1st is still moving, he probably does that to figure out where to send the 2nd to. Even with the suggested fix, the TUs displayed for the 2nd actor are wrong while the 1st is still moving.

no, usually in combat with RF reservation, positioning and shooting in mind, i dont have enough Time to select my next actor  for this to be a problem, on the other hand during the deployment phase, there is no thinking or planing, i already played this map and i know exactly where my soldiers are heading and i am trying to get there as fast as possible.

which why i mentioned the one square wide path's, i prefer not to but dont care if i had to fast click once more to exhaust my TU's, because at this stage i dont even look at them, i just fast clicking toward a general direction but i do care if my soldier runs on a detour or i have to start re selecting soldiers until pathfinder updates (or if one of them eneds his turn in that spot but this case is unrelated).


EDIT:
 so to sum it up, lets wait on cutting down features, if there is a possible solution great if not lets try to avoid the problem in the first place.

[dodon]

The only *clean* solution imho is to disallow 'new selection while moving'.

I don't know if the data is available or if this interferes with other parts of the code, but when the forbidden list is calculated, the current possition of a moving actor could be replaced with its destination. With that we get the right pathing informatin after the selection.

[PurpleCaterpillar]

... the current position of a moving actor could be replaced with its destination ...

This could work, as long as interrupted moves are also taken into consideration.
I'm pretty sure it would be harder to code and debug (I can imagine mysterious bugs this could cause),
but it's definitely "cleaner" than simply updating the calculation when an actor stops.

I think Duke assigned this bug to himself, so it comes down to what he thinks should be done.  =)

[Duke]

Your strong vote for keeping actors selectable while others are moving convinced me, so I just committed the fix. Happy testing.

@dodon: smart idea But looking at the code, it doesn't seem to fit well in there. We don't store the projected pos anywhere other than in the events themselves.

[PurpleCaterpillar]

Duke,
was your fix included in 2.3.1?

The bugtracker doesn't show any changes to this item, and in 2.3.1 the issue persists.
So if it's supposed to be included in this version, it didn't work.

Just FYI...

[Duke]

I don't think so. I only work on the 2.4 branch.
Can you test with 2.4 ?