UFO:Alien Invasion
Archive => Bugs in older version (2.3.1) => Topic started by: PurpleCaterpillar on October 30, 2010, 02:51:14 am
-
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...
-
Do you know how to add a bug on the sourceforge page (http://sourceforge.net/tracker/?group_id=157793&atid=805242)? 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.
-
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?
-
@ 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.
-
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 ?
-
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)
-
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?
-
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.
-
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.
-
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 (http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm)? 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).
-
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.
-
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.
-
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.
-
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 (http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm)? 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.
-
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.
-
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'.
-
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'.
-
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.
-
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.
-
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.
-
... 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. =)
-
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.
-
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...
-
I don't think so. I only work on the 2.4 branch.
Can you test with 2.4 ?