Loading...
  OR  Zero-K Name:    Password:   

weapon falloff rate

10 posts, 689 views
Post comment
Filter:    Player:  
sort

22 months ago
Hey so after a fine battle of commander vs jack, in which heatrays and D-guns appeared, and also some vaporization of ducks at max heatray range, I got to thinking. What is exactly is the shape of the damage falloff?

So github has this pile of code on it, from which I learned that both the comm flamethrower and heatray have falloff. (Or rather, non-default falloff.) The mechanism this works by appears to be defined in the Spring engine, but not in a way which yields its secrets rapidly.

Anyone so kind as to just illuminate me (everyone!) on all the mechanics of damage falloff?
+1 / -0
TL;DR: Scorcher damage decreases linearly with range to near-zero at max range. I don't think flamethrower weapons have damage fall-off at range.

--

As best I can tell the fallOffRate weapon parameter has to do with visuals, not weapon damage.

The relevant parameters for Scorcher seem to be:
https://github.com/ZeroK-RTS/Zero-K/blob/master/units/vehraid.lua#L99-L101
quote:
dynDamageExp = 1,
dynDamageInverted = false,
dynDamageRange = 270,

Pyro and commander flamethrower leave these as default and do not have damage fall-off. At least not using this mechanism. Shotguns, for example, do not use this mechanism but not all projectiles will necessarily hit a target at max range, so there is more than one way that a weapon may happen to do less damage at range.
Also note
quote:
range = 262,


The corresponding definitions in the Spring engine:
https://github.com/spring/spring/blob/develop/rts/Sim/Weapons/WeaponDef.cpp#L151-L154
quote:
WEAPONTAG(bool, dynDamageInverted, damages.dynDamageInverted).defaultValue(false).description("If true the damage curve is inverted i.e. the weapon does more damage at greater ranges as opposed to less.");
WEAPONTAG(float, dynDamageExp, damages.dynDamageExp).defaultValue(0.0f).description("Exponent of the range-dependent damage formula, the default of 0.0 disables dynamic damage, 1.0 means linear scaling , 2.0 quadratic and so on.");
WEAPONTAG(float, dynDamageMin, damages.dynDamageMin).defaultValue(0.0f).description("The minimum floor value that range-dependent damage can drop to.");
WEAPONTAG(float, dynDamageRange, damages.dynDamageRange).defaultValue(0.0f).description("If set to non-zero values the weapon will use this value in the range-dependant damage formula instead of the actual range.");


The actual function which applies these definitions seems to be
https://github.com/spring/spring/blob/develop/rts/Sim/Misc/DamageArray.cpp#L77
+1 / -0
Thanks, thats an very helpful response. Complete with references to source code.

Currently reading around a bit more. I am curious to see how the comm will choose what to shoot at when it has two distinct weapons. One case I have observed that the comm will often/sometimes prioritize a longer-range weapon so that the second weapon is idled, despite target options where both could be employed.

Kind of odd perhaps to ask code/dev questions on this forum, but hey: I see there is a proximityPriority set on various weapons and never apparently used in the ZK code, whereas there is also a proximity_priority set on customParams which is used in ZK code, but only for one unit. I guess any targeting decisions that give special consideration to the heatray would be in the Spring engine. I haven't dug all that deep. EDIT: OK yes I see where that is handled in the auto-target code in Spring. Now to understand how ZK might use that. EDIT3: I guess it is choosing a suitable target for the first weapon and only asking the second if the first is not able to find anything that works, so when building your comm, choose the short-ranged weapon first. ( CMobileCAI::GenerateAttackCmd(): https://github.com/spring/spring/blob/a8cf33ad1d2ac775e6008cd04baa7e859d1f23ec/rts/Sim/Units/CommandAI/MobileCAI.cpp#L1113 )

Would be handy if the two comm cannons were not co-axial. ;)

Commanders running around in the chaos are the best part of the game.
+1 / -0


22 months ago
Target priority is mostly overridden by ZK https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Gadgets/unit_target_priority.lua

The main config is a weapon x unitDef table defined here: https://github.com/ZeroK-RTS/Zero-K/blob/master/LuaRules/Configs/target_priority_defs.lua

Lower numbers result in a higher priority.

Some silly hardcoded behaviour in the engine overrides this code. The worst offender I'm aware of is that units sometimes switch to shooting at whatever just damaged them.

Notably for commanders, weapons have priority for shooting at units, not units onto units. Units with two or more weapons aren't necessarily going to do things that make sense. Luckily units with many weapons are rare enough for players to pay a bit more attention to them. In general, I think the final responsibility for targeting lies with the player. The priorities (and other tools) can help, but the difference between a decent target and a great target is usually up to strategic considerations, so if you really want your units to shoot at exactly what you want them to, you're going to have to issue commands.
+0 / -0

22 months ago
Thanks for that information also.

Interestingly target_priority_defs.lua has a comment that talks about "for heatrays" and uses a property proximity_priority what appears to only be set on Stardust. Thus a list proximityWeaponDefs is populated only with that one unit, and a bit of code described as "Prioritize nearby units" in unit_target_priority.lua only applies to that unit.

I understand your point that targeting choices are nontrivial, but specifically for a heatray-wielding comm, probably choosing close-by targets would be wise, and an acceptable computational load. I haven't read the code that determines what target is ideal, but some attempts at heatray sniping makes me suspect there is not a strong preference for close-by targets.

I'd like to continue to dig around understanding how the commander works (for example are targeting choices made with the first weapon), but that's not for right now.
+0 / -0


22 months ago
quote:
I'd like to continue to dig around understanding how the commander works (for example are targeting choices made with the first weapon), but that's not for right now.


I'm pretty knowledgable with commander stuff as I've gone through a major overhaul of commander stuff in FW. If you have questions let me know.
+1 / -0

22 months ago
Had to go take another round in Future Wars. Tons of wild toys to play with in there. An impressive effort.

Your treatment of the guardian as a pure long-range comm leaves me wishing I could mix things a bit. I'll need to try the riot comm next. IMO, an excellent upgrade path would see at least some types of comm able to equip two "arm" weapons plus a "backpack" weapon. A tool for every situation.

I'm going to need to try to dig around in more code before I can do more than ask the most basic of questions about how things work.
+0 / -0
[Spoiler]
+0 / -0
quote:
I understand your point that targeting choices are nontrivial, but specifically for a heatray-wielding comm, probably choosing close-by targets would be wise, and an acceptable computational load. I haven't read the code that determines what target is ideal, but some attempts at heatray sniping makes me suspect there is not a strong preference for close-by targets.

Target priority isn't a complete project, especially for commanders. If Scorcher or commanders could have weapon priority improvements, then work on it and make a pull request. I don't know why Scorcher lacks proximity_priority, perhaps there is an inbuilt weapondef that achieves the correct behaviour, so only Stardust needed it to be luaed. Check whether Scorcher works well.
+0 / -0

20 months ago
I've been poking around in the Lua a bit more, looking at commanders. Regarding the line:

https://github.com/ZeroK-RTS/Zero-K/blob/master/scripts/dynamicCommander.lua#L83

I think that GG.Upgrades_WeaponNumMap() is always returning nil because the function isn't expecting two parameters, and especially not the first one. Due to that function being apparently not successfully used for anything, it seems that over in LuaRules/Gadgets/unit_commander_upgrade.lua, perhaps the local variable unitCreatedWeaponNums could be removed entirely.

Its a bit confusing, but I guess there are a lot of different Lua contexts being maintained. So some things which are global actually have and retain different values, such as the "unitWeaponNames" in dynamicCommander.lua. I guess each commander loads its own Lua context or something.
+0 / -0