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

The lockups are gone, but now after a while an other problem occurs.

28.2.2018 08:13:56# Main heap: 1968205824
28.2.2018 08:13:56# ExternalCopy.totalExternalSize: 6241895
28.2.2018 08:13:56---
28.2.2018 08:13:58releasing isolate 5931b0ca0d6e8c000b0303f9
28.2.2018 08:13:58isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:13:59creating isolate 598e1fcfc0271d001a0722b2
28.2.2018 08:13:59isolated-vm timeout 598e1fcfc0271d001a0722b2
28.2.2018 08:14:04releasing isolate 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:04isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:06isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:06---
28.2.2018 08:14:06# Main heap: 1967157248
28.2.2018 08:14:06# ExternalCopy.totalExternalSize: 4903808
28.2.2018 08:14:06# User 598e1fcfc0271d001a0722b2 heap: 19169776
28.2.2018 08:14:06---
28.2.2018 08:14:11isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:13releasing isolate 598e1fcfc0271d001a0722b2
28.2.2018 08:14:13isolated-vm timeout 598e1fcfc0271d001a0722b2
28.2.2018 08:14:17---
28.2.2018 08:14:17# Main heap: 1964240896
28.2.2018 08:14:17# ExternalCopy.totalExternalSize: 3565721
28.2.2018 08:14:17---
28.2.2018 08:14:18isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:20isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:25isolated-vm timeout 598e1fcfc0271d001a0722b2
28.2.2018 08:14:27isolated-vm timeout 5931b0ca0d6e8c000b0303f9
28.2.2018 08:14:28---

restarting the runner fixes the problem.

I still have to setup the vanilla server without mods ... will do today, probably.

@rurik said in Draft: room event log:

Claimed rooms would never have to .find(FIND_HOSTILE_CREEPS) again. The hostile creeps could have their id's recorded when they trigger an EVENT_ENTER and tracked until death or EVENT_EXIT, which could both be handled differently. Granted you'd have to check the log every tick versus perhaps only doing a .find every x ticks. Which method would require more CPU do you think?

The log way will use much more CPU. FIND_HOSTILE_CREEP is quite cheap since it usually contains nothing. For the log you have to pay cpu for the parsing of all events in the room. With find you don't have to keep track of creeps.. you don't have to check if the entering/exiting creep was friend or foe. If a hard reset occurs your track of creeps in the room might be outdated. I don't see the advantage of EVENT_ENTER / EVENT_EXIT, yet.

@hiryus said in Draft: room event log:

Do you need room vision to access the logs ?

• On the plus side, it would be handy for solo structures being killed in remote room.
• But on the other side, reading events can give a lot of information without any risk (harvests, attacks, repairs, upgrades...). Which a good algorithm, you could probably know everything in the room (structures, positions, controller level, etc.).
• ... which is something you can see manually with the client anyway.

Any thoughts or decision ?

vision will be necessary... the server has to prepare the data it sends to your program before your code starts.