Posts made by bonzaiferroni

@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)

@w4rl0ck

We were talking about an idea that is similar to that in our alliance chat recently, I think it has some interesting potential.

One of the reasons I suggested these things in particular is because they would basically require little more than adjusting some constants. I know the devs have their hands full with performance upgrades and new features. I thought this might allow us to bring some balance to PvP in the meantime.

Those seem like some great ideas, and I'm very encouraged by the discussion.

The mechanics suggested by @dissi-mark have some nice potential but with those numbers they seem to just be a reshuffling, not an increase in potency. The proposed mechanic would have a 15-part CLAIM creep take down the controller by 3000 in one tick. Continuously attacking with a series of the same creep over 1000 ticks would also take the controller down by 3000.

It could even make some sieges longer. At the moment you can attack with more than one creep.

So it seems to boil down to an energy savings and a normalization of the amount of distance to the attack room. This is a step in the right direction, but the current big issues are the sheer amount of time it takes (which it could actually make worse) and the fact that it is too easy to lose all your progress as the attacker.

I still like the general idea and the normalizing effect it has related to the distance that the claim creep has to travel. I'd just ask that it be more potent, perhaps 500 per CLAIM part rather than 200.

As others have pointed out, it is very unbalancing that ticksToDowngrade is immediately restored upon upgrading with a single energy. It would be much better if upgrading increased it by some amount, but not completely restored it. Perhaps 1 energy would restore 10 ticksToDowngrade points.

edit: made it a little more concise

I was thinking about this too. In order for the rankings to retain their accuracy, there needs to be some way to adjust for shards. People will start to argue that the top player is only there because they are on a certain shard.

I think the ability to filter by shard would be a nice way to present the rankings. You could still view both shards together or one at a time.

I was also wondering if there would be a good way to combine power rankings and expansion rankings. Since it costs 50 energy per each point of power processed, it seems like a simple formula would be this:

total = expansion + (power * 50)

Going along with the filtering idea, players could also filter by expansion/power. That way you could have just a single rankings UI.

Screeps PvP is biased very heavily toward the defender. Being able to achieve an unbeatable defense is one of the stated goals of the game mechanics.

I personally don't see a problem with this, I think it adds a stability factor to the game. However, a virtually unbreakable defense should be the product of clever coding solutions and not the sheer amount of time you've been playing the game. For example, o4kapuk held his room against an incredibly intense attack with an average wall hits of 6m.

One player suggested a max hits of 50m, and this seems like a good balance. If players want to invest in additional security they can always add more layers at the cost of space and upkeep.

There is also too much difficulty in permanently removing a player from a room. The downgrade timer is just way too high. To downgrade fully from rcl8 takes 405000 ticks, which amounts to 21 days with the current tick times (14 days with more ideal tick times).

I realize the devs want to accomodate players who don't check screeps every day, but this needs to be balanced with the goal of making PvP realistic. I think a simple solution would be to make attackController much more potent than it is, perhaps by a factor of 10.

These are two relatively minor changes that would go a long way toward making PvP in the game more balanced, yet still provide a reasonably favorable situation for the defender. I think there might still be some additional balancing that is necessary. Too many players just do not engage in this aspect of the game because it is unreasonably difficult between more powerful players.

The good folks from the alliance DAL (dicks of arbitrary length) have placed many new signs around the world. Their signs highlight a minor cosmetic bug with the UI. It appears that strings without any spaces will just overflow. This creates a somewhat confusing experience when moving the mouse around on the map:

You can find many more examples around this area: https://screeps.com/a/#!/map/shard0?pos=24.5,8.5

This also appears to happen from within the room view.

I ran into an issue when trying to boost a creep that had claim parts. 

After trying to find the cause in my own code, I noticed it would go away when I just commented out lab.boostCreep. I asked another player to try to boost a creep with claim parts and he reported that he would also get the same exception. 

Perhaps this is because BOOSTS[CLAIM] is undefined?

http://i.imgur.com/roo9kyK.gif 

There is definitely a confirmation. Whether or not it is enough is a good question, but atavus makes a good point that it has been this way for a while and I'm unaware of any complaints or accidents.

I'm ready to put it behind me. I think in the future, if a rollback needs to happen in a PvP-heavy situation such as this, extra caution needs to be taken. If the administrators feel a rollback is warranted, it might be worth thinking about a compromise. For example, allow the room to go back into safemode but don't manually add RCLs to the controller.

Also, it is important to be transparent about the action you are taking. I think it would have gone a long way to diffuse concern if the devs had just said "we realize this room is involved in a conflict but we acknowledge there is an issue with the controller unclaiming mechanism and would like to restore this player's RCLs". To just silently accommodate one player shows a total lack of regard for the others involved in the situation.

Finally, there is a bit of an elephant in the room. Dissi, our community liaison, happens to be in the same alliance with the player in question. I'm unaware if it was Dissi or someone else on the team who made the reversal. What kind of assurances do we have that administrative decisions that impact dissi or his alliance will be objectively made? Personally, I'd be willing to accept even just verbal reassurance and transparency. When actions need to be taken that impact Dissi or those in his alliance, it seems best that someone else make the call.

> The room was already in safe mode, there was no effect on the conflict.

That's not true. The safemode ended when the controller was unclaimed and there is also 50k ticks before it can be reactivated. It is also very outlandish to think that you could have restored the room in 20k ticks even if a safemode was allowed.

edit: To clarify, I'm not asking for any reverting of the reverting. What's done is done and any further admin actions will just make the situation even more artificial.

Asking Hernandeur directly, it seems it was an accidental manual unclaim.

This doesn't sit well with me, should probably give a little context as to why. Hernandeur and I have been engaged in some combat over the last few days. He attacked me and took out a lower level room and forced another into safemode. This was likely a response to my alliance attacking someone in his alliance. After that, an attack by myself and taiga forced his room (the one in question) into a safemode.

Sometime after this, Hernandeur accidentally unclaimed the controller, significantly compromising his room. After submitting a support ticket, the room was restored to its original state.

I would really like the devs to clarify, is it their policy to revert player mistakes? How do you decide which requests to fulfill?

In a multiplayer game, an action like this has consequences not only the player in question but those he/she is engaged with. Making mistakes is part of any game, it changes the game significantly when players are insulated from their mistakes. 

The room at E2S7 on the MMO server went from RCL2 to RCL8 at record breaking speed this morning:

https://screeps.com/a/#!/history/E2S7?t=19550754

Can we get some clarification about what happened here?