Discussion with gamedevs: StartMoving and StopMoving

[Google_Frog]

From this ticket -> http://springrts.com/mantis/view.php?id=4458

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?

Here is the question more generally. Should there ever be a situation in which a unit walking along the ground triggered StopMoving more recently than it triggered StartMoving?

[smoth]

The unit should first trigger LANDING, then start moving once he begins movement on the ground.

[PicassoCT]

If a Unit flies through the air, the Units is not moving as in moving on its own accord (which is the basic information that the function delivers when beeing called).

So correct would be StopMoving on getting airborne and StartMoving on hitting the ground again.

But many will miss the trashing feet while units fly through the air. So leave things as they are?

[Anarchid]

But many will miss the trashing feet while units fly through the air. So leave things as they are?

There would be no feet-thrashing if the unit was propelled while not moving currently, not even if unit received a move order while flying.

[FLOZi]

Here is the question more generally. Should there ever be a situation in which a unit walking along the ground triggered StopMoving more recently than it triggered StartMoving?

Categorically, no.

[code_man]

Dont wanna derail stuff, but on the side can we expect callins for velocity/direction changes in the future?

[PicassoCT]

and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop
and its turning on spot, going slightly forward ,stop and its turning on spot, going slightly forward ,stop

The reason is actually that those calls would massively spam Engine and Lua communications..
Speed can be derived via positions and time.
Turning can be estimated using the heading. Its work but doable work.

Sorry, if i was a little harsh. Have not to fond memorys battling those issues.

[Silentwings]

Here is the question more generally. Should there ever be a situation in which a unit walking along the ground triggered StopMoving more recently than it triggered StartMoving?

I have seen those little kbot legs flailing wildly as they fly through the air and I wouldn't want to lose that either.

I think its true that, when a unit hits the ground whilst having a move order, it doesn't necessarily come to a stop before it "starts" moving, so in that situation it does continue moving without stopping so I would not have expected StartMoving to be called. But I don't have a strong opinion here. As long as whatever results from this doesn't break existing behavior (which works fine for me), I don't mind.

[Jools]

You can make a cob->lua-callin that is sent when the unit's velocity falls short of a certain value.

[smoth]

This is about a unit flying through the air?

why not write a function like:

Code: Select all

CheckMoveStatus()
 if inwater 
    return water
 elseif in air
    return air
 else
    return ground
 end
end

and just call that from your movecontrol. I don't see why the engine needs to handle this. some people may want startmoving to trigger while the unit is in the air.

it feels like a gamedev doesn't want to do the work of adding it to his scripts.

[Google_Frog]

The problem is not gamedev lazyness because it is really easy to write such a script and I have already done so. It cleanly replaces StartMoving and StopMoving within the LUS.

https://github.com/ZeroK-RTS/Zero-K/blo ... Moving.lua

The issue is that reimplementing things in lua is slow. If the callins worked to start with they would not need reimplementing.

[smoth]

The callin works, the unit is moving. What you want is a new bit of code to check something else that is easily written in lua.

[FLOZi]

The callin works, the unit is moving. What you want is a new bit of code to check something else that is easily written in lua.

No, no, no no no!

[Google_Frog]

Perhaps smoth you should answer this question:

Here is the question more generally. Should there ever be a situation in which a unit walking along the ground triggered StopMoving more recently than it triggered StartMoving?

[smoth]

I didn't answer that question because you didn't word it clearly. It feels loaded.

The callin works, the unit is moving. What you want is a new bit of code to check something else that is easily written in lua.

No, no, no no no!

He didn't want to use lua properly to solve the issue in question.

[FLOZi]

I didn't answer that question because you didn't word it clearly. It feels loaded.

The callin works, the unit is moving. What you want is a new bit of code to check something else that is easily written in lua.

No, no, no no no!

He didn't want to use lua properly to solve the issue in question.

Please stop claiming everyone is lazy and try and understand why having a callin work as expected is better than running a million polling loops.

Hint: OTA 'MotionControl' loop is the worst way to control motion.


edit: Sorry. I just find this discussion nearly as irritating as this one

[Google_Frog]

I didn't answer that question because you didn't word it clearly. It feels loaded..

Then ask for clarification or write a longer answer than 'yes' or 'no'.

[Silentwings]

... having a callin work as expected is better than ...

Imo thats an ambiguous statement since in this case its clear that different people expected it to do different things - Start/StopMoving does already work as I would have expected it too (from the name). So ~ maybe the real issue is lack of documentation of expected behaviour

It seems quite reasonable to me that people could want actions to occur either (1) when unit actually starts moving and/or (2) when unit lands on ground - obviously to have both these options requires two different situations in LUS.

[FLOZi]

Probably http://springrts.com/wiki/Animation-Lua ... #Passenger should be extended

[smoth]

Then ask for clarification or write a longer answer than 'yes' or 'no'.

I just did. I didn't say yes or no, I said I skipped that question. you still have not clarified.

Please stop claiming everyone is lazy

it feels like a gamedev doesn't want to do the work of adding it to his scripts.

I didn't say lazy. I didn't make an outright accusation. I said it feels that way. If we are talking zk/bar unit scripts, they have never really been cleaned up and are not a unified script like mcl or GBStestgame. So it is a lot of work for them to add this sort of code retroactively and test it in all units. Instead of doing that it *FEELS* like they are expecting the engine to automatically do it. This would result in unwanted behavior being forced in all non *A projects that might NOT want his desired behavior.

try and understand why having a callin work as expected is better than running a million polling loops.

the callin IMO is working as expected. The unit DID start moving and is moving. The unit did not STOP moving. it is moving but in the AIR.

Hint: OTA 'MotionControl' loop is the worst way to control motion.

and I DON'T USE THAT but they are using OTA based scripts so they probably still have that going on.

edit: Sorry. I just find this discussion nearly as irritating as this one

I didn't get offended/upset flozi. I am just annoyed that yet another feature is being requested for a specific game with no consideration on how it would potentially effect the flexibility of the code for other game projects. Spring is going to regress to the *a or zk engine again unless people raise these points.