Some rooms have source keepers that basically block an entrance, meaning anything that walks through and isn't prepared basically gets sniped. At the same time source keeper rooms can be really useful to walk through. It would be useful if the system could take them into account the same way it does with blocked exits.

There are a lot of things to implement for the support of the code being multi-shard ready.
Some include the following, feel free to create separate issues for subpoints and check them off as they are completed, linking to them from the list here also helps:

• Transfer creep memory through interShardSegment when traveling through shard portals
• Pathfinding/targeting to/after shard portals
• Respawn check needs to consider whether we are on multiple shards, and not just respawn when we look defeated on one shard
• Adjusting CPU limit allocation between shards
• Expanding from one shard to another
• Supporting one shard with civilian creeps/resources from another
• Attacking/defending on one shard with creeps from another
• Market arbitrage between shards

I've put together a very basic system for storing room layout plans- it uses the sos.lib.vram module to save data in a segment, and stores the room layouts themselves as a serialized costmatrix. This system should give us the building blocks for auto layout and build.

Next step is the layout itself. I'm thinking we use templates and the distance transform function itself to do this (rather than some sort of dynamic algorithm that uses different layouts in different scenarios). I'm thinking to start we have two templates-

• Core Structures - basically everything that isn't an extension or extractor, this layout will focus on spawning, boosting, and resource management. Towers will be clustered here for easy loading and for the strongest possible DPS when under attack.

• Extension Flowers - rip off dissi and bask in the cpu savings.

I have a starting point proposal google sheets.

As for the placement rules I think we should first attempt to put the core cluster down as close to possible to the controller, with the extensions as close as possible to the core cluster. We can then iterate over random positions and loosen up the rules until something fits.

This includes planning, building, and maintaining.

When the gruntfile was tossed in favor of gulp backwards compatibility wasn't maintained. Previously the host field was autopopulated with the servername if it wasn't defined.

This is the active part of #84. The primary goal here is to gain visibility to rooms to trigger the room intel process.

This array seems to be growing without being cleaned up at all. Since it is regularly sorted this has an adverse affect on CPU beyond just the memory usage problems.

• Avoid enemy rooms (unless desired).
• Generate custom costmatrixes with features such as spot avoidance (for walking around source keepers or towers).
• Detect when stuck and compensate.
• Switch ignoreCreeps on and off depending on circumstances.

This is reliant on #84, which is needed to feed the algorithms which will decide which rooms to expand into.

It should be possible to sleep processes for a specific amount of time.

The simplest way would be to add a new object to the scheduler's memory for "sleep", with the pid being the key and the unsleep time being the value. When a process is sleeping it should be removed from the running queues, and when it is no longer sleeping it should be placed back in.

The expand program is spamming construction sites and not cleaning them up (a bug on it's own), but in general a system that cleans up stale construction sites would be nice.

One way to handle it would be to save the construction site creation date in memory and remove any older than a specified timeout value. The Creep.prototype.build function can also be monkey patched to update that value when called on a site so things that are being built (just slowly) won't time out.

This way there is no gap in mining the source and it doesn't sit idle.

If a worker is standing where a new construction site is placed, and that site isn't walkable, the creep will get stuck. It will be unable to build the construction site, but it won't move because it is in range to the site.

This is a pretty rare occurrence as the creep has to be standing in the exact right spot, but it can happen.

This is a standing issue to let people looking for ideas on how to help know that work on the wiki is always appreciated.

This is the passive side of #85, which should manage actually getting room visibility.

Data to collect (please comment if there is something missing)-

• Room owner
• Room level
• Mineral
• Number of Sources
• Resources Positions (SK Rooms)
• Portals
  • Position
  • Destination Room
  • Destination Shard

This should ideally be stored using segments, possibly with the sos vram library (the room construction code is a great example on how to use this library).

The core layout includes a spot for a creep that sites adjacent to many of the major structures (nuker, power spawn, terminal, storage, link, and a spawn). This allows a single creep (the "crane", "loader", or "linker" creep depending on who you ask) to manage all of those structures without ever having to move.

This creep should-

• Move resources from the terminal to storage.
• Move resources from storage to the terminal.
• Move power and energy (economy permitting) into the power spawn.
• Move ghodium and energy (economy permitting) into the nuker.
• Move energy into or out of the link.

If someone clears a room out a construction site for the first structures they hit will be placed, but once they clear out the spawns nothing will be able to build it. Clearing out other sites will make the spawn build quicker and help the room recover.

In most cases this shouldn't be a problem, as the file won't get loaded if it isn't references anywhere in the uploaded code base, but there are cases during development where it can cause issues (for instance, if uploading code to a private server after removing a program- if the program doesn't exist the scheduler will just kill the process, but if the stale program is uploaded it can result in an unstable system or at a minimum a bunch of errors to the console).

Not sure why this keeps happening, and I have yet to replicate it off of the main server. You can see in this room that the builder which should be making walls is just sitting there doing nothing.

For anything but the most basic "dump on market at best price immediately" type deals #71 will be needed.

• Fillers that won't be able to fill (and will just drop energy when they die).
• Haulers that are too close to EOL to make the trip and dump resources in storage.

I've observed a creep crashing multiple times. No error's visible in the console, yet the creep stops doing his job and never recovers. It solves itself when the creep dies, but that's not the expected behavior.

Types i observed this with is: Miner & Hauler. In the miners case it was stuck on top of a container and stayed there, blocking other miners. In the case of the haulers (multiple), they were waiting next to a fully filled spawn, but not continued doing anything after the spawn was empty.

This is primarily an issue because of another already solved bug, but it should still be resolved for robustness.

Basically, if a rampart or wall is scheduled to be built but it is in an impossible to build on position it will attempt to add the construction site and fail. The next tick it will see that there is no site there and will try again.

This can be resolved by adding a check when looking for "gaps" to see if it is possible to construct and then skipping over those that aren't.

If we unclaim a room we can't spawn from it, so we should remove those spawn queues to clean up memory.

Currently the mining program caps haulers to a single creep with the default energy, which gives it a total of 600 carry capacity. For some rooms this isn't enough and energy gets wasted as it gets dropped to the ground.

This is calculated in the mining program around line 144.

This will be much easier to do with #84.

The idea here is to build a library that save historic pricing data which can then be used to develop #72 and #73.

The sos stats library will likely be useful here.