Delayed fire weapons
New implementation of the same idea as #768
Delayed firing
- It is possible to have any weapon fire with a delay by setting
DelayedFire.Durationon a WeaponType - it supports a single integer or two comma-separated ones for a random range to pick value from.- If
DelayedFire.SkipInTransportis set to true and firer is in a transport, no delay is applied to firing. DelayedFire.Animationcan be used to define animation to create when the delay timer starts.DelayedFire.OpenToppedAnimationis used instead if set if the firer is in a transport.- If
DelayedFire.AnimIsAttachedis set to true, the animation is attached to the firing TechnoType. IfDelayedFire.RemoveAnimOnNoDelayis also set to true the animation is removed when the duration expires or firing is interrupted regardless of its remaining lifetime. DelayedFire.AnimOffsetcan be used to override the weapon's firing coordinates / FLH for the animation's position.DelayedFire.AnimOnTurretdetermines whether or not the animation's position is calculated relative to firer's body or turret (only if it has one).- If
DelayedFire.CenterAnimOnFireris set the animation is created at the firer's center rather than at the firing coordinates.
- If
- If the weapon was fired by InfantryType and
DelayedFire.PauseFiringSequenceis set to true, the infantry's firing sequence animation is paused when it hits the firing frame defined byFireUp/ProneorSecondaryFire/Pronein itsartmd.inientry until the delay timer has expired. - If the weapon has
Burst> 1 andDelayedFire.OnlyOnInitialBurstset to true, the delay occurs only before the initial burst shot. Note that if using Ares,Burstindex does not reset if firing is interrupted or the firer loses target, meaning it will be able to resume firing without waiting for the delay.
- If
In rulesmd.ini:
[SOMEWEAPON] ; WeaponType
DelayedFire.Duration= ; integer - single or comma-sep. range (game frames)
DelayedFire.SkipInTransport=false ; boolean
DelayedFire.Animation= ; Animation
DelayedFire.OpenToppedAnimation= ; Animation
DelayedFire.AnimIsAttached=true ; boolean
DelayedFire.AnimOffset= ; integer - Forward,Lateral,Height
DelayedFire.AnimOnTurret=true ; boolean
DelayedFire.CenterAnimOnFirer=false ; boolean
DelayedFire.RemoveAnimOnNoDelay=false ; boolean
DelayedFire.PauseFiringSequence=false ; boolean
DelayedFire.OnlyOnInitialBurst=false ; boolean
NOTE: AircraftTypes, due to their different attack patterns, will not wait for the delay to expire before attempting to fire and will instead continue without firing if the delay is too long.
Nightly build for this pull request:
- compiled-dll-e329dde44a3393a98ad6f8677a4d57e9de933a1f.zip These artifacts will expire in 90 days and will not be available for download after that time.
This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.
DelayedFire.PauseFiringSequence=yes breaks the weapon if used with Burst.FireWithinSequence=yes, as the infantry will be unable to fire. Seems to work fine otherwise, for infantry and units. Does not work most of the time for AircraftTypes, and even if it works, the animation doesn't play.
And i think this could use an option to play the charge animation only before the first shot if the weapon has Burst= above 1.
Updated with fixes and some new features.
DelayedFire.Durationnow supports two-comma separated values for random range.DelayedFire.AnimOffsetcan be used to override FLH position for the animation.DelayedFire.RemoveAnimOnNoDelayif set to true makes the animation disapper if delay is inactive (f.ex unit loses target mid-delay)DelayedFire.OnlyOnInitialBurstif set to true makes it so that only first burst shot has delay. Do mind that with Ares burst index does not reset if unit stops firing midway through.
The interaction between DelayedFire.PauseFiringSequence and Burst.FireWithinSequence should now also be fixed.
Still doesn't work for AircraftTypes, so it should be noted in the documentation. Other than that, everything seems to be working fine now. Didn't test in multiplayer.
Rebased, improved the handling of animation offsets. This is ready for another testing and review pass if needed.
This build crashes when building one specific unit, but that unit works fine with other builds so i don't know what's the problem. Here's the except file. except.zip
This build crashes when building one specific unit, but that unit works fine with other builds so i don't know what's the problem.
Putting vehicle inside an open-topped vehicle crashes the game. This crash in particular happens for a VehicleType that has another VehicleType inside trough InitialPayload. Infantry does not cause this crash, only vehicles.
Putting vehicle inside an open-topped vehicle crashes the game. This crash in particular happens for a VehicleType that has another VehicleType inside trough InitialPayload. Infantry does not cause this crash, only vehicles.
I can't reproduce this crash. There might be some parameters in play that I am missing.
Try building it from a naval yard. Or preplace an open topped naval unit with a vehicle inside, that also crashes for me.
Try building it from a naval yard. Or preplace an open topped naval unit with a vehicle inside, that also crashes for me.
Still doesn't crash. Any chance you could perhaps provide full crash log(s), or atleast both except+debug?
I guess it might be related to me using the ground naval yard "hack", although i'm not sure why would it crash only with this build. Here's the crash including crashdump. https://drive.google.com/file/d/17xUR_p85On6gL7Jl1lpEZhmj36so2gGS/
Any chance this could get reviewed, as well as maybe an another testing pass or so given that I had to rebase and refactor this to fit in with the infantry gattling / SHP unit FireUp functionality hopefully not breaking anything - something I do not want to do again.
As for that crash, it crashes trying to draw veterancy insignia. I don't know why it would be constrained to this build only and I do not really have a way to figure that out either.
looking good
if primary fire during secondary's charging, it'll stop the charging process. Guess this is an intended behavior
otherwise good in testing
Per the current design charging is intentionally interrupted if firing is stopped or weapon changes. Persisting charging would require changing things and unsure how useful it would be (could quickly get confusing).
now that this one is tested and reviewed, gonna merge it first since there're other PRs for weapons in the pipeline, which needs to be resolved based on this one (e.g. https://github.com/Phobos-developers/Phobos/pull/1467)