External Process send Rerun

[YPetremann]

As for now their is more and more tools to help develop that start tic80.
Code and assets are reloaded on file changex in editor out of the box, which is great. But as for now doing a rerun need either to press Ctrl-R in-window or to send run in the in-window console.

For thoses tools this is'nt practical

I would suggest three alternatives:

• File based: a metadata could be inserted in the code to indicate how it should rerun the cartridge on file change (never as default, external to respond only to external file change, internal to run on save in tic80, both for internal and external at the same time)
• For Posix based systems (Linux, Mac, maybe Android): receiving a SIGUSR1 kill signal would be equivalent of a Ctrl-R
• For tic80 as child process: allow parent process to send keystrokes through stdin so Ctrl-R, Esc, Ctrl-S ... could be sent from the master process, in the console it could type commands and in-game keystrokes would be received by type() (a Ctrl-R or ^R would be as effective as in-window)

[YPetremann]

During the night I though of the file based metadata, it would really be universal, could be used by users and tools:

-- script: lua
-- autorun: load save watch

a metadata could be inserted in the code to indicate how it should autorun the cartridge, this metadata would be read at each file change (load, save and watch) and used to determine if it would run on this action

• load mean that the cartridge is run on load command
• save mean that the cartridge is run on save (in tic80)
• watch mean that the cartridge is run on external file change

to prevent autorun to be problematic, there could be a one second delay where the user can Esc to cancel autorun

[nesbox]

I think it will be better if we add this feature to the options menu.

[YPetremann]

An option menu can be interesting if people intention is to run tic at every save and reload But having a way for tools to opt in and out at will by adding or removing a specific metadata can be powerfull

Also to clarify, it only make sense when the developer has access to the source outside of tic80 and given that it can be hard to remove the metadata outside of tic80, so we can see it as a pro only feature or even a non-tic file only feature