@tigga pretty sure the destroyed event was put in to identify specifically which creep made the kill, which would not be able to be identified in code 100%. I remember that discussion when events were new.

I do not use it, but have seen or heard of multiple instances of game object wrappers that ppl have used (e.g. your new MyCreep(creepID)) and can provide some insight for ya.

I've heard of ppl using Proxy objects to create a "persistent object" similar to what the devs said they intended to implement eventually (TM) about a year or so ago. Basically, internal to the proxy object is the game object's ID, and each new tick, it grabs that game object again, and proxies any function calls to the wrapped object. you could add additional functionality by adding new handlers to he proxy itself, and let the proxy route the actual intents to the game object.

Also, there's the "initialize once, use multiple ticks" concept, which is how my Kernel, Scheduler and libraries work in my OS codebase. Basically, you initialize the object once, and assign it to global (global.kernel = new Kernel(Memory.SempOS)) and it will persist as long as your global does. It will re-init every time you push your code, or get a global reset for some reason. With IVM, you only have a single global, and resets are considerably more rare, so it's feasible to do things like this whereas 2+ years ago, it would have been much more difficult. Tying this concept to game objects, you'd init the object with an object's ID, and it would cache the object for that tick. it'd looks something like this:

function MyCreep(id) {
    this.id = id;
    this.creep = Game.getObjectById(this.id);
    this.tick = Game.time;
}

MyCreep.prototype.move = function(dir) {
    this.refreshCreep();
    return this.creep.move(dir);
}

MyCreep.prototype.refreshCreep = function() {
    if(this.tick != Game.time) {
        this.creep = Game.getObjectById(this.id);
        this.tick = Game.time;
    }
}

The third and final option is what you mentioned previously, which is initializing and disposing of new objects each creep so you dont need the refreshCreep() in the example above.

Personally, I lean heavily on modifying the existing objects' prototypes, either through Object.createProperty() or just appending more functions onto it. That way, i dont get the potentially expensive new calls, and it just works.

Hope this helps, @fritzy...

its ok @deft-code, ty for the suggestions, but yeah, i guess its not happening ever. devs put their foot down, testing be damned.

Ok everyone, @ags131 very graciously set up a pServ at prtest.screepspl.us as a test with my fork/branch of engine with a BaseCreep class. He and @WarInternal already helped me identify/fix 1 error in it, and it is running pretty smoothly right now. Please spawn in and post results if you can

@artch, idk if you have any code, but you and @o4kapuk are more than welcome to spawn in too. I'd love to get feedback on what the devs think. btw, figuring out the data() call was more tricky than I thought (see the commits from today lol)

Again, everyone can take a look at my branch here: https://github.com/semperrabbit/screeps_engine/tree/BaseCreep

@daboross yeah, at best, it'd be a minor breaking change... and seeing as modifying Creep.prototype.move etc affecting PowerCreep stuff is not documented in the API, no one has any right to get butt hurt about it changing. it's like if someone were to rely on the exact order of a .find(). if that changes and breaks their code, who's fault is that? Never trust anything that's not in the API...

@artch, @o4kapuk, check out this fork of the engine. I have successfully tested this with creeps with both my and an Overmind codebase for approx 160k ticks each. neither of them broke at all. I had to build it with the refact-remove-ivm branch of the driver repo, but master for everything else... @GimmeCookies said he would test PowerCreep code on it later today. so far, we have not found any breaking changes in the slightest. I would love for others to test it too (ideally including the devs), to see if there is anything to break.

Bumping because the devs never responded, although they responded to other stuff. Giving them the benefit of the doubt that they missed it...

I feel like the devs should be able to give you an answer on the CPU issues... this is from the PathFinder.CostMatrix section of the API.

You should avoid using large values in your CostMatrix and terrain cost flags. For example, running PathFinder.search with { plainCost: 1, swampCost: 5 } is faster than running it with {plainCost: 2, swampCost: 10 } even though your paths will be the same.

I myself would also love to know the reason... If they can't, then perhaps you should reach out to The_General as he wrote the PathFinder C++ code.

@vipo yeah, that's my point. If lots of players are doing it, why not just get the game itself to take care of it instead. It's like the mem_hack that lots of players are doing. The devs expressed interest in doing it on the server-side, to save Memory parsing if the player doesn't need it. Perhaps they should express interest in doing this too, and following through.

When PowerCreeps were first released, there was a lot of code duplication between PCs and Creeps, particularly the movement piece. This makes it more difficult for players to deal with certain things, including their own homebrew movement code. Is there any intent to refactor all of the movement code into a "Movable" object type, and make Creeps and PowerCreeps extensions of that? I know that @WarInternal has made a patch that does just that, but it's inefficient for players to do that, when it would be better for the game itself to do it.

In particular, I'd like to hear from the devs whether that was brainstormed and discarded (and why), or if it simply never came up in the decision making.