Some water movement tag related criticism

[code_man]

I want to give some feedback on water movement related behaviour, i wanted to mantis it at first, but decided it would be better if i post here first incase there is a reason why things are as they are.
I hope some more experienced game developers can give me input on this and if people agree maybe the engine devs will change them.

• First things first, maxWaterDepth is not be settable in the unitdef, its not a big thing, but its rather impractical.
  Its mentioned on the wiki that its not setable in the unitdef, but why is it mentioned at all there and more importantly why is it not settable when other stuff works just fine?
  While the waterline tag is not available in movedefs, or atleast the wiki says so, which is also a slight inconvenience.
• I noticed is that hover units that enter water move straight into the upright no matter how deep, or rather shallow they are, i think they should only do this when bellow or equal waterline, which looks very odd but also makes unit movements unnatural which may have a minimal impact on gameplay.
Another thing is that weapons refuse to fire in water above [i]maxWaterDepth[/i] or waterline for hovers/ships without [i]FireSubmerged = true[/i], again i think they should only refuse to fire when bellow or equal. Ofcourse the firepoint and turret of the weapon to be fired are above the water aswell, perhaps it might be worthwhile considering the weapon position rather unit position in the water. Its no big issue i suppose, but its still a rough edge having to use [i]FireSubmerged[/i] for every unit that can just move a bit in the water seems absurd. Now there is another case to this thing, what if i want a weapon to be fired only from above a certain depth? My game has infantryman that can swim and dont want them to be able to fire while swimming, but i dont want them to refuse to fire everytime they get their toes wet either. [/*]
• A real WTF moment for me was when i turns out that upright = false in the unidef does not work for hovers but SetUnitValue (COB.UPRIGHT, 0) in the unitscript does the trick, its just nonsense in this instance.
• Another absurd thing is that hover movedefs need the "hover" in their name, it seems like a real shitty method to me, even the old "canHover" tag seems like a better solution to me.

Well these things do not concern me much right now, i thought i mention them because they seem like logical traps, unless there is some deeper sense in these.
I would suggest the game and engine devs to consider these points and im sure there are more issues to be found based on how confusing these things are, i suppose it would warrant a closer look.

But i do have some actual important problems i remain with that really need addressing.

• First, i have a gadget that calls Spring.MoveCtrl.SetMoveDef to turn a non-hovering unit into a hovering one, it works almost fine except two things.
  Spring.MoveCtrl.SetGroundMoveTypeData (unit, "maxSpeed", XXX) XXX does not correspond to the value scale defined in the movedef/unitdef.
• Another is that the unit after having its movedef changed does not move on water, but along under the surface in the water.
  I have tried to use Spring.MoveCtrl.SetGroundMoveTypeData (unit, "floatOnWater", true) gives me "Warning: [SetMoveTypeData] incompatible movetype key for SetGroundMoveTypeData".
• As a small sidenote, i was told somewhen later that Spring.MoveCtrl.Enable was nececary to call, but it seems that Spring.MoveCtrl.SetMoveDef and Spring.MoveCtrl.SetGroundMoveTypeData work just fine without calling these, give the function name i began wondering what the point of it is.

Ok so my problem is that i my unit moves underwater after i change its movedef and that i cant change its maximum speed.

Quite another issue is that i have units that are already hovers but i want them to move slower when on water, if bellow waterline preferable that is, but i dont know how to do this.

Long post, i hope you find my noob gamdev input useful, i just thought i should mention those since what seems illogical is often a cause for trouble.
And answer my last two questions in the least.

[smoth]

could you use highlight

• lists
• like
• this

and quotes

to make your wall of text a bit less frustrating to read?

[Super Mario]

Take the time to format and proofread your post. It increases readability greatly.

[raaar]

with bos/cob, I made amphibious ships that move upright when they float on water, but follow terrain profile when they walk on land.

It's currently possible.

[Jools]

could you use highlight

Don't listen to him.

Please don't use bold font/coloured text etc. A general rule is that the quality of a text is conversely proportional to the amount of bold text it has, because what people think is important is subjective. Please let the reader make his own judgement and treat all text as equal.

If you ask me, you could use italics for proper names or quotes. Or just a slanted typeface. That's how the newspapers do.

... except the tabloid press: they use bold text a lot. But we all know how good they are.

Lists and quotes have their place of course, as long as you remember (1)

• Stupid things will not become
  smart because they are in a
  list.
  
  Smart things, though, can be
  presented beautifully in a list.

Edit: added source
1: From https://tobi.oetiker.ch/lshort/lshort.pdf

[Anarchid]

A list of complaints, though, belongs in a list.

[Karl]

because what people think is important is subjective. Please let the reader make his own judgement and treat all text as equal.

Uh-oh the Sentence Justice Warrior are coming! Thats right, if you don't treat all the texts as a equal living beings
with the same right as a human has you will be jailed for denying it! Oh nooo.

I dont know if you have ever heard/read about the word Emphasis maybe you should consider looking it up.

Don't listen to him.

...If you ask me, you could use italics for proper names or quotes. Or just a slanted typeface.

But "we" should "listen" to you instead? Ok boss.

That's how the newspapers do.

Cool story.

[Google_Frog]

Some more problems:

• The newline after each sentence.
• Lack of consistent structure to separate the points.
• Too informal/stream of consciousness. This style can be reasonable on forums but not within an OP for a technical topic. I find it hard to separate reports and your commentary.

maxWaterDepth is not be settable in the unitdef

It cannot be set there due to how movedefs work.

weapons etc...

Check whether the AimFromWeapon or QueryWeapon piece positions. I am not sure whether AimFromWeapon has to be above water. I have implemented units which can fire non-water weapons while their midpos is underwater. You have full control over whether a unit fires while swimming fire AimWeapon and BlockShot.

[Silentwings]

Nonetheless, several good points - probably mantis is the place to record the bugs. I think at this point you don't get to call yourself a noob game dev anymore.

[code_man]

Damn i kinda fucked it up, wanted to post 3 days ago but deleted my own post accidently after making it, so much for this.

Alright so turned my post into a list, i hope its somewhat better now, but i kept the content the same i figure not much point i fixing it now.
Tough i guess you should get the idea.
Im not used to use forums, as some of you know i guess, i suppose il try to try doing better next time.
But you guys didnt need to derail the thread like this while ignoring the core issues.

with bos/cob, I made amphibious ships that move upright when they float on water, but follow terrain profile when they walk on land.

It's currently possible.

Its the same thing i did with lua, with SetUnitValue (COB.UPRIGHT, 0) in the unitscript.
What bothers me is that upright = false in the unitdef does not work for hovers even tough it does the exact same thing as for non-hovers, on land atleast.

Nonetheless, several good points - probably mantis is the place to record the bugs. I think at this point you don't get to call yourself a noob game dev anymore.

I didnt want to dump a buttload of issues on the mantis that may not actually be problems, hence i wanted to ask first what game and engine devs think.
Well maybe noob doesnt fit, but there is so little i know of yet.

Some more problems:

• The newline after each sentence.
• Lack of consistent structure to separate the points.
• Too informal/stream of consciousness. This style can be reasonable on forums but not within an OP for a technical topic. I find it hard to separate reports and your commentary.

Il take that to note, but just leave it as is now since the thread is already fubared up.

It cannot be set there due to how movedefs work.

Oh well bummer, guess i can live with that.

Check whether the AimFromWeapon or QueryWeapon piece positions. I am not sure whether AimFromWeapon has to be above water. I have implemented units which can fire non-water weapons while their midpos is underwater. You have full control over whether a unit fires while swimming fire AimWeapon and BlockShot.

Both AimFromWeapon and QueryWeapon are over water and refuse to fire, if the unit is in the water.
Can you tell me any more details here? I could make use of this.

It came to me later that i forgot to mention 2 problems.

• If my memory isnt fucked up completely then ships make waves when moving, however seems hovers dont do this even if they move bellow waterline.
  Now its only graphical from my understanding, but its still another icky thing.
• A significant pressing issue for me is that depthModParams subtable is not applicable to hover movedefs according to wiki, which is utter bullshit considering hover units can move in and under water.

Now as said this still leaves me with 2 main problems that i need fixed or my game is going to sink.
And im not going to rest until someone tells me how to fix this.

• As said i cannot use depthModParams, but i need some way to slow down hover units when they move in the water.
  I have been told in #moddev that there are shitty ways to work around this, but have not been told how nor could i find anything on the wiki.
• Also i have a hover unit that simply moves under the water instead of along a constant offset of the water height.
  The pecilure thing in this case is that the unit is not a hover initially but has its movedef set with Spring.MoveCtrl.SetMoveDef.

I know the engine devs are busy and all, but so far working with hover mechanics has been nothing but a bullshit slide into a cespool right from the start.
I cant possibly be the only one who sees it that way and i doubt il be the last one to step into this.
Hopefully devs will review these issues.

[smoth]

The whole upright = false thing where hovers have that auto forced on them is kinda silly, as is the "hover"blah naming convention of the movedef. IMO both are TAisms that, NEEDS, TO, GO.

[Super Mario]

The whole upright = false thing where hovers have that auto forced on them is kinda silly, as is the "hover"blah naming convention of the movedef. IMO both are TAisms that, NEEDS, TO, GO.

Where are the cpp files that contain this? I will attempt to create a patch to remedy this.

[hokomoko]

Where are the cpp files that contain this? I will attempt to create a patch to remedy this.

The movedefs are a taism in the very core of spring, I'd advise against trying to contribute in that specific area until you've clocked more lines in the engine.

[smoth]

Thanks for the assist offer supermario but as hoko said, I would tread lightly there, I once made a change and got nothing but hate for my effort.

[Jools]

The whole upright = false thing where hovers have that auto forced on them is kinda silly, as is the "hover"blah naming convention of the movedef. IMO both are TAisms that, NEEDS, TO, GO.

The upright forcing is one thing but to complain over a variable name is lame.

[Anarchid]

Autodetection of physics based on the name of an entity is a no-no, whether it's TAist or no.

[FLOZi]

The movedef name issue was removed a few versions ago (pretty sure).

[smoth]

The whole upright = false thing where hovers have that auto forced on them is kinda silly, as is the "hover"blah naming convention of the movedef. IMO both are TAisms that, NEEDS, TO, GO.

The upright forcing is one thing but to complain over a variable name is lame.

It isn't a variable name. I is that we are forced to name a movdef hoverXXXXX in order to make something a hover. That is as asinine as using the actual username as the userId in a database.

Flozi: cool, I'd be happy if this is true!

[8611z]

I noticed is that hover units that enter water move straight into the upright no matter how deep, or rather shallow they are, i think they should only do this when bellow or equal waterline, which looks very odd but also makes unit movements unnatural which may have a minimal impact on gameplay.

What do you mean:
Hovers should smoothly go from "tilted on terrain" to "upright on water", depending on waterdepth?
Or the waterdepth at which they 'snap' orientation should be different?

A real WTF moment for me was when i turns out that upright = false in the unidef does not work for hovers but SetUnitValue (COB.UPRIGHT, 0) in the unitscript does the trick, its just nonsense in this instance.

I think this could be removed by tweaking here:
https://github.com/spring/spring/blob/1 ... f.cpp#L545
With SetUnitValue (COB.UPRIGHT, 0) I noticed no bad sideffects and I imagine from pathfinder view it is purely a cosmetic.

Another absurd thing is that hover movedefs need the "hover" in their name, it seems like a real shitty method to me, even the old "canHover" tag seems like a better solution to me.

It is bit less shitty if you keep in mind the name can be set to set all types of moveDef-types, it is not limited to "hover."
But see wiki https://springrts.com/wiki/Movedefs.lua#Tag:name ,it mentions two methodes:
"Prior to 9.50 this had to contain "tank", "hover", "ship" or "boat" respectively for non-Bot types. This is now set using speedModClass. " ( https://springrts.com/wiki/Movedefs.lua ... edModClass )
But on such stuff wiki is sometimes wrong/inprecise, so at top of wiki page is often a link to relevant files. It is worth clicking. Click "history", find this:
https://github.com/spring/spring/commit ... 0d56aa1a08
(or look at changelog)

...i thought i mention them because they seem like logical traps, unless there is some deeper sense in these.

There are many 'traps', imo no use to look for deeper sense, just take things as they are. Maybe some things have historical reasons, but knowing these stories does not really help anything except having learnt some useless detail that is forgotten next day.
Other things might have a reson but if one does not understand it then to just have to expect it.
Or it is someone else's reason and then again have to just expect it.
Sometimes things could be "cleaner" or "nicer" but often in practice it is not that dramatic:
Maybe it gets fixed, maybe not.
If it is not blocking you, then why bother?
moveDef types being defined by their name might seem strange but beside that no problem. It is nicer now

with the optional new way but nothing critical imo.
To some things possibly "nobody knows" the answer. Maybe some engine devs could give answer right from head,

but they dont post so often.
Others could look it up/investigate, but that is boring work and for one forumpost it is not worth it.
So if you want to know some tiny-too-special things will have to look yourself.

Spring.MoveCtrl.SetGroundMoveTypeData (unit, "maxSpeed", XXX) XXX does not correspond to the value

scale defined in the movedef/unitdef.

Different scales are not so unusual in spring.
iirc:
SetGroundMoveTypeData uses same scale as Lua-unitdefs: UnitDefs[unitDefID].speed
I think 30-time of value in unit file.
Mildly relevent looking things:
https://github.com/spring/spring/blob/1 ... f.cpp#L381
speed = udTable.GetFloat("maxVelocity", 0.0f) * GAME_SPEED;
GAME_SPEED = 30;
https://github.com/spring/spring/blob/1 ... ants.h#L33
https://github.com/spring/spring/blob/1 ... s.cpp#L762
Or look
https://springrts.com/wiki/SetMoveTypeDataExample
or
https://github.com/ZeroK-RTS/Zero-K/blo ... s.lua#L318

I have tried to use Spring.MoveCtrl.SetGroundMoveTypeData (unit, "floatOnWater", true) gives me

"Warning: [SetMoveTypeData] incompatible movetype key for SetGroundMoveTypeData".

Is it even possible to make a NON-hover mobile unit that drives on land and floats on water, just via unit file?
I made all my amphi-floater units as 'hover' because could not figure it out and iirc floater=true had no effect for bots/tanks.

i was told somewhen later that Spring.MoveCtrl.Enable was nececary to call, but it seems that Spring.MoveCtrl.SetMoveDef and Spring.MoveCtrl.SetGroundMoveTypeData work just fine without calling these, give the function name i began wondering what the point of it is.

MoveCtrl.Enable can be switcher to turn on/off spring physics:

Code: Select all

Spring.MoveCtrl.Enable (unitID)
x,y,z=Spring.GetUnitPosition(unitID)
Spring.MoveCtrl.SetPosition  (unitID, x, y+1000,z) --move unit into the air
Sleep (5000) --wait 5 seconds, the unit stays in air where you put as long as 'movectrl is enabled'
Spring.MoveCtrl.Disable (unitID) --now the unit will fall down

A significant pressing issue for me is that depthModParams subtable is not applicable to hover movedefs according to wiki, which is utter bullshit considering hover units can move in and under water.

It might be that engine has assumption that hovers always stay 'on top' of water, and then slowdown by water makes no sense.

Quite another issue is that i have units that are already hovers but i want them to move slower when

on water, if bellow waterline preferable that is, but i dont know how to do this.

You already found function to change unit speed. Ways to detect if unit is in water:
a) Spring.GetUnitPosition , Spring.GetGroundHeight
(water surface is always at y=0)
b) script-callin: script.setSFXoccupy (see wiki, yes the name is strange)
c) UnitEnteredWater, UnitLeftWater , https://springrts.com/wiki/Lua:Callins
(Check if the notes about not being in handler still apply, if yes then look at zero-K)

...wakes...

Well if you are unsure if/when ship make waves then test it, is not complicated to test
You can also make your own waves with EmitSfx:
https://github.com/ZeroK-RTS/Zero-K/blo ... ch.lua#L33
(instead of "3" can use constant SFX.WAKE)

I have been told in #moddev that there are shitty ways to work around this, but have not been told how

Such is to be expected.

For the other questions would be good if you share your mod, otherwise is too much guesswork.

/edit wtf is with all those random linebreaks and why are urls shortend so horrible

[code_man]

Hovers should smoothly go from "tilted on terrain" to "upright on water", depending on waterdepth?
Or the waterdepth at which they 'snap' orientation should be different?

Well waterline would a better parameter for that i guess.
And yes i want them to snap at a different depth, rather than 0, if it would go smoothly rather than how it does now then even better.

It is bit less shitty if you keep in mind the name can be set to set all types of moveDef-types, it is not limited to "hover."
But see wiki https://springrts.com/wiki/Movedefs.lua#Tag:name ,it mentions two methodes:
"Prior to 9.50 this had to contain "tank", "hover", "ship" or "boat" respectively for non-Bot types. This is now set using speedModClass. " ( https://springrts.com/wiki/Movedefs.lua ... edModClass )
But on such stuff wiki is sometimes wrong/inprecise, so at top of wiki page is often a link to relevant files. It is worth clicking. Click "history", find this:
https://github.com/spring/spring/commit ... 0d56aa1a08
(or look at changelog)

Oh yes lookign at my movedef, it does not have hover in it so its all good, the wiki was outdated.

There are many 'traps', imo no use to look for deeper sense, just take things as they are. Maybe some things have historical reasons, but knowing these stories does not really help anything except having learnt some useless detail that is forgotten next day.
Other things might have a reson but if one does not understand it then to just have to expect it.
Or it is someone else's reason and then again have to just expect it.
Sometimes things could be "cleaner" or "nicer" but often in practice it is not that dramatic:
Maybe it gets fixed, maybe not.
If it is not blocking you, then why bother?
moveDef types being defined by their name might seem strange but beside that no problem. It is nicer now

with the optional new way but nothing critical imo.
To some things possibly "nobody knows" the answer. Maybe some engine devs could give answer right from head,

but they dont post so often.
Others could look it up/investigate, but that is boring work and for one forumpost it is not worth it.
So if you want to know some tiny-too-special things will have to look yourself.

I didnt really look for things, it just occured to me that the water related stuff is a mess when working with it.
So i decided to point this out in hope that the community can reach a consensus on what should and should not be there.
Maybe engine devs will take a hint one day, at the least if it helps me get my game going il be satisfied.

Different scales are not so unusual in spring.
iirc:
SetGroundMoveTypeData uses same scale as Lua-unitdefs: UnitDefs[unitDefID].speed
I think 30-time of value in unit file.
Mildly relevent looking things:
https://github.com/spring/spring/blob/1 ... f.cpp#L381
speed = udTable.GetFloat("maxVelocity", 0.0f) * GAME_SPEED;
GAME_SPEED = 30;
https://github.com/spring/spring/blob/1 ... ants.h#L33
https://github.com/spring/spring/blob/1 ... s.cpp#L762
Or look
https://springrts.com/wiki/SetMoveTypeDataExample
or
https://github.com/ZeroK-RTS/Zero-K/blo ... s.lua#L318

Il have to digest this, tough silentwings told me in #moddev that i should file this in the mantis.
Not sure what to do about this.

Is it even possible to make a NON-hover mobile unit that drives on land and floats on water, just via unit file?
I made all my amphi-floater units as 'hover' because could not figure it out and iirc floater=true had no effect for bots/tanks.

Yes floater tag is useless, it was my first attempted aswell, i forgot to list that, so another one down.

MoveCtrl.Enable can be switcher to turn on/off spring physics:

Code: Select all

Spring.MoveCtrl.Enable (unitID)
x,y,z=Spring.GetUnitPosition(unitID)
Spring.MoveCtrl.SetPosition  (unitID, x, y+1000,z) --move unit into the air
Sleep (5000) --wait 5 seconds, the unit stays in air where you put as long as 'movectrl is enabled'
Spring.MoveCtrl.Disable (unitID) --now the unit will fall down

Now that might be useful to know, thanks.

It might be that engine has assumption that hovers always stay 'on top' of water, and then slowdown by water makes no sense.

But as they can move underwater it should be applicable.

You already found function to change unit speed. Ways to detect if unit is in water:
a) Spring.GetUnitPosition , Spring.GetGroundHeight
(water surface is always at y=0)
b) script-callin: script.setSFXoccupy (see wiki, yes the name is strange)
c) UnitEnteredWater, UnitLeftWater , https://springrts.com/wiki/Lua:Callins
(Check if the notes about not being in handler still apply, if yes then look at zero-K)

I understand that solution a would be a gadget, with lots of overhead, yes?
I could not understand the setSFXoccupy description on the wiki. Mind explaining?
So another gadget method with c again? I can try checking but if this doesnt work then i wont know what to do.

This reeks of hackiness, but at this point il try anything.

Well if you are unsure if/when ship make waves then test it, is not complicated to test
You can also make your own waves with EmitSfx:
https://github.com/ZeroK-RTS/Zero-K/blo ... ch.lua#L33
(instead of "3" can use constant SFX.WAKE)

Ah, this might be useful.

For the other questions would be good if you share your mod, otherwise is too much guesswork.

Cant do right now, but i might share the significant part of it for this discussion, if anyone thinks it might be useful.