[FEATURE] Custom Weapons & Weapon Archetypes

[NodokaHanamura]

Feature Description Implement a framework for custom weapons, and a new 'weapon archetype' system to replace the existing static weapon codebase. How would this function work? The framework would work similar to how we already have dats for aircraft and some ground objects such as SPAAGs and the sort.

There will be (initially) two components to these weapons:

• The weapon model, abandoning the static SRF file format for the more dynamic DNM file format, allowing for missiles to have animations for stage jettison, deployment of winglets and for 'container weapons', the opening of bomb bay doors.
• The weapon DAT file, which serves as the heart of the weapon itself, defining the weapon type, guidance type, damage, radii, circular error probable, RCS and other variables important to the implementation of the weapon within YSFlight.

Later, once if, and when we implement lua scripting as a feature for gamemodes, this can be extended for special weapons that are capable of providing multiple features or advanced guidance, such as cruise missiles with terrain following capability, or weapons with special animations for firing, like a railgun or anything of the sort. (Lest we forget about the magical girls..)

Why is this feature important?

Custom weapons has been an oft requested feature within YSFlight's history, and with its' rudimentary implementation by JTF108, it is entirely possible to implement custom weapons, but through the above method, this allows for end-user customization.

Concerns about compatibility are to be had, yes - and eventually client-side matters can be dealt with by developing a back-compat tool for converting aircraft targeting YSCE being made available for base YSFlight if one so desires - regardless, due to the server-authoritative nature of YSFlight, it is unlikely that implementing this framework will cause incompatibility with multiplayer.

This is because as shown below, all YSCE weapons must declare the WEPLGCYNAME variable value, and it must match one of the preexisting YSFlight weapon types, which in YSCE, for backwards compatibility with existing aircraft, will be reimplemented as close to their stock values as the new system allows.

When YSCE acts as a server, it will initially declare the weapon's legacy name as the weapon used, with a packet sent either on a second port or in such a way that it does not cause erroneous behavior in stock YSFlight, with the actual weapon type. if it does not exist on the client, it will fallback to the legacy version. If it does, its' visual model will replace the existing model (since DAT computation is not done on the client for non-local aircraft)

Any examples as to how this feature would work? An example weapon archetype DAT is shown below, and is to be considered a prototype. Not all variables are required for implementation (for example, WEPCLSLT doesn't need to be defined for an AGM-88.) and is only used as a technical design concept for capabilities of the framework, and may be expanded upon or revised.

WEPARCHNAME          AGM88                                 # Internal name. Should give an error in the event of a conflict.
WEPLGCYNAME          AGM45                                 # Legacy Name, use for network backcompat
WEPHMNNAME           "AGM-88 HARM (Harpoon Anti-Radiation Missile)"            # Human-readable version of the weapon name - use with if and when we shift to stores-based weapon management
WEPAFFILI            NATO                                  # Defines what affiliation can use the weapon. This variable would be defined in aircraft dat, and can be enabled or disabled globally on either a server or locally on the client as part of simulation options.

WEPTYPE              GUIDED                                # Can be GUIDED, UNGUIDERKT, GRAVITY, CANNON, SCRIPTED
WEPGUIDANCE          ANTIRAD                               # Can be INFRA, IRST, SEMIRADAR, ACTVRADAR, EO, ANTIRAD, GNDRADAR, GPS, SCRIPTED
WEPISCONTNR          FALSE                                 # Contains weapons, such as a weapons pod or rocket pod.
WEPISRAIL            FALSE                                 # Defines if the weapon can be mounted to a rail.
WEPISCLSTR           FALSE                                 # Defines if the weapon is a cluster munition.

#WEPCONTRSZ          1                                     # Defines the amount of hardpoints the container adds.
#CONTHDPOS1          0.00m 0.00m 0.00m 0 180 90            # Defines the orientation and position of the hardpoint relevant to the container.
#CONTHDOK1           B250                                  # Defines the archetype names that this hardpoint in the container will accept. 
#CONTHDJET           TRUE                                  # Defines if individual weapons in the container can be jettisoned.
#CONTHDBAY           TRUE                                  # Defines if the container has a bay door that must be open to jettison weapons.

WEPDAMAGE            30                                    # Damage relevant to HEALTH var in Aircraft DATs.
WEPMAXG              4                                     # Maximum Gs the missile can pull. Can also be used to determine how effective guided bombs are at gliding towards their target.
WEPRCS               0.95                                  # Radar Cross Section, determines how soon missile is detected by CIWS/MLWS (RWR)
WEPWEIGHT            800                                   # Weapon Weight in lbs, contributes to aircraft TWR.
WEPTHRST             1600                                  # Weapon Thrust in newtons (Not accurate at all probably)
WEPDRGCF             (???)                                 # Weapon Drag Coefficient (Would need someone more knowlegeable in aerodynamics for this..)
WEPMAXSPD            990                                   # Weapon Top Speed in m/s
WEPIMPRAD            10                                    # Weapon Blast radius in meters. Can be set to 0 for kinetic weapons or non-HE cannons, or up to 10000 for high yield explosives.
# WEPFUEL            15                                    # Time of booster life before missile transitions to unpowered flight.
# WEPCLSLT           10                                    # Amount of bomblets, only read if WEPISCLSTR is true.
# WEPCLSREL          1000                                  # Trigger altitude When the bomblet dispenser will release its' payload, in feet.
# WEPCLSCEP          10                                    # Maximum Circular Error Probable in feet for each bomblet from the 'source impact point' at the release height.
# WEPRKTCEP          3                                     # Maximum Circular Error Probable in feet for each rocket.

# WEPISHOBL          TRUE                               # Defines if a weapon is capable of high Off-bore lock and launch
# WEPHOBANG       150                                  # Defines the maximum angle of the seeker to determine a target lockable

WEPLNCHMDL           /weapons/dev/agm45.dnm                # Defines the location of the weapon model when launched.
WEPSTORMDL           /weapons/dev/agm45.dnm                # Defines the location of the weapon model when stored on the airframe.
WEPDESCTXT           /weapons/dev/agm45.txt                # Unicode-compatible (once implemented) basic text file containing information about the weapon.
# WEPSCRPFIL         /dev/null                             # Use for implementation of Lua scripting for missile guidance and features.```

[NodokaHanamura]

I have assigned a lot of the people who are active (and semi-active) to this issue as we should address this collaboratively.

I don't expect for us to implement this overnight - far from it - in fact, this is something that we should refine and mature until it is ready for a preliminary feature release and building it up as we work on other features.

[decaff42]

I'm thinking we will want glide and parachute weapons as well. Any idea if we could implement laser guidance? Currently if a weapon reaches end of fuel it disappears, how about adding a "you didn't hit anything, de-spawn after x time".

[NodokaHanamura]

I'm thinking we will want glide and parachute weapons as well.

Yeah, we can definitely implement that as behavior that can be part of the stock types.

Any idea if we could implement laser guidance?

We'd have to make it a seperate issue, but we could.

Laser and EO would effectively be the same, with the difference being the former broadcasts a target coordinate over a 'code channel' which missiles can receive targeting data from and guide towards as long as they're in launch range. Lynn and I were talking, and they suggested reimplementing the turret code and adapting it to work for a baseline for a Laser designator code, but that'd require discussing in its' own issue.

Currently if a weapon reaches end of fuel it disappears, how about adding a "you didn't hit anything, de-spawn after x time".

Currently, I think it'd be better if we have a check to see if the missile: A. Makes contact with a flare (since right now flares and chaff are one and the same) B. within 300m for one reason or another, the rate of closure goes negative (implying that the missile failed to hit C. No longer has the original target within a 10 degree (later definable when we implement weapon sensors) FOV.

[NodokaHanamura]

Addenum - we may want to allow server owners to blacklist certain weapons.