@o4kapuk sry for the late post, didn't see this, ty for the quick response

Confirmed. Slack is deleted. The only 2 owners that had permissions to do so were @artch and @gdborton_hatyr (or slack corporate...). I would love to hear a justification from the devs, @o4kapuk...

I am trying to identify a location to host some text files of the screeps slack. It is less than 400Mb of pure text. I wanted to know if the devs would be willing to host this. @Faff has done an amazing job of parsing a slack export (Jan 1, 2016 - Jan 1, 2021) and outputting it into readable plaintext. We could potentially find another location for it, but I think since slack is the "official" chat for the game, it would make sense to host the archive on an "official" server.

@artch, is there any way that when changes or decisions are made that affect the community, a quick paragraph or two of explanation could be included? I feel like the most recent post, where you explained the pixel generation, was perfect and exactly what the community was initially asking for.

This seems to be a trend that I feel yall could easily fix. I remember when the community PR for detecting novice/respawn zones, was closed without comment. It took the community multiple days of asking for an explanation. Again, yall posted a well laid out explanation where you pointed out that the way the PR did it only allowed for detecting them if the bot had vision, but you wanted to implement it without vision. Yall wanted to take the time to implement it correctly, critiqued it, pointed out a flaw, and explained why.

The why is what the community desires. I feel like many of us deal with knee jerk decisions at work, and if we see something with the appearance of a similar situation in a game, it adds a level of frustration that makes the game seem less fun. A quick 5 minutes to add a paragraph could save a great deal of grief for both you devs and the community.

@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.