This adds `EnumAND` and `EnumOR` which will return new enums based on the specified operations. These are handy for enums that correspond to bit fields, such as those used for object persistent sounds.
With several upcoming POF format enhancements (byte alignment, external weapon rotation, submodel translation) it makes sense to warn users if they happen to load an unsupported POF file.
The assumed location of a ship's "EngineSnd" is at its rearmost extent, which is fine for ships with engines, but not suitable for stationary objects such as space stations and comm nodes. If the ship doesn't have an "engine" subsystem, place the persistent sound in the center.
* wip
* basics are working
* turret case is handled
* better fighter beam handling
* missing commit?
* handle missile spawn
* clean up, commenting and ssb handling
* random in sphere and per burst rot counts for "share random" flag
* clean up, clarity and comments
* accidental whitespace changes
* bugfix
* NULL -> nullptr
* more efficiency/clarity
* review tweaks and bugfixes
Here's a bug that's been around ever since version 3.6. If the subsystem names were not essentially the same, the function wouldn't do the expected string comparison.
If a weapon has "inherit parent target" but not "child", a Warning will be generated. However, there is no dependency between the two flags; the weapon will function as the modder presumably expects. The Warning even seems to indicate this, by saying "No changes in behavior will occur" (as opposed to other similar warnings, which generally indicate that a flag will be ignored). Since the situation being warned about does not actually cause any issues, the Warning is entirely superfluous. As such, I've removed it outright.
The script-eval SEXP evaluates all arguments as individual script commands, which is not ideal because most FREDders expect the arguments to be concatenated. Since the script-eval-block SEXP handles its arguments this way, it makes sense to hide the script-eval SEXP in FRED to prevent confusion.
Commit 6c2ebab01c (#3439) added a `max_line_length` argument to `split_str()`, but one call had the extra argument added in the wrong spot, and so a previously-pointless-but-harmless `ignored_char` of 0 became a `max_line_length` of 0, resulting (ultimately) in an exception in the unicode code when the iterator tried to decrement at the beginning of a ship's description. This gets rid of the argument entirely, rather than reordering them, because ignoring null characters doesn't really do anything anyway.
I've also added `Assertion`s to check `max_line_length` that should prevent this specific problem from occurring again in the future.
Baezon