likewise with containers the upkeep cost could be different for owned rooms and unowned rooms.

should it be possible to build tunnels through build walls ?

should it be possible to rampart walls to prevent tunneling?

I like the idea of tunnels

but I guess they should be only allowed in own rooms ?

I'm also interested in whats going on... I have heard rumors about persistant game objects? Forums are quite silent the last weeks .)

@shibdib like "We're having some issues on the servers. Our technical staff is already notified." ? ... look at status.screeps.com

just wanted to thank you guys for work on the ivm it's really working great and a huge lift of the experience.

I was (particulary since the node 8 update) literally getting hundrets of hard reset mails every day... and they are all gone now. I only had a very small percentage of those high cpu ticks, and they are all gone with ivm.

I switched to lvm this morning... and cpu usage looks really smooth now... I hope it also has a nice advantage on backend site for you guys.

I thought about it some time ago and my idea was using redis as the interface to other runtimes. Maybe that's possible, but as @ags131 said permormance is key.. and the screeps dev are currently investing lots of time in optimizing the runtime ... I don't think new runtimes that might cause slower tick times are currently the right direction.

Looks like in the current beta RoomVisuals are not working for me...

I think the penalty is fine, even if that means that you need to have an outpost on a other shard to attack rooms there. There are more balancing differences between shards like tick times (=spawn times) , market availabilities and the area creeps can reach because of different portal placement.

Thanks for the update .. I will update my server and see how it goes .)

I like the change.

I don't think that the time changes really add much complexity to the system on the programming side

Most other suggestion like changing required RCL level for T2/T3 reactions would probably be much more complex.