Using `sav_objnum` caused the player to be restored into the object slot
of the pre-load level, in the object table of the post-load level. This
was harmless when the slots were the same, and wrong when they were not.
It became noticeably wrong when more player data was moved into the
object. After those changes, the player's data was stored into the
correct post-load slot, but the ship was assigned to the pre-load slot.
Remove the incorrect slot switch, and add an assert that the object
being overwritten is a player ghost. With the incorrect switch present,
this assert will catch most (but not all)[1] cases of the incorrect
restore. With the incorrect switch removed, this assert succeeds.
[1] In the unlikely case that the post-load slot was a player start, but
for a different player, the assert could succeed despite the slot
mismatch bug. In the common case, the post-load slot would not be a
start of a different player; it would either be the correct player slot,
in which case `sav_objnum` was harmless, or it would be some other
object, such as a robot.
Some flags merit a type other than int8_t. Begin moving flags out to
distinct variables with their own type.
Add static_assert checks that the ABI relevant structures do not change.
The latter more clearly shows that the code flow will not proceed past
this point while the menu is open. This conversion sets the stage for
later changes to make these menus asynchronous.
Commit e6875641c9 moved allowed_chars from global scope into
individual newmenu_item entries. However, it did not enforce that this
field be initialized, and some callers failed to do so. The save game
menu was such a caller, and crashed when using an uninitialized value as
the allowed_chars pointer. There is no character restriction here, so
explicitly set the pointer to nullptr.
Reported-by: kitelessd <https://github.com/dxx-rebirth/dxx-rebirth/issues/571>
Fixes: e6875641c9 ("Move Newmenu_allowed_chars into individual newmenu_item")
