Open Kaffeine opened 1 year ago
Similar to #4651.
Theoretically, stuff like this needs to go into the snapshot, as the info is needed during any tick (in a demo, e.g.).
Looking at the list of tunes, it seems like it might make sense to separate them into different classes. Some affect the character. Some affect projectiles. Some affect player-player-interaction!?
Maybe we could get a "character tune" snapshot object? We'd probably also need the same for projectiles, since they can persist after the owner left the server.
Sooo. Assuming that most character tunings are the same, we could associate a tune index with each character, and have a list of all tune settings that are currently active.
In various games different characters has different velocity parameters depending on various conditions, such as the player class (e.g. Team Fortress) or active weapon (e.g. Counter-Strike). Some mods
wouldfind such per-character params useful to vary the gameplay (typically there is a trade-off between speed/mobility and hp/damage; another application is a weapon which slows down the target).For race game type such flexibility would open a way to speed bonus pickups, 'slowing on touch' tiles (feature request for ddnet), etc.
One of the options is to add "tune zone" index to DDNetCharacter and introduce an extended version of
NETMSGTYPE_SV_TUNEPARAMS
to allow the server to override client tune zones individually. We already haveNUM_TUNEZONES = 256
which is quite enough for per-player or per-character tuning.On the client side the per-character tuning as-is works acceptable as long as AntiPing is off (infclass uses per-player tuning for many years). Turning on the AntiPing ruins the UX in some cases.