Calculation of TUs for movement - erroneous (sometimes)

[PurpleCaterpillar]

I've noticed that sometimes the calculation of TUs required for movement is erroneous.
Please see the attached screenshots for the easy graphic explanation.

I could only determine for sure that it happened on movement that:

• would exhaust all the remaining TUs,
• starts from standing-up position, and ends in one,
• happens on the maps: Africa, +city (the 7-story parking lot), in certain areas of the map.

Short explanation:

• When hovering over the target spot for moving, the calculation states the movement would require all of the actor's TUs. e.g. 32/32.
• However, after moving to that spot, it's clear that some TUs haven't been spent (and not due to reservation). e.g. 2/32.
• The remaining TUs can be spent normally.
• If the calculation is done "manually" : 2*<x adjacent tiles> + 3*<y diagonal tiles> : then it's evident that the initial calculation was mistaken, so the remaining TUs are correct behavior.

Attached:

• Example images, taken from the "Africa" map. View them in order (1,2,3), to illustrate the point under discussion.
• A savegame just before the mission starts.

BTW, this should be a low priority bug (IMO) since eventually the bug misleads the player, but doesn't cause actual harm.
TUs are eventually spent correctly.


EDIT: my attachments worked fine, so I removed a request for advice on adding images to the post...

[H-Hour]

Do you know how to add a bug on the sourceforge page? That will ensure it doesn't get lost in time. You can just throw a link to the forum in the description so you don't have to type it all out again.

And nice job documenting it.

[dodon]

I noticed this behaviour (on other maps).

Do you select a new soldier while the active one is moving?
Or better, do you remember which soldier moved while you selected the one in the first picture and where did it start?

[PurpleCaterpillar]

@ H-Hour :
I don't know how, yet, but I'm sure it's no big deal... I'll do it.

@ dodon :
I'm convinced no actors were selected during another actor's movement, on that turn.
I noticed the strange behavior on the previous turn, because the "photographed" actor was following another actor, "right on her tail".
And they both have exactly 32 TUs.

So I just "caught it" on they following turn, making sure I'm extra careful not to do anything unusual, and moving actors one at a time.

[Duke]

If the calculation is done "manually" : 2*<x adjacent tiles> + 3*<y diagonal tiles> : then it's evident that the initial calculation was mistaken, so the remaining TUs are correct behavior.

The walk on the screenshots looks completely straight, no diagonals there.
Or did the actor do any zig-zag move ?

[PurpleCaterpillar]

Duke,
Indeed, there was no diagonal movement in the example (screenshots).
Therefore in the example: x=15, y=0.

I simply noticed this bug on other occasions, where diagonal movement is involved;
 mostly on the +city map, on the first turn, when exiting the Firebird dropship.
Providing the calculation in that post is mostly supposed to show that "I know how it's meant to be calculated"...  =)

Edit:
I've given it a second thought, as your question made me think of a possible source for this bug:

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).
Sadly, this is inconsistent: Usually the problem won't arise for the previous actor nor for the next one, and I can't identify a single specific actor who's affected.
Anyway, I've seen this bug had been reported before (for the +city map) so I won't go on about it.

Now, what if for this miscalculated movement, the situation is as follows due to a "buggy spot" (which is actually walkable):

{ Legend:
  A      : Actor (initial position).
  x       : "buggy spot".
  -       : Adjacent movement.
  / or \ : Diagonal movement.
  o       : Destination.
}

A - - - - - - /x\ - - - - - o

So that the preview-calculation is considering the buggy spot as an obstacle to move around, thus using < 3 TUs * 2 diagonal steps > ;
which explains the "surplus" 2 TUs, which remain when the actual movement's calculation is performed as it should: < 2 TUs * 2 adjacent steps > :

A - - - - - - - - - - - - - o


(mmm long edit... But if I managed to explain myself coherently, I think this can be a good initial direction for debugging)

[H-Hour]

Anyway, I've seen this bug had been reported before (for the +city map) so I won't go on about it.

The only movement bug I'm aware of for +city is where the soldier can walk through a wall at the very top of one of the stairways, and I've just learned that is fixable. Is there another movement bug in that map that you know of?

[mor2]

not a bug, but the cement barriers near the spawn has only one space between them, which "fucks" the path finding because inpatient people like me tend to select the next soldier before the first one has finished his movement.

[Duke]

PurpleCaterpillar,

the way you describe the bug and your theory makes me think that you are a coder of some sort. Correct ?

The non-walkable places 'at the end of TUs' are a known issue and a result of an optimization we didn't implement perfectly. Fixing it will cost performance ==> low priority.

Your theory is logical and your conclusion is almost correct(see below). However, I already had that in mind when I asked that question. ==> you could have saved some work if you just answered my question. I guess I should write a wiki article "How to deal with Duke" someday. Well, consider it a nice round of brain-jogging for you

The code uses
- a routing table (which places are walkable. Constant !)
- a pathing table (where an actor can walk with his TUs. Dynamic.)
- the 'forbiddenList' (places occupied by other actors. Very dynamic.)

My current theory is that either the pathing table or the forbiddenList is not updated when it should be. That is, the 'following' actor still thinks he has to walk around his 'leader'.

Ok, let's try again
I assume the situation (leader/follower/exact location) is reproducible in skirmish. If you do so with 'confirm actions' ON, you should be able to create a screenshot of the designated path for that walk.
Please do so and post it here.

[PurpleCaterpillar]

the way you describe the bug and your theory makes me think that you are a coder of some sort. Correct?
The non-walkable places 'at the end of TUs' are a known issue and a result of an optimization we didn't implement perfectly. Fixing it will cost performance ==> low priority.

Guilty as charged...  =)
It's a shame it'll cost in performance, but I'm well aware of such tradeoffs, and I trust it's been an important one.
By the way, which algorithm are you using? Dijkstra's? Or something custom?
(Dijkstra's algorithm would make sense here due to varying costs... Especially if a future feature would be higher cost for moving uphill\through snow, for example).

... you could have saved some work if you just answered my question ...

I thought I did... The actor in the screenshot didn't zig-zag at all.
The additional stuff in the Edited post was provided after I've given it some more thought.

... If you do so with 'confirm actions' ON, you should be able to create a screenshot of the designated path for that walk. Please do so and post it here.

I've never used 'confirm actions' until now, so I'll try that, and post a follow-up.


Anyway, to sum it up for now: As I understand, currently the suspect is me:
When an actor is selected (let's call him Bill) while another one was moving (let's call her Anna), then:

• Anna's current position (which will be vacant soon, since Anna is moving) is used for Bill's movement's TU cost calculation,
  since the 'forbiddenList' indicates Anna is occupying that position.
• When Bill finally moves, Anna's final position is used to determine Bill's path-finding and movement, so the correct calculation is performed.

I'll try to find an example where I'm 100% sure that I didn't select an actor while another one was moving.
Otherwise, it would seem that mor2 and dodon caught me red-handed right from the start... =)
(However, if that's indeed the issue, I think I understand how it could be corrected).

[PurpleCaterpillar]

Alright, I'm convinced I've figured it out...
dodon and mor2 had hit the mark right from the start. It happens only when selecting an actor while another one is on the move.

To conclude:

• I'm convinced no actors were selected during another actor's movement, on that turn.

  That was a lie... Well, I remember I was convinced, but all current evidence suggest it was a lie.  =\
  Anyway - well done, dodon and mor2.
• The source of the problem is probably as I described in my last post (the "Anna and Bill" bit). It makes sense now and I can reproduce it at will.
• Even though it's all my fault, I still believe this is a (minor) bug which could be fixed:
  Either refresh the calculation when the moving actor had finished moving - or disallow selection while another actor is moving.
  I vote for the first option, by the way...

Here's one example of the suggested path, which bypasses a "buggy spot" (see the blue outline?).
This "buggy spot" was intentionally created by selecting the current actor while another one was moving through the said spot.

[dodon]

I'm convinced no actors were selected during another actor's movement, on that turn.

That was a lie... Well, I remember I was convinced, but all current evidence suggest it was a lie.  =\

No problem with that.
You actualy managed to refine a vague bugreport to reproducable behaviour.

not a bug, but the cement barriers near the spawn has only one space between them, which "fucks" the path finding because inpatient people like me tend to select the next soldier before the first one has finished his movement.

Cramped positions are a problem - it happened to me once or twice in a harvester.
As a workaround either move one step or select an other actor

The code uses
- a routing table (which places are walkable. Constant !)
- a pathing table (where an actor can walk with his TUs. Dynamic.)
- the 'forbiddenList' (places occupied by other actors. Very dynamic.)

If I remember that right there are 2 pathing tables (one for the "client" and one for the "server")
Here it seems the pathing table at the client is only updated when a selected actor moves or a new actor is selected.
The best solution would be to update this pathing table if any actor moved. And if that is to time consuming, update the table when an actor reaches its destination.

[mor2]

we can also try to avoid those once square wide paths, where they serve no tactical purpose, for example near spawn point as in the above screenshot, this will greatly reduced such problems.

[Duke]

Guilty as charged...  =)

You know what any admin of any given OSS-project will ask you then, don't you ?
Feel invited.

By the way, which algorithm are you using? Dijkstra's? Or something custom?

The code may look like an A* but it's not. We calculate the optimal TUs for *every* spot reachable with the actor's TUs+2(IIRC). That table is re-calculated when an actor is selected and in a few other situations. I assume this design was chosen because the required TUs for a spot are displayed with the moving cursor.

btw if I am right and the calculation threshold is TUS+2, there shouldn't be any spots falsely shown as unreachable unless we are walking around the ghost of an actor again. You may want to revisit that problem.

I thought I did... The actor in the screenshot didn't zig-zag at all.

You did. You just did much more than neccessary.

[PurpleCaterpillar]

You know what any admin of any given OSS-project will ask you then, don't you ?
Feel invited.

Thanks for the invitation; Naturally it crossed my mind many times during the last 3 years or so,
but - sadly - the level of commitment I can offer ranges from "very weak" to "none whatsoever"... And it keeps dropping as time flows...
Once my situation in that respect changes, however, I'd be happy to contribute.  =)

... We calculate the optimal TUs for *every* spot reachable with the actor's TUs+2 ...

Sounds like a good solution. The best, actually...
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).

This still wouldn't solve the following "problem":
If a move order is issued (destination is clicked) while another actor is moving,
then the calculation would still be (possibly) erroneous until the first actor stops.
However, such irresponsible behavior goes against the strategic spirit of the game, so I wouldn't bother over it. =)

btw if I am right and the calculation threshold is TUS+2, there shouldn't be any spots falsely shown as unreachable unless we are walking around the ghost of an actor again. You may want to revisit that problem.

I think that even if the threshold was TUs+0 you'd still be correct, but without diving into the code I'll just leave it as speculation...
I don't think I understand your comment about revisiting the problem, though. 
For all I can tell, we've pinpointed the exact conditions for this bug, and have a good lead on its source. So it's done.