Units descend TOO fast
Moderator: Moderators
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Units descend TOO fast
Here, take a look:
--YouTube--
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?
--YouTube--
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
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)
(https://springrts.com/wiki/Movedefs.lua)
The "allowGroundUnitGravity" game rule might need to be disabled
(https://springrts.com/wiki/Modrules.lua)
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Units descend TOO fast
unitgravity is disabled
afaik Slopemod only works on Ascending, not vice versa
afaik Slopemod only works on Ascending, not vice versa
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Units descend TOO fast
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.
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.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Units descend TOO fast
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
Here is a link: https://github.com/ZeroK-RTS/Zero-K/blo ... s.lua#L108
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Units descend TOO fast
Like this:
Maxslope = 70 (in ZK movedef) basically means that unit all-terrain.
I shall check how Zero-K units do it on practice though.
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
I shall check how Zero-K units do it on practice though.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Units descend TOO fast
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.
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Units descend TOO fast
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.
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.
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Units descend TOO fast
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.
-
- Posts: 20
- Joined: 03 Jun 2019, 21:06
Re: Units descend TOO fast
nop, just tested it. same in ZK.
Re: Units descend TOO fast
float maxSlope float slopeMod
https://springrts.com/wiki/Movedefs.lua
https://springrts.com/wiki/Movedefs.lua
didn't read any of the posts above before posting thisSpring 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
RAD2DEG(arccos(1.0 - 0.41221))
or 54 degrees. If maxSlope was 30, the MTTA would be 45, and if it was 60 (the highest sensible value due to that 1.5 scalar and the absence of overhanging cliffs) the bot could mount any terrain. In other words you do not need the long mathematical derivation, just remember that maxTerrainAngle = maxSlope * 1.5
--kloot, Thu Jul 31, 2008
-
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Units descend TOO fast
What is the map and location in the video?