Running a macro with infinite instruction loops freezes the game. Infinite instruction loops were properly detected and halted in an earlier version; not sure when it stopped working.

Add a global hotkey for showing or hiding the interface.

Dying or becoming incapacitated during macro execution sometimes causes the game to not respond to even PAUSE input, causing a softlock until the Player is destroyed.

Add a filesystem watcher that should mostly preclude the need for manual reloading.

Add a trigger for entering or exiting pipes.

Because the Player does not update in a pipe, it is probably not reliable to do this is the current macro execution loop. This mechanism may require implementing a latent trigger or a loop not tied to the Player.

Add minimize/restore button to windows.

Add button that opens the folder containing cookbooks in Explorer.

Instructions currently interact with a Stack<object> which requires some ugly casting that wouldn't be necessary with a better implementation. Consider making a dedicated struct as the information carrier instead.

TAMacro should handle invalid warps more gracefully.

Unsure if this bug still exists (will test after the holiday), but it has been listed in the wiki for a while now.

Allow partially setting the scugstate (perhaps with JSON-style input).

Add an optional window that displays the current macro callstack.

Save window position across RainWorldGame and application sessions.

Currently, macros are static; if macro A executes itself (once, not endlessly), it resets its own state.
For example, the following macro only runs R~20 once, regardless of where Slugcat starts.
If non static, it would run R~20 once for every L~20.

/NAME: foo
L~20
>goto 1 if scug located left of 500
>execute foo
>label 1
R~20

Macro names can contain characters which shouldn't be allowed (e.g., / in a macro name would make >executeing it impossible).

Add support for multiple players running macros simultaneously.

Possible designs:

1. Add an optional flag to each line that indicates which player the line affects, default to 1 (or a macro-level default). This is incredibly cumbersome to write a macro and would require refactoring how exactly a macro tick is decided.
2. Add an interface-level setting for deciding which player runs which macro. This requires making the library and macros non-static and makes the interface more complicated.
3. Add an extension to >execute which allows specifying player. This requires making the library and macros non-static. >execute does not tick and so simultaneously running different macros for different players would not be complicated.

Because the macros affect a specific Player, they do not affect possessed pups (via beeglitch), which should always respond to player 1 input.

Fixing this robustly may require intercepting input handling at an earlier stage.

if the slugcat is on a pole. Maybe could be expanded to include states. My use case is so a fast-climb macro automatically stops at the top of a pole.

May require special handling for lines that are too long, especially if devconsolas isn't used.

Add support for analog input beyond fastroll.

Syntax:
>loop macro (for number|while condition)
if its a number, then macro will be executed x amount of times (not yet possible, but usefull)
if it's a condition, execute while true (possible with current system, but impractical)