Page 1 of 1

### Units descend TOO fast

Posted: 13 Nov 2019, 19:11
Here, take a look:
Units move like they drop from the hill. Instead, I need them to move carefully, almost with the same speed as they climb, a bit faster though.
Should be something done on engine side or is it somehow controllable?

### Re: Units descend TOO fast

Posted: 13 Nov 2019, 22:15
The movedef your unit is using might need a higher "slopemod"
(https://springrts.com/wiki/Movedefs.lua)

The "allowGroundUnitGravity" game rule might need to be disabled
(https://springrts.com/wiki/Modrules.lua)

### Re: Units descend TOO fast

Posted: 13 Nov 2019, 22:29
unitgravity is disabled
afaik Slopemod only works on Ascending, not vice versa

### Re: Units descend TOO fast

Posted: 15 Nov 2019, 03:17
Confirm,
there is allowDirectionalPathing modrule, not mentioned on wiki. Setting =false make it descend w/ same speed as ascend.
This is not what I need though S:
More realistic is when starting from certain slope it work for descending but slow only, let's say, 50% of it would if ascend.

### Re: Units descend TOO fast

Posted: 17 Nov 2019, 10:01
If I understand correctly, your issue is that units move at a higher 3D velocity when moving down steep hills? You should post your movedef. The movedefs in Zero-K seem to implement what you want. I have not looked into why they work, but I suspect it is to do with slopemode = 70.

Here is a link: https://github.com/ZeroK-RTS/Zero-K/blo ... s.lua#L108

### Re: Units descend TOO fast

Posted: 17 Nov 2019, 19:06
Like this:

Code: Select all

``````{
name = "smallbot",
crushstrength = 5,
footprintx = 2,
footprintz = 2,
maxslope = 38,
slopemod = 8,
maxwaterdepth = 22,
depthModParams = {
minHeight = 4,
linearCoeff = 0.03,
maxValue = 0.7,
},
},

...
for i = 1,#MoveDefs do local moveDef = MoveDefs[i];
moveDef.allowRawMovement = true
moveDef.heatMapping = true
moveDef.heatProduced = 10
moveDef.heatMod = 0.1
moveDef.flowMapping = true
end``````
Maxslope = 70 (in ZK movedef) basically means that unit all-terrain.
I shall check how Zero-K units do it on practice though.

### Re: Units descend TOO fast

Posted: 18 Nov 2019, 02:30
It looked like you wanted all terrain. Anyway, what happens if you replace your movedef? Perhaps upright=true in the unitdef is causing this behaviour.

### Re: Units descend TOO fast

Posted: 20 Nov 2019, 21:26
It's intended behaviour, isn't it?
https://github.com/spring/spring/blob/2 ... th.cpp#L46
Would probably best to incorporate some formula. Hard to say which w/o testing though.
So it's time for Mantis I think.

### Re: Units descend TOO fast

Posted: 26 Nov 2019, 08:30
I think what you want exists in Zero-K. I don't quite know why your behaviour is different. Start copying it in bit-by-bit and find out.

### Re: Units descend TOO fast

Posted: 02 Dec 2019, 19:35
nop, just tested it. same in ZK.

### Re: Units descend TOO fast

Posted: 03 Dec 2019, 04:29
float maxSlope float slopeMod

https://springrts.com/wiki/Movedefs.lua

Spring doesn't represent terrain slopes in degrees, internally it uses (1.0 - the terrain normal's y-component) so the slope of vertical faces is 1 and that of horizontal ones 0. A unit's maxSlope value (which is in degrees in its movedef) is converted so that the "can we go here?" (ie "maxSlope > terrainSlope?") comparisons are meaningful, the formula is 1.0 - cos(DEG2RAD(maxSlope * 1.5)). If you want to know the terrain angle in degrees, compute RAD2DEG(arccos(1.0 - terrainSlope)). For a bot with a maxSlope of 36 degrees (~0.41221 in "Spring format"), the maximum tolerable terrain angle is approximately