Linked docking moduals

[Atas-Pelangi]

building a large ship with docked parts is risky if your trusting a single 1 block to hold your engines together

what i suggest is a linked docking unit
multiple Rail dockers OR new docking unit type link as 1, connect to multiple rails so if 1 is damaged your parts don't fall off

OR a "TEST FOR" "true/false" system
is docker adjacent to rail = is docked/not docked

this idea would only be intended for non moving objects or non rotating objects and Should require multiple docking and docker blocks.
each "additional docker should be slaved to the master in the hot bar. but should the master be damaged and removed from the hot-bar the others should remain docked and a new "master" can be chosen for the hot-bar.

each docker should be in contact with a docking block to count but lack of a docking block should not inhibit the other dockers from function.

 

[jayman38]

Yes, players have wanted this for doors and docked reactors as well. It would be much appreciated.

I think in the game's background, it would be easy enough to set up multiple docks in a list, so that if one link is broken (block destroyed, disruptor weapon detaches the link, etc.), the next link on the data chain is checked, to make sure the entity is still docked.

This list of links could represent docks that are close together, or hundreds of meters apart, just as long as they are linking the same child entity to the same parent entity.

 

[NeonSturm]

Two issue though:

When you undock, you have to prevent re-docking
And rail-docker-spam in your hotkey bar ​

But this could also be solved with greebly-dockers (dock as long as you don't undock even if killed)

I thought "When I dock thrusters on a rotation-rail to change thrust direction, that would be really awesome!"
But how then rail+dockers move apart from each other, except the central one.
​

What would happen if one rail is on shootout and the other on a normal rail?
If the rails give different orders to the docked entity?

 

[Atas-Pelangi]

my idea would only be intended for Non moving parts.

 

[Malacodor]

A lot of cool stuff could be built but isn't, simply because builders want their ships to be actually useful, not only good looking. No matter how big something is, if it's docked there's always that single point of failure. One lucky shot and the whole thing is gone or worse, lagging the server to death with collision checks.

 

[NeonSturm]

A lot of cool stuff could be built but isn't, simply because builders want their ships to be actually useful, not only good looking.

Or lag with entity collisions.

I thought about "controller+array = rail/docker+docked".
For entities which aren't meant to undock, greebly dockers (stay docked until manually undocked) would perhaps be better because of many issues.
If entities on simple rails –like doors– would leave a "shadow" where they could be, collision checks could be simpler too, I guess.

 

[Monchoman45]

Personally, I think any docked entity without computers (eg, no salvage computer, no jump drive computer, no weapons, and so on) should receive 100% parent shields and remain docked even if the docker is shot off. This covers elevators, rail doors, rail clocks, and other assorted things that have no combat purpose, and would help cut down on collision lag from undocked stuff.

 

[NeonSturm]

I like that, but "everything without computers" also includes shield or power reactors and docked thrusters.

Shields should be shared only to entities which have no own power or shields or thrust. I think redirecting to the nearest superior's available power+shields would make calculations easier too.

Edit: An entity without own shields+power would still be able to receive power-supply for the parent or be able to redirect EMP to the parent, but not longer be able to use energy-consuming stuff.

 

[Monchoman45]

Shield and power reactors need shield or power supply beams to work, which require power supply computers, and docked thrusters aren't any more powerful than just putting the thrusters on the mothership.

 

[Atas-Pelangi]

power and shields are another topic.
the issue here is structural integrity.
moving parts are weaker. but not all docked parts move. and there should be more ways to dock. ether with dedicated blocks with higher armor
or as my suggestion imply s, "distributed load"

 

[NeonSturm]

@Atlas_Pelangi
EDIT:
Well, it could work as long as

1. Rails are build for that and no random mixing of shootout / rotation with normal, etc.
2. The dock only changes through killing, not normal undocking.
3. The dockers could be grouped in the weapon's menu.

 

[Atas-Pelangi]

Not scalable.
Possible, but you get many edge-cases (one docker touching a shootout, one docker receiving an undock-signal from the rail)

That's why I prefer docking-blocks which can be physically destroyed and are technically still there until you manually undock for fixed-docked entities. It is easier for , so we get less bugs.
(Called greebly-dockers by someone else)​

i Don't anticipate a problem with the mechanic. unlocking would remain unchanged. the only thing that would change is "one shot shoot off" on large immobile docked parts.

in most cases these parts would be docked to dedicated places made for them and the docking modulus wold be manually linked or unlinked just like weapons.
Undocking could be done just as it is now with no change, by entering the docked entity and using the master docker. or by sending a signal to the rail the master docker is connected to. the only function the additional docker would serve is to Backup to prevent forceful unlocking.



I do personally like the idea of targeting subsystems.
seeing parts come off in battle is fun, but having the system rely only on 2 blocks to stay connected is a bit weak.

 

[jayman38]

Two issue though:

When you undock, you have to prevent re-docking
And rail-docker-spam in your hotkey bar ​

But this could also be solved with greebly-dockers (dock as long as you don't undock even if killed)

I thought "When I dock thrusters on a rotation-rail to change thrust direction, that would be really awesome!"
But how then rail+dockers move apart from each other, except the central one.
​

What would happen if one rail is on shootout and the other on a normal rail?
If the rails give different orders to the docked entity?

Yes, it would be responsible to discuss possible gotchas.
1. Redocking: The list I mentioned would be usable by undocking. When one module is undocked, run through every list it is on and undock everything on the list at the same time.
2. Well, there's already a lot of rail docker spam for those builders who like to use lots of dockers. Adding more connection points for moving sub-entities will be well worth the trouble. However, I would like to allow naming of each rail unit to make it a ton easier on the hotbar to select exactly what you want. So my solution to this issue is to have custom names for each rail docker.

It will be up to the player to avoid placing multiple rotor blocks out-of-line. Basically, every rotor block in the list will need to be located along the same rotary axis for the rotation to work. Then there is the issue of syncing all the rotors. I suggest that the list of rotors be re-used for this purpose: when one rotor is activated, every rotor on the list is rotated the same direction at the same time. (Well, technically, when a rotor is facing the opposite direction, it needs to rotate the opposite way, in order to rotate the subentity in the same way. Therefore, the rotor direction will need to be stored on the list and used as a modifier for the rotation.) Ditto for rotor dock replacement (changing direction.)
Hopefully, if such a mechanic were introduced, the devs would implement some sort of axis check, to warn the builder when they dock multiple rotors out-of-line, or if they dock a rotor and a linear rail at the same time. If the builder leaves it unfixed, it works like a regular dock: no rotation, just multiple contact points to keep a sub-entity in place.

I imagine different mechanics would be a key element of builder original designs: One rail serves as a "lock" and is "salvaged" to unlock movement on a different rail. So again, once one rail dock is removed, and a new one is "activated" to start movement, run through the list of attached rail docks and move them all the same way. With this mechanism, some docks might actually become undocked and fall off the list as the sub-entity is moved away from a rail dock(s) that do(es) not extend along the path of movement.

If multiple movement orders are submitted to multiple rail docks on the same list simultaneously, one rail needs to "win" and all the others need to "fail". I recommend, to keep it as intuitive as possible, place the first-placed rail dock first on the list and subsequent rail docks further down the list. The first rail dock activated wins.

In order for rail docks to be ordered in this way, all rail docks need to be added to an overall master "list" of rail docks and rotors that is created when building the ship. This list could double as the container for the rail dock "names" I mentioned earlier.