Same Atlas Node Timeout!

Feature Request
1

I don’t like when it plays the same node again, like sometimes if it dies on a node, it will replay it to try to beat it and not use your tablets (Already attempted maps cannot take tablets!) , which wastes a juiced map

Also a general timeout for same named maps would be cool. Like if it plays something called “Bliss” its next 3 map choices cant be bliss, and that knowledge would have to be remembered even if the bot is stopped and started again, so a little file would have to be kept as memory.

Like “Oh i see i played X,Y,Z maps the last time I ran, and in the recorded file it would look like

Atlas node name = 2
Atlas node name = 1
Atlas node name = 3

So say it checks memory, and it see’s “Bliss=2” it would say to itself, okay, for the next two runs, i CANNOT play a map called bliss, its ignored.

So it places your waystone somewhere else, lets call the map unicorn town, when it opens unicorn town, it will deduct 1 from that memory list.

Bliss=1 now

Now it plays another map, let’s called it cat dungeon. It knows to delete 1 from all of the cool downed maps recorded in our new memory file once again.

Now bliss ignore is completely removed from our new memory ignore list file, because it has reached 0, and been deleted / replaced by the next map to start an ignore countdown on. It should pretty much always be one will be going into the ignore list while one is being removed, once you actually get playing like this, or something close to that.

And cat dungeon and unicorn town would be added on, in my example, unicorn town would have left off at 2 ignores left, and cat dungeon would be at 3, having just been added.

That way it ALWAYS has a working memory of what not to explore, the only time it will skip this is if it failed on a atlas node and it HAS to complete that node to get to somewhere important, and there is no other path to get there, in that case, it would be perfectly fine to waste a juiced map

But… with that being said, if you didn’t want to waste a map in edge cases like that, you would need once again another system where a person could have pre-prepared “mover maps”, if it fails a map, and it MUST play it again to move to an important spot, and there is no other path, then it will say to itself “Okay, I’m ignoring the map IPD for a second, and i’m going to go get one of the mover waystones from tab 1” (The user would have to select a stash tab that is mover waystones only!)

Then it would kindly take the shitty mover waystone, play and beat the map you failed, then continue on with your normal map IPD file and waystone rules.

1 Like
2

I know I can write in a confusing way, so I had chatGPT 5-thinking take what I said and rewrite it for you, i’m not sure which will make more sense but this A.I version is structured more robotically which might make it easier for you

Core goal

  • Prevent replaying the same atlas node within a short window to avoid wasting juiced maps and tablet eligibility, with persistence across restarts.

Cooldown rules

  • When a map named X is played, add X to an ignore list with a countdown of 3 runs (configurable) so the next 3 choices cannot be X.

  • Maintain a persistent file on disk that records {mapName: remainingIgnores}; load at startup and write after each run.

  • After each map completion, decrement remainingIgnores for all tracked maps by 1; remove any entries that reach 0; then add the just-played map with remainingIgnores = cooldownLength.

Death/attempt handling

  • If a node is failed/attempted, do not immediately replay it because attempted maps cannot take tablets and would waste a juiced setup.

  • Exception: If the failed node is path-critical (no alternate route), allow a one-time override to clear progression using a mover waystone, then resume normal rules.

Mover waystones

  • Support a dedicated “mover” stash tab (user-configured index) containing low-value waystones for forced progression clears.

  • On path-critical failure with no alternate path: temporarily ignore cooldown/“IPD” rule, withdraw one mover waystone from the configured tab, clear the blocking node, then return to standard selection and cooldown logic.

Selection flow

  • Load ignore memory file → build candidate nodes excluding any with remainingIgnores > 0 → pick next node → place waystone and run.

  • On completion: decrement all tracked ignores, purge zeros, add the completed map with remainingIgnores = cooldownLength, persist file.

  • On failure: if alternate path exists, mark as attempted and pick a different node; if not, run mover override, then resume normal flow.

Persistence format (example)

  • JSON or simple KV: { “Bliss”: 2, “Unicorn Town”: 2, “Cat Dungeon”: 3 } where numbers are remaining runs to ignore; counts tick down each run, new map inserts at cooldownLength, zeros are removed.

Config knobs

  • cooldownLength: int (default 3).

  • memoryFilePath: string (e.g., bot_state/ignore_maps.json).

  • moverStashTabIndex: int (required for mover logic).

  • pathCriticalCheck: function/hook that returns true if the node is the only route to the target.

Guards

  • Never place tablets on already attempted maps; selection must avoid them unless executing mover override to clear path-critical blocks.