Add a `SaveAndQuitReenter` command

[psyGamer]

Adds a SaveAndQuitReenter, <Input/Simulate> command.

• Simulate (default): Simulates the Save & Quit, but never enters the main menu and doesn't require Unsafe
• Input: Inserts the inputs required to Save & Quit and to reenter the correct save file.

[psyGamer]

Actually i just noticed a few things I missed before opening this...

• [x] SaveAndQuitReenterMode command (should be easily copyable from StunPause)
• [x] Actually set SaveAndQuitReenterMode to Simulate by default
• [x] Add these commands to the Studio command list
• [x] libTAS support? I'm pretty sure this wouldn't work for libTAS, since the inputs are generated at runtime. Maybe by just assuming the first slot when exporting for libTAS? Also is libTAS support even still relevant/used today?

[psyGamer]

I'm not sure what you want to do with libTAS, but everything else should be ready to merge. EDIT: I've noticed that simulate doesnt always work correctly, currently looking into that. EDIT 2: Seems to work properly now.

[DemoJameson]

The need to insert inputs at runtime is due to adapting arbitrary slots I'd suggest forcing the first slot to be used so that the inputs can be inserted during the parsing phase After all, this command is mainly for the convenience of S&Q when running IL, and for full game run's TAS, I think it should be acceptable to force it to be specified as the first slot Just need to determine if the currently selected slot is the first, during the input mode parsing phase

[psyGamer]

It not just intended for IL, but also running a full game file. My first slot is my main save file (and i assume thats also the case for most others), and having to either adjust the TAS or move save files around just to run it is quite annoying and the thing which this is intended to solve.

Are there any issues with inserting inputs at runtime other that libTAS support? Because if not, I'd suggest only forcing the first slot when exporting for libTAS.

[DemoJameson]

I don't see any other isuues so far yeah, forcing the first slot when exporting for libTAS should be good enough

[psyGamer]

I think that should work. Didn't test it by running the game actually with libTAS, but it seemed correct after looking at the generated movie.

[DemoJameson]

inputController.FastForwards and inputController.FastForwardComments also need to be shifted and I think it's better to insert the inputs at parsing instead of runtime when simulate mode

[psyGamer]

So if the TAS starts on file select we can't determine which slot it will use (ofc you could make assumptions by checking the selected slot but still) So while parsing it would insert nothing/insert slot 1 load. If at runtime the command now calls RefreshInputs(), would it correctly insert the inputs now that we know which slot to use?

EDIT: Didn't see the simulate mode. But the problem still applies

[DemoJameson]

I don't think we need to care which slot, when in simulate mode don't we just insert the waitting frames

[psyGamer]

I meant for Input. I agree that simulate should just insert at parse-time, but do you know if my proposed solution for reparsing at run-time would work?

[psyGamer]

Turns out that not using any runtime inserted inputs greatly decreased the complexity. It now refreshes the inputs when the actual slot differs from the inputs, while even accounting for the potential scenario that the slot somehow changes turing the TAS.

[DemoJameson]

It looks like InsertedSlots doesn't need to use a dict, since all the commands record the same value

[psyGamer]

In 99.999% of all cases, it's the always the same slot, but if a TAS for some reason switches save slots, then inserting different inputs before the current frame would incorrectly offset it. I know that this will probably never happen, but I'd still like to account for that possibility.

[DemoJameson]

okay, I will keep that