Posts made by sonoftheflame

@dissi-mark said in [After RCL decrease, selection of disabled structure?]

This is done by comparing the distance from the controller: https://github.com/screeps/engine/blob/master/src/game/structures.js#L197
And the util method: https://github.com/screeps/engine/blob/b52164089564d1dc8a7e894835258f9a954cd37f/src/utils.js#L855

Ah! Thank you for that clarification! Could that information be added to the available structures per RCL documentation?

It opens quite a lot of ways to abuse the system if we would allow this. (transfer & disable, enable other link immediately)

Chaining disables and re-enables would be unwanted behavior. Could those issues be negated with a "cool off" and "warm up" timers so that the disabled structure and then the enabled structure are unavailable to disincentive that kind of abuse, or that after a structure is disabled to re-enable another of it's kind, unless the RCL returns to the needed and previous level, the structure can not be re-enabled for a large number of ticks?

Understandably that behavior would likely not be a small thing to implement and the time needed to do so versus it's benefit to the game, when compared to some of the other features that may be working on, so my question is more of a hypothetical than an actual request.

In the event of a RCL drop, how is the selection of which multi-level structure (where different numbers can be built at different levels such as towers and links) handled? Is it just the "alphabetical" ordering of the IDs or the structure's position within Game.structures and the last instance is disabled?

Additionally, is there a way to influence which structure is disabled other than destroying structures; such as setting a "disabled" or "off" value?

For instance, if at RCL 6 I built (in order) links A,B, and C where A is to transport from my source to B, which is next to my storage, and C is the drop-off point for remote miners and would transport energy to B as well. Due to layout issues I then needed to destroy B in order to relocate it. If my RCL then were to be reduced to 5 would it be possible to designate that C be disabled first?

Thanks!

@artch

When upgradeBlocked is active, upgradeController can't be called at all, it will return ERR_INVALID_TARGET.

This leads me to believe that while upgradeBlocked is active you can not increase the progress.

• While the controller is downgrading, new level cannot be triggered even when the controller has enough progress (progress is not lost but accumulated).

But this makes it sound like progress could still be accumulated.

Is it worded this way to say that attackController does not remove any progress, but also blocks the RCL change if the upgradeController preformed on the same tick as attackController would have triggered it?

Also, some more general questions that are not very clear in the documentation, what happens to the progress level after a controller downgrades, is it set back down to 0?

Upgrading the controller raises its ticksToDowngrade timer by 100. The timer must be full in order for controller to be levelled up.

Does this mean that while the timer is not full upgradeController actions are applied to both the controller's progress and 'ticksToDowngrade'? If so, is the 'ticksToDowngrade' increased by 100 per creep preforming upgradeController or does it scale with WORK body parts or the progress points that would be added (boost vs non-boost)?

You can see it jump from (48,38) just after https://screeps.com/a/#!/history/shard1/E2S46?t=1367292

@artch @W4rl0ck Ah, well alright then! Thanks for the responses!

Shouldn't my cpu not be impacted by the process of other users, and if it is would the fact that the majority of players on ptr only having 10 cpu mean that there would be significantly less additional overhead compared to the live server?

My reason for this post was to see is anyone else was seeing this as well because if the CPU cost of intents had doubled since a change on PTR (I had not seen this issue on prior sessions on PTR) then that may be something that needs to be pointed out, and if it was just me then that would more likely point to some flaw in my code or testing rather than an issue with the next deployment.

While running the same code on the live server as PTR, with similar situations (no large differences such as additional buildings or different rooms) I noticed that even with a greatly different amount of creeps (64 on the live server and 42 on PTR) I am seeing some significant differences in CPU use. on the live server I was seeing an average of 47.71 CPU per tick with my bucket staying above 9900. On PTR I was seeing an average around 72.8 causing my bucket to gradually deplete, despite having less creeps. After some investigation using the profiler it almost appeared as if things such as room.find are using more CPU on PTR than the live server.

Using the profiler over 30 ticks, on the live server I tracked 1360 calls to Room.find with a total time of 64.1 and an average of 0.047. On PTR I saw only 661 calls to Room.find with a total time of 65.5 and an average of .099.

While the difference in situations may very well be the issue with this discrepancy, could anyone else take a look at this and test it out to see if I'm correct in what I'm seeing?

Thanks!

The high ticks until regeneration appears to have been resolved, meaning that it appears that everything I brought up in this thread has been resolved. Seems that I was looking in the wrong tab and the high ticks still appear to be there. Thanks!

@artch Shard 0 now appears to be processing ticks, but many of the sources, including those with active creeps are showing refill times over 180,000 ticks.

The global. suggestion resolved my issue in the simulation rooms.

On PTR, Shard 0, rooms do not appear to be running or ticks are not being processed. TTL are not counting down on structures and creeps are not spawning. Even after registering for 24 hours of full CPU, no CPU is being used.

From the live world, in the training room and the custom room, declaring global variables (by setting a variable equal to something without using something like const or var) outside of the main loop, outside of the main file (such as in an includes file declaring roles) is resulting in an undefined error for the variable attempting to be declared.

With the combination of these two, players appear to be without a test environment unless they re-spawn onto shard 1.

Thanks!