@devblazer screeps-server-mockup, despite its name, is essentially just a wrapper to the official screeps server. All you should really need is to update the dependencies to the most recent server version and it should be good to go, I personally haven't used it in a while though.

AFAIK there is no builtin way to run a server one tick at a time, but it should be able to do so with a custom mod. You might want to check out the #servers channel in slack, @ags131 is usually able to help with any kind of server related questions.

It's not quite up to date, so you might have to do some updating yourself, but you might go ahead and try out screeps-server-mockup. It allows you to setup a private server via API including things such as terrain and RoomObjects (creeps, structures, etc) and run it one tick at a time.

@semperrabbit It's not optimized in any ways yet (paths aren't getting saved to database yet) and there are a few other things I would change before merging it in. Due to my experience with past pull requests I don't feel like spending more time on this until I get some sort of official response whether my changes are going into the anticipated direction at all.

I've started working on this, progress can be viewed in the pull request on the engine and driver. I plan on cleaning up some of the code and cache the paths properly before marking it as ready to merge in.

The source keepers should already act like they would normally do, but I can't confirm as I lack source keeper harvesting code, therefore I appreciate any feedback on this.

If anyone wants to test the changes, feel free to check out the source-keeper-to-processor branch on my screeps-server-dev repo which will help with setting up a server quickly.

@artch Mind sharing what exactly you think the issue with moving the Pathfinding to the processor is? I'm still fiddling with the server code to understand how exactly NPCs are integrated into the flow of the game, but calling the pathfinder differently seems like a fairly small issue to me, so maybe I'm missing something here.

Also what exactly is the overhead here? Is it the creation of the vm for each SourceKeeper or the setup of the API wrapper usercode has? Is it an option to just remove the vm layer for NPCs?

How about moving the keeper lairs right on top of the sources? This will remove the need to find a path at all and also won't require move logic in the source keeper code. Additionally this doesn't cause any issues for cases where the source is located on a single wall tile - I don't have an example for such a case in a source keeper room, but I certainly saw those in normal rooms.

I would like to pick up this challenge, but unfortunately I don't have a lot of time this weekend.

Sounds about right, except that each type of intent will only cost once for each creep. If your creep moves once and changes it mind in the same tick and moves somewhere else the constant cost is only applied for the first move call. In your example above this means that the constant cost will only be applied to creep.move(RIGHT).

Also keep in mind that multiple creeps trying to move to the same tile, interacting with the same object or conflicting actions will not conflict with each other inside your code, they will both return OK and the constant cost will be applied multiple times, even if only one of those actions is actually executed.

Will we get isolated-vm support for private servers as well?

I had the idea of giving bot creators a tool to create a binary of their bot's isolate snapshot that can be shared without publishing the source code. Currently bot publisher are trying to not publish a lot of offensive code, because it's going to be used on the official server, which in turn is hindering the experience of newer players. If this idea were to be implemented they could hold back parts of their code just like they do now, but publish the entire bot including military.

Actually implementing the upload and use of a binary snapshot can be taken care of by a mod, I'm just interested in whether we will get full isolated-vm support.

@hiryus To my understand only the tombstone decays and drops the resources on the ground afterwards, then they'll decay normally.

I can start working on it this afternoon.

Still got a few question that I need some input on:

Should the tombstone be created for creeps that die of old age as well? I think it should and contain the resources the creep was carrying.

Should creeps that suicide() create a tomstone? Maybe add this as an optional parameter (true/false)?

Should I add a FIND_TOMBSTONES contant as well? Are there any other ways of how to access tombstones?

Should this replace the current dropToContainer mechanic NPCs have? I think it should but it might break some peoples NPC raids or make them a lot less profitable until adjusting their code to tombstones.

Should room owners be able to remove()/destroy() tombstones before their ticksToDecay reached 0?

@artch said in Creep death: more than just a delete:

• One tombstone per creep, no stacking.

What do you mean with this? If multiple creeps die at the same RoomPosition, should there be multiple tombstones, one for each creep?

@artch said in Creep death: more than just a delete:

• No active actions.

What is this supposed to mean? No creep actions against tombstones? I previously thought about allowing Creep#withdraw (see NPC containers above), but this got me thinking. If withdraw isn't allowed it just delays resource decay, does it?