Read by Council Entity Merge or Permanent Docking to reduce lag

[alterintel]

So I got the idea from this post here

Premise:
As people get used to the rail system we are seeing some really nice rail designs. For example: Modular systems such as docked power, thrust and armor. There are also some really cool moving parts as well. But the more entities you have on your ship, the more lag it causes. Some designs can get so complex that battle becomes impossible. I think that everybody can agree that there needs to be more optimization when it comes to rail entities.

My Idea:
Permanent Dock, or Entity Merge
Is it possible to get rid of inter-entity collision checks? basically make it so that once you dock a non-moving modular component, you get the option to merge it with the parent entity. This would be some kind of permanent docking or entity merge, to where no more collision checks will be performed between the parent and child entity.

Also with moving parts: once you've installed the part and it's gone through it's complete motion without any collisions you could get the option to merge it to the parent ship.

What would this solve:

• well it would significantly reduce collision checks and therefore improve fps and reduce lag.
• once it's saved to the parent entity it would take the entity off of the nav menu.
• It would make modular ships much more intuitive

Possible Ballance suggestions:

• maybe make it so that entities can only be merged and unmerged at shipyards
• to encourage merging, make it so that when the docker block on the merged entity is destroyed, the merged entity doesn't become undocked and go flying way like it currently does.

Thoughts?

 

[NeonSturm]

Just one question: How would you handle entities that rotate, move and have moving parts on themselves?

I would make all blocks that are possibly obstructed be handled as permanently obstructed for merges.
All objects which rotate, will be rotation-symmetrical.

 

[alterintel]

Just one question: How would you handle entities that rotate, move and have moving parts on themselves?

I would make all blocks that are possibly obstructed be handled as permanently obstructed for merges.
All objects which rotate, will be rotation-symmetrical.

I'm not exactly sure what you're saying, but I think I do. Here's what I think you're saying:
What if there are some really complicated rail structures with unpredictable movements?

Well, I'm sure the Devs could figure something out if they wanted to. Either have some way of allowing the entities to only move to places where they've been tested, or have it so that it's ok for entities to occupy the same physical space? Not sure, but like I said, I'm sure the Dev's could figure something out.

 

[BoerToon]

Well, I'm sure the Devs could figure something out if they wanted to. Either have some way of allowing the entities to only move to places where they've been tested, or have it so that it's ok for entities to occupy the same physical space? Not sure, but like I said, I'm sure the Dev's could figure something out.

It is quiet simpel actually: you do collision detection on rail movement, not on disconnecting an entity.

Maybe it would be better to do this with all docked entities do reduce lag but I don't know if they can make a difference between an intentional undocking and one by external factors (destruction).

 

[jayman38]

I can see this being implemented in parts.

Phase 1: Eliminate inter-entity (linked) collision checks on linear entities where the maximum travel matches the maximum rail length and there are no secondary rails. (I.e. simple doors)

Phase 2: Eliminate inter-entity (linked) collision checks on rotational entities where the maximum radius of the sub-entity matches the inner radius of the hollow containing area and there are no secondary rails. (I.e. simple rotators)

Phase 3: Level 2 linked entities can eliminate inter-entity collision checks if their maximum travel or rotation are extruded along the path/rotation of the level 1 linked entities and found to not interfere with any-level linked entity, either up or down the chain. (I.e. The level 1 entities do not interfere with the root (level 0) entity, and the level 2 entities do not interfere with either the level 1 entity or root entity at any possible movement point.)

Phase 4: Extended 3-D kinematic calculations to calculate rail/rotator effects and interference effects for any level of linked entity (level 1+). (No matter how many entities, if they are all clear at any possible movement location, as long as there is no possible interference point, eliminate inter-entity collision checks.)

Phase 5: Eliminate inter-entity (linked) collision checks on sub-entities after determining and storing their maximum travel in any combination of multi-entity travel (should be override-able in case you want an entity to turn more at position A than at position B).

Phase 6?....

If you noticed the general trend in those phases, you'll notice that the collision checks are not removed if the game cannot guarantee freedom of movement. In other words, the collision checks remain if the traveling entity might possibly ever "hit" another entity, even if normal timing would normally guarantee no hits. (After all, normal timing gets broken all the time on real servers.) Also, you'll occasionally see entities weirdly "float away" from their possible position, and then eventually fly back into position, due to lack of collision checks. I've seen moving entities do that in other games under load, so it's only inevitable when collision checks are removed in this one.

 

[Lukwan]

I like any ideas that reduce collisions and lag. Good Post.

Here is a radical approach to docked entities that take critical damage:

EG-When a turret rail-docker takes critical damage it does not detach from the mother-ship (causing collision checks). Instead is causes a total failure of functionality. Turret no longer rotates, draws power or fires and looses all shield status. This replaces floating turrets and reduces considerable amounts of lag. For feedback to the attacker the turret could emit occasional particle animations that indicate 'broken'.