Group Details Private
RE: Changelog 2018-03-05
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.
RE: Possible solution for multi language support?
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.
RE: Replace TTL penalty on Inter-shard portals with portalFatigue
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.
RE: PTR Changelog 2018-02-28: lab reaction time
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.
RE: PTR Changelog 2018-01-18: isolated VM
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.
RE: 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.