This seems preferable to storing an entire mc_info object on every weapon, when the vast majority of projectiles (by the very nature of the fact that they still exist) won't have collided with anything.
On the other hand, I'm not wild about allocating and freeing memory every time a weapon collides with a ship or debris. If anyone has a better solution, I'm all ears.
Main use case is headanis where only one is played at a time and
caching the frames merely increases memory use & fragmentation, leading
to malloc errors with heavy apng use
The APNG changes required some additional work. A cursor now owns the
bitmap handle that will be used for the cursor. This is required in
order to support variable FPS cursors.
Use unique_ptr for safer pointer management
Simplify frame delay calcs when looping
Ensure animated cursor times don't lose precision
Switch Error to an Assertion
Fix LUA documentation formatting
Handle total_time directly requested from bm_load_animation
Make generic_anims request total_time directly
Move png-vs-apng check to apng class
Remove redundancy in apng exception messages
Update comments
Fix silly issue preventing getFrame() from working
Remove infinite loop when calculating frame num
Convert more animations to use new frame calc function
Reorder precendence of static image vs animation loading
i.e. load animations 1st if requested, then load still images
if the animation failed to load or if animations weren't requested
i.e. apngs (pre)loaded into bmpman slots
handles apng variable frame delays
Includes new lua function (getFrames) to find the current frame for
apngs. Also uses new function to correctly display apngs for mission
loading animations, ship thrusters & engine glows.
A few comparisons weren't excluding their upper bounds properly, and the documentation for the l_Wing length function was the documentation for the l_Mission_Wings length function.
The l_Mission_Wings indexer will return an invalid wing if supplied an invalid name/index. However, you had no way of telling that this was the case because there was no isValid() function to test its validity.
The purpose of this function is to provide modders the capability to jump to a mission using LUA scripts. There is an optional argument for jumping to a hub mission, a good example is the JAD campaign map.
Previously, the "this != NULL" checks in the isValid() methods were covering most of these cases, but they were removed as part of PR #274 because clang was generating warnings because calling a method on a null pointer is undefined behavior (so the condition *should* be tautological). This performs the checks outside of isValid(), which should avoid (at least this variety of) undefined behavior while fixing the crashes that dereferencing null pointers was causing.
MageKing17