[Dragon]

I've recently got an idea inspired by realistic flight sims and Wing Commander. FSO subsystems are rather limited in what they control, not to mention they generally work on an on-off basis. I'd like to see more subsystems available to modders, with dynamic damage effects. For example, if engines are down to 50%, so is your max speed and acceleration. In order not to break retail, I thought off a few new names for them, grouped into "sub-subsystem" categories. Not all of them would have to be on every ship, if the subsystem is absent, the "master" would control it's function. In POF and table, they'd all be normal subsystems, I only grouped them for ease of reading.

The list I've come up with:

$Engines (retail)
-$Thrusters (thrust and acceleration)
--$Forward, etc. (thrust and acceleration in the given direction, either direction or "Vertical", "Horizontal", "MainAxis")
-$Controls (maneuverability)
--$Pitch, etc. (maneuverability in different directions, it'd be a "sub-sub subsystem")
-$Afterburner (AB speed, charge and recharge speed)
--$ABCapacitor (AB max charge and recharge speed, if no generator is present)
--$ABGenerator (AB recharge speed)
-$Assistance (destruction forces the ship into glide. I don't think it'd be used often.)
-$Generator (master recharge control for all systems that don't have their own generator)
-$Capacitor (master capacitor)

$Weapons (retail)
-gun1b1, etc. (gun or missile points in a bank. This would work like damaging weapons subsystem, but only for a single gun/missile Also affects external models)
-ammopb1, etc. (health directly translates to ammo in a primary or secondary bank)
-$WepCapacitor (Weapon max charge and recharge speed)
--$WepGenerator (Weapon recharge speed)
-$Autoaim (controls autoaim FOV and how tightly the autoconvergence converges)
-$Countermeasures (CM dispenser)

$Sensors (retail)
-$RWR (with damage, missile warning become inaccurate and mess up)
-$IFF (everything is shown gray on the radar when destroyed)
-$Radar (disables the radar)
-$FTLScanner (subspace arrivals aren't shown on radar)
-$Targeting (disables targeting)
--$Locking (disables missile locking)
-$Stealth (disables stealth)

$Communications (retail)
-$FTLComm (disables calling for things that warp in, if the support ship/reinforcements arrive from a ship in mission, they'd be unaffected)
-$RadioComm (disables everything except the above)

$Navigation (retail)
-$Autopilot (disables AP)

$Shields (new big subsystem, controls shielding on an on-off basis)
-$FrShieldCapacitor, etc. (max shield quadrant integrity and recharge. Without quadrant identifier, it applies to all otherwise uncontrolled quadrants)
--$FrShieldGenerator, etc. (shield recharge, can also go without a quadrant identifier to apply to the whole ship)

$Cockpit (destruction doesn't kill the pilot, but scrambles the instruments)
-$HUDradar, etc. (in general, $HUD[gauge name]. Destruction disables a specific gauge. Very situational, or for modders with OCD/Hyperrealism obession (yes, I'd use it ))

$SelfRepair (controls self repair)
-$RepHull (hull repair)
-$RepSub (subsystem repair)
-$RepSupp (subsystem for a support ship, affects it's repair speed of other ships)

$Turret##
-$TurretGen## (disables the turret when destroyed)
-$TurretSens## (affects the turret's accuracy)
-$TurretAmmo## (health directly corresponds to turret's ammo load, if that's implemented)
-$TurretServo## (on multiparts, controls rotational speed)

Now, I'm aware it's a huge idea, probably a lot of coding, and not all those subsystems would be useful to everybody. I don't know how much of this can be done with scripts, but I don't think all of it can. I think that some of more realistic mods could use this kind of extended subsystem set. It'd bring it to par with most flightsims, Starshatter and Wing Commander on this field. Some suggestions might seem outlandish, but I've posted everything I've thought off, without thinking of feasibility, since I'm not requesting anything, just throwing an idea.

EDIT: Added a couple of ideas for turret additions. They'd probably be very situational, but could still be useful.

[MatthTheGeek]

Can you make a list of what in there isn't already doable with sexps and/or scripts.

[Dragon]

Scripts: I don't know, most of them should be doable. I wouldn't mind this as a script, but it'd get more exposure here than in scripting.
SEXPs: Some of them can be done that way, but might be a PITA due to the lack of a simple "all ships" argument, making it necessary to manually add ships to the SEXP. In general, FRED-side implementation of such a thing would get clumsy on a large scale. I should most likely make another thread about improvements I'd like to see in that matter, but that's for the later. Also, you can't SEXP individual gun/missile destruction, comm restrictions, capacitor settings...

[General Battuta]

I can see how this would be interesting so I wouldn't actively oppose it, but it reads to me as a lot of clutter.

I liked Falcon 4.0 but I'm not sure FreeSpace can ever be that.

[lostllama]

Although I like the idea a lot, I'm not sure what the demand is like amongst the community right now for this kind of detail in damage modelling. But as you say, not all of them would have to be implemented, the complexity is still the modder's decision after all.

I brought up a similar idea for fuel tank fires in another thread a long while ago; the idea would be to introduce a cascading damage effect as the fire burns away at other subsystems. Apparently that could be achieved via some SEXP work.

[Goober5000]

I already implemented shield systems many years ago; it's in the fs2_open-unstable branch.  Unfortunately, bumping the number of subsystems can't be done without breaking the pilot file.

[Dragon]

Unfortunately, bumping the number of subsystems can't be done without breaking the pilot file.

Woah. Well, that's FSO for you. Is that also the case with new pilot code? TBH, I'd like to know what pilot file has to do with subsystem count (red alert?).

[niffiwan]

you got it - for red alerts the pilot file stores the subsystems damage of each "red-alerted" ship, and the pilot file expects to have exactly X number of subsystems defined.  Add or remove some and FSO starts reading/writing rubbish data   I've actually been wondering if using sqlite and switching all the data to a key-value style system would help improve (red alert) reliability and expandability of the pilot file... this is nothing more than a vague idea in the back of my mind at the moment though 

[Dragon]

Wait, then how it's possible to make a red alert with, for instance, a Kentauroi? Has anyone tried? Animated parts are subsystems, so how it's possible for the player to fly fighters that have them? Are those ignored by red alert? And if so, can't all those new subsystems do that too? Of course, that would mean your guns get fixed after each mission transition... Well, I guess I found another problem with my idea. This many subsystems wouldn't be possible to carry from mission to mission, nor save in a checkpoint, because of the variable limit. I hate this kind of limitations.

Here's another idea: Let's move the ship status saving out of the pilot file and to an external location (somehow tied to campaign save, to avoid messing it up). Perhaps that way, a simple SEXP "save ship" and "restore ship" could work for any number of ships, of any complexity.
And now, you can explain why it's not gonna work.

[Admiral MS]

Here's another idea: Let's move the ship status saving out of the pilot file and to an external location (somehow tied to campaign save, to avoid messing it up). Perhaps that way, a simple SEXP "save ship" and "restore ship" could work for any number of ships, of any complexity.
And now, you can explain why it's not gonna work.

That's what you can use scripting for - the shipsaveload script I made does exactly what you want here. Unless the pilot file gets some nice "database like" additions I don't think we will see further data saving support soon besides red-alert that may or may not get fixed.

[niffiwan]

hmmm... I re-read the code to be sure and it seems that red alert would save/load the 1st X subsystems it found.  Add extra subsystems and they'll get ignored, possibly in some semi-random way

Code: (code/missionui/redalert.cpp:red_alert_write_wingman_status_campaign) [Select]

        for ( j = 0; j < MAX_RED_ALERT_SUBSYSTEMS; j++ ) {
            cfwrite_float(ras->subsys_current_hits[j], fp);
        }

        for ( j = 0; j < SUBSYSTEM_MAX; j++ ) {
            cfwrite_float(ras->subsys_aggregate_current_hits[j], fp);
        }


Code: [Select]

code/model/model.h:61:#define SUBSYSTEM_MAX 12
code/missionui/redalert.cpp:48:#define MAX_RED_ALERT_SUBSYSTEMS 64

So this isn't quite breaking the pilot file (maybe Goober is thinking of a different problem), but you're certainly not getting the behaviour that you want.

As for saving the state of ships, IIRC Admiral MS wrote a cool checkpoint script which probably does what you're talking about (and the man himself ninja'd me )

[Goober5000]

I re-read the code to be sure and it seems that red alert would save/load the 1st X subsystems it found.

Mmm-hmm.  And what happens when the code tries to save/load the next data point after the subsystems?

[niffiwan]

umm... well... won't it read in/write out 12 or 64 subsystem values regardless of whether the array was actually populated with any real subsystem data or not?  Am I missing something here?  Doesn't the rubbish data problem occur when you write X values, but read Y back, and all your cfile offsets get screwed up?   

[Goober5000]

Imagine this:

Code: [Select]

read variable a
read variable b
read variable c
for (i = 0; i < MAX_SUBSYSTEMS; i++)
    read subsys[i]
read variable d
Now, what happens to variable d if there are too many subsystems?

[niffiwan]

Sorry - I still can't see it

I understand that if you wrote 13 subsystem values to the pilot file, and then only read 12 back, you'd get an offset error and variable d would contain the 13th subsystem instead of the real value it should have - it may read complete garbage if variable d is not a float like the subsystem values are.  It's a similar result if you wrote 12 and read 13. However, if you increase the number of subsystems it looks like you'll hit this assertion instead:

Code: (code/missionui/redalert.cpp:red_alert_store_subsys_status) [Select]

        Assertion((count < MAX_RED_ALERT_SUBSYSTEMS), "Too many subsystems in ship %s with red-alert-carry status. Tried to store %d, maximum is %d\n", shipp->ship_name, count, MAX_RED_ALERT_SUBSYSTEMS);

Or for "generic" subsystems (engines vs engines01a) you'll hit this loop:

Code: (code/missionui/redalert.cpp:red_alert_store_subsys_status) [Select]

    for (i = 0; i < SUBSYSTEM_MAX; i++)
        ras->subsys_aggregate_current_hits[i] = shipp->subsys_info[i].aggregate_current_hits;

which just writes 12 values out, regardless of whether you have more or less than 12 subsystems on the ship.

I guess to summarise what I think is happening is that you'll always write 64 individual subsystem values, followed by 12 generic subsystem values.  If the ship has more that 64 individual subsystems, you'll hit an assertion & exit.  If it has less than 64 individual subsystems, it'll still write 64 values to the pilot file.  If the ship has more than 12 generic subsystems, some data gets lost.  If there's less than 12 generic subsystems, 12 values are still written.

Lastly, if you bump MAX_RED_ALERT_SUBSYSTEMS or SUBSYSTEM_MAX then the new pilot files are incompatible with the old ones, old pilots will probably crash FSO on loading unless you add code to handle both old and new values.

edit: maybe this is what I'm missing - can you add new subsystems without increasing SUBSYSTEM_MAX?  I thought that you could, i.e. that there were less than 12 "normal/generic" subsystems.  e.g. 5 on many fighters, 6 on the Hecate, 7 on the Orion, 10 on the Colly? (assuming I'm counting them correctly)

[Goober5000]

edit: maybe this is what I'm missing - can you add new subsystems without increasing SUBSYSTEM_MAX?

Nope.

[niffiwan]

ah right - that'll do it - thanks for persisting with explaining this

[Dragon]

That's some very interesting insight into how Red Alert works in FSO.

[The E]

All of the scripting drama has been split out.

[Dragon]

Leaving 18 on-topic posts from a 5-page thread. Talk about getting out of hand.
Anyway, since the last two and half of a related post didn't make it:

Lastly, if you bump MAX_RED_ALERT_SUBSYSTEMS or SUBSYSTEM_MAX then the new pilot files are incompatible with the old ones, old pilots will probably crash FSO on loading unless you add code to handle both old and new values.

I take it's all regarding the main branch. What about Antipodes 8? Would pilot code problems mentioned also apply to the new pilot code, or does it allow increasing those values with minimal problems?

From a 10 min read through the Antipodes 8 code, I think this problem has been removed.  The new approach is to write the number of used items (weapons/subsystems/etc) into the pilot campaign file, then read that number back and use it to determine how much data to read from the file.   So while you still have a subsystems limit, the pilot file shouldn't break / be invalidated when this is changed.

Sounds like my idea will become more viable when this is commited then. If you need feedback, I've been using the new pilot code for a long time now, pretty much for everything (thanks to The_E providing updated builds with it to BP staff), and I haven't had a single issue with it yet.
I guess I'll remind you about this idea when Antipodes 8 gets into trunk.

Anyway, if anybody has more subsystem idea, post them here and I'll add it to the list, so they'll all be in one place.