Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Dragon on October 03, 2012, 09:59:56 am
-
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.
-
Can you make a list of what in there isn't already doable with sexps and/or scripts.
-
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...
-
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.
-
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.
-
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.
-
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?).
-
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 :)
-
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. :)
-
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.
-
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 :)
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/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 :))
-
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? :)
-
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? :nervous:
-
Imagine this:
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?
-
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:
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:
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)
-
edit: maybe this is what I'm missing - can you add new subsystems without increasing SUBSYSTEM_MAX?
Nope.
-
ah right - that'll do it - thanks for persisting with explaining this :D
-
That's some very interesting insight into how Red Alert works in FSO.
-
All of the scripting drama has been split out.
-
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. :yes:
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.
-
:bump:
I promised to remind you about this once Antipodes 8 is in. I do not forget about my promises, and though 3.7 RC phase took longer than I expected, it's finally here. :)
Now that the new pilot code is in, how about re-visiting this idea? Is MAX_RED_ALERT_SUBSYSTEMS still a problem, or did the new pilot code got rid of that? I think that additional subsystems could be useful for a variety of purposes.
-
On one hand, I completely understand the need for FSO to comply with retail versions of Freespace and for developers to shift the need of additional subsystem management from code to SEXP's or scripts...
And I just said I completely understand, so there is no need to explain otherwise or give reasons.
But it is a damn...damn shame that Freespace isn't growing beyond it's Lego 1.0 model to make room not only for subsystems, but actual working ship systems that can be turned on and off to make for a more realistic simulator.
And to repeat, I completely understand the way code works and how important it is to maintain retail compatibility, but realistically, shouldn't FSO eventually move beyond it's 640k memory limit?
-
And I just said I completely understand, so there is no need to explain otherwise or give reasons.
No, you completely do not understand. Your post makes no sense.
Now that the new pilot code is in, how about re-visiting this idea? Is MAX_RED_ALERT_SUBSYSTEMS still a problem, or did the new pilot code got rid of that? I think that additional subsystems could be useful for a variety of purposes.
I'm still familiarizing myself with the new pilot code. I'm currently in the process of removing MAX_MEDALS, so if that works successfully, it's likely that MAX_SUBSYSTEMS will be similarly painless. On the other hand, the red-alert code does need a bit of an overhaul.
-
On one hand, I completely understand the need for FSO to comply with retail versions of Freespace and for developers to shift the need of additional subsystem management from code to SEXP's or scripts...
Uhhh, no. All of the things discussed here would be additions (slightly complex though they might be) to the code; they would not impact retail compatibility in the slightest. The reason why we were arguing for this to be implemented in scripts or sexps is that these sort of additions require rather a lot of work that won't be used much. It's work to set up the gameplay logic for this, it's work to test it, bugfix it, and maintain it. If these were features that would make a big improvement for many mods and campaign authors, it would be easy to justify spending the time and effort, but if this is going to just be used by a small subset of mods, then the question is if adding these functions via scripting isn't a better choice.
And I just said I completely understand, so there is no need to explain otherwise or give reasons.
It seems that you don't. Also, you're not the only one reading this thread; explaining our reasoning is never a bad thing.
But it is a damn...damn shame that Freespace isn't growing beyond it's Lego 1.0 model to make room not only for subsystems, but actual working ship systems that can be turned on and off to make for a more realistic simulator.
See, it's for these kinds of things that the scripting API was made for. Small details that enhance the gameplay of a specific mod, but that are useless to the majority of mods and somewhat tricky to maintain and balance properly. Now, if the scripting API is unable to fulfill these functions, then we'd have to change the API (grant access to specific internal variables, for example), but that would be a comparatively small change that we can easily justify making.
And to repeat, I completely understand the way code works and how important it is to maintain retail compatibility, but realistically, shouldn't FSO eventually move beyond it's 640k memory limit?
I am not quite sure where you get this idea that we're in any way memory-limited (I mean, technically we are, we can't allocate more than 4GB of RAM no matter what we do, but noone has gotten close to that yet).
-
I think he was alluding to the "640k ought to be enough for anybody" quote.
-
Maybe. Not that it makes any more sense even if read that way.
-
I'm still familiarizing myself with the new pilot code. I'm currently in the process of removing MAX_MEDALS, so if that works successfully, it's likely that MAX_SUBSYSTEMS will be similarly painless. On the other hand, the red-alert code does need a bit of an overhaul.
That's great news. Red alert needed overhaul since retail, TBH. I haven't had the old Red Alert Bug since the new pilot code introduction, but then, I didn't play all that much since then.
-
the pilot file has a version number in it somewhere, right?
-
the pilot file has a version number in it somewhere, right?
Yes, one number in the .plr, and another independent one in the .csg's
-
Maybe. Not that it makes any more sense even if read that way.
I was alluding to the idea that Freespace needs more than just updated code that makes the engine work, it needs an idea of what "Freespace 3.0" should include if the game is to truely involve and not just be more mods or patches, but a new level of space combat.
Sure 1941 on the NES is fun to play once in a while, but there's a reason I have DCS: Warthog.
-
I was alluding to the idea that Freespace needs more than just updated code that makes the engine work, it needs an idea of what "Freespace 3.0" should include if the game is to truely involve and not just be more mods or patches, but a new level of space combat.
Have you played Windmills, or the latest release of Blue Planet, or Bem Cavalgar?
-
I was alluding to the idea that Freespace needs more than just updated code that makes the engine work, it needs an idea of what "Freespace 3.0" should include if the game is to truely involve and not just be more mods or patches, but a new level of space combat.
Have you played Windmills, or the latest release of Blue Planet, or Bem Cavalgar?
Last I checked, all have normal primary and secondary weapons, normal subsystems and normal shields. If there are any bonuses, like stealth, they feel 'put on top' of an existing ship, not part of the initial design.
There are no ship start-up sequences, no take off procedures, no interactive cockpits, no partial system usage(i.e. turning off weapons, shields, or engines completely). No realistic targeting features(the targeting system lets you target anything you want, anytime you want, there are no penalties or bonuses for having an AWACS present unless it's programmed as part of the mission story). There are no field-of-vision radar style systems except for scanning. No ship weights, no bonuses to flight/movement for being fully loaded versus empty. No fuel systems, no afterburner limits, no shield limits, no oxygen limits, no communication system irregularities(i.e. you either get the message as it's programmed in the mission, or you don't...as it's programmed.)
Or, in short, nothing to make the aircraft any more realistic than its 2D R-type or Gradius counterpart.
This is why I made the comparison to 1941. Sure you change the ship speeds, shield power, hull power, weapons, and turn speed, but for the most part, there is nothing that actually gives the model any depth to the play.
This is what I am looking for in the next iteration of Freespace. I don't care about other games, they all failed to make the mark. Freespace is the only one that has a decent chance of getting the simulation/combat/story balance right.
-
Why would you possibly want realism. That sounds highly counterproductive.
-
There are no ship start-up sequences, no take off procedures,
I guess Diaspora's start sequences don't count?
Thing is, these are gameplay elements that, at least for me, do not add anything to the gameplay, but rather make the process of getting into the game a whole amount of Not Very Fun. Also, these can be done via scripting if you really feel the need to torture your players with what amounts to a fancy quick time event.
no interactive cockpits,
Define "interactive" in this context. If you want Falcon 4.0-style "The cockpit model is the menu" interaction, I think you're in the wrong game.
no partial system usage(i.e. turning off weapons, shields, or engines completely).
Can be done easily in scripting.
No realistic targeting features(the targeting system lets you target anything you want, anytime you want, there are no penalties or bonuses for having an AWACS present unless it's programmed as part of the mission story).
Why would we hardcode this stuff? Why shouldn't we leave this up to mission and campaign designers? I think you're looking at this the wrong way.
Also, realism? Really?
There are no field-of-vision radar style systems except for scanning.
And missile lock-on. Also, you cry realism and then expect me to believe that spaceships centuries from now won't have more advanced sensor systems?
No ship weights, no bonuses to flight/movement for being fully loaded versus empty.
You could model this in scripting, but the fundamental brokenness of FS physics will get you. So why not start rewriting the physics system? Can't be that hard, can it?
No fuel systems, no afterburner limits,
I could swear there's a limited Afterburner option that was used by WCS, for example. Oh well, I must have been imagining things.
no shield limits,
What does that even mean?
no oxygen limits,
The average mission in FS2 has a duration of up to 30 minutes. There is no fighter plane in the world at this moment with that low an endurance.
no communication system irregularities(i.e. you either get the message as it's programmed in the mission, or you don't...as it's programmed.)
That's what mission scripting can provide.
Or, in short, nothing to make the aircraft any more realistic than its 2D R-type or Gradius counterpart.
....and that's bad?
This is why I made the comparison to 1941. Sure you change the ship speeds, shield power, hull power, weapons, and turn speed, but for the most part, there is nothing that actually gives the model any depth to the play.
This is what I am looking for in the next iteration of Freespace. I don't care about other games, they all failed to make the mark. Freespace is the only one that has a decent chance of getting the simulation/combat/story balance right.
Then I am sorry to disappoint you. FS isn't, never has been, and never was intended to be a hardcore Falcon 4.0-style simulation. If you can convince a coder to implement those features for you, or you implement them yourself, great. Just be aware that we have our mission scripting and lua scripting systems for a reason, and that is to allow people to change the gameplay without having to change the engine.
-
No fuel systems, no afterburner limits,
I could swear there's a limited Afterburner option that was used by WCS, for example. Oh well, I must have been imagining things.
TVWP did it looooooong before WCS. And you could do it with retail if you wished.
no communication system irregularities(i.e. you either get the message as it's programmed in the mission, or you don't...as it's programmed.)
That's what mission scripting can provide.
One word. EMP.
-
Then I am sorry to disappoint you. FS isn't, never has been, and never was intended to be...
I have intentions, and I am looking for those who have ones similar to myself.
-
You still haven't made your case as to why we would have to hardcode a lot of the behaviour you want into the engine.
Let me repeat my point from earlier in this thread:
1. Adding features to do more "realistic" simulations takes time and effort if done in the engine, increases code complexity and thus makes maintaining the code harder.
2. We have very powerful scripting systems that can be used to model this behaviour without making the engine more complex
3. Most of what you want to do can be done in scripting.
4. So why insist that we have to do this in the engine? Why not build it in scripting?
-
You most hardcode all the things... so that modders can be lazy.
Actually, I have a feature request. Can you code FS to mod for me?
-
Sorry, I never meant to insist that they be hard coded a-in in the source, I meant that a framework be set up and a standard set to make a next level sim.
But you are right. I shouldn't have posted in this discussion because the feature requests and ideas I have in mind don't need to be talked about here.
-
We already have a "Falcon 4.0 in space"-suited game on this very forum. Starshatter could, with enough effort, turn into this. Even now, it's around the level of Novalogic's F-22 sim when it comes to realism. It could use a bigger community and more coders, though. My intention when posting this thread was something along the lines of Wing Commander. It had a lot more things that could get shot off in a fighter. I'd like to see that in FS, too. WCS could benefit from this, as could Diaspora (which also aims for a realistic feel) and perhaps FoTG (XWA also had quite a few subsystems on it's ships, IIRC).
-
I'd like to see the disabled/destroyed instances implemented differently.
Getting a turret disabled would make it's subobject disappear as if destroyed, even if it was only attacked with disabling weapons.
I know it's a tricky thing to change because that will probably break retail compatibility, but as it stands now I find this behaviour more and more difficult to assimilate.
-
Sounds like it'd be easier to put freespace models into an engine like xwing.
-
No, it won't. X-Wing engine is much more limited than FS engine. For one, there's no such thing as an SCP for it and it doesn't really allow custom weapons. I looked into it, but it didn't work.
I'd like to see the disabled/destroyed instances implemented differently.
Getting a turret disabled would make it's subobject disappear as if destroyed, even if it was only attacked with disabling weapons.
I know it's a tricky thing to change because that will probably break retail compatibility, but as it stands now I find this behaviour more and more difficult to assimilate.
Actually, that's a good idea for a new subsystem. For example, TurretGen##. It'd be a subsystem that, when disabled, would also disable it's corresponding turret. It could be placed on the turret itself, or somewhere else. I'll add that to the list, along with a few more ideas for turrets which came into my mind.
-
Do it.