View topic - Depthmod is completely broken in spring 85


All times are UTC + 1 hour


Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: 27 Jan 2012, 13:09 
Evolution RTS Developer
User avatar

Joined: 17 Nov 2005, 02:43
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.
Top
 Offline Profile  
 
PostPosted: 27 Jan 2012, 20:31 
MC: Legacy & Spring 1944 Developer
User avatar

Joined: 29 Apr 2005, 00:14
Location: #moddev - join it!
Belong on mantis.
Top
 Offline Profile  
 
PostPosted: 27 Jan 2012, 21:44 
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
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/develop/rts/Sim/MoveTypes/MoveMath/GroundMoveMath.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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 20:28 
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
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?
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 20:36 
User avatar

Joined: 23 Oct 2004, 00:43
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:
speedMod /= (1.0f - std::max(-1.0f, (height * moveData.depthMod)));


Remember,

Code:
x /= y


is shorthand for

Code:
x = x / y


Now, consider if DepthMod is zero - that means

Code:
speedmod /= 1 - 0

=> speedmod = speedmod/1



so no change

On the other hand, consider nigh-infinite DepthMod. That means
Code:
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 20:57 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
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
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 21:34 
User avatar

Joined: 23 Oct 2004, 00:43
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:

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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:07 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:09 
User avatar

Joined: 23 Oct 2004, 00:43
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:11 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
are you going to write the patch?

movedefs effect the pathfinder also.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:23 
User avatar

Joined: 23 Oct 2004, 00:43
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:24 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
This isn't the issue forb had. Forb wanted his units to move at a certain speed in the water.

NOT based on depth.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:35 
User avatar

Joined: 23 Oct 2004, 00:43
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:40 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 22:50 
Evolution RTS Developer
User avatar

Joined: 17 Nov 2005, 02:43
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.
Top
 Offline Profile  
 
PostPosted: 31 Jan 2012, 23:25 
User avatar

Joined: 22 Feb 2006, 01:02
Location: cheap kitchen
Quote:
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.
Top
 Offline Profile  
 
PostPosted: 01 Feb 2012, 00:09 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
good points knorke.
Top
 Offline Profile  
 
PostPosted: 01 Feb 2012, 00:12 
Evolution RTS Developer
User avatar

Joined: 17 Nov 2005, 02:43
Depthmod 0.0001; does fuckall to help the problem.
Top
 Offline Profile  
 
PostPosted: 01 Feb 2012, 00:17 
Content Developer
User avatar

Joined: 13 Jan 2005, 00:46
what about this then:

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

and then bam done?
Top
 Offline Profile  
 
PostPosted: 01 Feb 2012, 01:53 
User avatar

Joined: 23 Oct 2004, 00:43
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.
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: Google Feedfetcher and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.