Hardcoded kludges list (needs fixing)

[jK]

Configurable EMP decline
http://springrts.com/mantis/view.php?id=2684

A variable in modrules that controls the decay rate of EMP damage. Currently it is hardcoded to 100% -> 0% in 40 seconds.

Specifically for the version I looked at in https://github.com/spring/spring/blob/d ... s/Unit.cpp [^]

"float CUnit::empDecline = 2.0f * (float)UNIT_SLOWUPDATE_RATE / (float)GAME_SPEED / 40.0f;"

The magic number "40.0f" means 40 seconds. This would need replacing with a value from modrules.

That's just wrong!
Do you always see 40sec emp counters ingame? No!
The empDecline just defines how fast the empdamage counter decreases. IT HAS NOTHING TO DO WITH HOW LONG AN UNIT IS EMP'ED!
The empdamage counter is NOT in 0..100%, yes it's relative to the units health but can be 120% or even 300000%, too!

How long an units is max emp'ed depends only on the weapon which defines it in seconds (from 0.000001s upto 1e7 seconds!)

If you want to know more about these numbers check the healthbars widget that parse all those correctly.

[Jools]

Yeah, sonar is pretty lackluster. Is it even possible to have underwater radar dots?

Or sonar dots. I don't think so. If you have sonar you also have LOS.

[smoth]

forb add radar auto targeting. that is an annoying " feature" which we cannot control

[SinbadEV]

Not sure if it's on the list but based on that other thread http://springrts.com/phpbb/viewtopic.php?f=14&t=29675

It would appear that some game designers would like the old broken version of First Person mode back (aka, no auto-targeting and allowing friendly fire etc.)

[Anarchid]

It would appear that some game designers would like the old broken version of First Person mode back (aka, no auto-targeting and allowing friendly fire etc.)

Where do i sign? If i want my units to autotarget, there is no reason to FPS in the first place; and refusing to shoot that suspicious cloud just makes no sense either.

[Forboding Angel]

Configurable EMP decline
http://springrts.com/mantis/view.php?id=2684

A variable in modrules that controls the decay rate of EMP damage. Currently it is hardcoded to 100% -> 0% in 40 seconds.

Specifically for the version I looked at in https://github.com/spring/spring/blob/d ... s/Unit.cpp [^]

"float CUnit::empDecline = 2.0f * (float)UNIT_SLOWUPDATE_RATE / (float)GAME_SPEED / 40.0f;"

The magic number "40.0f" means 40 seconds. This would need replacing with a value from modrules.

That's just wrong!
Do you always see 40sec emp counters ingame? No!
The empDecline just defines how fast the empdamage counter decreases. IT HAS NOTHING TO DO WITH HOW LONG AN UNIT IS EMP'ED!
The empdamage counter is NOT in 0..100%, yes it's relative to the units health but can be 120% or even 300000%, too!

How long an units is max emp'ed depends only on the weapon which defines it in seconds (from 0.000001s upto 1e7 seconds!)

If you want to know more about these numbers check the healthbars widget that parse all those correctly.

JK, When this thread was made and emp added, it was still a bug.

[jK]

Healthbars widget is older than this thread.
Also googlefrog even made a mantis ticket with your request and kloot then implemented it (and caused me trouble when reverting the commit).

So please edit the post and remove the request, cause it's just wrong.

[Google_Frog]

I don't think you see the purpose of my request. Maybe the implementation was wrong, I don't know. I know exactly what I was asking and you haven't refuted it.

EMP decline rate changes the amount of emp damage required to increase a unit's paralysis duration by one second.

If it took 20s for a unit to decay from 100% emp then a weapon with an EMP timer of 30s would have to deal 250% emp damage to reach the full time. If instead it took 40s for a unit to decay from 100% then the 30s emp timer weapon only has to deal 175% emp damage to reach the full 30s.

empDecline has plenty to do with how long a unit is emped. If a unit has 200% emp damage then it will be emped for the duration of empDecline. Additionally emp weapons have emp timer which just sets a limit on emp percentage. They don't deal emp damage over this percentage.

max emp percentage = 100 + 100 * emp timer / empDecline

[jK]

If it took 20s for a unit to decay from 100% emp then a weapon with an EMP timer of 30s would have to deal 250% emp damage to reach the full time. If instead it took 40s for a unit to decay from 100% then the 30s emp timer weapon only has to deal 175% emp damage to reach the full 30s.

Increase emp damage of all weapons, same effect.

[Kloot]

Remind us again why gamedevs should have to edit EMP damage FOR ALL WEAPONS (which affects balance with respect to how quickly units become stunned from it) when they could just change a single damn constant controlling the global decay rate...?

Code: Select all

// the current magic constant
empDecline = 2.0 * UNIT_SLOWUPDATE_RATE / GAME_SPEED / 40.0 = 2.0 * 16 / 30 / 40.0 == 1 / 37.5

// the EMP damage reduction every SlowUpdate, note the 2.0 and 0.5 cancel out
paralyzeDamage -= ((modInfo.paralyzeOnMaxHealth? maxHealth: health) * 0.5 * empDecline);

[jK]

Where do we end then? Add a variable to scale all weapon damage, one for scale all healths, one for speed, one for metal production, ... ... ... ...?
-> Games are already able to scale ALL those via *_post.lua in a much better fashion!

[Kloot]

The point is that no *_post script can control EMP damage reduction alone because the decay rate is hardcoded to 1/75th of a unit's current / maximum health per SlowUpdate.

There is only one way to customize it indirectly (Spring.SetUnitHealth(unitID, {paralyze = x, ...})) which still doesn't prevent the auto-decay from happening.

[jK]

EMP damage is something totally internal. The game shouldn't be interested into it at all (except for computing emp time itself).
Only thing that matters is emp time and damage needed to start stun.
And the first is totally controllable already, the 2nd isn't but won't either be with a game defined empDecline.

[Google_Frog]

Scaling weapon emp damage is not even equivalent to changing emp decline speed. Units become disabled before the full emp time is reached.

As in say you had an emp time of 40s and 10s to decay from 100%. Then the opposing unit will become disabled after taking 1/5 of the damage which the weapon can apply.

If instead it takes 80s to decay from 100% the unit will be disabled after it takes 2/3 of the damage it can hold.

The difference in these examples which cannot be solved by scaling weapon damage is that once the unit in the second example is stunned it quickly becomes stunned up to the max emp time.

[jK]

EMP damage is something totally internal. The game shouldn't be interested into it at all (except for computing emp time itself).
Only thing that matters is emp time and damage needed to start stun.
And the first is totally controllable already, the 2nd isn't but won't either be with a game defined empDecline.

Just for completeness, there are 2 modes for the 2nd atm. It needs damage of the amount of...
1. actual health
2. maxHealth

[knorke]

forb add radar auto targeting. that is an annoying " feature" which we cannot control

AllowWeaponTarget callin?
http://code.google.com/p/zero-k/source/ ... _radar.lua

[Google_Frog]

I would not use that gadget for disabling radar targeting on everything. It is kludgy. Units get automatic attack commands as well as attack goals both of which need to be blocked. The gadget requires integration with LUS in AimWeapon and BlockShot.