Posts made by keenathar

@o4kapuk Well that's embarrassing. The second I code something without a linter I make such a rookie mistake.

However, this doesn't explain why the oneliner in the game's Console failed as well. At that point I had commented the line you point out, and there is no such mistake in the console command - it's literally just grabbing the object and setting the intent. The error messes with the conditions for the else if-statement, but in the cases of that replay it would also be true with proper comparison. While the sign is wrong, it shouldn't have actually changed anything in the offending replays (as the creep was in the proper room as held in the variable targetRoom).

More specifically, the creep is moving to the proper room from from:

// Proceed if target is truthy (Controller | RoomPosition)
if(target) {
    creep.moveTo(target, opts)

result will be -7 ERR_INVALID_TARGET if the creep isn't in the right room, or -9 ERR_NOT_IN_RANGE if too far away in the proper room:

// Attack controller
const result = creep.attackController(target)

So this branch would not be entered

   // console.log(Game.time + " - " + result)
    if (result === OK) { ... }

Bringing us to the offending line. Even with the = mistake, the error occurred while the creep was adjacent to the controller. That means the = is essentially doing A becomes A, as they're already the same.

 // Claim if need be
 else if (creep.room.name = targetRoom && target.level === 0 && creep.pos.isNearTo(target)) { ... }

How would that cause the issue regarding property novice? The first condition is true from the single =, but target must still be the controller because otherwise target.level === 0 would already throw cannot access property 'level' of undefined - which did not happen.

I'm trying to understand, but don't see how the single = could cause the observed error.

Edit: I tried it, first with the incorrect = and then with the fixed ===, and it did solve the issue. However I'm still curious how it makes a difference, just for my own understanding. Especially because if the creep is adjacent to the controller, they should be the same

This is a really brief one, but Ruin is not recognized by the syntax highlighter. Should be purple.

The code works, can be verified as oneliner in console. It's only the highlighting.
let a = Game.getObjectById("..."); (a instanceof Ruin) // true

Which shard is affected?
It happened on S3 - not sure if it affects others.

What happened?
My claimer creep ran into an error. Its memory had an array of roomNames. It would go to the first in the list, .attackController if it was owned, .claimController otherwise, then shift it out of the array and proceed. After going through the array, it would try to go home and recycle. Full code is at the bottom.

After numerous succesful .attackController lapses, the owner (same for all six rooms) respawned. Immediately afterwards the problems appeared. At least, based on the replay. I noticed only after it had been going on for a while.

The creep would move up to the controller, but claimController gave the error: TypeError: Cannot read property 'novice' of undefined

During troubleshooting I disabled the claimController line with a comment, which stopped the errors. I then manually tried claiming the controller with a console command:
let a = Game.getObjectById("..."); Game.creeps.downgrader.claimController(a)

The used id was copy-pasted and the creep was adjacent to the controller, as you can see on the screenshot below.

The console command returned an error, again as seen on the screenshot: TypeError: Cannot read property 'novice' of undefined and continued with runtime details.

What should have happened?
The controller should have been claimed successfully.

How can we reproduce this?
Honestly I'm not sure. The same thing happened with the controller 1 room down south, E31S5, but I didn't look into it then because I assumed it was an error on my part and I decided against claiming that room instead of troubleshooting. It also happened in E32S4 judging by the replay, yet it claimed fine later with the same code.E33S4 claimed fine afterwards as well, again same code.

There is about

Replay link:
E31S4 - from the screenshot The replay doesn't really show much, but the creep should have 'booped' the controller and then move on east. Interestingly this happens much later than the successful claims from below.

E32S4 - broken
E32S4 - successful claim intent at 12643142, roughly 1800 ticks after the broken attempt.

E33S4 - successful claim intent at 12643192

I did not check behavior along the rest of the route.

Piece of code which shows the bug in action:

Claimer memory shoved into spawnCreep(body, "downgrader", { memory }):

    // const memory = { downgradeNames: ["E31S5", "E31S4", "E32S4", "E33S4", "E33S5", "E32S5"] }

Full creep code: (please don't judge, this was shoved together on-demand).

function runDowngrader(creep) {
    const visualizePathStyle = {
        fill: 'transparent',
        stroke: '#fff',
        lineStyle: 'dashed',
        strokeWidth: .15,
        opacity: .2
    }
    const opts = { range:1, reusePath: 50, ignoreRoads: true, visualizePathStyle };
    
    // Load array of target roomnames from memory
    let targetRoom = creep.memory.downgradeNames[0]; 
    let target;
    
    
    // Load controller object if vision on target room
    if (Game.rooms[targetRoom]) {
        target = Game.rooms[targetRoom].controller;
    }
    // Load controller position if not visible
    else {
        const flatPos = Memory.rooms[targetRoom].controller.pos;
        target = new RoomPosition(flatPos.x, flatPos.y, targetRoom);
    }
    
    
    // Proceed if target is truthy (Controller | RoomPosition)
    if(target) {
        creep.moveTo(target, opts)
        
        // Attack controller
        const result = creep.attackController(target)
        // console.log(Game.time + " - " + result)
        if (result === OK) {
            creep.memory.downgradeNames.shift() // Remove roomName from memory array
            console.log(creep + " succesfully attacked " + target + ", " + target.ticksToDowngrade + " remain before losing RCL " + target.level)
            
            // Move to new target
            targetRoom = creep.memory.downgradeNames[0];
            const flatPos = Memory.rooms[targetRoom].controller.pos;
            target = new RoomPosition(flatPos.x, flatPos.y, targetRoom)
        }
        // Claim if need be
        else if (creep.room.name = targetRoom && target.level === 0 && creep.pos.isNearTo(target)) {
            console.log(target) // These are all the `[structure (controller)]` logs from the screenshot. Commented this line eventually. 
            const res = creep.claimController(target); // Commented this out during troubleshooting
            // console.log(res)
        }
        
        // Activate observer for pathfinding
        const obs = Game.spawns.Spawn1.pos.findClosestByRange(FIND_MY_STRUCTURES, {filter: (s) => s.structureType === STRUCTURE_OBSERVER})
        
        if (obs && targetRoom) {
            obs.observeRoom(targetRoom)
        }
    }
    // Recycle if all targets are visited
    else if (!target) {
        target = Game.spawns.Spawn3; // HARDCODE. The horror!
        // creep.moveTo(target, opts)
        
        if(creep.pos.isNearTo(target)) {
            target.recycleCreep(creep)
        }
    }
}

A really minor but to me interesting change:

Can the ruins from player respawn have randomized expiration durations? e.g. anywhere between 400k and 600k? Would add some immersion to the world if there are "half collapsed" rooms here and there, instead of everything disappearing at exactly the same tick.

Not sure how much overhead this would cause and if that's a reason not to do it, as I have no clue how often people respawn and how many structures they tend to have.

There was an issue about this about a month ago: https://github.com/screeps/docs/issues/121

Is that repository incorrect or not actively maintained?

@qgazq I think people with pre-boosting code will be more engaged with the game, and therefore more likely to be around in Slack or on these forums. So there's some selection bias in the population you used for your observations.

Doing this through to the server seems very strange to me.

Don't forget you can run Javascript in the client through <script> tags in the console. Consider writing a function you can call from the console that modifies your client UI, or check #client-abuse in Slack for examples. (They're working on a redesign for the UI though, so choose carefully how much time you invest.)

@systemparadox Let's call them "train" and "wagon" for sake of convenience. "Puller" and "pulled" looks too similar.

1. Train moves on exit tile, wagon is adjacent to exit.
2. Train changes rooms, wagon stays adjacent to exit in original room
3. Train changes rooms back to the original room, swaps positions with wagon (position swap is possible with .pull).
   Wagon is now on exit tile in original room, train is adjacent to exit in original room.
4. Wagon changes to new room, train moves to exit tile in original room.
5. Wagon changes to original room, train changes to new room.
6. Train moves off exit tile in new room, wagon changes back to new room
7. Train pulls wagon off exit tile.

Really excited about this!

It looks really slick, and I like how the new logo's c is a creep. Looking forward to the full release

I've tried slimming it down, but I lose a lot of mobility and end up with something that feels like an inferior version of o4kapuk / bonzAI's bunkers. (Planner)

I'm not sure if I consider it an improvement. Placement will surely be easier (smaller and simpler shape) but I think I need traffic management to make it work. Additionally it'll be annoying to determine which orientation to place it, given that the mobility top-left to bottom right is much better than perpendicular to that. Additionally the old design guarantees all extensions can be filled from the inside of the bunker, whereas the new one does not. If I add a road around the base it'll suddenly have the same footprint as the old design again.

@wtfrank Thanks for the suggestion. I'll try rearranging for 4-deep clusters.

I guess "saving move intents" was the wrong phrasing. I meant just fewer moves, so that miners are at their sources quicker without having to go through congested space.

The docs article you link is about answering the question: which actions can 1 creep simultaneously within a single tick?
That means that order of execution indeed isn't answered there: just if something executes. For example, it shows you cannot build() and repair() in 1 tick with the same creep, but you can rangedAttack() and heal() (not rangedHeal()).

Execution order is little tricky. Regarding damage, you can consider all attacks and heals to occur at the same time. newHits = hitsLastTick + receivedHealing - receivedDamage, so you can save your creep by healing it at the same time it receives damage. In fact, "pre-healing" is a common part of how to attack rooms with defending towers.

Some other intents like moves are more tricky. If two creeps want to move to the same tile, it's pretty random which one gets it.

So after giving it more thought (thanks again for all feedback), and evaluating how my previous design did, I drew a few conclusions:

• The design must be spherical / square to have centered towers
• The design must have easily accessible exits for active defenders and lazy traffic management
• The spawns must be on or near the outside to reduce congestion and save move intents after spawning
• The terminal and storage must be near the labs
• There must be a link near the storage and terminal
• The design must be my own, instead of being a copy

I came up with the following: planner link

It's 13x13, so not as compact as such designs (like Overmind's 11x11), but definitely not huge either by any standard. I'm pretty happy with how many open diagonals I was able to fit in, hopefully allowing me to postpone real traffic management until I've finished more interesting modules.

The top and right edges have a blind spot for active defenders. I'm too much of a sucker for symmetry to move one of them to the spot top-right of the storage, and I don't want to block the diagonals, but particularly the right edge seems like the weakest spot because of the single full-damage tower. I might give up the topleft-bottomright diagonal by filling the gaps between the + patterns.

I decided to go ahead and make a few more small changes, so I fixed the blind spots at the cost of the topleft-bottomright diagonal. Given the other parallel routes, it's not too bad to give it up. The image above is updated to reflect these changes, though the old version is here.

Another downside of this design will probably be fill speed, though that wasn't high up on my list of concerns.

I'm still considering the build order, and might swap the top-left spawn

@Orlet I really liked your layout, but wanted something more "open". As well as my own design

Who's available for round 2 of feedback?

I think this has to do with NodeJS instead of with Screeps server code.

Without some snippet of the module I'm not sure why it gave the incorrect line number, though.

const sites = Game.rooms[roomName].find(FIND_CONSTRUCTION_SITES);
for (const site of sites) { site.remove(); }

You can one-line this in the console and have them all removed. Alternatively, you can put it somewhere in your room script so that it runs if you place a flag with a name like removeConstSites which then also removes the flag.

@tigga then it'll just kill whoever else lives in the other rooms of your house. I'm not sure if that'sa great idea

Regardless of implementation, this suggestion seems to be popular. I haven't seen anyone protest.

I'm really hoping for an official reply from the devs

I went with Labor of Love. I think it's slightly more appropriate, because creeps are alive and not machines!

I don't see the logic of the big creep holding back.

Honestly, if we're looking for a hitback-nerf / anklebiters-buff I think it would be more logical to limit hitback to once per tick but at full power.

1. Each of the ten 1m1a attack for a combined 300 damage. 1 of them is hit by the big creep, and 1 of them receives hitback damage. 8 remain full health, 2 tombstones, big creep is at 2000-300-30 = 1670 hits.
2. Repeat: 8x30 = 240 damage, 2 small creeps die, big creep is at 1670-240-30=1400 hits.
3. Repeat: 6x30 = 180 damage, 2 small creeps die, big creep is at 1400-180-30=1190 hits.
4. Repeat: 4x30 = 120 damage, 2 small creeps die, big creep is at 1190-120-30=1040 hits
5. Repeat: 2x30 = 60 damage, 2 small creeps die, big creep is at 1040-60-30=950 hits.

The result is similar, but make more sense to me.

Other than that, I'm impartial about this change though. I don't really care whether it goes through at all or not. I don't mind the bias towards big creeps.