Runtime flags: New bit-fields for storing various interpreter states

[florianessl]

I suggest adding some general-purpose UInt32 fields for following data structures:

• SaveEventExecState
• SaveEventExecFrame
• SaveMapEventBase

This PR adds a new field 0xC8 "easyrpg_runtime_flags" to these 3 structures and also includes some suggested bitmask values for "SaveEventExecState" based on some requirements for @Ghabry's suggested rework of the "SetInterpreterFlag" command -> EasyRPG/Player#3123

[florianessl]

I think this issue is pretty critical, so I just pushed an additional new field here to address it before 0.8.1 is released:
SaveMapEventBase.easyrpg_clone_map_id

There's currently no way of determining if an event has been inserted dynamically via the new "CloneMapEvent" command.
This would make some tasks that require inspecting & applying patches to an active map impossible.

I'm currently trying to achieve in-game changing of the game's language without having to re-enter maps & this new command would make it impossible to implement this in a reliable way...

[Ghabry]

I'm currently trying to achieve in-game changing of the game's language without having to re-enter maps & this new command would make it impossible to implement this in a reliable way...

Ideas from the chat to prevent issues with "index adjust" because ShowMessage can be longer or shorter:

Original command (3 line message box)

ShowMessage   This is a line of text.
ShowMessage_2 This is another line
ShowMessage_2 This is a 3rd line

Case 1: Translation is shorter

ShowMessage   This is a translated line.
ShowMessage_2 This is the second translated line.
EasyRpg_NoOp  <- Padding command to keep the index the same

Case 2: Translation is longer (Problem):

ShowMessage   This is a line of text.
ShowMessage_2 This is another line
ShowMessage_2 This is a 3rd line
ShowMessage_2 This is bad I don't fit :(

Case 2: Translation is longer (Solution):

CallEvent    ID 1000, Page 1   <- To be decided: Event creation, ID & Page
EasyRpg_NoOp
EasyRpg_NoOp

In the called event:

ShowMessage   This is a line of text.
ShowMessage_2 This is another line
ShowMessage_2 This is a 3rd line
ShowMessage_2 I fit now <3

[Ghabry]

@florianessl the flags can be actually encoded using our Flag feature.

This way you can do both easyrpg_runtime_flags.patch_destiny_on etc. or easyrpg_runtime_flags.flags for the entire bitmask. So less bit masking needed in the code.

I will do directly the same for maniac_event_info. Can you tell me the bit mapping of this?

---

The flag stuff we have in lcf is not usable for what you want to do with it. But I'm working on a patch so the flags can be added at all locations you propose.

[florianessl]

@florianessl the flags can be actually encoded using our Flag feature.

This way you can do both easyrpg_runtime_flags.patch_destiny_on etc. or easyrpg_runtime_flags.flags for the entire bitmask. So less bit masking needed in the code.

I will do directly the same for maniac_event_info. Can you tell me the bit mapping of this?

The flag stuff we have in lcf is not usable for what you want to do with it. But I'm working on a patch so the flags can be added at all locations you propose.

All the mappings for "maniac_event_info" were already documented here:
https://github.com/EasyRPG/liblcf/blob/master/generator/csv/enums_easyrpg.csv
(EventPage::ManiacEventInfo)
I checked for these values using Maniac´s "Get Interpreter State" command to see if they matched & also analyzed the field inside the save data. The only part that I couldn't verify was the flag value "64" for BattleEvents. (As noted in a comment in the commits of the associated PR)

[Ghabry]

Ah okay so they aren't really bitfields but a mix of both. Not suitable for our flag code

[Ghabry]

Thanks I picked the suggested chunks and implemented the runtime_flags in terms of the "Flags" class we already have.

Closing this in favour of #492