Units descend TOO fast

Units descend TOO fast

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Post Reply
DmitryProfessional
Posts: 18
Joined: 03 Jun 2019, 21:06

Units descend TOO fast

Post by DmitryProfessional » 13 Nov 2019, 19:11

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?
0 x

raaar
Metal Factions Developer
Posts: 817
Joined: 20 Feb 2010, 12:17

Re: Units descend TOO fast

Post by raaar » 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)
0 x

DmitryProfessional
Posts: 18
Joined: 03 Jun 2019, 21:06

Re: Units descend TOO fast

Post by DmitryProfessional » 13 Nov 2019, 22:29

unitgravity is disabled
afaik Slopemod only works on Ascending, not vice versa
0 x

DmitryProfessional
Posts: 18
Joined: 03 Jun 2019, 21:06

Re: Units descend TOO fast

Post by DmitryProfessional » 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.
0 x

Google_Frog
Moderator
Posts: 2440
Joined: 12 Oct 2007, 09:24

Re: Units descend TOO fast

Post by Google_Frog » 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
0 x

DmitryProfessional
Posts: 18
Joined: 03 Jun 2019, 21:06

Re: Units descend TOO fast

Post by DmitryProfessional » 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.
0 x

Google_Frog
Moderator
Posts: 2440
Joined: 12 Oct 2007, 09:24

Re: Units descend TOO fast

Post by Google_Frog » 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.
0 x

DmitryProfessional
Posts: 18
Joined: 03 Jun 2019, 21:06

Re: Units descend TOO fast

Post by DmitryProfessional » 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. :mrgreen:
0 x

Google_Frog
Moderator
Posts: 2440
Joined: 12 Oct 2007, 09:24

Re: Units descend TOO fast

Post by Google_Frog » 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.
0 x

DmitryProfessional
Posts: 18
Joined: 03 Jun 2019, 21:06

Re: Units descend TOO fast

Post by DmitryProfessional » 02 Dec 2019, 19:35

nop, just tested it. same in ZK.
0 x

Ares
Posts: 315
Joined: 19 Mar 2011, 13:43

Re: Units descend TOO fast

Post by Ares » 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

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
didn't read any of the posts above before posting this
0 x

Google_Frog
Moderator
Posts: 2440
Joined: 12 Oct 2007, 09:24

Re: Units descend TOO fast

Post by Google_Frog » 06 Dec 2019, 23:58

What is the map and location in the video?
0 x

Post Reply

Return to “Game Development”