Depthmod is completely broken in spring 85
Moderator: Moderators
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Depthmod is completely broken in spring 85
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
http://springrts.com/mantis/view.php?id=2937
Last edited by Forboding Angel on 01 Feb 2012, 00:16, edited 1 time in total.
Re: Depthmod is completely broken in spring 85
Belong on mantis.
Re: Depthmod is completely broken in spring 85
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.
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.
Re: Depthmod is completely broken in spring 85
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:
So I would not say that it is nessecarely broken but maybe not made for units that submerge completly?
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:
So I would not say that it is nessecarely broken but maybe not made for units that submerge completly?
Re: Depthmod is completely broken in spring 85
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.
Remember,
is shorthand for
Now, consider if DepthMod is zero - that means
so no change
On the other hand, consider nigh-infinite DepthMod. That means
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).
edit: this is the important part that changed.
Code: Select all
speedMod /= (1.0f - std::max(-1.0f, (height * moveData.depthMod)));
Code: Select all
x /= y
Code: Select all
x = x / y
Code: Select all
speedmod /= 1 - 0
=> speedmod = speedmod/1
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 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.
Re: Depthmod is completely broken in spring 85
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
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
Re: Depthmod is completely broken in spring 85
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.
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.
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
Re: Depthmod is completely broken in spring 85
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.
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.
Re: Depthmod is completely broken in spring 85
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.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.
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.
Re: Depthmod is completely broken in spring 85
are you going to write the patch?
movedefs effect the pathfinder also.
movedefs effect the pathfinder also.
Re: Depthmod is completely broken in spring 85
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.smoth wrote:are you going to write the patch?
movedefs effect the pathfinder also.
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.
Re: Depthmod is completely broken in spring 85
This isn't the issue forb had. Forb wanted his units to move at a certain speed in the water.
NOT based on depth.
NOT based on depth.
Re: Depthmod is completely broken in spring 85
Absolutely.But looking at this snippet.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.
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.
Re: Depthmod is completely broken in spring 85
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.Pxtl wrote:However, nobody noticed it because none of the major mods *use* depthmod, do they?
I am saying that this isn't why forb started the thread.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Depthmod is completely broken in spring 85
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).
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.
Re: Depthmod is completely broken in spring 85
the problem are different understandings of "in the water" and "set speed".but my point was that we should be able to set a speed for our units in the water, based upon percentages.
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.
Re: Depthmod is completely broken in spring 85
good points knorke.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Depthmod is completely broken in spring 85
Depthmod 0.0001; does fuckall to help the problem.
Re: Depthmod is completely broken in spring 85
what about this then:
waterslowdown: 0.0-1.0(percent)
startsubmerge: heightvalue(as in 55 = -55 is underwater)
and then bam done?
waterslowdown: 0.0-1.0(percent)
startsubmerge: heightvalue(as in 55 = -55 is underwater)
and then bam done?
Re: Depthmod is completely broken in spring 85
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.
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.