Depthmod is completely broken in spring 85

Depthmod is completely broken in spring 85

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Depthmod is completely broken in spring 85

Post by Forboding Angel »

Units underwater with a depthmod of 0.1, moving at a crawl. You can test this easily with evo's amphib units on kaisers new map.

http://springrts.com/mantis/view.php?id=2937
Last edited by Forboding Angel on 01 Feb 2012, 00:16, edited 1 time in total.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Depthmod is completely broken in spring 85

Post by FLOZi »

Belong on mantis.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Depthmod is completely broken in spring 85

Post by knorke »

Don't know if it was changed but afaik the slowdown was always quite dramatic.

this might be relevant:
https://github.com/spring/spring/blob/d ... veMath.cpp
speedMod /= std::max(0.01f, 1.0f + (-height * moveData.depthMod));

Using that, with depthmod=0.1 units and a water depth of 10 (which is not that deep really), units will already only move at 50% speed. And then you might have slopes slowing it some more.

Here is something random that might be all wrong or not but now i am going home.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Depthmod is completely broken in spring 85

Post by knorke »

These changes might be of interesst:
https://github.com/spring/spring/commit ... veMath.cpp

https://github.com/spring/spring/commit ... veMath.cpp

Tbh I am too lazy to test if it really behaves very different compared to 0.87 maybe you should.

Imo using depthMod for units that go completly underwater (drive on sea floor) is wrong.
It makes sense for units that partly go into water and wade through shallow water like this:
Image
So I would not say that it is nessecarely broken but maybe not made for units that submerge completly?
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Depthmod is completely broken in spring 85

Post by Pxtl »

Perhaps a second tag, MaxDepthMod, and the slowdown or speedup of the SpeedMod can't exceed the MaxDepthMod?

edit: this is the important part that changed.

Code: Select all

speedMod /= (1.0f - std::max(-1.0f, (height * moveData.depthMod)));
Remember,

Code: Select all

x /= y
is shorthand for

Code: Select all

x = x / y
Now, consider if DepthMod is zero - that means

Code: Select all

speedmod /= 1 - 0

=> speedmod = speedmod/1

so no change

On the other hand, consider nigh-infinite DepthMod. That means

Code: Select all

speedmod /= 1 - Max(-1, ReallyHugeSpeedMod * height)

(remember height is negative)

=> speedmod /= 1 - Max(-1, ReallyHugeNegativeNumber)

=> speedmod /= 1 - (-1)

=> speedmod /= 2
So speedmod is just cut in half at the extreme case.

So really, the old depthmod logic is just how quickly a submerging vehicle/robot reaches the 1/2 underwater movement modification cap.

The new logic is submerging robot gets slower and slower as it goes deeper, and depthmod is the coefficient of this process.

Obviously the missing factor here is a maxdepthmod - one that is either above *or* below 1, allowing for units that move faster underwater too (Smoth scripts this for Gundam, iirc, but that means it's unsupported by the pathfinder).
Last edited by Pxtl on 31 Jan 2012, 20:59, edited 1 time in total.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

or just allow us to set how much speed is dampened by water?

because IDEALLY amphibs should be depthmod=0 and dampen=0
that way we can set how much water slows units on a per-def basis.

for speed boosts, that should be gadget IMO
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Depthmod is completely broken in spring 85

Post by Pxtl »

My proposed patch for the snippet - supports negative depthmods. Requires a new movement class attribute, the DepthModLimit. Default this value to "0.5" to get the pre-85 behavior.

Code: Select all


float depthFactor = -height * moveData.depthMod;
//the amount depth will alter speed - positive value slows things down, negative values speed things up, zero means no change.


float depthFactorLimit = (1.0f / moveData.depthModLimit - 1.0f);
//convert the user-comprehensible depthModLimit into the logic used in these formulae.
//this calculation should be cached in the moveData class.

depthFactor =  std::abs(depthFactorLimit ) < std::abs(depthFactor) ? depthFactorLimit  : depthFactor; 
//we want whichever has the lesser magnitude, the calculated depthmod or the hard-coded depthModLimit.
//this could be branchless if C++ had a sign function.

speedMod /= std::max(0.01f, 1.0f + (depthFactor));
//then apply it, making sure we don't go beyond increasing unit speed beyond a hard-coded value of 100x normal

speedMod *= waterDamageCost;
//no freaking clue what this does

Fixed. DepthModLimit of 0 to 1 are slowdowns - 0.5 is half speed. DepthModLimit of greater than 1 is speedup - 2 is double speed. depthMods are expressed as positive or negative - positive ones slow the unit down (as current) negative ones speed the unit up.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

DEPTHMOD IS NOT FLAT FOR ALL WATER... think of it as a multiplier...

the deeper you go the faster or slower depending on the value(if you add negatives it would go faster the deeper the unit goes)...

do not treat it as "amphibs go faster in water"

that is NOT what it is for.

is is based on the DEPTH of the unit.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Depthmod is completely broken in spring 85

Post by Pxtl »

smoth wrote:DEPTHMOD IS NOT FLAT FOR ALL WATER... think of it as a multiplier...

the deeper you go the faster or slower depending on the value(if you add negatives it would go faster the deeper the unit goes)...

do not treat it as "amphibs go faster in water"

that is NOT what it is for.

is is based on the DEPTH of the unit.
Yes, but depthmod used to be capped at half-speed. So you could have a depthmod of 9999 and your units would *still* be limited to going at half their normal speed.

And either way, the patch code above I posted does not change depthmod itself. It is the exact same depthmod behavior as current, but with the ability to cap it with depthModLimit. To recreate the pre-85 behavior, use a depthmodlimit of 0.5. To recreate the current behavior, use a depthmodlimit of zero.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

are you going to write the patch?

movedefs effect the pathfinder also.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Depthmod is completely broken in spring 85

Post by Pxtl »

smoth wrote:are you going to write the patch?

movedefs effect the pathfinder also.
I would imagine that the pathfinder uses the same groundmovemath since the file stands alone with no references to units - just movedata and height/slope information.

Honestly, I don't have a build environment set up for Spring, but if I did I'd take a swing at it. That code I posted above *should* work... but we all know how well that goes. Also, I don't know how to add an attribute to MoveDefs.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

This isn't the issue forb had. Forb wanted his units to move at a certain speed in the water.

NOT based on depth.
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Depthmod is completely broken in spring 85

Post by Pxtl »

smoth wrote:This isn't the issue forb had. Forb wanted his units to move at a certain speed in the water.

NOT based on depth.
Absolutely.But looking at this snippet.

Yes, Forb's understanding of what depthmod *does* is wrong, but it doesn't change the fact that modders have lost an important tool for amphibs.

Nobody was actually ever using depthmod correctly... instead, they were functionally getting the following choice because they hit the cap fast:

1) Units may move at half-speed underwater.

2) Units may move at full-speed underwater.

Now they no longer have this choice. This makes depthmod worthless for actual gameplay concepts because what map is designed with that in mind? What map has the underwater slopes constructed specifically to consider how units will go slower the deeper they get?

The old approach was wrong and dumb but useful. The current approach is right but useless.

However, nobody noticed it because none of the major mods *use* depthmod, do they?

In the meantime, Forb should try adding a zero onto the start of his depthmod... maybe 0.001 or 0.0001 would work better for him.
Last edited by Pxtl on 31 Jan 2012, 22:45, edited 1 time in total.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

Pxtl wrote:However, nobody noticed it because none of the major mods *use* depthmod, do they?
I disabled it. I don't think adding a depth mod ceiling makes any sense. I am saying you are going to have to do a bunch of work to display that range to the player SHOULD a mod use it. I am saying it is a complicated thing and not at all just as simple as basic speed. I am saying you are going to have to do pathfollower work. Ultimately, I don't really care. I don't use it, I disable it.

I am saying that this isn't why forb started the thread.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Depthmod is completely broken in spring 85

Post by Forboding Angel »

Pxtl, you are missing the point. I appreciate what you are saying, but my point was that we should be able to set a speed for our units in the water, based upon percentages.

For example, 0.1 = 10% reduction in speed. I understand that that isn't how it works now, but amphibs in spring's water have always been shit. My suggestion would "fix" it.

Edit: I will try 0.0001 and see what happens. I thought the float was capped at 0 - 1 with only 1 decimal place (which is the case with a lot of the tags).
Last edited by Forboding Angel on 31 Jan 2012, 23:26, edited 2 times in total.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Depthmod is completely broken in spring 85

Post by knorke »

but my point was that we should be able to set a speed for our units in the water, based upon percentages.
the problem are different understandings of "in the water" and "set speed".
Should -1 water slow down as much as -10? Should slowdown at -10 and -100 be the same? -100 vs -500? etc. Should -1 shallow water even be considered as "in the water"?

There are many ways to do it..Pxtl's code is one.
But maybe somebody wants a unit that goes fullspeed in shallow water (say up to -15) and after that moves at 50% speed. I think atm and in Pxtl's code you can not have that.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

good points knorke.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Depthmod is completely broken in spring 85

Post by Forboding Angel »

Depthmod 0.0001; does fuckall to help the problem.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Depthmod is completely broken in spring 85

Post by smoth »

what about this then:

waterslowdown: 0.0-1.0(percent)
startsubmerge: heightvalue(as in 55 = -55 is underwater)

and then bam done?
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Re: Depthmod is completely broken in spring 85

Post by Pxtl »

Obviously there are endless permutations of height/slope/depth passability and speed bonuses/penalties one could come up with. Ultimately the most powerful and versatile solution would be some sort of arithmetic parser that creates a compiled arithmetic statement that's faster than lua (lua would likely not be performant for this use-case).

But either way, that's overkill. Yes, you can come up with cases that aren't covered by "gradually increase X until cap". Absolutely.

However, a simple, reasonable goal would be "support the old behavior that was obviously desirable (flat speed penalty underwater) and the new behavior (gradual increase in speed penalty)", while generalizing the old behavior into a user-configurable variable. I mean, I haven't touched Hardcore Annihilation in a year, but if I dusted it off I'd need the old behavior for Crocs and Tritons.

That said, do mods have access to the typemap that would allow them to create and apply their own types? Because that would be an alternative - Forb could apply a 50% slowdown type to everything below elevation zero.

edit: I'd absolutely support a simpler equation - a simple linear formula down to a fixed cap would be fine. This current formula is complicated because it's intended to gradually increase the depthmod indefinitely, which is always mathematically ugly when you're applying an infinite possible depth with a coefficient that ranges from zero to one.
Post Reply

Return to “Engine”