Says 1000 characters, but it's actually 500.
http://docs.screeps.com/api/#Game.notify
Test code:
var str = ''; for(var x = 0; x < 1000; x++){str += x%10;} Game.notify(str);
Oh I guess it's been reported before:
http://screeps.com/forum/topic/762/Game-notify-message-length
It's most likely the Memory parse cost. The first time you access memory, you incur the cost of unpacking the whole thing.
Try adding another 2 lines at the top:
console.log('before memory', Game.cpu.getUsed());
Memory; // This will force the Memory to de-serialize and be read into the cache for use during the tick
<rest of your code here>
I've had the same "error" when I had half-built extensions in a room and then reclaimed it. While I agree that it's a pain to code your creep.build() around, I think it's a fair implementation and the solution is "don't put yourself in that situation."
Also for what it's worth (though it's not always consistent), the spawn/construction site/whatever closest to the controller is the "correct" one according to the game.
Dewey
Hey, I found a bug. Seems like there's inconsistency in several areas of the code. I believe it has to do with this latest patch:
https://github.com/screeps/engine/commit/91c9bf03a13743d3837b082f26b0a7689021237d
To sum it up - Active structures are determined by range to the controller. But ties aren't broken consistently. Extensions (and other structures probably) in re-claimed rooms are messed up. I'm getting 4 different sets of information.
1. Visual - Some extensions look normal, some are red (duh).
2. Structure.isActive() - One of the red extensions returns TRUE. One of the normal extensions returns FALSE.
3. Room.energyAvailable - The number agrees with what I see visually (not from isActive() )
4. Spawn.createCreep() - This will pull energy from extensions that are visually (#1) marked as active, rather than checking isActive().
What causes the issue?
I think isActive() is based on range to the controller. Ties aren't resolved consistently.
Why is this an issue?
When I'm re-claiming a room, I inherit the extensions. To keep my extension fillers focused, I filter the extensions based in isActive().... So yeah, the room never fills up, and my spawn process gets choked up.
How'd I resolve it?
Well, on my end - I kept deleting extensions until the problematic extensions were on a path frequented often, so they got filled up in passing. Not totally ideal.
Thanks! Hopefully someone better at this than me can take a look!
Dewey
p.s. I started deleting extensions soon after this: https://screeps.com/a/#!/history/W59N46?t=19734400
Currently marked normal, but isActive() == false: 5927f47427ccaf9c36aae085
Currently marked red,but isActive() == true: 5925da43966ccf98054823e9
Hey there, I have a small convenience/improvement request.
I was just searching for the correct spelling of something on the API (http://docs.screeps.com/api/#Resource.resourceType). Since it's not something I type often, I double-clicked it to get the right spelling. But that unfortunately also pulls in the type, so when pasting it comes out like this:
Not something big - but it was a nice function of the old API !
Thanks!
Dewey
Coteyr: I agree it is straightforward, but I see the core issue differently. I think the core issue is the signage.
If a room is signed with a respawn notification, then I'm happy to understand that the devs have decided to mark it for a respawn zone. Players should act accordingly.
If, however, the previously signed rooms suddenly become unsigned, then logic would dictate that the devs changed their mind and we shouldn't expect a respawn zone there any more. And that's where the problem came up. A respawn zone had its signs removed and then ~12 hours later it became a respawn zone anyways.
I'm happy to believe this was a bug / one time thing. But I'd appreciate confirmation and reassurance from the devs.
Dewey
Great post. I agree that we need clarification and consistency. If the signs disappear, that gives the impression that the area is no longer being considered for a respawn zone.
I wanted to provide some prior resources/discussions:
Initial thread:
http://screeps.com/forum/topic/234/Room-signs-failing-to-prevent-novice-zones-from-appearing
PTR mention of signage:
http://support.screeps.com/hc/en-us/community/posts/115000582245/comments/115000216869
Official "respawn zone" document:
http://support.screeps.com/hc/en-us/articles/115001774029-Changelog-2017-03-09
I've seen multiple reports of this since this change: http://support.screeps.com/hc/en-us/articles/115001774029-Changelog-2017-03-09
awr000 reported it on Slack this morning.
Definitely game breaking. Please resolve this asap.
I figured out why my creeps were disappearing. I'm able to "renew" creeps while they're still spawning by using a different spawn. The affect of this is in the screenshot attached (TTL goes from undefined to -17850488). When it spawns, the creep immediately disappears (no energy dropped).
See https://screeps.com/a/#!/history/W73N64?t=17850234 - the bottom most spawn.
Players Icon & Vaejor were able to help me pinpoint the engine code:
https://github.com/screeps/engine/blob/master/src/game/structures.js#L1132
> This checks for if(this.spawning), which only checks the StructureSpawn, not the Creep.
https://github.com/screeps/engine/blob/master/src/processor/intents/spawns/renew-creep.js
> Same here
________________
I'm no engine expert, but the discussion we had suggested that the check should be done twice. First is structures.js to check via the API for creep.spawning and return ERR_BUSY. The other is in the renew intent, to check whether the creep actually spawning.
________________
I've lost many good honest creeps to this. Please think of the creeps and fix this soon!
Dewey
I found Dissi's suggestion of "intermediate rooms" very interesting.
What about yellow/orange sectors for intermediate players. While there wouldn't be walls blocking entry, it would have some limitations to help players get established. For example - no boosted creeps (any creeps entering the zone lose their boosts), and no nukes.
I could also support Tedivm's idea of signing controllers with boosts to prevent noob zones from opening.
Dewey
_.omit(controller, 'sign');
Has solved my problem, but it should still be resolved.
Hi,
There seems to be a bug with the new signing feature. Controllers signed by someone else cannot be accessed programmatically.
Game.getObjectById('controllerId').sign
-->