This is a large proposal, and many sub-parts of it can be their own tickets in their own right, but I think it is important to include all the sub-parts in the initial proposal to ensure they are understood by readers. This is a large proposal with a lot of moving parts, but I believe it would be relatively easy to implement, and brings a lot of side-features along for the ride. `AHIGH LEVEL OVERVIEW` The goal of this proposal is to create a system where people can make bots that function mostly in-game (though still with the client *open*, so as not to compete with crons), without needing to do complex OOG stuff like sending keystrokes, figuring out how to read data, AHK/node/robotjs/etc. My hope is that this can be a "good enough" automation system that it can replicate like 80 to 90% of what a state of the art OOG bot can do but significantly easier, so that more players can compete in the high-level botting game without having to be experts in the field. I do not expect this to replace many existing OOG systems, but it might be able to in many cases. The system is build around `C/auto`, with some QOL features added on top. `ATHE PROPOSAL` (note: the first few parts are QOL/buildup, the last couple are the important ones) 1) `C/auto` QOL 1: in addition to `C/auto` and `C/auto <mindelay>`, support `C/auto <mindelay> foo.bar {baz:quz}`, for easier startup (i.e. rather than having to run the script, wait for it to return, then `C/auto` it, put the script and args in the `C/auto` line) 2) `C/auto` QOL 2: add support, in `Nok`/`Nmsg` objects, for a new key `Ncancel_auto`. The client never displays it, but if it is set to a truthy value and the client is running `C/auto`, the `C/auto` is canceled with a message like `C-auto terminating at script request-` (i.e. indicate it was requested). This allows for cleaner output when ending. 3) `C/auto` QOL 3: Require 2 [or more, perhaps by tier?] *identical* errors in a row to end `C/auto`. One error, or ever-changing errors, should keep on keeping on. This gives `C/auto` enough resilience to be relied on over night or while at work without the need for a watchdog bot to keep it going. 4) The big one: If a user is `C/auto`ing a script that belongs to the caller (that is, if the current user is foo, and they are `Cauto`ing a script owned by foo, but not if they are using a script owned by bar even if bar is an alt of foo), the client should inspect the return value for a new `Nnext_args` key (type string) in any `Nok`/`Nmsg` returns. If set, the client replaces the *current* set of args it is using with what is specified in `Nnext_args`, and re-checks to make sure "is this valid to `C/auto`" (if not, the `C/auto` can simply terminate). Note: this replaces the old args, they do not have to be saved. In effect, it's a latch. For example, if the current script being `C/auto`'d is `Cfoo`.`Lbar` {`Nquz`:`V"quuz"}`, and it returns {`Nok`:`Vtrue`,`Nmsg`:`V"hi"`,`Nnext_args`:`V"{target:#s.``Ftrust``V.``Lpublic_sonoso``V}"`, the next script run the client sends will be `Cfoo`.`Lbar` {`Ntarget`:`V#s.``Ftrust``V.``Lpublic_sonoso`} 5) In all the same conditions `Nnext_args` is used above (i.e. script owned by caller, being `C/auto`d), look for a key `Nhardline`:`Vtrue`. If set, the client should execute `Fkernel`.`Lhardline` and type the numbers in at a reasonable human pace (say 2 per second), and then resume executing it's `C/auto` workload once control is returned. (NOTE: `Nnext_args` may or may not ALSO be present, just that `Nhardline` uses the same 'should i look for it' criteria) `AUSECASES` First off, this enables poor-man's string-to-scriptor easily: you can simply add a new scriptor to `Nnext_args` (one can imagine a followup proposal to enable `Nnext_args` checking on cron bots). This immediately enables such tasks as: * auto-farming (start with no args, request a t1 or t2 corp, scrape it to the db, then start requesting locs and hardline as needed. when out of hardlines or locs, back to scraping) * t3 scraping, with access to the db/fileserv scripts * fragment scraping (pull scripts from things like ls, request them, scrape them, etc.) * dynamic job allocation: just grab whatever scripts are needed for a given task, use them, then drop them in favor of other scripts, to minimize parse time (again, if this were added to cron bots as well, this would be amazing) `ADESIGN DECISIONS` This is designed specifically to work largely inside the client, and therefore necessitates the client being run for botting to work. This avoids too much conflict with crons (which work when you are offline but have a resource cost). Bouncing everything back through the client is deliberate, to ensure you basically either pay in in-game resources (crons) or OOG resources (always-on hardware), rather than creating a new system that requires neither, or attempting to shoehorn a cost onto `C/auto`. The requirement that the script being `C/auto`d is owned by the caller prevents this from interacting too significantly with the sec level system: if you wrote the script, you trust the output, and if the output adds a nullsec to your next call, that's on your head. This would likewise be acceptable in the logical expansion to crons: you wrote the script, you decide the return, if it asks for a scam you've no one to blame but yourself. Users can trivially write short wrappers around shared scripts for bot fleets, the same way we do for cron bots. There is a minor issue of current scripts that might return untrusted third-party script results unaltered, which could be abused, but that usecase seems small. By having the client latch to new args rather than retain old ones, i believe it requires minimal changes to the client; just an extra "scan output, re-validate `C/auto`-safe, and update what i'm `C/auto`ing". No ongoing "and do that for one run then switch back", etc, which could get complicated fast. The goal is minimal changes needed for largest gains. `AUSECASES NOT COVERED` The largest usecase that this proposal, among current OOG-bot uses, that is not covered is any kind of bot that needs to so significant data input from an out-of-game source. For example, importing a magnara database from scratch, importing chat API data, etc. I think I am one of the few users that significantly relies on bulk data import and I can live with this not being covered for simplicity's sake. We always have real OOGs, and the goal was just "good enough most of the time", not perfect. User switching and script editing is explicitly NOT covered by this proposal, which is meant to be a MVP type thing. These advanced use-cases could be added in a followup after the initial system is implemented and tested, but for now, "one user" is very much baked into this proposal for simplicity.