- http://springrts.com/mantis/view.php?id=4458 "If a static unit is thrown through the air and given a move order in-flight it sometimes moves without calling StartMoving. "
- (a unit is in flight, it is given a move order, it should recieve startmoving? Or should it always call start moving once it is in the air? I am unsure.)
- "If a unit flies through the air, hits the ground and then walks along the ground normally should StartMoving be called when it begins to walk along the ground?"
- (should a unit call start moving after it lands and is walking)
These two statements should be ignored for now. They follow from the more general third statement.
Point 1 mainly suffers from poor wording and assumptions. The wording is because to me "walking along the ground" means the same thing as "moving" (with "flying" being the alternative to "moving"). The assumption is that everyone thinks StartMoving and StopMoving should satisfy an invariant which is closely related to Point 3.
Point 2 is a specific case of Point 3 with the added proposition of a reasonable time to call StartMoving. I realized that proposing a solution was pointless until I figured out whether people agreed with my invariant.
The important thing here is Point 3. The purpose of this question is to check whether people agree with my invariant for StartMoving and StopMoving.
[*] "Should there ever be a situation in which a unit walking along the ground triggered StopMoving more recently than it triggered StartMoving?"
- (the unclear question about stopmoving being called once a unit is already walking(my best guess on what h means))
[/list]
This is the sort of clarification request I needed. I do not see what is unclear about my statement and your question helps guide my clarification. I will be try to thoroughly explain what I mean by that (and probably look annoying condensing).
Ignore the times at which StartMoving and StopMoving. It is sufficient to know that they cannot be called at exactly the same time because this means they can be ordered in time. For each unit you could make a list and on this list note down whenever StartMoving or StopMoving is triggered. Whenever one of these callins is triggered note down that fact at the bottom of your list. The most recent triggering is the one written at the bottom of the list. So I can say that either StartMoving or StopMoving was called most recently. That is what the bit " triggered StopMoving more recently than it triggered StartMoving" means. If StopMoving is written at the bottom of the list it was triggered more recently than StartMoving.
To reiterate; I can abstract away when the calls occur because for this argument I only need to keep track of which of StartMoving and StopMoving was more recently triggered. When they should be called can be a separate argument.
Walking along the ground is how most ground units in Spring travel. It is their normal movement. Give CMD.MOVE to a ground unit and it will do what I had better call walking along the ground.
So back to this in full:
Should there ever be a situation in which a unit walking along the ground triggered StopMoving more recently than it triggered StartMoving?
Every unit has this theoretical list recording StartMoving and StopMoving. Every unit either triggered StopMoving more recently or StartMoving more recently. For my purposes in this particular argument it does not matter when or how in whatever previous situation they trigger these callins, it only matters what was triggered most recently. So the question is whether these two things should ever happen at the same time for a unit:
- The unit is walking along the ground.
- The unit triggered StopMoving more recently than it triggered StartMoving.
I have no idea how to decompose it further. Hopefully that clarifies the statement.
The invariant I have in mind for StartMoving and StopMoving is that if a unit is walking along the ground the most recent call to trigger is StartMoving. Violations of this exploit make the callins useless for triggering animation scripts and movement based abilities because it will lead to skating and exploits. So I think it is a pretty good invariant.