I got my answer yesterday night.

a rather small battle around a relatively small gamma base: I got killed before i could active a module even once -> because of lag.

i didn't even see my own explosion, just the loging screen.

If any DEV says "we didn't expect players to do that" regarding 500m tall terrain walls, 1000 Turrets with 1000 support structures within a visual range of even the worst detection bot, with each Turret having its own accumulator, independant AI and permanent LoS calculations, probably for two weapons individually.
Now add the bandwidth issues you get when sending 100 player the uncompressed terrain data at the same time, everytime a plant dies...

Is there a client debug/monitoring tool? If not can one easily be created? A stress test on the Test server would be good. The DEVs should create a massively terraformed base with hundreds of structures and invite a fleet of 100 or more to come attack it. If we all run the debug/monitoring  tool it might help get to the bottom of the inconsistent lag.

I have been involved in a few of these battles around many structures and terraformed terrain now and the one thing I've noticed is that there is no consistent performance between participants. Last night both the clients I was running were perfect, responsive with no more than the usual tens of micro-second lag whilst others right next to me were having big issues. In other battles its been me with the lag issues and others without.

i dont really think its structures per network - seems more like structures on the shard and total on server.

Ludlow - there is no Test server anymore. it was integrated into the network to host a few of the gamma islands. The only Test enviroment they have is the DEV server, which often simply doesnt show the issues.

they dont have to simulate masses of npcs - that works like charm. the issues start when the server has to communicate with clients all over the world.

Needs a tick box for polygon pbs structured like with robots

Well, there should be a killswitch, it's always useful

Yesterday i used "Process Monitor" to spy a bit on the perpetuum.exe and what it does while i am playing.

i always thought that things that i discover ingame are directly written into the gbf-files. eg. plants, terraforming changes and buildings/walls (black dots/lines on map), and that this is the reason for the crashes and such.

The monitoring yesterday showed me something different:
- layers.gbf (the terrain database) is only accessed on loading screens or when you got the worldmap open (not minimized) writing happens when you hit a loading screen.

- live changes from terraforming and exploration are stored in RAM or handled by a process that i didn't see

- as long as i have the world map open, there is a constant Read/Write access to the layers.gbf, even when not moving or zooming anymore.

- didn't pay to much attention to the TCP/IP traffic but sometimes it takes very long to get a terraforming update, especially when your moving from south west to north east.

another thing i noticed is a directX error message during loading screens...

last but not least - the tool showed me which island runs on which server. knowing that you can probably tell which islands are affected when one server is overloaded and you dont want to be fully affected by it.