#41 Add governor to limit acceleration to survivable!

[Ian Lacey]

I propose to go forward with creating new governor restriction specific to various ship types for acceleration which is not dependent on thrust and weight.

High end cargo ships should be limited by what the governor allows. Something like 4.5G's plus the amount allowed by purchased inertial mitigation technologies. Low end fighters would then be limited by thrust, while high end fighter would be limited by the governor limit of around 8.5G's plus inertial mitigation technology allowances.

I think adding governor and inertial mitigation will make it possible to set perfect balance to the ships in the future after adding specific limitations depending on realistic variables.

[Ian Lacey]

Here is the link to the tracker request by klauss where the conversation about this was had. http://forums.vega-strike.org/viewtopic.php?p=130280#p130280

[Turbo Beholder]

I think it should be done via ship parts system ([feature-requests:#44]), with parts having their limits or modifying (as in "mult_..." upgrade) said limits:

1. pilot/crew cabins (i.e. parts with habitable cockpits) - per species.
2. passenger cabins
3. cargo containers - different types (cargo_bulk, cargo_liquid, cargo_gasholder, cargo_hard, cargo_fine, cargo_extrafragile), also generating different units with different survivability after being jettisoned.

So while inertial compensator is good and got Functionality at 1.0 it's possible to accelerate a lot, if not - well... The ship part system provides placement, so now that we knows where it's bolted on, we can not only make it contribute to the ship's MoI properly, but also apply proper inertial forces back to it. When the ship's tractored by one side into uncontrollable rotation, something may fall off.

[Turbo Beholder]

Another side of this is that (speaking of VS core setting) Rlaan use gravitics. My understanding is that their ships have so much available equipment space exactly because they use gravitics instead of thrusters, so they have advantage of construction approach that is not "spars and bulkheads must hold the rest of a vessel attached to its longitudinal bars at 5-15 g", but simply "non-squishy shell with some bracing, internal parts may just as well be organic" - a sealed building instead of a missile.
So we'd need to discern accelerations somehow.

Edit: see also an old discussion on forum -"Modified Acceleration and Consumable Fuel"

[Klauss++]

So, this feature per-se means adding the governor limit. The upgrade system handles the rest, and some sane initial values would be:

Most ships at 4.5, heavy cargo haulers below 1.0, fighter ships around 8.0, rlaan 15 (almost limitless because they use gravitics, which impart no stress).

It seems simple enough, although adapting ASAP and FlyTo AIs could entail some unknown amount of work. Will look into it during the weekend.

[Jack]

A quick thought - it may be worth considering (prior to implementation of the acceleration governor specification) providing for different levels of sustained vs. maximal acceleration. Maximal would be a relatively straightforward addition, but monitoring sustained acceleration limits would be more complicated. Still, even if the sustained acceleration limits were not enforced in any near-term versions, the description of acceleration limits could be future-proofed.

[Jack]

I guess there's also a question of how best to represent the information that an installed component or carried fragile/live/etc. cargo is the limiting factor on currently "acceptable" accelerations. I imagine the latter to be the more potentially confusing one for players.

[Klauss++]

I see those as separate improvements. Because:

I don't see how sustained acceleration differs from instantaneous acceleration from a structural POV. The only factor I can think of that could limit sustained acceleration, is waste heat management (ie: the engines overheat, no way to get rid of the excess heat fast enough). That pertains to a separate improvement that is heat simulation and management, which has been on the table for a while now.

Perhaps there's some other way in which sustained acceleration differs from instantaneous, which is shock absorption. You may have an inertial compensator that can absorbe high G's but only for a fraction of a second. I wouldn't implement this as a separate component, but rather explicitly as shock absorption (N Gs for M time). I'll have that into account, but this could be harder to implement, as it pertains to the damage model rather than the governor. So perhaps it's better to have as a separate ticket.

As for how components affect the limits, I think this has to be left to the upgrade system. There's a long standing task in the to-do, that is to refactor the upgrade system to work entirely based on upgrades. That is, units have base stats, that are modified by upgrades, in some manner, and every time damage happens (or an upgrade added), the whole modifier stack (upgrade stack) is re-evaluated to compute new stats. This differs from the current method of evaluating modifiers only at upgrade time, in that it's far easier to understand, and less error-prone.

Also, upgrades should not be forced to be of a specific kind in full. Ie: all mult_ or all add_, but rather, stat columns should have the modifier. So the "crew quarters" upgrade could add crew capacity while it limits (minimum) acceleration. The CSV would convey this as a prefix to numeric values: +5 adds 5, -5 subtracts 5, =5 sets 5, *5 multiplies by 5, lower(5) clamps down, upper(5) clamps up, etc...

Again, this goes into a separate task, that is the upgrade system overhaul. And it could be split into smaller tasks as well.

[Jack]

Oh, for sustained vs. instantaneous, I was thinking of the pilot/crew more than the ship :). I agree any effects of sustained acceleration would be a different feature (warranting a different ticket). In terms of future-proofing, I was just thinking it would be related to the max acceleration governor solely in terms of formatting in the CSV (that one might want to group the acceleration governor settings together). Of course, the formatting of the CSV is its own legacy boondoggle, so don't mind my mental meanderings.

[Turbo Beholder]

Good point about governors vs. stuff itself.
It may be a bit more complex than add_/mult_ overhaul because of angular accelerations.
But in the end, most of the time specific parts' parameters can be hidden behind "safe limits" governors via same big RecalculateUnit() stats-crunching method, taking into account position vectors too - just like with MoI. And when something will gently touch a wingtip with Heavy Tractor or otherwise force the ship to break the set limits, may as well walk the tree to see what was smashed by centrifugal forces.

[Jack]

If we assume that the governors aren't all set to redline everything, we might then want an "engineering margin" for the acceleration governor for a given part. This could either be expressed as a percentage or as a second acceleration limit. This, rather than the governor, would be used to calculate damage from externally induced behavior outside of operating conditions rather than to limit internally requested behavior to adhere to standard operating conditions. For instance, a passenger liner may have passenger compartments that are designed to operate at 1g, because comfort, but that have no intrinsic structural problems until much higher accelerations.

The margin could also be a differentiator for military vs. civilian vs. sketchy "Sure it'll handle 5g! (Just don't ask about 5.1!)" suppliers of hardware that, for physiological reasons, may otherwise (normally) operate very similarly when installed. If we wanted to wander very far off into "this would be a separate feature request" land, then, assuming there exists a governor and a margin, then one might imagine that military parts might have an in-flight adjustable governor vs. margin knob, whereas civilian parts that have their governor settings changed void the warranty and dramatically lose resale value :) [no, I'm not advocating for said features at this time]