* Fix C4709 Warnings on latest VS
* more
* suppress false positive
* Switch to using any/none_of
* Address Feedback
* Fix Line endings?
* Fix commits and strip out flag_combinator
* more fixes
* nolint
* Adapt particle at runtime
* Refactor EffectHosts
* fix issues
* cleanup
* Remove live transitive particles
* paticle hosts now do local correctly
* Fix effecthostparticle local mode
* again
* Set particle host orientation
* I don't like mixed local and global vectors
* agaiiin
* Fix validity check
* parent foo
* Fix bugs, hopefully finally
* refactor
* Flip new table option for intuitiveness
* Fix support for GCC9 due to issues with LWG3052
* Address feedback
FRED takes a long time opening mods that have a lot of particle entries in the particles table such as FotG (can take over a minute or more sometimes), so given FRED never renders or pages in particles, just skip the parsing.
* avoid undefined behavior from UNREACHABLE on reachable code paths
UNREACHABLE expands to __assume(false) / __builtin_unreachable() in
release builds, which is undefined behavior if the code is ever actually
reached. Many UNREACHABLE sites only guard against unexpected-but-
possible runtime states (values from tables, mission/save files, network
packets, scripting, or user input), so reaching them should degrade
gracefully rather than invoke UB.
Replace UNREACHABLE with Assertion(false, ...) at all such sites. It
still pops an error in debug builds, but in release it is a harmless
no-op that simply falls through to the following code. Sites that are
genuinely unreachable by local invariants (e.g. a switch over a bounded
random number) are left as UNREACHABLE.
A few converted sites had no safe fall-through -- an uninitialized read,
null dereference, or null call would have followed -- so they also get a
minimal recovery: initialize the value, guard the dereference, return
early, or skip the offending item.
Where the converted site was a simple guard of the form
if (x) { Assertion(false, ...); return; }
hoist the check onto the invariant instead:
Assertion(!x, ...);
if (x) { return; }
This states the expectation directly and shows the offending value in
the debug popup, while keeping the same graceful runtime degradation.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* addendum
After consultation with Lafiel, use UNREACHABLE in situations that are effectively impossible even if not provably impossible. UNREACHABLE = "this shouldn't ever happen"; Assertion = "if this ever happens, it's a coding error". Also fix a few other sites and change a couple to Warnings.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
Curve input follow-up to #6926 and #6889, in that it adds two new curve input Nebula and Particle Detail Levels for use within the particle effects table. These new inputs will allow modders to develop effects that can properly be optimized per varying particle and nebula detail levels.
* use std::move() for local variables that are copied but not reused
Addresses ~140 Coverity "Variable copied when it could be moved"
defects across 74 files. Every std::move() targets a local variable
whose value is consumed by push_back, emplace, assignment, lambda
capture, or a function call and is never read again afterward.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
* clang: use std::make_shared
* clang: use std::make_unique
* address feedback
---------
Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
1. Modify `ship_get_subsys_for_submodel` to use the subsystem indexer. This changes the operation from O(n) to O(1) and also allows the function to work with turret gun barrels.
2. Add an `isValid` check to `ParticleSource::finishCreation` to prevent unknown state from being accessed if the source is not valid.
3. Tweak `EffectHostTurret` and make sure it works for fighter beams.
4. Prevent `createOnTurret` from running on submodels that are not turrets.
* Add curve to control the duration of a particle source
* Also add fractional Life Left curve input for sources
* Actually register new particle curve output
* Two 1-line fixes for new particle lights
This PR provides 2 semi-fixes for the particle lights with 2 simple conditionals.
------------
First, it fixes#7124. In sum, it fixes the issue that new particle lights not affected by light quality slider. This fix is done by adding a conditional check so that particle lights only render when weapon lights do, at the highest lighting setting. This ensures that lower end machines can properly turn off particle lights to help with performance.
------------
Second, this PR adds an extra conditional to ensure that the system does not attempt to render particle lights if the radii is <= 0.
Light emitters logically do not cast light if the light emit radius is <= 0. In 2015, there are assertations in each of the `light_add` functions that trigger if the radii are <= 0.
With the new particle lights and addition of curves for particle lights, this can make result in light radii <= 0. This approach is useful to allow things like hit effects to only give off light if the hit effect is large enough (IE if it hits a large ship scale the radii to be larger, and if it is too far away or a small ship scale the radii to 0). So, in those situations of <= 0 light radii, the modder would expect that the light point is just not shown and simply not attempted to be rendered. Unfortunately, this is not quite the case, as any light radii <= for particle lights will trigger the assertation within the `light_add` functions.
The fix for this is simply to have early conditional checks for light radii. There is already precent for this in the code in 3 locations--1) within the weapon light code in `object.cpp` line `1365`; 2) within the beam light code in `beam.cpp` at line `2009`; and 3) within the fireball light code in `object.cpp` line `1457`. Note these sections also early out if the light intensity is <= 0 as an optimization step, which also makes sense.
This PR simply follows that precedence for particle lights by adding an early out if the light radii are 0. This allows modders to properly use a range of radii and helps ensure internal consistency with the code mentioned above that already does this early out for weapon and beam lights.
----------
Given the benefits listed above, having this PR in before stable would be fantastic (or a relatively quick point release after stable).
Tested and fixes the issue as expected. Happy to answer any questions and/or discuss!
* comment signpost
* Add parent / host input curves
* reorder some includes to allow particles access to ship.h
* Allow modular_curves to deal with functions returning optionals
* Add convenience function to return an optional from an objp and an instance type
* Add a bunch of particle curve inputs
* Fix internal linkage warning
* Add hitpoint and shield fraction (albeit limited to ships)
From Sept 15 onward in fast debug I hit this error when using weapon create
ASSERTION: "cur_frame < part->nframes" at particle.cpp:371
Assert: "cur_frame < part->nframes"
File: particle.cpp
Line: 371
Thanks to lafiel, `that assert should have an `|| (part->nframes == 0 && cur_frame == 0) appended beaause while we need to stay inbounds for animations, frame 0 for both is valid for static images`
* Make particles aware of the effect that spawned them
* Allow modular curves to call global functions from submember inputs
* Add more in and outputs for particle lifetime curves
* Allow post-curve velocity as a curve input
* fix warning and incorrect assig
* Disable CheckTriviallyCopyableMove
* Clang Tidy
Background:
Many mods, especially Event Horizon, have highlighted how versatile and useful using nebula are for creating a wide variety of immersive effects beyond just nebula, including weather, volcanic ash, specialty debris falling from the sky, and more. In addition volumetric nebula have opened another realm of possibilities for modders to creatively utilize. Furthermore, modders can not leverage the powerful updates to the particle system to create a wide diversity of effects, which can be also utilized within nebula (or any mission) by making weapons with those effects and then spawning those weapons with scripts/sexps. Just one creative example is exploding rock debris from a volcano (like in Event Horizon). The visuals of nebula poof though are of course spawned in density according to the `Nebula Detail Level` graphics slider in the Graphics tab of the Options menu. Thus, what the player sets will affect visuals of the nebula. As a modder creating visuals, this can have the effect where particle effects spawned from weapons used in nebula may look different in less dense fields. Ideally there could be a way for the modder to incorporate this Nebula slider detail into the development of their effects, to ensure that the effect visuals properly reflect and integrate with the nebula density that the player might see. The solution to this problem is luckily not difficult, as PR #6889 shows how it can be dealt with. That PR added a particle curve input `Particle Usage Score` which is incredibly useful to allow particle effects to scale visually according to the `Particle Detail Level` that the player has set in the Graphics tab of the Options menu. As such this utility could also be extended to the Nebula detail level to allow modders to develop weapon spawned effects for nebula missions that properly visually integrate with the nebula detail level.
This PR
This PR follows and extends the relatively simple approach of #6889, in that it adds a new curve input `Nebula Usage Score` for use within the particle effects table. This new input will allow modders to develop effects that can properly mesh with varying nebula detail levels--all with the aim to further expand the visuals and range of nebula utility for environmental effects.
* Another particle fix for standalones
Fix more standalone crashes from particles by "allowing the code to create particles, and just silently quit if in standalone. I.e., accept an invalid effect handle if in standalone and that'll just quit out the source on its first frame of processing." Thanks to @Bmagnu for the fix! Putting here to allow taylor and chief to more easily test.
* add needed include
* and another fix
* Make scripting use the full-blown particle system
* Add reverse option
* Add animation reversal as an option to modern particles
* Start implementation of beam particles
* Add multi-emission particle source API for legacy particles
* Attach beam muzzle particles to the correct host
* Reorder code in order to facilitate apparent visual size as modular curve input for particles
* fix lua api
* Typo
* Fix scripting and beam muzzle particles
* Remove muzzleflash code, prepare to replace with particles
* Begin mflash effect conversion
* Pass final parameters to mflashes and fix curve
* Remove deprecated particle function
* Add debris flame particles
* remove weapon_explosion table
* Convert shield explosion particles
* Fix modular curve full inputs and convert particle curve inputs accordingly
* Allow particle volume offset and rotation with curve-based rot around fvec
* Add Ring and Point Volumes
* Convert PSPEW to new system
* Make particle curve timing aware of interp
* Update todos
* get rid of performance waste
* Add last parameter for converted pspews
* Fix pspew bugs
* Fix direction for default pspew
* Fix order for voluem rotation
* particle vel interp
* particle vel interp 2
* Make beam muzzle stay parented to the firing ship, as it's likely the more commonly intended variamnt
* fix scripting particle lifetime
* Allow beam muzzle particle override
* Skip invalid pspews
* remove pspew dcf code
* Fix sparkler stretch
* Correct sparkler bia
* General sparkler weirdness
* Tune distribution of sparklers
* Convert Asteroid particles
* Fix conversion warning
* Fix conversion warning again
* Fix conversion warning again again
* Really clang?
This was discovered thanks to the new assertions from #6596. For particles with 0 velocity, the code would attempt to normalize a 0,0,0 vector with predictably undesirable results. So, pick the global `z` vector in these cases, while normalizing in the usual case.
Most places in the code that use `vm_vector_2_matrix` do so on already-normalized vectors. Changing these to `vm_vector_2_matrix_norm` avoids redundant normalization.
BMagnu