Topics created by bonzaiferroni

@artch if you launched it next week and put it in production three weeks later (for a total of about four weeks) it should be fine. People won't be getting back from the burn until September 5th, so they won't see this announcement until after that.

Thanks for reporting, fixed!

> I would really like the devs to clarify, is it their policy to revert player mistakes? How do you decide which requests to fulfill? The break of RCL2 lasted only 6k tiks (19544756-19550756).During this time there was no attack so restoring is not affected to anything.But if it had not restored then the following negative consequences are possible: * Hernanduer is unhappy because he's all thumbs;* The belligerents are unhappy because they are lost a fair fight;* Support is unhappy because couldn't help;* Developers are unhappy because created a button that makes everyone unhappy. Be happy!  

Is seems that resets for CPU and hard resets have diminished somewhat (feels that way, but I have not data to support it). It would still be useful to have a process to save data as it is produced so that no code issues would destroy it. Could the Dev's give us any available methods that they know of to effect this "save of data".  

My profiling code showed, that a simple Move (without path, just one direction) or Pickup can need 20ms. To execute the first line of the mainloop can need 120ms! If you detect such high cpu usage at the beginning of the mainloop, then most likely all other operations would also be very slow. You might consider skipping that tick - or at least, just execute what's absolutely necessary. Otherwise it's wasting your cpu time in bucket with a timeout. So, if it's not in your hand, you can find that out easily by looking up CPU-time at the beginning of the loop. For other cases, I've found that Memory is saved even after a timeout! So you can write your current state/position into Memory all the time, removing it at the end of the loop. If your script was cancelled by timeout, you can fetch the last state/position from Memory the next tick. However, it would be useful if the system would give us a stacktrace to lookup the last position before timeout.

@Atavus As always, enjoyed your thoughts. Maybe deciding to go to war for just for the fun of it isn't the best way to go, might be better to let it happen naturally. I can't help but get the impression you are basically saying "feel free to have your wars, just don't do it in my yard". TK does have a diverse set of motivations for playing. We all drift in and out of involvement in screeps, but things keep humming along either way. I think as an alliance we sour on the idea of conflict for personal reasons, so we will always avoid that. I've been a lot less likely to send attacks myself except for with players that I know are open to PvP.  @Tedivm Sounds like our motivations overlap more than expected. I enjoy gaining territory as much as the next player, but there are higher priorities. Since I've respawned I've been well under the room and cpu limit. There are rooms nearby that I could take but I'd rather focus on writing the code for it to happen automatically. Maybe those of us who are focusing on automation can join up on a private server. I'd be surprised if there wasn't one already started with that intention.

Bonzai 4 president

You will be able to send, but resources will always drop on the ground.

I think that from technical side communication is totally enough, thus `.say()` and embassy suffice. Everything else, such as alliance mechanics, only restricts players (i.e. backstabbing). Even if you don't have comms, you can gift tributes. If you have comms, you can also say "Please". How you'd think he will respond? If you have comms, you can ask for other guys email or IM. If you have comms, you can trade and share resources. We already have market system that streamlines it. If you have comms, you can wage combined invasions. IMO you don't need cooperative enhancements, because coordination is the best you can have in the end anyway. And it is more fun to code coordination than to build "that cool super enhancement just because you happened to have ally". Also, together you also have higher surge (time to build X sized army close enough to enemy) than alone. Having military allies already is OP, lets don't make it even more. If you have comms, you can wage combined invasions a lot further. Remember that GCL is exponential thus together you would have more controllable rooms than alone, thus you can have bases spread across wider regions. If you have comms, you can agree to invade and seal a self-enclosing group of rooms together. Thus you would optimize your defense capacity A LOT. If you have comms, you can agree to build wonders. For example decorative signs from walls. IMO super-power special wonders will only force players to play more cooperative just because it is more efficient. I'd prefer leaving it to players to decide how to play. If you have comms, you can build mutual trust. IMO trust is more important than enforced alliance mechanics. Are you afraid of backstabbing? Well then you need to make sure that also a partner benefits from cooperation and he isn't a YOLO guy. But that's politics. I am only saying that this is a cooperative game already with enough ways how to cooperate (after they introduced .say(), but even before that you could encode message in a "dance" with screep). But UX improvements would be nice. For example to have a blue color for myself, green and yellow custom lists of players and everyone else red. Also some metrics and highscores for "combined wars" or "mutual defences" would be awesome, even if non-official.

+1 to this. One of the things I really appreciate is the approachability for new players and how CPU use is structured to support that. When you're just starting out on your first room, you really can't overuse CPU unless you're doing something horribly wrong. Then as the game progresses and your influence grows, you start (gently, at first) running into things that are taking more CPU time than they should, but even the most basic of optimizations gives you enough headroom to keep growing. Then you look at the top players, and CPU optimization is almost all they think about. They're coming up with creative ways to stretch every last bit of usefulness they can out of it. I also appreciate the way the base library is organized. The obvious, first level stuff that you want to do with creeps is readily accessible. There's quite a bit of depth to the available information, but it also leaves what I assume are some intentional gaps, things that technically work, but might not provide things in exactly the way a developer would want them. This is, after all, a programming game. I'm sure many of us have added quite a bit to the core objects to support our goals. Finally: a shout out to power banks. I know there's a discussion about whether power creeps make sense in the game balance, but mechanically the concept of power banks is brilliant from a game design perspective. It provides an energy sink for players with more energy than they can spend, and it provides an incentive for otherwise peaceful players to implement code that could be very easily converted to be useful in assaulting remote rooms. Many players would never develop code for this without such an incentive. Your team and efforts are much appreciated. Looking forward to more!

Inactive terminals now have storeCapacity equal to 0. You can send to them, but resources will always be dropped on the ground.

Yes, this is a known issue, we're going to address it in one of the next patches.

Thanks for you thoughts, much appreciated. Please consider writing a review on Steam once you buy the game. In fact, it could be clearer overall that the game requires a monthly subscription, it is only mentioned once pretty far down in the description. When most people buy a game on Steam they aren’t expecting a subscription model, it has to be really clearly stated. The problem is that the clearly visible CPU subscription purchase option is still hidden at the store page due to a setup mistake made by Valve staff. I hope it will be resolved today.

Yea.. thats the issue... finding someone to trust... *eyes everyone carefully*