Skip to content

Option to disable main fireball when ship is destroyed#7179

Open
Kestrellius wants to merge 1 commit into
scp-fs2open:masterfrom
Kestrellius:fireball-disable
Open

Option to disable main fireball when ship is destroyed#7179
Kestrellius wants to merge 1 commit into
scp-fs2open:masterfrom
Kestrellius:fireball-disable

Conversation

@Kestrellius

Copy link
Copy Markdown
Contributor

Add a boolean option to get rid of the main fireball when a ship blows up, to provide the ability to more easily avoid redundancy with the $Ship Death Effect that spawns at the same time. In all other cases, when I added particle hooks for ship explosion effects, I arranged it so that the relevant fireballs would be disabled if a valid particle effect was present; however, the $Ship Death Effect predated me and didn't have that behavior, so I couldn't add it.

I wish I could have handled this more cleanly, but I think this is the best option. I considered trying to do something with the $Explosion Animations field, but the list of animations defined there is multipurpose.

@wookieejedi wookieejedi added the enhancement A new feature or upgrade of an existing feature to add additional functionality. label Jan 3, 2026
Comment thread code/ship/ship.cpp
@@ -9785,30 +9792,30 @@ static void ship_dying_frame(object *objp, int ship_num)
polymodel *pm = model_get(sip->model_num);
shipp->end_death_time = timestamp((int) pm->core_radius);
} else {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

In order to minimize diffs, one possible method you may consider is to make just two else if conditionals. One for the else if (sip->disable_main_fireball) and a final else

@wookieejedi wookieejedi left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Code make sense, but had one suggestion for making cleaner diff

@wookieejedi wookieejedi added this to the Release 26.0 milestone May 8, 2026
@BMagnu BMagnu modified the milestones: Release 26.0, Release 26.2 May 30, 2026
@BMagnu BMagnu 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 May 31, 2026
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. Waiting for Stable Marks a pull request that is to be merged after the next stable release, due to a release cycle

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants