I often find that the UI is rendering roads on top of other objects (creeps, containers, etc) like this:

When this happens it affects the entire room, so all roads are drawn incorrectly. Changing to another room doesn't fix it - in fact, all rooms will have the same problem. Going into the display options and clicking OK doesn't fix it, but refreshing usually does.

Chrome 75.0.3770.100 on Linux (Debian 9) 64-bit. Hardware acceleration is enabled, graphics card is Nvidia GeForce GT 610.

I've noticed that the room history doesn't show creeps entering the room properly. The creep is invisible whilst on the exit tile, and suddenly appears in their next position (with no move animation) when they move off the exit.

For example, see https://screeps.com/a/#!/history/shard3/W39S27?t=8188729. The towers heal an invisible creep which then appears the following tick.

I'm pretty sure this used to show correctly, perhaps before the recent WebGL updates.

Thanks.

@deft-code said in Typescript - adding to existing classes without duplication:

I only use the inheritance chain for Creep. It has completely eliminated all this casts from my code.

Is that because you're just calling creep.main() for each creep and then you're already inside CreepExtra when making any other calls to extension methods? I've got quite a few extensions that get called on the results of things like room.find(FIND_HOSTILE_CREEPS), which obviously still returns a Creep[], so typescript doesn't know those extensions are available. The obvious solution is to cast every find result to a CreepExtra[], but this is the kind of thing I'm hoping to avoid.

Perhaps I should make room.findCreeps, pos.findClosestCreepByRange, pos.findCreepsInRange, etc.

For all of my other modifications I do it with a single class in a single file. I also have serveral mixins shared among different types. I keep the mixin class and interface declarations in a single file.

Could you give some examples of these? I'm not sure what you mean by modifying "with a single class".

My Room extensions are kind of a mess half are in a single file the rest are sprinkled wherever and all of the declaration are in types.d.ts. I'm not happy with it but it hasn't climbed my annoyance list enough to fix it.

I think I've come up with something reasonably sensible for Room extensions. There are only a few places where you ever get a reference to a room, so it's not too bad to override them all like this:

interface Creep {
    room: RoomExtra;
}

interface Game {
    rooms: { [roomName: string]: RoomExtra };
}

interface RoomExtraObject {
    room: RoomExtra | undefined;
}

interface Source {
    room: RoomExtra;
}

interface Structure {
    room: RoomExtra;
}

interface OwnedStructure {
    room: RoomExtra;
}

EDIT: Ignore this, it doesn't actually work - typescript complains that Subsequent property declarations must have the same type

To be sure, this feels like something that's really lacking from typescript - the ability to declare that an existing interface is being extended with everything from a new class.

Surely you'd have to typecast everywhere for that to work? Or is it just that in practice you only need to typecast in a few strategic places?

What about things like helper methods on RoomPosition?

I'm in the process of moving my codebase over to typescript. I've read through the typescript documentation and the typescript deep dive (highly recommended by the way), and I feel like I have a reasonable understanding of it now.

However, I haven't found any sensible way to extend the builtin prototypes (e.g. Creep, Room, etc). So far the only way is to use Declaration Merging to add the declarations to the interface, and then define them separately like this:

interface Creep {
    main(): void;
}

Creep.prototype.main = function () {
    // ...
};

I have two major issues with this:

1. It feels like a lot of duplication. Even if I keep all the type information in the interface and don't even bother to annotate the types in the actual function, it's still pretty horrible.
2. The safety is lacking, which rather defeats the point of using typescript. If I add a method to the interface but forget to actually define it, typescript will tell me nothing.

I was hoping I could declare the existing interface to also implement a class I've defined, and then I could dynamically mixin all the methods like this:

class CreepExtended {
    main(): void {
        // ...
    }
}

interface Creep implements CreepExtended {}

Object.getOwnPropertyNames(CreepExtended.prototype).forEach(name => {
    Object.defineProperty(Creep.prototype, name, Object.getOwnPropertyDescriptor(CreepExtended.prototype, name));
});

But this doesn't seem to work. Typescript will still give errors like Property 'main' does not exist on type 'Creep'.

All of the public codebases I've seen are wrapping everything in their own new objects. I feel like I'm going to have to resort to this, but it seems like a lot of effort with a negative performance impact for no benefit - it's just to keep typescript happy.

Has anyone managed to achieve this?

Thanks.

Yey! Access to the market history will definitely make the market easier and less costly to use.

It's great that we can eventually get our fee back if no-one deals our order. However, this does make me start to wonder why we can't just get the fee back if we cancel the order early? Is there a reason why we need to enforce a time limit on this?

Those are interesting. I've been wondering about how best to defend remote miners. At the moment they're defenceless - when invaders appear they will try to run away and wait for a defender to come and clear the room, but they don't move very fast so they usually die.

Because it's ~100,000 energy between invasions it feels like it's probably more efficient to let them die, but it feels unsatisfying. This is what got me thinking about unusual part combinations.

Since specialist creeps are usually best, most players seem to be using fairly standard combinations of parts. The most common ones I see:

• WORK+CARRY - harvesters, builders, workers, etc
• CARRY - haulers (sometimes with 1 WORK to fix roads)
• CLAIM - claimers, reservers
• ATTACK, RANGED, HEAL, ATTACK+HEAL, RANGED+HEAL - military
• WORK - offensive dismantler (some of the more unusual ones include RANGED or HEAL)

Some observations:

• Giving an offensive dismantler ATTACK doesn't seem useful, since you can't attack and dismantle at the same time
• I don't see much value in ATTACK+RANGED, unless you want to attack two specific targets at once for some reason
• It seems wasteful to put anything else with CLAIM (since the addition of creep.pull() I'm planning to not even give them MOVE anymore)
• I can't see any point in combining CARRY with ATTACK, RANGED or HEAL

I'm interested to know if anyone is using any unusual body part combinations, and if so, what for?

I would really like this to be fixed. As others have suggested, it would still work conveniently if it was linked to the room.toString representation, but would allow us to easily avoid the auto-linking if we don't want it.

@artch, at the very least, if this really isn't going to be fixed please could you point us in the direction of the source code which does this so we can create the best workaround possible. Thanks.

I'd really like to see some quests/achievements to help direct new players to try everything out. Even without any rewards I think this would be helpful.