1) Upgrade the pilot file code to correctly save flags whether entries are added *or* removed
2) Make the tech-db/tech-db-multi ship flag handling consistent
3) Add scripting support for intel entries
4) Add scripting support for adding and removing entries from the tech room
5) Minor cleanup
1) Write all non-UTF-8 strings to JSON, either by converting or truncating
2) Add `coerce_to_utf8` function
3) Tweak `read_raw_file_text` because the function returns length on success, not 0
The largest new feature is that it is now possible to include other
files into the RML by using the "include" tag. This is useful for making
markup files more modular.
Also added some more options for existing things (e.g. built-in detail
options).
There are now three states for cutscenes: always viewable, where they will appear no matter what; never viewable, where they will never appear; and viewable, which can be modified during the campaign. Currently cutscenes will go from not-viewable to viewable, but organizing the flags this way will allow a future feature to make cutscenes not-viewable, if that is desired.
There's also a small edit to csv_convert to guard against array overflows. Not directly related to the feature but it's in the same place and affects the same code.
When loading a .plr file, HUD_config.rp_dist is loaded and then sanity-checked; if the value is out of bounds, a Warning is generated and RR_INFINITY assigned. HUD_config.rp_dist is also loaded when loading a .csg file, however the sanity check isn't present; this copies the block over so the behavior is identical.
"Cloning" failure was actually being caused by the pilot verification function resetting all pilot info and then not loading controls from the file to replace them.
The Control_Config array would all be set to -1 and then would get written into the file the next time the player was saved, making it seem that the controls were not being copied.
The original and current code would reset controls to defaults when a pilot was created. And it would just let the old controls remain in case of a clone. The above problem would occur just as you hit accept on the bottom of the baracks screen.
This was an oversight in the JSON changes since those were made long
before the CFile location flags were a thing. This uses the correct
location flags for enumerating pilots for conversion.
This changes the pilot reading code to always use JSON files for storing
the pilot data. Old pilots are converted to the new format when FSO
starts and after that point only JSON pilots will be used.
The previous code simply set a boolean flag to indicate that the data is
"invalid" which failed the campaign loading operation. With these
changes, those entries will simply be skipped. That can happen if a mod
added or removed a ship or weapon class or if two campaigns share the
same campaign name.
This can be used for mark parts of the code which should be unreachable
in normal execution. In debug mode, if such a statement is reached an
Error dialog is shown which aborts the execution. In release mode the
macro is replaced with a compiler specific expression that lets the
compiler know that this part is unreachable which allows it to optimize
the code better.
Add missing new line to BSP Parse timing and make it nprintf("Model").
Log value of HUD_config.rp_dist when it is not valid.
Fail reading a .plr file if it has a zero-length section.
startSectionWrite would push unnamed sections on _sectionOffsets, but
endSectionWrite was not removing them, leading to _sectionOffsets
containing tens of unnamed sections when parsing the HUD config.
Pop the unnamed sections in endSectionWrite.
This is a new implementation of the JSON dumping which was already
proposed in #22 but this version tries to allow implementing both
reading and writing JSON files without having to change the existing
code too much. This is done by using an abstract class to hide the
differences between writing the JSON and binary files.
This is currently only capable of writing the files but not reading them
so if the option is enabled all changes to the pilot file are lost. I
will implement reading after this PR has been merged since I would like
to reduce the amount of changes that need to be reviewed.
This introduces a new mechanism for handling bit flags. Instead of using an int (or two, or three) to write bits into, this uses the std::bitset in a wrapper class that accepts an enum class as input. This means that certain classes of errors we've had a few of in the engine, where a coder used the wrong set of flags or checked them against the wrong variable (SF_STEALTH vs SIF_STEALTH, for example) can now be detected at a compiler level rather than not at all.
Taylor Richards