Maniac CallCommand - Add ResolveEventCommand

[jetrotal]

in maniacs this is a thing:

To support it, this PR Introduces the ResolveEventCommand method to process Maniac Patch @cmd (Call Command) event commands, resolving them into their actual form. Refactors interpreter logic to use this method where event commands are accessed, ensuring correct handling of Maniac Patch commands and improving compatibility. Updates function signatures and documentation accordingly.

Test map (dog npc):
Map0003.zip

[Ghabry]

Your screenshot is misleading. The code in Map0003 is different to it.

Also a typical problem with these AI generated commit messages: They explain "what" they did but not "why" they did it.

---

So here is the why explanation:

Commands like ShowMessage read the event commands right after to locate stuff such as ShowMessage_2 (line continuation) or ShowChoice.

What is new: The "right after" scan also supports now CallCommand lines for on-the-fly generation of e.g. continuations. To implement this, the parsing logic from CallCommand had to be extracted into a new method ResolveEventCommand which is now used everywhere where these continuation scans happen.

[jetrotal]

Sorry I edited the map but forgot to save before zipping.

Correct map:
Map0003.zip

Yeah, I also forgot to explain why those changes happened. The idea, as you said, is to properly support parent/sibling commands both as its typical command or as a call command.

[Ghabry]

This PR actually looks fine code-wise. Will revisit it again in January to do some testing.

[jetrotal]

while doing some tests in my free time I discovered this:

Maniacs also supports using variables in a bunch of other commands, that we don't support.
This happens due to our implementation of call command:

// Our implementation pushes a new frame containing the command instead of invoking it directly.
   // This is incompatible to Maniacs but has a better compatibility with our code.
   Push<ExecutionType::Eval, EventType::None>({ cmd }, GetCurrentEventId(), 0);

the solution to this seems to be adding something like this right before the lines above:

bool Game_Interpreter::CommandManiacCallCommand(lcf::rpg::EventCommand const& com) {
   // ...

   // Finalize command parameters
   cmd.parameters = lcf::DBArray<int32_t>(values.begin(), values.end());
   
   // 1. Inherit the indentation level so loops and branches can find their pairs
   cmd.indent = com.indent; 

   // 2. INLINE FAST-PATH FOR CONTROL FLOW
   // Control-flow commands inherently manipulate the execution frame's instruction pointer.
   // Because they never trigger async Yields, it is completely safe to execute them inline.
   switch (static_cast<Cmd>(cmd.code)) {
       case Cmd::JumpToLabel:
       case Cmd::Label:
       case Cmd::Loop:
       case Cmd::BreakLoop:
       case Cmd::EndLoop:
       case Cmd::EndEventProcessing:
       case Cmd::EraseEvent:
           return ExecuteCommand(cmd); // Run inline, modifying the parent frame!
       default:
           break;
   }

//...

Can't test it due to my current work + college routine, I'll probably open a new PR for that, to not postpone (more) the aproval of this one.

[Ghabry]

yeah for control flow commands they must (unfortunately) run in the same context. I'll amend this

[Ghabry]

Not setting the indent was actually a real bug.

Also fixed some performance issue in ResolveEventCommand. In 99.9% of all cases this command will return the input command. In your version it copied the command which is kinda wasteful, especially in loops. Returns now a reference instead.

Flow control should work now. Please test again @jetrotal

---

The more I see this stuff the more I hate this command cough

[jetrotal]

Control flow didn't change, at least related to jump to label, here's my map for futher testing:
Map0001.zip

[jetrotal]

looking good in my tests!