Controls 0, 1, and 2 - Vectorize Controls_config, Refactor Control Presets, and Use Undosys for undo/redo actions done in the Controls configuration menu.
* Revert Joy_axis_action_index changes. Feature to be added later
* Strip out most of the preset and undo capability. Only the backup ability survived.
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.
Joshua Glatt