@artch

That might be very workable, I'll definitely look into what it would take. I wonder if it would be possible to get a new subforum for asking questions related to 3rd party tools, sometimes a little direction from the devs can go a long way.

@artch

Do you have any thoughts on what would be the best solution for your project, considering our needs with this new system?

Unfortunately I don't have any brilliant ideas. Clients are going to be in a whole different class of data use compared to an automated tool like a stats-checker. While a stats-checker will use a little bit of data constantly, a client will use potentially quite a bit more data except only when the player is active. That is why I thought the per-day limits might mitigate the problem, but it is only a partial solution and it isn't suitable for the reasons you've stated above. Another issue is meeting these limits with the client might lock a user out of other tools, which would be unacceptable to most players. The heart of the problem is that automated tools can be designed to stay within reasonable limits, but a client's data use will be intrinsically unpredictable and sporadic.

I can't think of any solution short of allowing clients to bypass the limits, as you've done with the official client. It might be that the best use for 3rd-party clients is with private servers. Since the Screeps3D project is being developed under the MIT license I suppose it would be possible for the dev-team to release their own version that has been modified to access the public server, but I realize that is probably unrealistic.

The screeps3D project was planning on an early release to showcase the work so far. Based on this discussion, it sounds like there are still some issues to be considered for 3rd-party clients (overall data use including websockets, resetting rate limits). In light of that, it probably seems best not to do a release when it is uncertain what kind of issues it might cause for the public server.

About the rate limits, I'd humbly request some other option than the manual reset. It would not be very good user experience to be scrolling around the map and occasionally have to do a CAPTCHA. I'm not a web-dev so I looked up the invisible reCAPTCHA and I'm not sure that will be possible to do in a non-web environment like unity3d. Of course I understand that the dev-team has limited resources to accommodate the needs of a 3rd party client, so I'm not expecting it. It might be best to put the project on hold until there is something available.

The per-day limits would help to mitigate the issue, if it still serves the same purpose.

• 10 per hour -> 240 per day
• 60 per hour -> 1440 per day

To keep players from being locked out of using the game for a whole day because of abnormal use or some bug, perhaps a limited-use reset system would help.

In addition to that, if it were possible to raise some of the limits that are easier to hit that would probably solve a lot of the issues at least with my project.

I'd be interested to hear about the purpose for the limits, I had assumed it is so that players cannot bypass the CPU limitations with 3rd party tools.

The auth tokens seem like an excellent feature.

As someone working on a 3rd-party client, the rate limits are a bit concerning. My interpretation is that, for example, a user will only be able to use the POST /api/user/memory 10 times per hour. The given limits seem geared toward an average session and most will probably be hard to reach with normal play. But if you were debugging or testing some screeps code I think it would be very easy to reach many of them. This is sort of a difficult situation for anyone making a client, and it would almost seem to make it unfeasible.

I don't think the dev-team should feel obliged to support 3rd party clients, I imagine there are a lot of potential issues with accommodating them. But if that is the intent it would be good to let the community know.

I did a write-up on the tournament: https://screepsworld.com/2017/09/enter-the-botarena/

@SteveTrov those sound like some good suggestions for "the quickening". Maybe also increase the amount of hits lost by rampart upkeep or reduce the interval between them.

Some excellent changes, thank you for engaging with us on this.

These changes shouldn't impact the standard defense very much, it should still be very difficult to take over a well defended room. The main difference would seem to be in the aftermath. Without the help of safemode and insta-recovery, the defender will need to put an equal amount of effort into taking back a room. They can still build structures and restoring a controller is still much easier than attacking a controller. But other than that, it would seem to be a level playing field.

It will also mean that players need to be more careful about guarding their controllers.

Over all, this ought to breathe some life into the possibility of attacking/holding a room.

@artch

we need to consider power creeps in this regard

I can see the sense in waiting to see what solutions Power Creeps will bring, rather than add mechanics that might eventually be unnecessary.

Since we don't know when that will be, is there anything that seems reasonable to you to adjust in the meantime? Even just increasing the potency of attackController would go a long way toward addressing this issue. CLAIM parts are already very expensive and distance-limited. It seems like the current potency is below what is justified by the cost.

@artch

Some ideas for StructureSiege:

• Disallow safemode while it is in the room (safeMode can always be popped before it is completed)
• Have upgradeBlocked while it is in the room
• Give it .energy and .energyCapacity properties and allow some of the same functions as a StructureTower
• Energy might also be used to attack the controller to reduce ticksToDowngrade
• Make it expensive to build but also give it enough hits that it can't be knocked down in just a few ticks (perhaps 1m hits)