scp-fs2open
Modular curves for weapon attributes during lifetime
This branch adds the ability for the modder to specify an arbitrary number of 'modular curves' in weapons.tbl. Each curve has an input (from a list of possible inputs) and an output (from a list of possible outputs), and the name of the curve to be used. Optionally, the curve can also have values for scaling and translation along the X axis. The advantage of these values is that they're random ranges, so the behavior of a curve across different instances of a weapon can be randomized.
This batch of curves deals with attributes changing during the weapon's existence, as opposed to on launch or on hit. In practice, this means mostly cosmetic attributes affecting lasers and lights, with a couple of mechanics-affecting ones as well. I intend to add a weapon velocity multiplier as an output later on, but for now I've left it out -- it will be a bit complicated to set up.
There are a few input-output pairs that overlap with curves already specified in the table. I've folded those hardcoded curves into this system: when they're specified in the table, parsing will convert them into modular curves and add them to the list.
There's a set of considerations to make regarding when to lump curves together into a single set, and when to split them; I lean toward lumping into one set so long as that's possible, which mostly depends on whether the necessary inputs all make sense under all relevant circumstances. There are a few other sets I plan to add to weapons: curves dealing with attributes on launch, ones dealing with attributes on hit, and ones dealing with child spawning. Launch and hit curves will require inputs that wouldn't make sense for this set, and child-spawning curves will have to be defined on a per-child-weapon basis.
@BMagnu's been putting together a system to generify modular curves, so we're expecting to integrate these changes into that before it's merged.
Okay. @BMagnu's modular curve system is now fully integrated, and I've tested the included features.
Went and cleaned up the easy stuff. Will handle the more complicated fixes soon.
There are at least a few things I can point out though. Aside from these it also looks like beams don't have dot curve handling, I know they didn't before, but they should and this is as good a time as any.
Dot curves on beams are difficult as of now. If the beam is wider than 40% of the ship it's colliding with, we perform a sphereline check. The dot of such a sphereline check is dependent on the first polygon that matches a collision, which may be a very unintuitively angled polygon if you're unlucky. Since it's super intransparent to the modder when a sphereline check is performed and fairly inconsistent which polygon might match a collision first, we should think about how to get proper dots for sphereline checks (and what is actually sensible for "dot of a collision area"), but that's out of scope for this PR IMO.
We don't need to overthink this, if the target is smaller than the beam_area_percent, just use a dot of 1. If people are using dot curves for beams, they're definitely thinking about the small beam big target case.
