Jump to content

[WIP] Nert's Dev Thread - Current: such nuke, wow


Nertea

Recommended Posts

I was playing around with reactors and radiators, and with the way stock heat params are it feels like my entire ship is one giant solid copper block. It's very hard for any meaningful heat gradient to build up.

I'm really tempted to write a plugin that outright replaces the stock system and tries to do a better job.

Does anyone know if the stock heat model can be "turned off" like aero? I'd also rather not mess with reentry stuff, so hopefully reentry heating works through the standard heat transfer methods. (Physical API I guess?)

Link to comment
Share on other sites

In the same boat as Starbuckminsterfullerton.

One quick design test I did with the H2 tanks. Props on the tank designs btw Nertea!!

Quickly recreated my first 0.9 Nerva based Duna/Dres (2.5m tanks) interplanetary only design I have. And I had some real troubles getting enough DV (~3600) for a 20t payload with NFP 1.0. Without making the design ungainly large/long/unlaunchable.

Looked at CommunityResourcePack which is now used and LqdH2 density (70.85 kg/m^3) although correct, is much lower than what it was in NFP 0.9.

Which explains my design problem.

To be honest, I don't know if I like that change, albeit it being more realistic, it does leave me feeling a bit unsettled game balance wise.

Sorry if I sound a wee bit sour ;) but 1.0 didn't make me jump out of my seat and through the roof (in the its fun department).

Btw a request about texture size Nertea. Could you perhaps include a 512x512 texture redux pack? In regards to memory usage on heavily modded installs.

Edited by Gkirmathal
typos + addition
Link to comment
Share on other sites

It's not totally my fault - the LV-N got hit kinda hard in 1.0, which strongly adversely affects the LH2 modes. Also I thought I didn't include the NTR configs - the ones I'm working on actually bump the Isp in LH2 mode to 900. If you're using different ones, you might want to try that.

That being said, what do you think the discrepancy for the fun department is? I was originally working off the approximate benchmark that 1 huge 3.75m tank of LH2 with patched LV-N stats should give approximately the same DV as a jumbo-64 full of LF would. I haven't actually tested that with the heavier LV-N though. We will 100% be going off CRP resources going forwards, but if things aren't fun I can artificially inflate the capacities of the LH2 tanks.

edit - texture size eh... well maybe. Not really a priority because with DDS as the new standard, it shouldn't be too hard for the end user to do.

Edited by Nertea
Link to comment
Share on other sites

It's not totally my fault - the LV-N got hit kinda hard in 1.0, which strongly adversely affects the LH2 modes. Also I thought I didn't include the NTR configs - the ones I'm working on actually bump the Isp in LH2 mode to 900. If you're using different ones, you might want to try that.

Yes I know! Of course it is not related to you :)

Just my expectation of 1.0 (part of the fun I was talking about) and a nagging thing in the back of my head something is amiss. Don't know what, can't put my finger on it, maybe it's me and it's becoming full moon again ghehe.

LV-n, lowered its weight to what I had modded it in 0.9, 2.5t, it seemed a good number from the RL 10t Nerva. Also edited the NTR H2 config included from 0.9 NFP to 1.0, simple edit.

That being said, what do you think the discrepancy for the fun department is? I was originally working off the approximate benchmark that 1 huge 3.75m tank of LH2 with patched LV-N stats should give approximately the same DV as a jumbo-64 full of LF would. I haven't actually tested that with the heavier LV-N though. We will 100% be going off CRP resources going forwards, but if things aren't fun I can artificially inflate the capacities of the LH2 tanks.

Personally I benchmarked my first Duna design, from 0.90 (with the new NFP 2.5m tanks), for a payload cap. of ~20t (1 or 2 landers + 2 probes) and needing 3400Dv for Duna and back with no aero braking.

The H2 density used in 0.9, of 0.0004, made the designs somewhat "simple", not ungainly tall and thus launch-able if empty.

With CRP, although I must confess, I like it due to it being real life based! Only the design got very tall, with 31t LqdH2 and under 3300Dv/vac. The 3.75m parts as well, needed 2x a M-60+radials stack, for 37t LqdH2/3700Dv/vac

In sandbox that is not a problem, because you have all large docking parts to assemble with. But in career this might be problematic when a player hits the LV-N and cannot get enough Dv in orbit due to not having every thing unlocked.

Not taking into account custom TechManager tech-trees, which could make it even harder.

Increasing tank cap, don't know, might do the trick. But how much? What is the dimensions you used to calculate the m^3 an fuel cap of the tanks btw?

edit - texture size eh... well maybe. Not really a priority because with DDS as the new standard, it shouldn't be too hard for the end user to do.

Been looking for a batch dds converted/resize utility. Could you recommend a good batch converter? Doing it in paint.net is, rather, well manual :P

Link to comment
Share on other sites

Nice stuff on reactors overheating Nertea :)

Just some thoughts that might be of interest for you:

1. Effects of overheating / damaging reactor:

- much increased enriched uranium consumption when reactor is overheated

- when reactor is damaged it's impossible to shut it down; it must operate at minimum i.e. 35%

- when reactor is damaged it leaks enriched uranium / depleted uranium at a rate of i.e. 50%

- (radiation effects I guess will have to be left for some future radiation mod;))

- when reactor is damaged it's impossible to refuel it; transfer anything in or out of it

- after fuel runs out damaged reactor still produces heat at i.e. 50% power

- severe damage results in kaboom :)

2. Also I ability to switch on / off reactors on demand and move power slider to 0% mean effectively that the reactors never need to be fueled. The power from reactors is only needed for burn times; don't know whether many people use those for colonization purposes since a) there aren't such extreme power needs for colony modules atm and/or B) people use MKS reactors stuff.

So maybe it would be good idea to introduce switchability limitation for reactors:

- you can switch reactor on only once then it has to run continually; you can limit fuel consumption only by reducing its power. Since this affects refuelling ability maybe instead of switching off it would have something like 'refuel mode' in which all remaining enriched uranium would be automatically converted to depleted one'. This would simulate removing integrated fuel cartridge and replacing it with another fresh one (you normally cannot refuel cartridges at the reactor, there are highly specialized facilities to do it). So player in this mode could remove depleted fuel and pump as much fresh uranium as he wants:)

This would ensure player would use shut-down/refuel as one-off event. This event might take couple of days before reactor is ready to refuel and it would still require cooling (for example for liquid lithium coolant to cool and solidify around fuel cartridge so the whole thing can be removed).

- alternatively you could shut it down and don't refuel but heat emission would stay at i.e. 50% to account for cooling spent fuel in reactor

- power operation range; in short - normally reactors cannot operate and release heat from 0 to 100% when they are working; thus introduce minimal operation power for power slider for example 25%

==========================================================

Link to comment
Share on other sites

Been looking for a batch dds converted/resize utility. Could you recommend a good batch converter? Doing it in paint.net is, rather, well manual :P

Have taken a look at DDS4KSP tool by Lilleman? It does what it should with some options to tweak, although it doesn't generate mipmaps if the original texture doesn't have them. The original thread here.

Only textures used by parts need conversion. Toolbar icons and other stuff is usually hardcoded and should be left as is.

Edited by Enceos
Link to comment
Share on other sites

The main problem I see is with all tanks (which are usually cryogenic) that 1st they could withstand such large internal temperatures (higher than reactor and heat sinks), 2nd they could radiate soo much heat being insulated from outside (and inside). Right now probably any fuel tank (stock included) is simply superior in temperature radiation and temp operating ranges compared to heat radiators hehe:)

I guess there are couple solutions for that:

1st option - reduce heat dissipation dramatically; soft rebalance - ship will need radiators to dissipate heat; tanks still can withstand quite hard atmo reentry and closeness to kerbol

2nd option - reduce max temperature dramatically; you'll need thermal barrier part otherwise they'll go boom; cannot perform reentry with those tanks, tanks dissipation is also reduced because max temp is smaller, tanks cannot be used close to kerbol (or need some kind of shield). Now you also need to check tanks against engines temps (even if they operate at lower temperatures)

3rd option - reduce both heat dissipation and max temperature - so you need thermal barrier and cannot perform reentry and close kerbol orbits. Plus you might possibly need some small radiator for multiple tanks if they acquire heat (which they cannot dissipate themselves) during long journey? You'll need thermal barrier between engine and tanks as well (or just cluster engine to reactor and then use thermal barrier just like in 'real' sci-fi designs:)

A lot of this behavior really comes down to the use of passive heat transfer, though. Stock KSP doesn't seem to care about heating up cryogenic and/or manned spacecraft to furnace temperatures without any sort of consequence, and as such, making the entire vessel a giant radiator is pretty much the default behavior. You'll recall me voicing my great disappointment about this before, Nertea :P

Meanwhile in prior versions of KSP and Near Future electrical, we had something that could pretend to be active cooling. Heat was directly funneled into the dedicated radiators, the rest of the spacecraft was undisturbed. I would much prefer this option. I spent some time mulling this over in my head, and I came up with the following example idea for an active/dedicated cooling system:

- A radiator which surface attaches to a part will reduce that part's positive internal flux by up to x.

- The radiator instead gains x internal flux itself, and it possesses the thermal properties necessary to radiate it away safely.

- Bonus improvement: the value of x, and therefore the upperceiling on radiator performance, can once again be set directly and displayed comfortably in the VAB, which greatly eases balancing and improves usability.

- The radiator could still be used passively on parts which do not have positive internal flux; useful if the part in question is next to something that produces heat but doesn't allow surface attachment (hello LV-N!). It would follow all the normal rules of stock thermodynamics in that case; there's no extra code required.

Now with that in mind, imagine making the nuclear reactor itself a thermal insulator with near zero heat conductivity. Flavor it something like "the heavy radiation shielding prevents most heat exchange with neighboring parts". Suddenly, you need the active radiators attached to the reactor to keep it from meltdown - and at the same time, you prevent people from using giant cryogenic tanks as radiators. All without having to set the heat management related values of reactors and radiators to completely bogus values!

Literally the only step back in this system would be that you once again need radiators directly on the reactor, and cannot just use them anywhere on the ship like in .90 versions. But really, this capability is already compromised right now anyway, because of the need to keep radiators and reactors close together for them to interact at all and not just flooding the ship with heat and letting it radiate by itself. And you still have the option of attaching radiators elsewhere for handling other heat soruces, which was one of the goals of the shipwide implementation anyhow.

Edited by Streetwind
Link to comment
Share on other sites

Will you be adding anything akin to heatsinks (which we could then attach our radiators to) nertea?

- - - Updated - - -

- - - Updated - - -

Also, do you know what's missing in the tech tree here? missing a line in the command pods?

dxcmfikh.png

Link to comment
Share on other sites

Will you be adding anything akin to heatsinks (which we could then attach our radiators to) nertea?

- - - Updated - - -

- - - Updated - - -

Also, do you know what's missing in the tech tree here? missing a line in the command pods?

http://i.imgur.com/dxcmfikh.png

This is going to cause so many support questions: it's because nothing you have (or I know of, TBH) does "simple command capsules", and while the tree allows the empty nodes to be hidden, it doesn't hide the arrows. The other nodes all use "one of", so it's not a problem for the user (the mods are responsible for enabling empty nodes that they depend on)

Link to comment
Share on other sites

Ok, new version

vX.4.7

  • Reactor heat production reverted to 1/2
  • Reactor emissive constants back to 0.15
  • Radiator emissivity when deployed increased to 1.0, retracted decreased to 0.7
  • VAB/Inflight reactor UI is more informative
  • Reactor nominal temperature added (~750-800K). Exceed this value and Ec production decreases
  • Reactor heat bar now shows if you are over nominal temperatures
  • Reactor overheat animation returns and plays if over nominal temperatures
  • Power slider now has minimum power level again (30%)
  • Rector now has spinup time, takes ~3 hours to get to full power
  • Core integrity returns, can be field repaired (EVA) with level 5 engineer to up to 75%
  • Exceed critical temperature and core damage occurs
  • Added dummy Heat Exchanger part, high conductivity

Not worth the rebuild right now, but NFP tanks got kicked to 0.2 emissivity.

So one thing I want to know - are the advanced heat management parts useful? The heat pipe, heat exchanger, heat isolator. Affects whether they will be modeled or not.

Link to comment
Share on other sites

Yes they are. Haven't got to nuclear engines yet (been playing career mainly and waiting for porkjets atomic age to update), but from what i have messed about with in sandbox they add a lot more to building, which i like, so thumbs up from me.

Link to comment
Share on other sites

Cool, I'm also for making new parts, I guess they might come in handy rather sooner than later after another patch of KSP or NFT ;)

As for heat pipes, light-glowing lithium-molybdenum (renium-molybdenum tube with heated lithium) looks cool and is best we have today (10x better than copper + it glows nicely).

http://china-heatpipe.net/heatpipe04/08/2008-4-28/Heat_pipes_address_thermal_management_problems_inside_high-performance_aircraft_engines.htm

As for the future silver is 100x better than copper when it comes to heat transfer amount but there are no images to date nor testing rigs of it. Also it's required operating temperature range in heat pipe is also much higher.

Link to comment
Share on other sites

- alternatively you could shut it down and don't refuel but heat emission would stay at i.e. 50% to account for cooling spent fuel in reactor

Actual number for real reactors is more like 7% of operating power a few seconds after a SCRAM (follow link for Kerbal-ish lore), ~2% after 10 minutes, but it's still 10kW/ton after a year and 1kW/ton after 10 years.

See also http://en.wikipedia.org/wiki/Decay_heat

Link to comment
Share on other sites

Was testing your heat mods along with atomic to see if they played nice, all seems well, but the game ctd when the radiators were about to explode, didn't give me a crash report though and nothing in the log.... oddness

Link to comment
Share on other sites

Yes, insulators and conductors are very useful, I do not know about the others, but I would very much like to insulate reactors and nuclear engines from the rest of the ship and let their heat dissipate through radiators.

Can not say anything about heat pipes, didn't get my hands on them yet.

I also would suggest nerfing heat tolerance of cryogenic tanks.

Link to comment
Share on other sites

I think Streetwind makes some good points. His proposed solution (i.e., representing active cooling by allowing radiators to take on the positive internal flux of the part to which they are attached, up to X per radiator) would certainly allow for straightforward and predictable heat management from the perspective of the average user, and it would effectively isolate NFE from the silliness of the stock everything-is-an-excellent-radiator behavior (by making reactors' conductivity very low).

Alternatively, if you go the route of embracing the stock heat system, I think there needs to be consequences to super-heating parts for minutes/hours at a time. The stock maxTemp numbers are surely meant to represent the maximum temperature that can be transiently tolerated during re-entry, with most of the heat in the hull/casing, and with the sensitive internal contents protected by insulation. I can't imagine that Kerbals are meant to survive in a capsule whose temperature has equilibrated at 3000K.

Edited by Fraz86
Link to comment
Share on other sites

Another path (more difficult, out of scope, but realistic) would be to assign each resource (except EC) and "crew capability" its own critical temperature and low conductivity. To simulate something like "part in part".

For example, LF: 500K, Oxidizer: 350K, LH2: 300K, crew: 320K. And very low conductivity, to simulate insulation. So a part could heat up, but its 'contents' would receive this heat gradually through insulator.

Link to comment
Share on other sites

Another path (more difficult, out of scope, but realistic) would be to assign each resource (except EC) and "crew capability" its own critical temperature and low conductivity. To simulate something like "part in part".

For example, LF: 500K, Oxidizer: 350K, LH2: 300K, crew: 320K. And very low conductivity, to simulate insulation. So a part could heat up, but its 'contents' would receive this heat gradually through insulator.

This would be a marvelous solution, though I imagine rather difficult to implement.

Link to comment
Share on other sites

A lot of this behavior really comes down to the use of passive heat transfer, though. Stock KSP doesn't seem to care about heating up cryogenic and/or manned spacecraft to furnace temperatures without any sort of consequence, and as such, making the entire vessel a giant radiator is pretty much the default behavior.

Yeah, it's clearly built to approximate skin temperature during reentry and it doesn't really cut it for internal temperature.

Last night I turned on the thermal debug menu and watched temperatures as a nuke-powered tug pushed a stack of NOMS containers to a station.. Cooked en route, delivered extra crispy..

Link to comment
Share on other sites

Resources and crew capacity info is readily available for parts. Some hero is needed to write a module that would count heat transfer according to existing stats to save the day.

Getting back to topic... 8 XR-500 radiators are not enough to cool MX-2, equilibrium is at 1150K. (If we are comparing with 0.90 era).

- - - Updated - - -

Power setting still can be set to zero (at least for MX-2)

- - - Updated - - -

OK, new results for my same test vessels:

M-EXP: 1045K

MX-1: 950K

MX-2: 1150K

MX-4: 1177K

MX-L: 1140K

Link to comment
Share on other sites

Another path (more difficult, out of scope, but realistic) would be to assign each resource (except EC) and "crew capability" its own critical temperature and low conductivity. To simulate something like "part in part".

For example, LF: 500K, Oxidizer: 350K, LH2: 300K, crew: 320K. And very low conductivity, to simulate insulation. So a part could heat up, but its 'contents' would receive this heat gradually through insulator.

It would be a realistic solution, but I don't think it would play well. Already, the heat management system combines unnecessary complexity with the act of hiding most of the system from the player unless he goes through the debug menu. From a game design perspective it's just a poor feature, possibly the only truly poor feature in all of 1.0. Now in KSP such a system can pass because there's underlying potential for modders to expand on it, the debug menu is pretty much a regular gameplay feature and the community is slightly masochistic (:P), but in any other game this absolutely wouldn't fly.

As such, adding additional complexity to an already obscure system is a bad idea. It'll just lead to players scratching their head why their fuel tank contents are going down without running their engines, or why their oxidizer runs out more quickly than their LF over the course of the mission even though the engines are supposed to be balanced, and all that sort of stuff. My suggestion was aimed at removing complexity without removing gameplay depth - the two are not the same. Extra Credits had

. (Among many others. If you're interested in game design, follow them! :))

Then there's the age-old "realism for realism's sake" trap. Something being realistic has absolutely no connection to how well it plays. Much rather, something being believable has a direct connection to how well it plays. Sometimes the two overlap, because realistic things tend to be believable by default because we are so familiar with them from real life. And sometimes the two don't overlap, for one of two reasons. One, the feature in question doesn't transition well from concept to ingame representation due to limitations in control scheme, the ability to display information, or due to being disruptive to other gameplay elements. It ends up frustrating the player and feeling wrong, in the way, unusable, not believable. The other reason is that we might simply expect something else - either from simply knowing nothing about the topic, or from being used to seeing it handled a certain different way. Great example came from Notch (of Minecraft fame) when he was tinkering with 0x10c, a first person space survival sandbox which he later dropped due to dissatisfaction. He was dead set on simulating physics as realistically as possible. He started with the character's movements. As soon as he had modeled jumping according to all the laws of physics, he discovered that he hated it. Not only that, but his testers also hated it. It didn't feel right. It wasn't what they expected jumping to feel like in a game. It wasn't believable. It made for poor gameplay.

That's not to say you can't make unexpected realism feel believable. A great example of this is orbital mechanics in KSP. It goes against everything we are trained to believe by popular media and games about how spacecraft are supposed to move - and it's complex to boot. It should kill believability dead. But it doesn't, because it's implemented in a way that is completely seamless with all other mechanics, is extremely controllable, gets by with very little information display and promotes visual learning to an impressive degree. The player is easily able to shed all their preconceived notions about spacecraft movement and accept this new method as believable because it is immediately obvious that this is how it should be, and controlling it feels right. The novelty factor also helps it a great deal, and it exposes a lot of depth for its complexity investment.

But the heating system has none of that. No matter how realistic it might be (and it still derps in some areas, if you look into it), it fails to take the player along for the ride. In fact it's largely hidden from the player, who gets to see only the explosive results, but never the reasons. There is depth somewhere in there, something the player can do - but where? And what? This is not a conceptual issue, but one of implementation: it's extremely hard to expose this to the player in a seamless, entertaining fashion, without it getting in the way of the rest of the game. Near impossible, I'd wager. The concept of realistic thermodynamic simulation and consequences just doesn't "gamify" all that well. The little floating heat bars added in 1.01 are a band-aid feature aimed to expose and involve the player a little bit more, to make them realize that there's actually a logical game mechanic hidden somewhere among the random explosions, but it also resulted in a number of players being upset about them getting in the way.

The main saving grace for stock KSP here is that, as mentioned, the heat system appears only transiently in a select few special cases - during atmospheric reentry, and during LV-N burns. The heat simulation part of drills and ISRU refineries got axed by Squad within a few business days of releasing 1.0, and for good reason: it just doesn't play well in any non-transient scenario. This is a pretty big concern for Near Future, because heat load from reactors is not transient. Nertea's job here is pretty difficult, because he needs to make a poor gameplay feature feel like fun when players use his parts. That's why he implements things like the thermal insulation parts - those give the player more control over how their vessels handle non-transient heat loads. And when the player is in control, things feel more believable.

Link to comment
Share on other sites

Actual number for real reactors is more like 7% of operating power a few seconds after a SCRAM (follow link for Kerbal-ish lore), ~2% after 10 minutes, but it's still 10kW/ton after a year and 1kW/ton after 10 years.

See also http://en.wikipedia.org/wiki/Decay_heat

well yah, if the ratio is 7% for operating power for large reactors (MW thermal before conversion to MW electric) it would be more like 10% for NFT reactors. NFT reactor total MW thermal = MW thermal + MW electric.

7% from (MW th + MW el) = about 10% from (MW th). So realistically after shutdown you would have 10% of total thermal heat generation and that would drop.

@Nertea, I was testing new version which included reactor core damage and I feel it's not serious enough. Currently I just don't care whether reactor is damaged as soon as I drop it to 75% core integrity. Since I can always (having appropriate engineer) repair it to this point.

1) Thus my suggestion for core damage below 75% (or lets say 50%) to

a) rapidly (and exponentially) consume remaining enriched uranium and convert it to depleted one - this would simulate reactor meltdown @ very low core integrity

B) produce additional heat (to account for freshly produced spent fuel radiation) with rapid conversion to depleted uranium; have a look at below graph to see how much heat is generated by one ton of spent fuel. Largest MX-L (3MWreactor holds up to 5.25t spent fuel so this means about 20MW of heat in case of total meltdown that decays to 5MW after one day and 2.5MW after one week.

2) second thing - currently reactor that is shutted down stops taking damage from critical heat. So for example you abuse your reactor and it overheats heavily, take core damage to 20% (almost complete meltdown), you shut it down and in a second a) it doesn't take any further damage B) it doesn't produce any heat c) after cooling you can take remaining fuel back to other 'healthier' reactor

My suggestion is that reactor takes core damage no matter whether it works or not after achieving critical temp. I know that potential side effect will be core damage when shut-down reactor is overheated for other reasons (lithobreaking or engines or other reactors).

3) reactor is always repairable; I imagine after reaching 0% core integrity (meltdown) it would be in FUBAR state (damaged beyond repair). So it should be at least dead mass. In more advanced version dead mass that generates a lot of heat (core is full of spent fuel that cannot be removed at 0% integrity).

GzlBGhg.png

Edited by riocrokite
Link to comment
Share on other sites

@Streetwind

While I agree with the theory of your post, I disagree that heat mechanics cannot be presented to a player without making them understandable. Stock gameplay is famous to hide information from the player -and I'm still amazed on how they managed to get the orbit thing down right (and still I think that no neophyte ever got docking right without a tutorial) . If we use your reasoning the new aero should be axed in favor of the old one, since they aren't explained at all and one was at least simple, while the new one is often unpredictable also in regard to RL.

Heat mechanics are actually much more straightforward to people - thermal mass, conductivity aren't really known by this name but a lot of people have an idea of what they are. What Squad hasn't done right is telling the player that this system exists at all, and it is a shame since it can give a new, fun challenge in building spacecraft, even in non-transient scenarios. That don't work because squad hasn't tweaked values at all initially to allow equilibrium points inside the max temperature range, and it hasn't given us critical parts needed, like radiators and insulators. Now that Nertea is adding those, along with tooltips in the VAB to signal what parts produce heat and dissipate it well (every part should have it, like the mass reading), he is having the problem that large ships ends up being the radiators of a reactor, and bumping up the heat production to fix this put in danger small ships. In the end, instead of pushing the player towards the "correct" assembly - a ship with a hot part with radiators and heat sources insulated from the cold part, the mod is juggling to accommodate every possible design.

Now, I never minded Nertea not adding boiloff - it was an unnecessary complexity where there was no need, since heat was modelled poorly and it had no integration with NF reactors. However, now that we have a "realistic" simulation environment the mod ends up not conforming to reality and our expectations of "need radiators for reactors" because large ships act as one - and people were indeed surprised that the tanks could tolerate high temperatures loads, not that the heat was flowing all over the spaceship. So, borrowing from real-life a mechanic that force the engineers to insulate the hot parts from the cold (and Nert has given us an insulators that works wonder!) could prove useful. I don't say it will solve all the problem out of the box, or that it will actually be fun in game, but now there is a reason to try it.

Oh, and again, delivery of the info to the player, and a more simple modelling to avoid unnecessary complexity can be done easily. Initially, give to LF and OX the same boiloff rate, so they keep the ratios intact, make boiloff start at a critical temp (not realistic, but this give the players an hard limit and we can have the temp bar popping out when we reach this) and add RCS effects and sounds to the surface of the tank, that start appearing when the temp reach the critical point to give visual feedback that something is wrong.

If you can tell me on how liquid boiling, a common sight in everyday life (people even know that during summer some of your gasoline disappears if you don't use your car), presented in this way is less intuitive that plane matching I'll call myself wrong.

Link to comment
Share on other sites

Having consequences is a good idea, yes - you just need to be careful about the what and how. Your example with the boiloff causing vapor plumes is pretty good - not realistic, but quite suitable for a game (especially a lighthearted one). I was arguing against blind realism for realism's sake, not against implementing real concepts in a believable way :)

The aero thing can probably be argued, I found that especially planes got more intuitive and controllable. I also think that "my plane/rocket must be aerodynamic" is much more on the forefront of player's minds than "my plane/rocket needs to reject excess heat". But perception plays a big role in these things, and I suspect this perception would differ based on previous exposure to FAR... :P

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...