Powering/shielding docked entities: Test results about something undesirable(?)

[DeepspaceMechanic]

Had some questions about the details of how power/shields work with docked entities, and did some experimentation for the answers.
Sharing the results for those still unaware of these details, as well as to suggest a change (which seems much-needed and straight-forward, at least to me).


Have a ship with a shield generator (that consumes power) and a power system (that can feed everything onboard). While undocked, the shield generator will protect all blocks (of main entity and its docked stuff) within its bubble, and put a load on the onboard reactor. However, when docked to a station, things start making less sense.

Have a station with reasonably long docking arms (to leave space for the parts of big ships that protrude beyond their USD ports). Plot twist: the ship is comparable in size/mass to the station. When such a ship is docked, power/shields behave as such:

• ship reactor shuts down, and transfers all of its loads to the station (as reflected in the ship's flight-mode power bar or build-mode power stats, which stop showing onboard reactor load, and start showing the station's reactor load instead)
• ship shield bubble no longer protects either main entity or its docked stuff (or the station)
• ship shield generator still consumes power, adding its full load onto station's reactor
• ship blocks outside station's bubble can get damaged, despite both station/ship shields being full and consuming power

Further plot twist: if the ship is larger/heavier than the station, its inactive shields can overload the station.

Suggestion: disable power consumption on inactive shields (and perhaps on other inactive systems).

I don't think it's uncommon or unreasonable to have stations anchor ships that are either individually or collectively more massive/power hungry than the station itself...

 

[Dr. Whammy]

Had some questions about the details of how power/shields work with docked entities, and did some experimentation for the answers.
Sharing the results for those still unaware of these details, as well as to suggest a change (which seems much-needed and straight-forward, at least to me).


Have a ship with a shield generator (that consumes power) and a power system (that can feed everything onboard). While undocked, the shield generator will protect all blocks (of main entity and its docked stuff) within its bubble, and put a load on the onboard reactor. However, when docked to a station, things start making less sense.

Have a station with reasonably long docking arms (to leave space for the parts of big ships that protrude beyond their USD ports). Plot twist: the ship is comparable in size/mass to the station. When such a ship is docked, power/shields behave as such:

• ship reactor shuts down, and transfers all of its loads to the station (as reflected in the ship's flight-mode power bar or build-mode power stats, which stop showing onboard reactor load, and start showing the station's reactor load instead)
• ship shield bubble no longer protects either main entity or its docked stuff (or the station)
• ship shield generator still consumes power, adding its full load onto station's reactor
• ship blocks outside station's bubble can get damaged, despite both station/ship shields being full and consuming power

Further plot twist: if the ship is larger/heavier than the station, its inactive shields can overload the station.

Suggestion: disable power consumption on inactive shields (and perhaps on other inactive systems).

I don't think it's uncommon or unreasonable to have stations anchor ships that are either individually or collectively more massive/power hungry than the station itself...

This is a pretty big issue; one that even I experience at my scale of building.

Quite frankly, it makes no sense for a ship to put that kind of drain on a station unless said ship is still using its shields and weapons (presumably on turrets)

I tend to keep my ships considerably smaller than my stations but even I find it "challenging" to manage a station's power output/drain ratio when multiple or larger ships are docked.

I'll have to check if there's a config setting that can eliminate this.

 

[Crashmaster]

For the power consumption problem I was wondering if two home bases might be a solution. One for normal and one just to dock to. If it was an easier config change than fixing the problem.

 

[DeepspaceMechanic]

For the power consumption problem I was wondering if two home bases might be a solution. One for normal and one just to dock to. If it was an easier config change than fixing the problem.

Right, I forgot about the invulnerability of homebases, lol.

I guess if used solely to anchor and protect ships, a homebase wouldn't need either shields or power... The constant overload by the ships' systems wouldn't matter, if you use no power consuming stuff on the homebase. The savings could be invested in the defenses of a second station, where factories, etc. would be set up.

Don't know if these issues apply to carriers too.

 

[DrTarDIS]

The irony here: That entire system was put in place to "stop people bypassing size requirements for reactors" and to "prevent exploits like the docked reactors caused"

Typical Squeaky wheels breaking other stuff when they get all the grease they ask for.

 

[Maxajax]

Had some questions about the details of how power/shields work with docked entities, and did some experimentation for the answers.
Sharing the results for those still unaware of these details, as well as to suggest a change (which seems much-needed and straight-forward, at least to me).


Have a ship with a shield generator (that consumes power) and a power system (that can feed everything onboard). While undocked, the shield generator will protect all blocks (of main entity and its docked stuff) within its bubble, and put a load on the onboard reactor. However, when docked to a station, things start making less sense.

Have a station with reasonably long docking arms (to leave space for the parts of big ships that protrude beyond their USD ports). Plot twist: the ship is comparable in size/mass to the station. When such a ship is docked, power/shields behave as such:

• ship reactor shuts down, and transfers all of its loads to the station (as reflected in the ship's flight-mode power bar or build-mode power stats, which stop showing onboard reactor load, and start showing the station's reactor load instead)
• ship shield bubble no longer protects either main entity or its docked stuff (or the station)
• ship shield generator still consumes power, adding its full load onto station's reactor
• ship blocks outside station's bubble can get damaged, despite both station/ship shields being full and consuming power

Further plot twist: if the ship is larger/heavier than the station, its inactive shields can overload the station.

Suggestion: disable power consumption on inactive shields (and perhaps on other inactive systems).

I don't think it's uncommon or unreasonable to have stations anchor ships that are either individually or collectively more massive/power hungry than the station itself...

The thing with docked entities is considered undesirable, for reasons I will get to below.

The irony here: That entire system was put in place to "stop people bypassing size requirements for reactors" and to "prevent exploits like the docked reactors caused"

Typical Squeaky wheels breaking other stuff when they get all the grease they ask for.

As someone who was there when the Deep Magic was written, docked reactors were never an exploit. They were a functional facet of the game, and I for one always shared my blueprint with new players to help them power their station and ships.

They were axed for a practical reason, not a moral one, as the only excuse for not having them was sloth. When one of the warships powered by docked reactors suffered damage that resulted in the destruction of the docking block, the docked reactors would begin to spasm within the hull. This would usually result in the server crashing. This was considered undesirable, especially since servers only updating at certain intervals meant that each crash resulted in a rollback. Thus using them was made impossible.

On the other hand, they were beautiful, complex pieces of engineering, and the people who pioneered them all put in countless hours to get as much energy as possible out of the smallest amount of cubic meters. Those were Omnissiah-blessed days.

 

[DrTarDIS]

They were axed for a practical reason, not a moral one, as the only excuse for not having them was sloth. When one of the warships powered by docked reactors suffered damage that resulted in the destruction of the docking block, the docked reactors would begin to spasm within the hull. This would usually result in the server crashing. This was considered undesirable, especially since servers only updating at certain intervals meant that each crash resulted in a rollback. Thus using them was made impossible.

On the other hand, they were beautiful, complex pieces of engineering, and the people who pioneered them all put in countless hours to get as much energy as possible out of the smallest amount of cubic meters. Those were Omnissiah-blessed days.

Fully aware, but considering the "size requirements" that the new reactors/stabilizers put in when introduced you have to admit there had to be some misguided balance objective as well.

Considering the "easy" way to fix undocking and clipping poblems would be to make docking blocks act like they do now...yeah, I maintain squeaky wheels breaking other things. Docked entities being the "shut down parasites" they currently are are also done AFAIK for that same kind of misguided balance objective.

See the old shield tech blueprint I've still got on the dock (in a pre-rails update so it doesn't explode and lag-bomb you) to get an example of a self-powered-and-shielded overlapping shield wall. With a bit of thought you'll probably figure out some Omnisiah-blessed use cases.

 

[Maxajax]

Fully aware, but considering the "size requirements" that the new reactors/stabilizers put in when introduced you have to admit there had to be some misguided balance objective as well.

Considering the "easy" way to fix undocking and clipping poblems would be to make docking blocks act like they do now...yeah, I maintain squeaky wheels breaking other things. Docked entities being the "shut down parasites" they currently are are also done AFAIK for that same kind of misguided balance objective.

See the old shield tech blueprint I've still got on the dock (in a pre-rails update so it doesn't explode and lag-bomb you) to get an example of a self-powered-and-shielded overlapping shield wall. With a bit of thought you'll probably figure out some Omnisiah-blessed use cases.

I am not so sure that I would bother with a logic-driven docked shield injector myself. And I say this as someone who was there when Antimatter cannons were the only weapon system, and Shields and Armor did not exist. I have always embraced new additions to the game with enthusiasm. Even for me, logic-driven docked shield injectors are simply a step too far. This is because whilst I was one of the people involved in the creation of the first logic-driven docked energy injectors, the objective was never to go for unnecessary complexity. That is in fact the exact opposite of what an engineer strives for. Ideally you would have the best performance for the least amount of expenditure, both in terms of server resources and building materials. We never wanted to stress or crash servers when we created the first docked reactors. All we wanted was to be able to use more power than the 1 million energy per second that we derived via latticed axis trees of power regen blocks on meta ships. But shields? You can just get more shields by simply adding more shieldy blocks to the entity itself. It doesn't have a diminishing returns boundary, and it does not require a special shape. There is inherently no need to spam docked shield injectors, and thus we never did. We made logic-driven docked power injectors solely because the harsh diminishing returns for power generation on a single entity forced us to do so. Here is a picture of one of the first docked reactors. The ship floating in the background used 16 of them laid out in a 4 by 4 pattern within the hull. This meant that the ship had a native e/sec of 2 mil with an additional 32 mil e/sec from it's reactors. Despite the ship itself only being 1.15 million blocks.


The cross-section of that ship's energy generation compartment would have looked like this:


You will note that docked reactor model provided 2 million energy per second, which was well above the diminishing returns point for energy generation efficiency in that iteration of the game. The reason why it was designed to supply 2 mil e/sec instead of a more efficient 1 mil e/sec was that it was more considerate towards the server owner to have only 16 slightly less efficient 2 mil e/sec models docked inside of a ship, than 32 hyper-efficient 1 mil e/sec models. This is the best evidence that I can provide to highlight that we were not trying to crash servers when we theorized, created and used docked reactors. And why were they removed? It is not like a docked reactor detaching and twerking inside of a ship was any worse than a turret detaching and doing the same. Starmade was inherently very wonky during this time period, and probably still is today. The reason why docked reactors were removed, but docked turrets were not, was technophobia. In that sense the leap from power generation by spamming power blocks like a barbarian, to power generation via properly made docked reactors was similar to mankind's leap from ships powered by coal combustion to ships powered by nuclear fission, in the sense that things -can- go horribly wrong if you let Homer Simpson operate it, but under normal circumstances, when used correctly, it was like


But the fear of servers crashing and having to roll back to a previous save alone was enough for people to lobby for their removal. We imagined wonders and built them, and others tore them down. Without docked reactors, I can not see any reason to build bigger than this:

 

[DrTarDIS]

I am not so sure that I would bother with a logic-driven docked shield injector myself....

Pretty obvious you didn't look, as the thing I was talking about with "shield" in it's name primary point was to divert ALL the e/sec of it's dedicated power supplies (the hyper efficient around 700k/sec lattice) to combat shield generation (ten times the e/sec of passive shield generation per block at the time IIRC, 2.2e/s -> 22e/s) in an overlapping plane to mitigate the "outage" timer in regeneration. Though "shield injectors" DID also mitigate the "outage timer" in other ways.

That's also besides the main thrust of what I said above:
-the EASY way to FIX the PROBLEM of INTERNAL DOCKED ENTITIES becoming UNDOCKED and CAUSING LAG BOMBS OR CRASHES was to MAKE THE DOCKING BLOCKS INVULNERABLE TO DESTRUCTION and ALL THE PROBLEMS WOULD GO AWAY.
--This was arguably easier to fix in pre-rails systems too, as the "core" was already invulnerable to destruction until overheat timeout, which generally didn't cause much if any lag itself(other then becoming undocked and collision/clipping). Combat-undocking-lag did not get fixed that way until much later.

-The game DID implement this INVULNERABLE DOCKING FIX many versions after docked power was removed because "Pretty" things like INTERNAL DRONE BAYS or SLIDING DOORS still caused the SAME COMBAT SLIDESHOW LAGBOMB if they got disconnected in combat with a lucky penetration that the old "docked power" system did.

-The squeaky wheels got systems removed and reworked, when the solution of "do not let merged entities fall apart in combat damage" was on the table in the first place. The solution of "do not let merged entities fall apart in combat damage" still had to be implemented LATER because the actual problem was not FIXED, it was misdirected by Squeaky Wheels demanding grease .

-Current build "docked entities shut down their own power and shield generation" mechanisms are likely implemented that way because of a misguided "balance" objective versus edge-cases like a "self-shielded docked hull section" giving a second "shield in outage but I still have shields here" advantage to a clever builder. And if there's one thing the squeakers squeak about, it's someone gaining an advantage though being clever.(link) OP TALKS ABOUT THIS IN RED, and the fact the docked entities still "suck power" like they are turned on and working is likely an oversight in that misguided "balance" attempt.

 

[Sgtwisky]

TL:DR
I think allowing self powered docked entities again would A. Fix the OP's issue, and B. Give me back features that I liked. and C. Would not cause the issues it used to cause.


I pretty much agree with DrTarDIS on the docked power/self powered docked entities. An argument I kept seeing from players was "You shouldn't have self powered turrets because it makes a ship OP as it can surpass the e/sec limit." Followed by the possibility of crashing. At the time it just felt like players really didn't like the idea that you could pass the softcap of power with creative building, and crashing seemed to be the argument to fall back on when the first didn't work.

Now the arguments against self powered docked entities is pretty much gone when you consider:
1. Undocking due to combat and causing massive lag isn't a thing anymore
2. Fleets can allow a single player to counter 1 big ship with many small ships (You can lookup the old drone thread for solid research numbers at the time. I think it was something like a small fleet could best a ship of roughly 40% more mass then the combined fleet.)

I'm not sure there IS a good argument for not allowing power to flow out one way from the main ship to docked entities anymore. Though I can't see a good one for docked injectors anymore ether. Personally I care way more about the former then the latter due to the way I like to build.

Just my 2 cents and I doubt that this subject will likely ever be revisited and the decision reversed. But reversing that decision would bring new interesting building challenges and fix the OP's noted issues.