Runs priority creeps first, then runs the rest in a queue until CPU is full. Any remaining in the queue go first next tick after priority is done.
Edit: I accidentally deleted the attachment, see below for current version.
#Creep Management Queue
raven wave
change
if (Game.cpu.getUsed() > 19) return;
to something like:
if (Game.cpu.getUsed() > this.cpulimit) return;
also I recommend removing all the roles from the base code, or maybe add them as examples
blazing gull
Yeah I was thinking about having an initialization function in main and making a heap.roles
raven wave
oh also
instead of having a base priorityQueue, assign something like a number as the priority
for example:
roleMap: {
harvester: {name: roleHarvester,priority:10},
True, though in this case I just need a boolean. If it's a priority run it regardless of queue, otherwise wait until the general queue to run it.
blazing gull
Ugh, I deleted the original file thinking to re-attach the updated one, but noooo it won't let me attach a file in an edit. In any event here is the improved version.
If CPU is > 19 AND bucket is less than 5000, return. 🙂
This lets it remove throttling when not in a low CPU state
graceful creek
Nice! You've been making some really solid progress since you've started! You're starting to adopt an #operating-systems approach to dynamic CPU management. That sort of thing has been on the backburner for me for a while and I'm very into it, so here are a lot of random ideas that you can take or leave:
You could get further control over over your CPU usage by including non-creep operations/jobs in this setup (ex: running towers/labs/links/observers/etc, base planning, remote room add drop, market / terminal operations, etc). Adding to Geo's priority suggestion, you could assign a priority group/index/value to each creep role / other job type, then maintain queue for each of them.
Adding to Geo's CPU limit suggestion, I think I remember seeing a snippet somewhere else where someone dynamically adjusted the percentage of the available CPU in a given tick that they would use in order to smooth out CPU use bursts and still maintain a minimum CPU bucket level. Doing this could stop you from idling large amounts of creeps if, for example:
- You run
Game.cpu.pixelize() - You have a high CPU use earlier in the tick before your creep runner starts
- You have a lot of creeps in the priority queue
Consider caching whatever queue structure(s) you end up with across ticks to save CPU. Instead of iterating over each name in the queue and then splicing it out of the queue, you could iterate by index, cache the index, and use queue.heap as a ring buffer (way more efficient than iterating through and splicing each name out).
Caching:
- If caching as mentioned above, you need to invalidate the cache whenever you successfully trigger a spawn operation, and you can remove any missing creeps as they come up in the queue(s). Add a cache TTL for safety.
- This does make intershard transit trickier unless you have a short cache TTL and you're okay with letting them idle until the cached result expires (or just really solid InterShardMemory management?)
blazing gull
Thanks for the feedback! Referring to it as an operating systems approach makes a lot of sense. I have made some minor refinements since I posted this, experimenting with burst handling, so that when bucket is over a threshold, add some more roles to the priority queue, but nothing solid enough to share yet. I'll look into your other suggestions!
I'm also working on a wrapper for all intent functions, so that I'm forced to intentionally use the intent when coding them. For now it's simply experiments with creeps saying things before every intent, with different emojis for different intents, so that I'm aware of the cost accumulation when watching them.
prime otter
It might not help as much with creeps specifically, but since we're talking about cpu management: coroutines. They let you yield control of the function back to the executor as often as you'd like. My current js bot has 1500 coroutines that tick once per tick, and can optionally run multiple times or even consume 10k cpu automatically spread out over like 20 ticks