Page MenuHomeFeedback Tracker

Independent Damage States - a replacement for the Hitpoint dependency system
New, NormalPublic

Description

The Hitpoint dependency system (currently only used on infantry in vanilla) works, but it has some usability problems. If a Hitpoint needs to be dependant on many other hitpoints, all those classe have to be daisy chained together in terms of class inheritance, just so that one hitpoint can be dependant on them. Also, accessing it via scripting has issues (dependent hitpoints not updating properly). https://feedback.bistudio.com/T120705
The only reason why we need the dependency in the first place is, that the "damage states" are hardcoded to certain Hitpoint class names. With "damage states" i mean Death, FuelExplosion, Limping State, Arm Shaking, Tank Track disabled, Engine disabled, Instrument Malfunction on Helicopters, etc etc

Currently for a car, a Hitpoint with name HitFuel is hardcoded to cause an explosion at damage >= 0.9 (iirc).
Infantry currently has 2 death "damage states" hardcoded - one for HitHead and one for HitBody.
Why do damage states have to be configurable and be dependant on multiple instead of a single hitpoint? Because different hit locations that are not logically connected can contribute to the same damage state, and they may not contribute equally to it.

It would be much better (and alot more future proof) to define the "damage states" seperately from Hitpoint classes. That way we do not need Hitpoint interdependency and the messy class structure it requires for the dependency to work, and will not have handling issues with scripts. In addition, such a seperate system provides a base for further expansion of damage state functionality (e.g. additional damage states, non-binary damage states, ...)

Arbitrary Example (using some nonvanilla hitpoints just for the sake of conveying the idea).

//for Infantry
class DamageStates {
	class Limping {depends = "HitFoot + 2*HitLeg";}; //causes limping in case the "depends" formula is >= 1
	class Death {depends= "(HitFace + HitNeck) max (HitBody + 0.5*HitLeg + 0.25*HitArms)";};
	class AimShake {depends= "0.75*HitArms";};
};

//for Car
class DamageStates {
	class Engine {depends="HitEngine + HitGearbox";};
	class Explosion {depends= "HitFuel";};
	class WheelFL {depends="HitWheelFL";};
	//etc
};

//for Tank
class DamageStates {	
	class Explosion {depends = "HitBody + HitAmmo";};
	class Turret1 {depends= "HitTurret + HitAuxPowerUnit";};
	class Engine {depends= "HitEngine";};
	class TrackL {depends= "HitTrackL + HitSteeringunit";};
	//etc
};

These damagestates should also be usable in model.cfg as animation sources (like Hitpoints currently are as well), to not lose functionality (see my comment for use case)

Details

Severity
Feature
Resolution
Open
Reproducibility
N/A
Operating System
Windows 7
Category
Feature Request
Additional Information

Non-binary damage states would be neat.
E.g. an engine with damage=0.7 would put out less power than one without damage. Currently there is only working/not working.
Another example would be a vehicle Turret. damage=0.8 could move a lot slower than damage=0 (e.g. it is beeing hand cranked after the powered turretdrive failed) and finally be locked at damage=1.0

one method to possibly achieve that in a universal fashion i described here
https://feedback.bistudio.com/T83575

Event Timeline

Fennek created this task.Dec 5 2016, 10:02 PM
Fennek updated the task description. (Show Details)
Fennek updated the task description. (Show Details)Dec 6 2016, 6:55 PM
Lex added a subscriber: Lex.Dec 7 2016, 2:07 AM
oukej added a subscriber: oukej.Dec 7 2016, 10:17 AM

For an equivalent usability this replacement needs one more feature - the damagestates themself need to be usable as animation sources in model.cfg, like the Hitpoints currently are.

use case:
If you have a house model with interior, but you dont want it to show the interior by default you can block all windows and doors with boards/etc in the model and hide the entire interior via animation by default. Now you can set it up (via chaining all Window and Door hitpoints together), that when somebody destroys any of those boards or doors, it would unhide the interior.

Fennek updated the task description. (Show Details)Dec 11 2016, 12:25 PM
Lex removed a subscriber: Lex.May 23 2017, 4:52 PM