Feature RFC: Pre-Rollover Script Concept

[MCroft]

I am thinking of a feature that is is being worked on for Autoscend that might make a useful platform feature.

The idea is that a specified time before rollover, stop whatever we're doing and execute a Day-Ending Script.

I'm thinking it would need to
1: stop any running script
2: clear the command buffer
3: run a user-selected script that could do anything, but would most likely consume to full and put on pajamas. Other things may also make sense. Pulls, etc...

It would probably have to be a best-effort based script; if a running script did not exit, you might not get it run.

Also, not entirely sure what the best User Experience is if they're in the GUI or the Relay Browser when T-300 (or whatever the timeframe ends up being). If there's no script running to interrupt, does it wake up and run?

This is all related to the scripting discussion from a while back about how to have an abort function at all.

If you want to have your script do anything whatsoever when it exits, wrap the code in your main() function in a try/finally construct.

This is VeracityMeatFarm:

   try {
    set_property( COUNTER_SCRIPT, new_counter_script );
    run_tasks();
    } finally {
    set_property( COUNTER_SCRIPT, old_counter_script );
    // ... //

    print( "Net income = " + pnum( meat_delta ) + " Meat in " + pnum( turn_delta ) + " turns. Meat/Adventure = " + pnum( run_mpa ) );
    print( "Cumulative income = " + pnum( meat_total ) + " Meat in " + pnum( turn_total ) + " turns. Meat/Adventure = " + pnum( cumulative_mpa ) );
    }
}

My script could "exit" or "abort" and it would still execute the finally block.

 

[phreddrickk]

autoscend, and a few other scripts, have a bespoke property for interrupting that can be flipped on using a relay script, giving the script the opportunity to safely abort at its leisure.

One possible implementation of this would be to have it set some "interruptScript" property that multiple scripts could share use of and that would get set by the timer and would get un-set once the rolloverScript starts running.

The issue of course is that this would be "opt-in" for running scripts, and I suppose it wouldn't necessarily successfully interrupt things that aren't scripts. The advantage is that by making it opt-in for running scripts, you can guarantee that they terminate elegantly and won't unilaterally interrupt a script that doesn't want to be.

 

[Malibu Stacey]

One possible implementation of this would be to have it set some "interruptScript" property that multiple scripts could share use of and that would get set by the timer and would get un-set once the rolloverScript starts running.

If this happens, a button on the interface to toggle the interruptScript property would be lovely.

 

[Baden]

autoscend, and a few other scripts, have a bespoke property for interrupting that can be flipped on using a relay script, giving the script the opportunity to safely abort at its leisure.

One possible implementation of this would be to have it set some "interruptScript" property that multiple scripts could share use of and that would get set by the timer and would get un-set once the rolloverScript starts running.

The issue of course is that this would be "opt-in" for running scripts, and I suppose it wouldn't necessarily successfully interrupt things that aren't scripts. The advantage is that by making it opt-in for running scripts, you can guarantee that they terminate elegantly and won't unilaterally interrupt a script that doesn't want to be.

This would be a lovely feature.

 

[MCroft]

I've thought about `interruptScript` as well. It doesn't (immediately) let me automate, but it would keep scripters from needing to invent their own. And it might give me the infrastructure to make the automated change. Let me take a look!

 

[phreddrickk]

One issue with interruptScript is that, well, it's not entirely clear when we would want to un-set it. If someone chains a couple of CLI commands, we probably want to skip those as well. If a script calls another script via cliExecute, and the inner script obeys interruptScript, we dont' want it to get unset for the outer script.

To implement this alongside a rolloverScript we'd just need a rolloverScript and a rollverScriptTimeLimit (or whatever the pref for "when do we pull the trigger" is).


That being said, as I start to think about it, interruptScript is awfully similar to this proposal.

 

[fronobulax]

As a user I don't care about pre-rollover because rollover is past my bedtime and all my mafia sessions will be shutdown and logged out by then

I get frustrated when I mash Abort/Esc and the running script restarts or the command I had queued runs. So anything that can be linked to this button mashing and works better is an improvement.

I remember Ye Olden Days when script authors did not even attempt to capture errors and restore state. So I can forgive some kind of stop that actually stops but at the cost of requiring state to be manually restored.

So as a first step I wonder about a global preference that script writers can opt in to use and stop cleanly and mafia would use to prevent any new scripts from running, clear the command queue and so on.