Spring RTS Engine

Noticed this commit by Kloot and thought it was kinda cool:
https://github.com/spring/spring/commit ... acca07f90d

make units crushable like features (extends Spring.SetUnitBlocking with an optional 4th argument)

---
I was wondering if it applies to enemy/allied (or both) units? It seems to apply to all units but I can not really tell.
Both might be usefull but primary use would probally be "vehicles running over enemy infantry while friendly infantry just gets pushed aside (as currently)"
Will that be possible?
Also it does not seem to require the (expensive?) watchUnit-Unit-collision function thing?

This is getting kind of creepy, like Kloot reading minds.

Oh, wait i dont have to dirt_workaround that in lua? All praise be upon Kloot.

Question: Can we have a specialised feature that is only called for units, once they get stomped? Want to make a 2dscaled version of mine :D

Bonuspoints if you can define a piecewere the "rolled" over unit would be moved towards, before feature converted. Would allow for controlled "vannishing" of infantry at exact spot..

christmaslist-> nextElement

bumPinging this because it deserves to stay on the map

Is our esteemed Bong requesting an audience?

I was wondering if it applies to enemy/allied (or both) units? It seems to apply to all units but I can not really tell.

Only enemy units by default, unless you set the allowCrushingAlliedUnits mod-rule. I may also add an explicit allowCrushingEnemyUnits if desired.

Both might be usefull but primary use would probally be "vehicles running over enemy infantry while friendly infantry just gets pushed aside (as currently)"
Will that be possible?

yes

Also it does not seem to require the (expensive?) watchUnit-Unit-collision function thing?

Crushing happens just before the events are sent, you do not need to listen to them.

Question: Can we have a specialised feature that is only called for units, once they get stomped? Want to make a 2dscaled version of mine :D

You can spawn any feature you want by registering for and reacting to the UnitUnitCollision callin, which tells you whether a collidee was crushed.

Of course, that feature might then itself be crushed, so you would probably want it to be non-blocking.

Bonuspoints if you can define a piecewere the "rolled" over unit would be moved towards, before feature converted. Would allow for controlled "vannishing" of infantry at exact spot..

nein (too messy at present, just use SetFeaturePosition und so weiter)

How is unit crush resistance determined?

Their mass IIRC.

You can spawn any feature you want by registering for and reacting to the UnitUnitCollision callin, which tells you whether a collidee was crushed.

Feels like I posted this before but how about a parameter bool crushed to UnitDestroyed() and FeatureDestroyed?
Or even better, number deathType: 1=death by weapon, 2=reclaimed, 3=crushed (possibly more)

Bonuspoints if you can define a piecewere the "rolled" over unit would be moved towards, before feature converted. Would allow for controlled "vannishing" of infantry at exact spot..

just use SetFeaturePosition und so weiter

better use SetUnitPosition and keep the crushed unit alive with Sleep() or loops in script.Killed() so it can wiggle while being vanished!

Can two units of the same type crush each other and both get crushed?

---
just collecting links to related commits for later reference:
new tag "crushStrength" which defaults to mass:
https://github.com/spring/spring/commit ... 231cde368e
modrules to crush allied units
https://github.com/spring/spring/commit ... 7aaefd2163

knorke wrote:new tag "crushStrength" which defaults to mass

New? Really? I recall it being added years ago, to crush features, especially wreckages. Also, beware, it belongs to the movement class and not the unit def.

unit.cpp:
+ crushStrength = udTable.GetFloat("crushStrength", mass);

but did not look closer, i just posted while game was loading. (from iphone)
so possible non-sense.

i-phones are still hip?`And i thought they would die like a parasitic plague, once the great mother alien dies, who gave birth to all those flat stones.

zwzsg wrote:

knorke wrote:new tag "crushStrength" which defaults to mass

New? Really? I recall it being added years ago, to crush features, especially wreckages. Also, beware, it belongs to the movement class and not the unit def.

Look at commit (and my comment). It's a new tag which determines the minimum value of 'crushStrength' (in the movedef) that is required to crush the unit or feature (before this was controlled solely by mass, now mass is the default)

http://springrts.com/phpbb/search.php?k ... shStrength

The earlist mention of crushStrength is from 2005.

LOOK AT COMMIT.

Is that not for crushing features, whereas the commit is for crushing other units?

It's for units *being* crushed. Different tag, same name ---> confusion city.

still, i had hope that i would get around the work to manually shove the unit to be crushed to the zone(s) were it could be crushed.

But enough complaining this is something that can be accomplished.

FLOZi wrote:It's for units *being* crushed. Different tag, same name ---> confusion city.

What?

You called the same a unitdef tag and a movementdef tag that do opposite things? How much you resist to crushing vs how much you crush? No wonder I got confused!

Please rename that new crushStrength into crushResistance!

I suggested to kloot minCrushStrength, crushResistance is another alternative. I wholeheartedly agree it must not remain the same.

I like crushResistance which makes it clear it's the complementary opposite of crushStrength.

minCrushStrength is not only too long but sounds like it plays the same role of crushStrength in absence of crushStrength or something.

yeah, but crushstrength has this wordMazeSon qualitys, that maxdamage posseses. The Foo is strong in this one.