- W48N96 can not remove hostile constructionSites (via the web interface)

I hope I'm not too stupid, didn't touch PTR for a long time now

 - It took very long (~a minute) between uploading code via grunt to PTR and actually showing the code in the web interface

More important:

 - `> JSON.stringify(Game.rooms)
< {}`

I just respawned in room W48N96, I guess I should have at least the room, where my spawn is located.

As always, I'm late to the party Interesting discussion.

Artem: Thanks for clarification. If you ever have any issues with my code base, let me know. Didn't happen yet, so I think I should be fine. It also tells me, I shouldn't include anything which sends me resources (never seriously planned)

Even though I think the discussion is over, with an expected and highly appreciated result, still I would like to add my cents:

Multi-account is a no go. I thought about it by myself a couple of time, to be able to test my attack and defense, but this is solved with the private server. So no reason for Multi-account (tedivm your second account is fine).

Communication protocol: I wouldn't have opened a thread here, I would have expected that it is fine. Planing it anyway since a couple of month, while the authentication is in my case much more important and tricky, than sending some commands.

New players: I'm well aware that some new players are upset by my code, sometimes by the players using my code. It is not necessary a screeps question: Do I reinvent the wheel or do I just use a framework or ready made system. Reinventing the wheel and being upset that you are slower, well I'm missing the understanding for that. Btw. my autoattack is not that strong, I see it more as the minimal level you should be able to handle to survive when the newbie area times out. Just to make it clear, I fully understand the fun in writing the first thousand lines of code, I started from the scratch, there were some code pieces (not compared to today), but I wanted to do it on my own. I wouldn't do it again, today.

The Hive event: Whatever, I don't mind. - Slowly I get the messages from players using the TooAngel AI, mostly from active contributing members. And this is exactly the point where the argumentation for the Event breaks in my opinion. I think it got more tricky to attack other players, because of the alliances, without provoking a proper War. If you want to attack certain players do it (I would do it), but please don't try to reason it by something which is not true. Tbh I think it is boring to attack more then one TooAngel AI, the next one will anyway behave pretty similar

TooAngel Bot: (I distinguish between the bot for the private server, and the TooAngel AI which is the actual logic). I didn't plan to opensource my AI or let other players use it (I didn't announce that my code is opensource at anytime, except of now?;-)). I wanted to release my code as bot, so that I'm able to play against it. From the feedback I got, it is highly appreciated. So you can't have both a bit more advanced bot that the simple bot, but no fully automated code available.

Because I'm mainly developing with the bot in mind, this my most tricky part for the communication. How do I make sure that I don't friend up with the TooAngel bots on the private server, while doing it with the TooAngels and ocs on live

It would be awesome if the subscription info (how long it will last) be available from the in game API and also applying tokes (not sure if it is already).

Especially to judge if I should sell my last token or keep for some days to apply.

I don't think it matters, because I didn't have the impression that I was involved in the WW (was I?).

Bonzai took out most of TooAngel's rooms in E15S15, E5S15 and E5S5, after TooAngel helped out ThyReaper defending. (@Skorp)

A bit late to the party, just some thoughts from the defensive side.

As most of you might know I have some months getting a lot of rooms destroyed (but not many rooms unclaimed) history. Also from the perspective of a player not yet fully in the mineral age, but fully automated.

Given equal attacker and defender, as soon as the defender looses a room, they have a disadvantage, one less room for resource supply and the need of building up the room again.
Getting the room back to be a reliability is hard. The attacker showed already that they are capable of destroying the room. Now the structures needs to be build up (which can be prevented in multiple ways), which is expensive. Also the walls are broken down. So you have to send at least the same amount of fighting creeps as the attacker, plus something rebuilding the room.
IMHO as soon as the last spawn in the room is destroyed it is a clear advantage for the attacker - Just for maintaining the status of the room.

So, I guess, the main point of this thread is: How long should it take to have a room get unclaimed by itself, how much can you speed it up and how easy should this be prevented.

To be honest from my perspective I can't judge if the current system is unfair. What I have seen so far:

- pretty successful and creative approaches, usually blocking the entrance to the room or the path to the controller, combined with attacking the controller. Maybe some attack on the rooms which are sending creeps, to keep them busy, not to kill the room. (Usually smaller players with less resources)
- the attack or resource approach: Destroy other rooms from the player until the actual room downgraded, without a proper attempt to actually prevent or speed up the process (from my experience, mostly used by the bigger players or alliances and less successful)

I didn't do proper attempts to prevent controllers from downgrading, just sending a creep with some energy worked out for the second case. For the first case I usually only saw the replay and I'm excited for the next to try the approach and if I can find a way to come around their attempt to defend the downgrading controller.

Maybe I'm missing the proper fights around room downgrades. Did you really properly tried to get the rooms and not only be disappointed that the counter was back at the beginning after a night of sleep without having defense in place.

So the impression I got a bit is: Fighting is a quick (some hours maybe some days) thing and (at least before the world war) most people are surprised that just killing the spawn is not a win.

IMHO as soon as the room is destroyed the attacker needs to show their 'defensive' skills, which is not necessary a resource fight. You just have to snipe the creeps with the WORK parts and a properly timed attack on the controller does wonders.

To force a mind change for the situation, I think attacker should be somehow motivated to defend that room, without wiping the other player. Just as an idea: A couple of days ago on slack there was a discussion about, make structures belong to the controller owner, so if you are able to claim the controller, you own the structures - maybe if the defender respawns all structures should be destroyed - not sure if it is motivation enough.

If I had to vote for a suggestion made in this thread, maybe QzarSTB last edit: 'Block' Controller, preventing upgrade and attack on the controller, can be build up, can be broken down. This introduces more complexity to handle both sides. Could be my wrong impression, but I think the current complexity is not handled by the players instead usually solved via brute force (wipe the player). I doubt that introducing more complexity will help so much. Same story here from heggico, I could build up the 'Block' Controller and it will take x amount of time, or I wipe the other player and will get the room much quicker.

Most of the other suggestions fall for the same problem, you could do X, but you could also wipe the other player, K, will wipe them.

There you go http://steamcommunity.com/sharedfiles/filedetails/?id=800902233

Hey, thanks for testing and sorry for the inconveniences.

I had something similar issue once, where no more ticks where processed (not directly related to adding a bot, but having ~5 bots running). After closing everything, screeps-server, screeps-steam-client, even steam and restart everything again it was fine.

I'm not sure if and how I could have introduced the error, the mod is mostly a combination of the example-cli command, the signup and the set-spawn method from the server. Nothing fancy.

I hacked a mod to add a bot to your local screeps server:

https://github.com/TooAngel/screeps-server-bot-mod

The status is 'works for me', just one command `addBot()`: Selects a room, places a spawn randomly and uploads the code. The code is presented as json file, similar to the one which is used for uploading via API, so can be easily replaced.

The bot is based on the TooAngel AI, in most of the cases rooms are fully automated to lvl 8 and new rooms are claimed, if possible. The bot is not really challenging (not yet), but I think a good base to improve on.

The best: Now you can beat up the TooAngel AI on multiple servers and instances

Any feedback or suggestions are welcome.

Hey, I like the `Creep.withdraw`. Will PTR also be in a status soonish again in a status where the changes can be tested an implemented. Currently the tick duration seems to be between 5 seconds and ~8 hours, which takes a long time to test