My ongoing brainstorm of "Chamber" Mechanics, Heat, and a total overhaul

[DrTarDIS]

Some muzak theme while you contemplate your own contribution.

This thread is specifically to Brainstorm the Power system overhaul proposed by schine, and logical steps to the building practice foreseen by such outside the chaos of the main thread. It's also because I don't expect to fully realize my own position is one sitting at one computer.

Spoiler: heat

Heat

We remove “power regen” and “power capacity” as we know them right now and replace it with only one value you would see on your screen: Heat, 0% to 100%

Anything that previously used power, will now generate heat instead. Depending on your reactor size and how you build it, the heat you accumulate will be manageable...or it won’t be.

If your reactor is too small for the systems you want to use, they generate more heat than usual:

• Reactor has X output depending on reactor core (optimally built reactor)
• Needs Y power depending on systems (weapons, thrust, etc)
  • Y - X = deviation
• Heat generated is deviation + defaultMinOfSystem

If your reactor is too big, you would not generate extra heat, but you would be wasting power and space due to the new “heat influence area” or “hear boundary” system we will talk about below.

Heat generation will be available to the player in percent by value. We will also break down for the player, what they can do to improve their reactor.​

​

​

From my understanding of the new system proposes to replace generation of power with generation of load.

1. Functionally, all that happens to your hud is you flip the power bar top/bottom. It starts "empty" and "filling" it is bad.
   
2. this load/heat and generation will rely on a some form of calculation to derive the Capacity.
3. Each "reactor core" will work like power capacitors, and will cause "bonus heat generation" to other systems in it's "heat boundary"/bubble. It will REDUCE(?) the heat generated by systems outside/connected that "chamber". Or simply allow it to function at all.
   
4. Each "Cooling block" in the chamber will "reduce the heat bubble" around a reactor-block. OR "move it somewhere else"
   
5. Each {connected?}system on entity will use/create a static amount of load on your "heat" and this amount will magnify if it goes over the capacity value.

The idea of cooling accumulated heat as a fixed %value would provide one baseline to "balance" builds on.

Another might be basing cooling/sec on the ship's mass value. A high-energy:mass ship would "burn-out" in a short period of time, but be suitably "better" during that time than it's low-energy:mass rival.

Spoiler: 2 reactor heat bubble

Spoiler: until mass is the only maneuvering penalty doomcubes will always rule

The "heat bubble" around reactors is intended encourage non-systems space in builds.

• Maneuvering profile penalty for high-efficiency systems spacing
  
• Maneuvering profile BONUS for hot/inefficient systems spacing
  
• Entities without maneuvering profiles, such as stations or planets benefit more from "bloat", ships are constrained

Essentially, a "hot ship" could work for a defined period of time before requiring a break, while a "cold" ship can function indefinitely.

Assuming the listed ship is to an arbitrary scale we wish to keep, the first maneuvering min/max(PVP) I came up with was along these lines: I think it would be good to avoid the "doom cube" effect it implies, which happens because of "rotation=boxdim". Tieing maneuvering penalties exclusively to mass and freeing boxdim from the calculations entirely is the only viable solution to doomcubes I can think of.

Extrapolating this into 3D, reactors in the extreme corners of your build with systems in a giant cross in between would likely be optimal. Again, ugly cubes bad, so boxdim must be unteathered to maneuvering.

Assuming armoring and destruction maintains it's current iteration, Rotating the "minmaxed portion" of the image above 90 degrees filling he "heat area" of the reactors with your armor seems like a likely event. if this is not an intended game mechanic "heated armor" should probably suffer a penalty of sorts, such as reuced armor value, or bonus damage taken.

Other people have mentioned a "chandelier" effect relatively equivalent to the doomcube observations above. i think we agree the steps to avoid forcing that route lie in boxdim thinking.

Spoiler: these chamber things

Chambers as a concept for Systems seem interesting. I will ASSuME Everything from weapons to scanners is going to get a "chamber" of sorts. I'll also assume those chambers require a physical linkage to a "reactor chamber" to function. Do believe I'll expand on this in a later post (s) as the concept matures.

I wonder if each chamber type will have it's own heat box and value? Allowing "negative heat" auras/boxes from specific "cooling chambers" might be a mechanic to incorporate if this is the case. A high-heat, high DPS&alpha "cannon system chamber" either encased within, or surrounded by "cooling chamber" to deal with it's otherwise atrocious requirements would make sense to me.

Sensors and heat: I've long argued that e/sec should drastically change a ship's detectable range. With heat as a mechanic "shining brightly" would certainly be a logical extension of a high numerical heat.

That's all for now folks.

 

[NeonSturm]

I've heard that not only energy flow contains energy, but also the change in energy flow contains energy.
In a water pipe, the constant water flow has inertial energy, but a change in the flow speed such as schockwaves from an explosion contain energy too.

Sure, some might call that electrons have little mass, but electrons have a magnetic field which interacts with higher-mass atoms, especially magnetized molecules and charged atoms.

When I hear "electrical load", I think about the equilibrium of energy generation and consumption. You cannot shut down or start atom reactors in a few minutes when 100'000 peoples decide to turn on their oven.
​

About heat … heat is the movement of atoms and molecules … movement in a random direction … directions which cancels each other out in macroscopic objects.

Atom A goes up, B goes down = total goes nowhere.

Heat might be harnessed as energy if you could get the atoms which move up and those which move down to separate from each other without friction. Or if you have some sort of thermal transistor.

However, even if you could harness Heat for electrical energy, the converter-unit has mass and slows your ship down.​

 

[DrTarDIS]

A primary concern that's been raised in my ongoing mish-mash of all glory and problems starmade Has often been ded-dock collision nightmares. I had an epiphany about "chambers" and solving that problem not too long ago.

Chambers should use the entity-chain system. A couple of Features the community has requested, particularly solutions to de-dock lag, and wasted-time-flying-turrets, would make this viable.

• The old docking system's bounding boxes are effectively an existing implementation of the "heat area" schema was talking about in the main thread. At the very least they're a good visualization of it. Even the "turns red" portion would be a great way to INTUITIVELY show players that the system block they just placed is a bad idea. (random googled example picture, for newer players)
  
  
  
  
• Of course "chamber" (sub)entities should not be able to be de-docked from the "main" entity. This would require some rework of the interaction with the "docking" point. The envisioned "conduits" seem a perfect reskin of that. Docking Point now becomes "Conduit Connector" an invulnerable, utility block of sorts. Invulnerable might be a strong word, perhaps it simply "opens" like a door becoming non-clipping but not actually destroyed upon zero HP. "docking enhancers" Renamed as "chamber enhancers" to define it's area. Customization of "heat" area is I think an important thing.
  
• I'm going to go ahead and invent a new "core" type that would exclusively use this "old" docking system. The Chamber Core. Functionally, it would be nearly identical to a build block or ship core, BUT "flight mode" would only allow you to move the chamber entity exactly 1 blockspace at a time(digital vs analog movement.) This defined-space movement would be limited to the bounding box of the defined chamber, allowing builders to "fine tune" the placement of the sub-entity on the fly and heading off "aw shazbot! I misplaced and now need to rebuild (large number) of blocks!" problems.
  
• Entity-paste/spawn: A tool requested by anyone who's ever had to dock turrets to a larger ship. you should be able to, and encouraged to, spawn a completed blueprint on a docker while building. I think this feature has been in the back of the dev's list for a while. I think chambers as I understand them lights a fire under tushies for this feature. The reasoning may not be obvious at first, so I'll elaborate. Assuming a "predefined" reactor chamber, weapons chamber, or shield chamber, or whatever is in the plans, noobies are going to be even more in the dark. "paste chamber" with a default "reactor" "weapon" or whatever "blueprint/template" takes a load off the design portion of building. Define a chamber size, spawn a template, functional reactor or whatever is placed down for you. Advanced builders will make their own templates I'm sure, but the noobies need some default shovels and buckets for their sandbox.
  
• Nav markers could become a mess. By default chamber markers should only show up in build mode. I think Chamber-cores should only show up on regular nav at close range, and/or only for a defined period of seconds after an active scan. This would add some immersion/tatctic gameplay to combat. Intelligently finding the power chamber(s) (or life support, or weapons, or whatever) should be an active process.
  
• Loading/lag optimization. A "chamber" sub entity should be one of the last things to load or render. It's PROPERTIES should be applied to the main entity directly regardless of it's load state. I think it would be a great way to quickly calculate occlusion culling for a vast majority of blocks.
  
• Master and slave chambers: I see an interaction planned between chamber types. As an example, Thruster chambers being powered by dedicated reactor chambers. the C->V system seems like an easy way out for this. Perhaps certain chamber types could automatically be assigned master/slave status when physically connected to each other via the conduit system.
  
• 
  

[doublepost=1487052201,1487050850][/doublepost]

I've heard that not only energy flow contains energy, but also the change in energy flow contains energy.
In a water pipe, the constant water flow has inertial energy, but a change in the flow speed such as schockwaves from an explosion contain energy too.

Sure, some might call that electrons have little mass, but electrons have a magnetic field which interacts with higher-mass atoms, especially magnetized molecules and charged atoms.

When I hear "electrical load", I think about the equilibrium of energy generation and consumption. You cannot shut down or start atom reactors in a few minutes when 100'000 peoples decide to turn on their oven.
​

About heat … heat is the movement of atoms and molecules … movement in a random direction … directions which cancels each other out in macroscopic objects.

Atom A goes up, B goes down = total goes nowhere.

Heat might be harnessed as energy if you could get the atoms which move up and those which move down to separate from each other without friction. Or if you have some sort of thermal transistor.

However, even if you could harness Heat for electrical energy, the converter-unit has mass and slows your ship down.​

I think you start here by talking about EMF, if I'm parsing you correctly.
Some IRL stuff:
Believe it or not, you can shut down an atom reactor insanely fast. There might still be residual pressure in the boilers, but the load passed back to the generators will quickly seize them after the reactor itself gets the axe. You might be interested in some of the advancements. Why boil water, when you can boil LEAD?
Thermal-electrical couplings are quite well known in physics. Mechanical versions are usually turbines, but solid-state examples are abundant as well. The Einstein Fridge that maintenance guys HATE to even think about is a great example.
Heat-energy often interferes with electrical energy as resistance of materials grows with their temperature. Heat often HELPS chemical-electrical conversions, a hot battery lasts&produces WAY longer than a cold one. Try to start your car at -40 with your average car battery from Texas and you're in for a world of disappointment. This has to do with Specific Heat catalyzing reactions, related to auto-ignition.
Weather Starmade should mimic these things isn't really something I have a stance on beyond "education though fun can be cool". Games tend to follow the "rule of cool" rather than "simulate the real world" for good reasons.

 

[DrTarDIS]

Brainstorming one specific segment again tonight.

Forced design choices

StarMade has a great build system with endless options when it comes to decorating your structures or creating complex interiors, yet making a ship functional with all our systems can take a while and is usually a less creative process.

It’s not only the power system that suffers from it, but every other functional system that follows its design principles. Currently, most ships have a non functional ‘skin’ and everything else is filled to the brim with systems.

Filling your entire ship with systems is the most optimal way to make a ship. Making any interior or extra decoration creates weaknesses on your ship. It also favours one ship shape over another, in order to fill it with as many systems as possible; Doom cubes.

More systems and power means a better ship, and there is no incentive or mechanic that would ever make a pretty ship with interior as good as one filled with systems.

BIIIG point here that AFAIK you are SUPER WRONG on schema. DOOM CUBES are caused by BOXDIM MANEUVERING PENALTY. The one and only cause.
Here's some terminology, I'll sloppily drop in at times. Aircraft principal axes - Wikipedia
Even that "forced" design is not really forced. High-tier PVP ships are VERTICAL or HORIZONTAL DOOM-rectangles. Weather they are vertical to maximize left-right turn, or horizontal to maximize up/down rotation, is up to the pilot/builder's preference on pitch or yaw.
The iconic "space dildo" people intuitively build, a LONG ship, is penalized(punny) in BOTH pitch and yaw by boxdim, while the relatively useless ROLL is left free.
These problems become apparent in any battle where pilot-is-gunner: to maintain target-lock/firebox/killbox on your opponent you absolutely require maneuverability in pitch, or yaw.
The end result is that a SPACE DILDO will use a shit-tonne of turrets to track what it can't turn to hit with main weapons.
Since STRAFING and pitch/yaw allow pilots to dodge incoming fire while returning their own, the above-mentioned vertical or horizontal shapes naturally show themselves in any "quality player" engagement.
Once more: BOXDIM turning penalties are the root cause. Fix that(switch to mass) and it will be the death of cubes.

If you really want to make "pretty ships" competitive, screwing with the power system won't do that. No logical connection between the two. There are a few other, less drastic ways:

• make "RPG blocks" perform a function that provides a bonus to the ship they are on. NPCs or players manning consoles give a bonus to the ship. Consoles that tie turrets together into fireing groups. Things like that.
• Apply a life-support mechanic: there's no air in space. The should be air in a space suit, air in a ship, and better air on a planet.
• Require a crew-count for every count of systems: One man can not a battleship command. unless it's starmade. Putting crew requirements to systems values to have them function optimally, or at all, immediately "forces a design choice" that requires interiors (and/or viable "pretty ships"). This plugs in with the first "rpg blocks" section above.

 

[NeonSturm]

BIIIG point here that AFAIK you are SUPER WRONG on schema. DOOM CUBES are caused by BOXDIM MANEUVERING PENALTY. The one and only cause.

HAHA. Consider "target-size / evasion" and "hull area vs system volume" too.

And sometimes it's not math, but the thought about what I said which is enough.
Just a thought or meta that says: more dense is better.

 

[DrTarDIS]

HAHA. Consider "target-size / evasion" and "hull area vs system volume" too.

And sometimes it's not math, but the thought about what I said which is enough.
Just a thought or meta that says: more dense is better.

Only applies if you can't "face your enemy." If your enemy is always in "front" of you, only the "front" needs heavy armor. This considerably reduces the surface area you have to cover in actual armor, the sides and back of your ship can be covered in standard,hull, or ultra-low-mass:HP blocks like girders or scaffold.
I'll cite mechwarror(irony, another game that uses a heat mechanic.) and Wing Commander as examples of battle-games as examples. Also real-life things like tanks and APC who "armor what needs it" and might even leave the rest to open air.
Wing Commander CIC Ships Database - Terran Confederation
Guidelines For Assigning Armor To Mech Locations
http://www.clan-rangers.com/forum/m...terrificterrible-strategies/filter/most-views

Has anyone considered crew boxes? (as in: "you need 20x10x200 in total to support your current systems at their current size" …)

In the middle of that myself NS. I'd agree, if crew required space, and systems required crew, and the "heat space" mechanic was instead a "crew area" thing, it ccould function "better" to releive density in larger ships. Perhapse "control consols" or even the computers" for each system could have a minimum effective size/space around them, and more slaved blocks increase that size & crew requirement?

 

[NeonSturm]

Only applies if you can't "face your enemy." If your enemy is always in "front" of you, only the "front" needs heavy armor. This considerably reduces the surface area you have to cover in actual armor, the sides and back of your ship can be covered in standard,hull, or ultra-low-mass:HP blocks like girders or scaffold.

But Capitals might face drone-spam in all directions. If they are not supposed to travel with thrust but by jump-drives, they are very likely relatively heavy relative to thrust/turn rate.

In the middle of that myself NS. I'd agree, if crew required space, and systems required crew, and the "heat space" mechanic was instead a "crew area" thing, it could function "better" to relieve density in larger ships. Perhaps "control consols" or even the computers" for each system could have a minimum effective size/space around them, and more slaved blocks increase that size & crew requirement?

I like this.

If there would be a way to detect "floor blocks" with 2x empty space above, you could give each crew-man requirements on that.
But this wouldn't cover wedges on the side of floors for aesthetics.

Thus I thought about crew-boxes, but it might be difficult to detect whether their 6 faces point into vacuum of space.
When a hangar is crew-space, open/closed doors might make that crew-space usable/unusable?

I look for input on this idea, but I know for sure that I prefer multiple small boxes over one large one (I think about 3-10 for most ships).​

 

[DrTarDIS]

But Capitals might face drone-spam in all directions. If they are not supposed to travel with thrust but by jump-drives, they are very likely relatively heavy relative to thrust/turn rate.
​

mm, again why vertical/horizontal build-for-maneuvering-profiles creeps it way into the meta. turn-face andkeep as much of the "real enemy" covered by your "real armor." Even then it's only a problem if you let the drone-swarm flank you, IE get into knife-fight range. That's something your own maneuvering , and own "screen" of fighters/drones should have taken care of before it became an issue.

I'm going to tangent here a bi: A lot of "but what if" arguments are centered around BAD TACTICAL POSITIONS. You put yourself in a bad tactical position and use it as an argument for a mechanic change. It's an absurd argument. Why the hell is the drone swarm allowed to flank you? Did you jump into the middle of it instead of approaching from a flank yourself? Did you fail to take out the approaching swarm with your own wave-motion-gun or macross-massacre?

 

[NeonSturm]

Perhaps it's an ambush by 6 cloakers or carriers jumping into systems around you.

Or perhaps your enemies have "thrust overdrive" and can "tank through swarmers which get overkilled" until they positioned around you.
Don't expect to turn faster than your enemies in a ship as big if your enemies rely on evasion and you on your armor.​

 

[DrTarDIS]

Perhaps it's an ambush by 6 cloakers or carriers jumping into systems around you.

Or perhaps your enemies have "thrust overdrive" and can "tank through swarmers which get overkilled" until they positioned around you.
Don't expect to turn faster than your enemies in a ship as big if your enemies rely on evasion and you on your armor.​

Exactly: A Bad tactical position, vs enemies Specked-into that position. That's not a game-mechanic argument, it's a tactical deployment one. Do you see the difference?

Let's step-back from game mode to IRL: Capitol ship vs medium submarines, and capitol ship vs bomber wave. This is arguably the same situation set you gave above.
Why did the caitol ship not hear them on it's sonar/radar? why doesn't it have it's own fleet screen of medium sub/frigate/fighters/turrets?(in starmade: why didn't the pilot use scanners? Why is there not a fleet around the capitol doing their thing too?

Even in that situation, with the maneuvering profile of a "high or wide" ship, these hypothetical "flanking at melee" enemies have a set of bad decisions to work with. They can try to focus on your back armor, but a "thin and tall" ship can spin left right remarably fast. The same speed as any ship built "long" to it's "thin" dimensions, while maintaining the systems_weight of a ship much larger. The opponents have to "hide" along tht "top/bottom" "point" of the ship-shape, and thus be subject to a narrow hitbox to fire at, AND the majority of the turrets having easy-track on their msmall "safe-ish" area of sky you can't spin your capitol ship to bring main weapons to bear with remarkable speed. In practice: the only ships that can keep THEIR main-weapons to bear on you, without suffering your MUCH LARGER counter-attack, are ships that arn't in of themselves very large relative to you.

Again though, this whole argument stems from a "broken battle line", a tactically disadvantageous position from the outset. You SHOULD be expected to lose to begin with. Do you really expect anything to be able to wade right into the middle of an opposing force with impunity? Is there ANY example of this kind of heroics outside of action-movies and anime, where it's hero vs mooks?
let's talk balance and whatnot from the exact opposite situation: What is a group of full-loaded cargo and mining vessiles going to do when a capitol ship comes at them from medium range with a rapid-fire cannon that can punch holes clean through them with every shot, shooting at 10 shots/second?
Balance, it's equality not equity.


Edit: better picture

 

[NeonSturm]

My argument is that the attackers always have the advantage, because they wouldn't attack if they had not.

They can equip weapons against the strategy you chose.

If you have guns against big enemies, they swarm you.
If your weapons are against swarmers, expect a frontal-assault ship or snipers.
If you have balanced weapons (big,small) and long range vs snipers, expect them to jump on top of you and use close-range weapons with higher DPS than your accuracy-based weapons.
If you have frontal guns, they backstab you. If you focus on turrets, they may try to snipe your turrets with hit&runners.

It's your capital. Your (mobile) home-base and central thing. It will be scouted.
And if that all wouldn't help attackers, they just don't attack you until they get a strong ally to overwhelm you.​

The solution is simple:

1. You make your capital invulnerable
2. You try to not be a priority target
3. You stay in the shadows
4. You make a defence-pact with others
​

And Ofcourse you have your own fighters and drones, especially if your capital is a carrier.

A carrier-capital could play a fire-support role and equip mostly defensive systems, letting fighters/escorts do the offensive job.​

 

[DrTarDIS]

My argument is that the attackers always have the advantage, because they wouldn't attack if they had not.

They can equip weapons against the strategy you chose.

If you have guns against big enemies, they swarm you.
If your weapons are against swarmers, expect a frontal-assault ship or snipers.
If you have balanced weapons (big,small) and long range vs snipers, expect them to jump on top of you and use close-range weapons with higher DPS than your accuracy-based weapons.
If you have frontal guns, they backstab you. If you focus on turrets, they may try to snipe your turrets with hit&runners.

It's your capital. Your (mobile) home-base and central thing. It will be scouted.
And if that all wouldn't help attackers, they just don't attack you until they get a strong ally to overwhelm you.​

The solution is simple:

1. You make your capital invulnerable
2. You try to not be a priority target
3. You stay in the shadows
4. You make a defence-pact with others
​

And Ofcourse you have your own fighters and drones, especially if your capital is a carrier.

A carrier-capital could play a fire-support role and equip mostly defensive systems, letting fighters/escorts do the offensive job.​

That's not an argument for "Just a thought or meta that says: more dense is better." though. it even highlights what I was saying re: Doom cubes and doom sticks.
"solution" sounds silly to me. Your home base is your home base, your capitol is your right hand, and all the rest are your left. I disagree with the idea that hands(projection of force) should be invulnerable to begin with. That's a boring game right there. With just a little bit of tweaking to mass and return values per block(an order of magnitude more dense) and an actual "chose six of eight, or less and weapons" mathematics to defensive effects the majority of the "pretty is bad" characteristics disappear from the game.

Even with min-max being "such a bad thing" as a mindset, a majority of the difficulties in starmade come from not being able to "just go fly." A "basic income" to every player of some sort, say a standard blueprint would go a ridiculously long way towards devaluing blocks and fixing the "fear reflex" people have in a game that essentilly comes down to making lego trucks and crashing them together to see which one explodes.
[doublepost=1487309349,1487308014][/doublepost]Ok let's consider heatvalue as a balancing factor for ships. Lets consider heatboxes, and systems themselves.

Let's assume every single systems block becomes exponentialy more functional based on how many other blocks are within a given range of it. This puts a theoretical maximum density based on how large it's influence radius is.

Eg Weapons blocks with a 5-block radius

• 1 block, nothing in 5-range. basevalue
• 2 blocks touching, or 2 blocks separated by a 4 block spacer in any direction, : 1 projectile 2(basevalue)^2, 2 projectiles 1(basevalue)^2
• any single block in such an array would reach maximum value after an 11^3 cube. (basevalue)^1331

So a "race to linear " balance curve. upon which to base the other balance values upon.

 

[DrTarDIS]

Hmm, wonder what "negative SysHP weaponblocks" would do...

 

[NeonSturm]

Hmm, wonder what "negative SysHP weaponblocks" would do...

Nothing if knows protocol filters.

Every value has a min, average and maximum value.
If you do your function on these three possibilities,

eg1: "[xmin= 0, xavg=127, xmax=255] * [ymin=0, yavg=127, ymax=255] / 255" = [0, 63, 255]
eg2: "[xmin= 0, xavg=127, xmax=255] + [ymin=0, yavg=127, ymax=255] / 2" = [0, 127, 255]​

Then you get a graph showing you exactly what values you have to expect.​

 

[DrTarDIS]

Nothing if knows protocol filters.

Every value has a min, average and maximum value.
If you do your function on these three possibilities,

eg1: "[xmin= 0, xavg=127, xmax=255] * [ymin=0, yavg=127, ymax=255] / 255" = [0, 63, 255]
eg2: "[xmin= 0, xavg=127, xmax=255] + [ymin=0, yavg=127, ymax=255] / 2" = [0, 127, 255]​

Then you get a graph showing you exactly what values you have to expect.​

too bad you get an error
Edit: It's weird, cause I thought java used signed value systems to begin with? Isn't forcing unsigned putting up object load?

Spoiler: too bad you get an error

I'm puzzeling it out in a broader sense right now. Effectively, the new proposal seems to be something like "systems cause an area load". I'm puzzeling it out as a balance thing with the "room" blocks they seem to want to encourage as a source of syshp, which you "spend" on system blocks.
Eg cannons

 <BlockResourceType>2</BlockResourceType>
  <ProducedInFactory>4</ProducedInFactory>
  <BasicResourceFactory>0</BasicResourceFactory>
  <FactoryBakeTime>5.0</FactoryBakeTime>
  <Animated>false</Animated>
  <Armour>0.0</Armour>
  <ArmorHPContribution>0</ArmorHPContribution>
  <StructureHPContribution>75</StructureHPContribution>
  <Transparency>false</Transparency>
  <InShop>true</InShop>
  <Orientation>false</Orientation>
  <Slab>0</Slab>
  <Enterable>true</Enterable>
  <Mass>0.1</Mass>
  <Volume>0.1</Volume>
  <Hitpoints>50</Hitpoints>
  <Placable>true</Placable>
  <InRecipe>true</InRecipe>
  <CanActivate>false</CanActivate>

Not thinking about <Hitpoints>50</Hitpoints> I mean if <StructureHPContribution>75</StructureHPContribution> was a negative value on "load" blocks.

I'm reasoning a certain amount of hull and whatnot would be a requirement for the block's placement. Without that, the craft spirals into overheat from the weapon's negative effect on the pool. does it combined with some scale-changes on systems blocks themselves effectively simulate "needing control rods" or whatnot.
I'm not neccesairily saying weapons only, just using it as a starting value. Had intended to edit some more expanded thoughts in later.
It gives both PVP and RP ships something to think about in mass vs hp vs damage output vs damage mitigation mechanics. At least on my first thought. it might switch balance mechanics a strange direction.
It would also mean that "getting them blown up" without destroying hull as well moved you away from structHP50%.

Just considering it as a growth-limiter variable. I'm thinking if they specialised cicuits, motherbords, and "intended hulling blocks" as "overheat protection" bonus system hp blocks allowing you to have the "takes support but projects influnce" blocks like "shield recharge, power, weapons" etc the "penalties" on "the useless outer shell" would become assets.

Depending on if you building in-universe or in-shipyard you'd have to have enought "hulling" to prevent you from overheating if you place too many.

Eg: "iconic" shipcore + thruster + energy. Let's say that's supposed to be the "absolute best thrust to mass to syshp" and use it as a baseline.
Thuster 25 bhp 100 shp
reactor 25 bhp 100 shp
shipcore 250BHP 100SHP 100AHP
Totals 300BHP 300SHP 100AHP
If the "iconic" stick was still to work, but be "fragile without hull" the thruster and reactor could be assigned sys values anywhere up to -50 each but not both.
Let's assume "not completely useless" is an intended level of "iconic balance" and give them bot -20 Syshp while maintaining BHP.
totals 300BHP 60 SHP 100 AHP.
If ship core is shot, structure will overheat after somewhere between 250-350 damage when it loses the ship core +100 SHP and falls to -40 from the other two.
if either of the other two is shot, the SYS total will increase to 80. Weather the total increase includes a "refund of syshp" too might matter in larger block balances, but for now causes no overheat. it does however disable the thust:mass or power regen of the ship, crippling it in another way.

Another idea could be to have engines be "part of the SHP pool" since disabling engines just seems like a good idea.
Somethilg like Core +100SHP, thruster +50SHP, reactor -100SHP
placing 2 reactors on a single core, or on a core with only 1 engine would put structure hp negative(either prevent placement or "disable ship." placing some hull or deco around would allow more systems.

Adding a hull allows you to install more systems. the "useless armor shell" might need some strategic thinking. perhapse inverted BHP:SHP ratio of armor levels to provide specific function. Heavy armor has a low syshp bonus of +5, standard a mild +10, hull better at +15, and "decoration blocks"(for lack of another term) like lights and consoles better still at "arbitrary room enabling number" but very low actual block hp requiring protection.

I think a special argument might be in order for aux and other potential "high risk" blocks being a source of +syshp rather than -syshp. but don't quote me on it

I'm thinking an end atio that's favorable to having an appropriate "hull volume" in standard armor or whatnot, but at an appropriate weight penalty to make deco and "empty spaces" viable and useful against missiles etc.
Balancing vs overall thrust, mass, systems, AHP and power regen maintains complexity, building to any particular "ideal" can be defined by the mass of the +shp blocks and the -SHP blocks combined in dependence. Placement of "functions you'd want to lose first" lets you chose what systems "fail" and take the load off your SHP pool taking damage from hull/support loss.

I like this, I might go experiment.

 

[DrTarDIS]

Spoiler: Special thoughts on aux-like mechanics in the above spoiler tag, stuff that's more out there

"overheating, and meltdown. in the above thoughts on negative systems hp awarded for some blocks there are a few outside-context problems. having a negative total with Sysp is one of them. If a ship of arbitrary ration close to even syshp expands or contracts that ratio by a 50% degree the core "overheats." for a set period of time. it's possible that through continued + SHP systems destruction without destroying - SHP systems the result is negative current SHP. Should such a state occur I'd think some outcome should be considered.
One possible (and simple) resolution could be "refuses to turn on." that lets you build/repair until a positive ratio is reached.
Another might be to incorporate a "meltdown" state. With the aux-destruction mechanic, have the -sysp blocks "blow up" until an equilibrium is reached at some defined ratio of net-positive. How the selection of destruction is determined could be a consideration to design in either case. I'll assume there's "skin-tight minmax" build that evolves using "decoration" a little abusively inside of the "theoretical heatbox". with an aux-like mechanic as above such a build probably would result in run-away destruction of the system and it's supporting structure at the same time, at-least if built incorrectly. "intentional run-away" could even be a mechanic to deny any victorious foe a chance to steal valuable secrets or resources from any lost vessel.

Newbies experimenting with building reactors will find a ship that explodes in their face without support, possibly even as they are building it. The support methodology should be self-teaching and self-enforcing past any 5-block ship in that way. Something like (warning SHP:mass is dangerously low!) popping up while you're building would probably be a good derived variable to warn them with in a popup.

Aux reactors might be a case for a special kind of system, one that is inherently an "Ideal balance" and thus zero syshp, but which automaticaly suffers from instability inherent with such design. a "place and drive" system that "would be slightly better if you built it out of core blocks yourself to look purdy" perhapse. Further encouraging "an engineering feel and/or advantage" for those that want it, but enabling "black box" functionality for a casual user that can be upgraded/replaced later. The actual usefulness of such a platform in that light is really based on how much time you spend making any one ship, and how much it's worth to you. A sort of "casual enabler" with it's own pitfalls.

or not.