Just so you know, you are asking for what is close to a framework, not a snippet. Path re-use is one of the more complicated tasks to undertake in Screeps.

The documentation is very good covering 'What does this command do' but mediocre to poor on 'What are the ramifications of this' and 'How do I accomplish common tasks'.

A good example is creep parts. There is precisely no coverage of 'how many move parts do I need for different situations' or 'how much claim is enough' or 'what does my creep cost per tick' or 'when is it worth it to boost a creep part'. Answers to all these questions require a lot of math, spreadsheets, or experience and none of it is explained in any documentation despite being critical information for decision making.

It can all be derived from the given information, but that's not the same as being explained. There are many systems in the game that have no explanation of how they work, and no intuitive understanding can be made without doing math. This is in contrast to other RTS games that draw on real life to provide context and intuitive understanding of the relationship between units. Because we are require to build every unit ourselves from scratch, but are given no context about what makes a good unit for different roles, it's a serious sticking point for new players.

Programming is difficult... programming when you don't even understand the system requirements is much harder. The documentation does not provide a surrogate 'expert user' to get domain knowledge from. It should.

A single large variable will be faster to store and restore every tick than an equivalent amount of data stored in many small variables.

The decision of whether you should store one big variable (and parse it out yourself) or many smaller variables (and let the built in code handle everything for you) depends mainly on two factors: "Is it worth optimizing yet?", and "Do I access all this data every time, or frequently access only part of it?"

For example, the system stores the room cost matrix into a single variable, because when you are making a path you usually need most of the matrix anyway. But paths are stored as an array of steps, because you usually only need to see one step (the next step in the path), and there is no reason to decode the entire path out just to retrieve one step.

It's important to understand that the built-in memory handling uses memoization: you don't pay the decoding cost until you access the variable. So if you don't read the value of a piece of memory it never gets decoded.

Because of all these factors, the real answer is 'it's complicated'. But in general, if you are storing an array of arrays directly into the memory object, you're probably doing it inefficiently. If access to that memory is frequent, then it's likely eating up a notable amount of CPU and it's worth looking into squishing it into a big string and parsing that string into the full array yourself.

That's not a bad suggestion, but you could easily fake it you know with some code of your own.

You could use a custom flag finder that EITHER returns a visible flag OR returns a position object tied to a deleted flag's memory. Flag.hide could delete the flag but not the memory, and store the position and color into that memory location. Flag.show would create a flag with the old name, pointing at the old memory.

Some tedium to set up, but should be CPU efficient and emulate the exact result you want.

I find it funny (and sad) that the author of the message doesn't seem to have a recovery code path for when the hauler dies without enough energy to replace it available to the Spawn. His room has been ticking down for ~12 hours.

I agree a search tool would be nice (or just making common criteria, like 2 available sources and no enemy connected, highlighted on the map). But two sources is just fine in a room; I don't think more are necessary at all.

I agree that respawning into a newbie area and harassing inexperienced players is detrimental to the longevity of the game. I believe that newbie protection is too short.

On the other hand, it is that short, and re-spawning to a new location has very few costs associated. If the player did not have a tower up then in less than a day they could recover their previous glory in a new location with their improved code. What I do think should be clarified and emphasized to players is the importance of their code being able to bootstrap itself from nothing-to-defenses on its own in a new room. If players have that as their goal then having to restart is simply another chance to see how well their code bootstraps a new room. That goal is under-emphasized I think, and that can lead to players thinking that starting over really means starting over, rather than 'another chance to test my code'. It's a perception thing, and I don't think the current tutorial and documents encourage the right perception.

StructureSpawn.createCreep does not create a creep that very tick. Like all commands, it actually begins on the next tick. Unfortunately only Creeps allow you to cancel a pending order (it would be nice if that could change), and if you want to remember what orders you have made this tick you need to keep track of it yourself.

What does happen immediately when you use the createCreep command is the adding of the optional memory object into Memory. But the actual creep creation has not begun, and so StructureSpawn.spawning is correctly false. It's not hard for you to manage your own flag on whether you have ordered a creep this tick or not.

Can you describe the room and tick when it happened? The History being blank is a bug, but it's possible you got invaded. They only last 1500 ticks (just like your own creeps) so they often sweep through, kill your creeps, then expire before doing much structural damage.

Multi-role creeps are rarely efficient. For example, anytime a balanced (MOVE/WORK/CARRY) creep is harvesting a source into a container, all those MOVE and CARRY are wasted. Even builders and controller-upgraders should have different bodies, because a builder moves a lot and burns through 5 energy per tick (per WORK), while a controller moves rarely and burns through only 1 energy per tick (per WORK). So a builder needs more MOVE and CARRY than an upgrader.