Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modular curves for weapon attributes during lifetime #6319

Draft
wants to merge 23 commits into
base: master
Choose a base branch
from

Conversation

Kestrellius
Copy link
Contributor

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.

Copy link
Member

@Baezon Baezon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The curve handling feels like it should be in a function. They're all doing very similar things, it's quite verbose, and highly specific, i.e. something other coders are likely going to want to just skip over and it's only going to get worse over time.

It'd be a heck of a function though to properly encapsulate all the cases, so It's not something I'll ask for in this PR, but it's something we really ought to think about as this system continues to be used.

code/object/object.cpp Outdated Show resolved Hide resolved
code/object/object.cpp Outdated Show resolved Hide resolved
code/weapon/weapons.cpp Outdated Show resolved Hide resolved
@@ -385,7 +434,7 @@ struct weapon_info

float damage; // damage of weapon (for missile, damage within inner radius)
float damage_time; // point in the lifetime of the weapon at which damage starts to attenuate. This applies to non-beam primaries. (DahBlount)
int damage_curve_idx; // damage over time curve
int damage_curve_idx;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason you couldn't update this one like the others?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For damage, I would want things like hit angle and target health as inputs, so that needs to go in a separate batch. (I went back and forth on this a lot.)

@wookieejedi wookieejedi added the enhancement A new feature or upgrade of an existing feature to add additional functionality. label Aug 26, 2024
@Goober5000 Goober5000 added the Waiting for Stable Marks a pull request that is to be merged after the next stable release, due to a release cycle label Aug 27, 2024
@Kestrellius Kestrellius marked this pull request as draft September 7, 2024 07:16
@Kestrellius
Copy link
Contributor Author

@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.

@Goober5000 Goober5000 removed the Waiting for Stable Marks a pull request that is to be merged after the next stable release, due to a release cycle label Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A new feature or upgrade of an existing feature to add additional functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants