I might have come across an enlightenment that trying to butcher MemoryManager even further might be a futile attempt. Which brings up the need to discuss this ahead of the merge.

On the #screeps-ts-manager Slack channel Erik mentioned earlier that he doesn't have any memory storage available for that. Except for the miners (which holds the memory on which sources they go after, since we have a limit of miners per source), every other roles don't store a piece of their target ids in the memory. Therefore most of the roles don't need to rely on MemoryManager, it'd be essentially just there to let ourselves easily access the Memory.* shorthand. They would end up just grabbing everything from their respective *Manager classes.

I might experiment with this in a branch once everything is fully converged.

Since @ErikVanNorstrand is now added into the collaborators list, we've decided that we will converge both of our source codes together over from https://github.com/ErikVanNorstrand/screeps-typescript - once convergence is complete Erik's fork will be the ones that we'll use from now on.

Convergence shall start after #15 is fully merged.

Right now we don't really have a FlagManager class, so we should at the bare minimum create one that has a method which pulls a flag with a certain name.

As described in @resir014's comment on issue #5, null-checking target_repair_site_id doesn't quite work like it should. We should find an permanent alternative way of checking the validity of a creep's target_repair_site_id.

If a builder, repairer, or wallRepairer creep has no more things to do, then they need to renew and move to spawn, they will stay at/around spawn afterwards, therefore clogging the spawn and blocking the spawn's ability to create new creeps.

We should have them move to a certain flag on the map when they're doing nothing so that the spawn wouldn't get congested.

[DUPLICATE - please ignore]

As part of the convergence, we will take some steps into improving our role management. This will include new roles that we brought in from Erik's repo, and a more balanced role management.

With #29 being merged, we still need to refactor the entire codebase to improve performance and make it TS2 compliant.

Should be finished by this weekend.

The current job queue system is very inefficient. We need to rewrite the entire system to a more structured object-based system.

It's finally time to rewrite the legacy creep logic. After reading this really good guide on Screeps World on how to approach state-based creep management, I'm going to sketch out some ideas for a modular, state-based creep management module.

Currently, the canCreate*() method is unused because using that somehow doesn't cause the creeps to autospawn if needed in some cases. We need to improve this.

Reference: https://github.com/ErikVanNorstrand/screeps-typescript

Right now the way we implement everything relies on us having only one room only. So we need to refactor so that everything's not room-dependent.

Trying to fix this may also help us in fixing #7.

Right now the method of creating a new create*() and *GoToWork() method every time we add a new role is not even DRY at all. We should create a single createNewCreep() and creepsGoToWork() that takes a role: string parameter we we can work from there.

This new creep creator will also need to support multiple possible body parts. e.g. [WORK, CARRY, MOVE] for "emergency mode", [WORK, WORK, CARRY, CARRY, MOVE], if we could create a stronger creep & a certain number of creeps already exists. Or even add another, much stronger one, later on.

The output of creeps would need to be balanced so that we don't end up with a lot of "emergency" creeps after RCL 2.

It seems that we really need to tweak the balancing rates of creep spawning. Whenever the number of extensions in a room exceed 5, I found out that creep generation starts to fail horribly when reaching builders/repairers, due to the fact that the spawner mostly fails to generate creeps with [MOVE, MOVE, MOVE, MOVE, CARRY, CARRY, CARRY, WORK, WORK, WORK] body parts.

The MemoryManager is currently just a bunch of not-DRY-at-all methods and a bunch of hacks put on top of hacks. Let's try to clean it up.

MemoryManager was broken in the effort to add multi-room support. This bug was weird.