@artch Due to how prototype inheritance works I don't believe this would break anything.

If we introduce a LivingEntity (choose any name) class between RoomObject and PowerCreep/Creep, the empty class by itself will change exactly nothing in the behavior. Existing properties and methods will still be inherited.

If we then move the method move to it, both classes would inherit the method as-is. The move methods on PowerCreep could be removed entirely, as instead of a hacky cross-prototype call, they'd inherit them from the LivingEntity class. And If you ever wanted to introduce a third type of movable actor you'd already have a decent base class to work with.

As for the common monkey-patching that we do that is 1) never been officially supported I thought and 2) surprise, still not broken. If you monkey-patch move on the Creep method, it will still inherit from the super class, only now it's not breaking PC because they have their own copy of move, from the LivingEntity class, and we have the option of patching that if we want to affect both.

If anybody can think of something it would break, I'm all ears.

Edit:

As for the if (!this.room) check in PC move, a prototype call can still be made but it needs to stay within it's own chain. If PC inherited from LivingEntity, something like:

PowerCreep.prototype.moveTo = register.wrapFn(function(firstArg, secondArg, opts) {
        if(!this.room) {
            return C.ERR_BUSY;
        }
        return globals.LivingEntity.prototype.moveTo.call(this, firstArg, secondArg, opts);
    });

would be acceptable, if LivingEntity were the parent class to PowerCreep.

My main issue is the cross-prototype calls in the power creep like this:

   PowerCreep.prototype.moveTo = register.wrapFn(function(firstArg, secondArg, opts) {
        if(!this.room) {
            return C.ERR_BUSY;
        }
        return globals.Creep.prototype.moveTo.call(this, firstArg, secondArg, opts);
    });

It looks innocuous but there's a problem here; It goes against expectations (and general OOP). Creep.prototype.moveTo is expected to only be called on creeps. Therefore any overrides, any internal behavior of moveTo, expects this to be an instance of a Creep, or a class derived from one. A PowerCreep is neither, it's an entirely separate class abusing the scope of a Creep method. There are several methods and properties like this, that could be written once and reused, but the only common base is RoomObject which for obvious reasons is too abstract for this.

I understand why a PowerCreep can't simply be a child class of Creep, too many differences. But If you find yourself writing calls like this it's time to consider writing a shared based class.

This would allow for things like hits, carry, moveTo, my, owner, etc and any other methods or properties identical between the two to be written once and reused across as many types of actors as you want.

I'm a strong proponent for having a shared base class. Due to the way prototype inheritance works, adding such a prototype to the engine would not cause any breaking changes to existing player code.

Code deployed to PTR doesn't match PTR branch on github, creep to creep transfer broken on currently deployed code. Line 25 of function prevents transfer to anything not a structure.

 if(!register.structures[target.id] || !utils.capacityForResource(data(target.id), resourceType)) {
            return C.ERR_INVALID_TARGET;
 }

const is block scoped and won't show up on global, like you were attempting to use it. If you want to use it from the command line you either have to put it on global or type it on the command line itself.

That did it. Thanks

@o4kapuk Steam version, haven't tested the npm version

@o4kapuk MMO appears working now, but steam private server showing v3.3.2 and.. event now shows the associated number (12) but the constant EVENT_TRANSFER is not in global scope.

Updated to steam PS version 3.3.1, EVENT_TRANSFER is still not defined. Not seeing it on MMO either.

Hi, I'd like to know if we could pass in a position and maybe zoom as url parameters to links, so we can more easily focus a specific position in our links. Something like #!/room/shard0/E59S39?x=5&y=16&zoom=3, maybe?

I'd like to see transfer and withdraw events separated into two constants, please.

In the current implementation only object and target id are reversed, and you still have to run a series of convoluted checks to figure out what happened, which is exactly what it's trying to prevent.