For the nuker, you could have it charge instead of store-so the ghodium is lost when added to the nuker, instead of when it's used.
Labs are trickier. Maybe add a .store.maxMineralType/.store.maxMineralAmount that returns the mineral with the highest count (not including energy, power, etc)? That way it would always work like .mineralType/.mineralAmount does now on labs, plus it would be useful for storage, terminals and creeps too.
@mrfaul I kinda like the old signs being there. It gives a respawn the feeling of a new bot rising from the ashes, rather than starting from a blank slate. Also gives you an idea of who might be interested in slaughtering you once the walls come down.
Memory is not affected, it's the same thing as a syntax error in a code download.
Sometimes all your creeps get killed, and your room needs to rebuild itself. It seems fine to me that some invaders can poke holes in your walls and kill all your creeps. It should be rare (and it is), and it should be possible to develop out of it at RCL 8, but I think all the way up through development this should be handled by being able to rebuild the room, not kill the invaders.
So after trying a few ways, I created a module that requires itself. I include that conditionally at the end of the loop, and then I can trigger it by conditionally requiring the module without burning CPU or losing a tick.
Not exactly elegant, but it works.
@gankdalf Thanks, I'll try that. I think I have a memory leak in a closure somewhere. But if I make a code change, everything starts working again just find, so reloading the modules should stop the leak from killing me until I can plug it.
In keeping with the infinite loop idea...I think if you hit the memory cap it resets the global. So maybe if you just wrote 500 MB to memory in one tick it would work.
Is there a way to force a global reset from within the game loop with the iVM architecture?
I tried changing the name of module.exports.loop to module.exports.foo, hoping that would force me back into the pre-loop execution-style for a tick, but it didn't work.
I would honestly be fine if I could filter on amount in the ui (rather than just sort).
This screen cap (from the Shard2 market ui) shows 9 different orders, but they are all selling the same 675 H. This basically means that if you look at any single-component resource on Shard 2, all you see is this one guy's market order for a small amount of that resource.
I think the tools to modify market orders are sufficient, and using a small amount of resource to completely dominate the user interface is kind of annoying.
But I can see the other side of it too: the user gets 50 market orders, and if they want to put the same 675 H up for sale 50 times, and pay the listing fee, maybe it's better to not restrict the players.
I know this is kind of old, but here's my thoughts on a contract system:
Rather than contracting for executing commands, the contract needs to be based on fulfilling criteria before a deadline.
The same code should be run by the client and contractor, so they both pay the same CPU cost. The code should run before your personal loop.
If the code returns true, then you advance to the next criterion in the contract, or the contract is complete.
Then the code for the contract would be to evaluate whether those conditions are met, not specify how to fulfill them.
So it would be tough to burn someone with bad code that just ate their CPU (since you are running it also). But writing code that says "Contractor has picked up 1000 energy units" is tricky in and of itself.