administrators

As far as I can see, they're fixed.

I'm not sure that I can imagine use cases when such methods will be really useful.

An inter-room flood fill sounds insanely expensive on the heap while an intra-room version can be easily implemented by a player.

@nobodysnightmare It was before:

CONTROLLER_DOWNGRADE[level] - CONTROLLER_DOWNGRADE_SAFEMODE_THRESHOLD

Now it is:

CONTROLLER_DOWNGRADE[level] / 2 - CONTROLLER_DOWNGRADE_SAFEMODE_THRESHOLD

So you're safe even if you don't make any changes to your code.

PTR updated. Let's check this out and ensure that we have no reasons to be unhappy about this mechanics anymore.

This post describes changes on the Public Test Realm.

Commits on GitHub:

• engine#440cc83
• common#68d9b1d

Changes:

• Controller downgrade timers are changed to these values:
  • 1 level: 20000 ticks
  • 2 level: 10000 ticks
  • 3 level: 20000 ticks
  • 4 level: 40000 ticks
  • 5 level: 80000 ticks
  • 6 level: 120000 ticks
  • 7 level: 150000 ticks
  • 8 level: 200000 ticks

• When the controller gains or loses one level, its downgrade timer is set to 50% instead of 100%.

• Safe mode activation unavailable period starts from this 50% point minus 5000 ticks.

See previous discussion in this forum thread.

This feature is supported in private server ptr branch:

npm install screeps@ptr

@maxion it will be available, we're changing it from CONTROLLER_DOWNGRADE[level]-CONTROLLER_DOWNGRADE_SAFEMODE_THRESHOLD to CONTROLLER_DOWNGRADE[level]/2-CONTROLLER_DOWNGRADE_SAFEMODE_THRESHOLD

Looks like Option 3 contains a calculation error: RCL6→RCL7 case is still 600 ticks, not 750. Hopefully, this effect will be somehow compensated with a proper attackController overflow handling.

Thank you for reporting. It's a known issue, we're working on it.

I was using Microsoft Visual Studio Code for a long time, it's free, lightweight and generally cool.

Thanks for your report, we'll take a look