Large Drone Swarms cause FPS lag, other people claim to be unaffected.

[Gwyvern]

The title prettymuch says it all. I've compared specs with some of these people and I usually wind up equal or higher, so It isn't my computer, is there a setting I should have turned on that makes large swarms of drones not grind my FPS to a halt?

 

[Sachys]

The title prettymuch says it all. I've compared specs with some of these people and I usually wind up equal or higher, so It isn't my computer, is there a setting I should have turned on that makes large swarms of drones not grind my FPS to a halt?

Would be handy if you could post your specs, your settings and give some idea of how large a swarm of drones (as well as their mass - perhaps even a rough loadout). I'm sure somebody can advise then.

 

[Gwyvern]

Intel i7 4790K, Nvidia 970, 16GB ram, Windows 10 64 bit

First swarm unknown, didn't count them, second swarm were tiny little miners, about 120 of them, enough mass for two beam/salvagers at efficiency, some power, thrusters, and a bit of cargo space. The second swarm didn't even do anything, the lag hit the moment they undocked.

 

[Crusade]

Lag will happen when you undock initially, this is due to collision calculations - even if nothing is colliding, the game will still try to calculate collisions for ships - give the drones a moment or 7 to get out of the collision range of the mothership - that should remove most of the lag.

Also, turn off framebuffer. you can get some pretty substantial FPS gains from doing so.

 

[Scypio]

Also undocking them one by one, or a least little by little should be less painful.

 

[Sachys]

about 120 of them

this may well be the issue - possibly they are colliding into each other.

also, you didnt supply info about your settings.

 

[Panpiper]

I have similar issues, and it doesn't just affect me, it affects the whole multiplayer server. I recently built a fleet of eighty drones. These were unusually large ships for drones, massing 6K and carrying no less than 16 PD turrets each. The server was fine till I fielded that fleet, and then there was a server wide slowdown from a constant low grade lag. I moved the fleet to be three sectors away from my homebase such that they read on my fleet report as 'unloaded'. At that point, all lag disappeared and the server was back to it's regular self. Then, while the admin was on, I bade him watch as I was about to jump into the sector that contained my drones. The instant I did so, server lag redlined with pings above 4K.

Fortunately my ship recharges it's jump drive in little more than ten seconds, and for some reason, something was firing at me. I did not stick around to find out what was going on (if for some reason my drone fleet was firing at me, I would last mere seconds). I jumped out of the sector blind. The ping promptly went to normal. That's when I requested that the admin delete my drone fleet.

Many have theorized that the problem was less the drones and more those 16 PD turrets on each of them. It amounts to a total of 2640 entities in a sector, all of whom likely are doing that collision check thing. I would dearly love to know for sure though, as IMO lots of PD is essential to keep a drone fleet from being a sitting duck to swarmer drones. Just how little PD can we get away with? In theory the PD of other ships would factor into the defense of individual ships, but not completely, and the ships are going to be all over the place, while the swarmers will likely be more concentrated.

 

[AtraUnam]

Ok heres what causes lag in general from my experience:
2 huge entities does not cause lag
Lots of little entities do not cause lag
2 or more large entities each with several little entitieis docked to them THAT causes lag.

 

[Malacodor]

2 or more large entities each with several little entitieis docked to them THAT causes lag.

Even small entities cause lag, if many other entities are docked to them.

 

[Panpiper]

We need a system that declares entities inert until such a time as they are not. If a ship has no call to rotate it's entities, it's entities should be declared inert and simply added to the size of the ship's own bounding box. A collision of ship's bounding boxes would wake the inert entities (maybe) so more precise calculations could be made at that point. But there is absolutely no reason for a bunch of drones sitting in space to have to be doing collision checks for their turrets that are doing absolutely nothing.

Moreover, it might also be useful to have two bounding boxes for ships. There would be the immediate bounding box that includes the size of any projecting turrets. something impinging upon that box would wake all entities within the box. There should be a larger box however, probably something on the order of ten or twenty blocks further out in all directions, when something impinging upon it would cause the ship to attempt to move out of the way of the impingement with a speed proportionate to the velocity of the impingement (then promptly stop with maximum thrust when the penetration is cleared). Something penetrating 'that' bounding box should 'not' wake the docked entities of the ship.

 

[Lukwan]

I wonder if it would help if Schine re-imagined turrets as AUX-entities instead of 'separate' entities. Same for doors and other cool logic. Once they have been designated as Auxiliary Entities they remain (semi-) permanently connected to the main entity. The rail-docker connection must become intangibly fused to the main ship rather being destroyed, maintaining it's orientation to the ship even after being rendered non-functional (the block should pass damage through to avoid an indestructible exploit).

The Aux-entities could still be docked and un-docked in build mode or a SY but they would remain firmly in place during battle. It would make sense to add an AUX-Rail and an Aux-rail docker as two new blocks. To prevent a ship-exploit AUX-rail dockers should not work with ships. When an Aux-rail docker is 'destroyed' the docked entity ceases to function (no movement, no power generation) and remain as a dead-weight of mass.

The big advantage with this arrangement is that the number of collision-checks could be reduced. (I assume...just brainstorming here)

 

[Spartan4845]

If they could/would add this, it would be amazing. I could then add all the sliding doors, turbolifts and other moving systems in my ship, lol.

I wonder if it would help if Schine re-imagined turrets as AUX-entities instead of 'separate' entities. Same for doors and other cool logic. Once they have been designated as Auxiliary Entities they remain (semi-) permanently connected to the main entity. The rail-docker connection must become intangibly fused to the main ship rather being destroyed, maintaining it's orientation to the ship even after being rendered non-functional (the block should pass damage through to avoid an indestructible exploit).

The Aux-entities could still be docked and un-docked in build mode or a SY but they would remain firmly in place during battle. It would make sense to add an AUX-Rail and an Aux-rail docker as two new blocks. To prevent a ship-exploit AUX-rail dockers should not work with ships. When an Aux-rail docker is 'destroyed' the docked entity ceases to function (no movement, no power generation) and remain as a dead-weight of mass.

The big advantage with this arrangement is that the number of collision-checks could be reduced. (I assume...just brainstorming here)

 

[Malacodor]

Something similar is planned.

 

[Panpiper]

Something similar is planned.

This would help a great deal for doors and such, but does nothing to address the issue of idle turrets creating lag.

 

[Malacodor]

This would help a great deal for doors and such, but does nothing to address the issue of idle turrets creating lag.

Fixing idle turret lag would just postpone the lag to the start of a battle.

 

[Panpiper]

Fixing idle turret lag would just postpone the lag to the start of a battle.

That's not 'just'... 99% of the time, such a fleet is 'not' in combat. Reducing such lag for that 99% of the time would be a major thing. Furthermore, it is not one fleet, it could be a great many such fleets across the server's universe, all of which would likely only be in combat 1% of the time. If such entity lag could be reduced by 99% across the board for all ships and fleets, it would have such a massive effect in reducing server load that the times a fleet 'does' get into combat, the load would perhaps be bearable.

 

[Malacodor]

That's not 'just'... 99% of the time, such a fleet is 'not' in combat. Reducing such lag for that 99% of the time would be a major thing. Furthermore, it is not one fleet, it could be a great many such fleets across the server's universe, all of which would likely only be in combat 1% of the time. If such entity lag could be reduced by 99% across the board for all ships and fleets, it would have such a massive effect in reducing server load that the times a fleet 'does' get into combat, the load would perhaps be bearable.

That 1% is the most important percent. But you're right, as long as not the entire server goes to war at once it would still be an improvement.