PTR Changelog 2017-06-23
-
I respawned on the ptr and noticed that my MOVE,MOVE,CARRY,WORK creep gets fatigue when running over plain terrain:
2 when empty, 4 when full
-
New fixes arrived, please confirm.
-
Cool. I'm completely out of energy from some of the last bugs. If you inject some energy into my storage and/or terminals I'll be able to test a lot faster.
-
I got the same issue, I'm completely out of energy.
-
OK, PTR data has been re-deployed from the main server.
-
Nice!
Possible bug to report: I nuked myself in E28N61. At the time the nuke dropped, my 3 spawns had creeps spawning with 30 - 150 ticks remaining each. When the spawn animation completed, none of the creeps came out. I think they're still supposed to spawn, but I don't have a lot of experience with nukes, so I may just be misinformed.
-
All creeps should be killed regardless of spawn time when a nuke lands
I do agree that the spawn should stop spawning after a nuke hits. But that's a different topic.
-
Ah, interesting, didn't realize that. Thanks!
-
I just claimed two rooms and they don't appear to be listed in overview
and Game.time froze around tick 19915153, everything stopped updating. I think we broke something.
(Edit: Appears to be ticking again)
-
BUG: I respawned... it not only removed all my objects from the room.. it also removed the controllers
example: https://screeps.com/ptr/#!/room/W15S69
-
BUG: I respawned… it not only removed all my objects from the room.. it also removed the controllers
Fixed.
I just claimed two rooms and they don’t appear to be listed in overview and Game.time froze around tick 19915153, everything stopped updating. I think we broke something.
Do I get this right that ticks had stopped running right after rooms have been claimed?
-
Sorry, that was poorly worded. That was two separate things. And checking my memory, the freeze occurred 80 to 116 ticks after room claims, so likely unrelated.
-
Game.getObjectById(undefined) is returning an object again. Game.getObjectById(null) works correctly.
Specifically in this case it's giving me an extra road in my rooms. I've seen this appear in a few of my rooms and I'm confused as to how. So far each time it's an extra road segment in the same place as an existing road segment. Similar hp. This of course is causing some weirdness as I have come to expect goid undefined to give back an undefined/null return value. As it turns out, undefined is a perfectly legal object key, so it's keyed to _something_ at register._objects[undefined], and the || null doesn't fire.
Here's the excess road segment stringified, in case it helps:
{
"room": {
"name": "E58S43", "mode": "world",
"energyAvailable": 137, "energyCapacityAvailable": 300,
"visual": { "roomName": "E58S43" }
},
"pos": { "x": 14, "y": 35, "roomName": "E58S43"},
"id": "undefined",
"ticksToDecay": 635,
"hits": 4000, "hitsMax": 5000,
"structureType": "road"
}
-
Unfortunately, the Cassandra experiment has failed.
We've migrated the entire room objects data set on the live world, set up proper partitioning based on room key, and allocated server capacity to Cassandra instances 3x times larger in comparison to the MongoDB server.
The world simulation worked correctly. However, no considerable performance increase has been achieved.
This thread is now closed, the PTR is switched to the master branch. We're back at the world sharding idea, the discussion is in this thread.
