Remove minimum map hardness

[Google_Frog]

How is this still not fixed?

Here is a patch for spring/rts/Map/MapInfo.cpp that should restore the old behaviour.

[hoijui]

but.. this is not a patch, but a file.
is it based on master (which revision?) or release?
to see what you actually did, i would have to diff the in-source file with your version in the right branch...
actually everyone who would want to see what you changed would have to do that.
-> bad way to supply a patch.

we prefer patches through git, where all of this can not possibly happen.

[Kloot]

How is this still not fixed?

Because 1) we don't work at your leisure and 2) it's not broken?

Non-positive hardness values are disallowed for a reason.

[zwzsg]

And what is that reason?

[Kloot]

Hardness appears as the denominator in several divisions whose results do not make sense (and would have to be analyzed for their impact on the simulation) when its value is negative and are undefined when it is zero.

[Google_Frog]

This change is when hardness became limited to positives (or 0).
https://github.com/spring/spring/commit ... 401#diff-2

Where in that is hardness now required to be positive? I had experienced no errors with earlier versions of Spring that did not limit hardness to positives. Though there are many commits between each release so it may be required for earlier or later things.

The nature of the change looks like hardness was thrown in there as something it would be logical to clamp. But as far as I can tell there is no reason to disallow any values except for 0. Btw the clamp permits 0 which is broken no matter how you look at it.

The only thing hardness should affect is explosion terrain deformation. If there is negative hardness the explosions are merely inverted. What is wrong with that?

[Forboding Angel]

[Google_Frog]

I don't get it.

0/u is perfectly fine, it is 0.

[zerver]

Yeah, the change was because 0 hardness would cause a div by zero. I did not know negative values were of any real use. We can change it to allow it if you want.

[Google_Frog]

Yeah, the change was because 0 hardness would cause a div by zero. I did not know negative values were of any real use. We can change it to allow it if you want.

Well yes that would be good. Something has to be done anyway because negative hardness is rounded back up to 0, this causes a crash.

And sorry about coming across as belligerent. But this is a few line fix that hasn't been looked at at all for almost a year.

[hoijui]

"i want minimum map hardness < 0!"
goes reads codes -> change value from 0 to MIN_INT -> added 10 bugs
"devs are stupid, could have done that 10 years ago, cost me no time really!!"

[zerver]

Something has to be done anyway because negative hardness is rounded back up to 0, this causes a crash.

https://github.com/spring/spring/commit ... 879eeedb83

The value is actually clamped to >= 0.001, so shouldn't crash, but if you say so...

[HeadHunter]

As a player - I have to remind you that Spring is the only RTS engine nowdays that supports terrain deformation. I hope it stays this way. It is a UNIQUE feature! You should not just throw it away because BA guys think its no cool.

Regarding visual FX - current cratering is indeed ugly. BUT. Is not SM3 going to fix the rendering problems in a sense that it already creates map by dynamic blending? I mean if we add another texture stage called damage, and then make empty blendmap, where engine would add points upon explosion so that damage texture can be blended in? Or is it not the way it works?

[MidKnight]

Regarding visual FX - current cratering is indeed ugly. BUT. Is not SM3 going to fix the rendering problems in a sense that it already creates map by dynamic blending? I mean if we add another texture stage called damage, and then make empty blendmap, where engine would add points upon explosion so that damage texture can be blended in? Or is it not the way it works?

SM3's dead, man.

[Argh]

Actually, last time I tested it, it worked the best it ever has- it was faster than SSMF over here. That said, yes, it's dead.

[Google_Frog]

There must have been a reason for restricting it in the first place. What was the reason?

[Google_Frog]

Bump.

Maps with minimum hardness are broken with the clamp anyway, what is the worst that could happen if it is removed?

[zerver]

I guess nagging works

https://github.com/spring/spring/commit ... afd57163ce

[Pxtl]

Y'know, in hindsight the variable probably should've been the inverse - "softness", which would avoid all the discontinuities and div/0 frustrations.

[SinbadEV]

Y'know, in hindsight the variable probably should've been the inverse - "softness", which would avoid all the discontinuities and div/0 frustrations.

...code needs comments that are percolated up to some kind of automatically generated documentation for game devs...

so the valid values are what now? -1.0 to 1.0 with anything > -0.001 and <= 0 being rounded to -0.001 and anything < 0.001 and > 0 being rounded to 0.001 with 1.0 representing no deformability and -1.0 representing infinite deformability?... wouldn't that make -1.0 an invalid value too?