[WIP] Nert's Dev Thread - Current: various updates

[RedParadize]

Hello Nertra

I have a bug report for the NFT spacraft. The FL-T9000 does not sheild part. Took me some times to figure out why the stock cargo and the FL-t6000 (maybe not if up side down) works and not the T9000, but it seem that the hole on both side is responsable of this, make sence when you read this: http://forum.kerbalspaceprogram.com/content/327-On-Cargo-Bays-and-Part-Occlusion

Hope it helped. And many thanks in advance for your NFP & NFE updates.

[veber]

Mr Nertea, a small suggestion for the use of capacitors - to increase the range of adjustment of the discharge. By extending it at least to the range of 10-100% smaller capacitors will be more demand for small devices.

[void_error]

I just started goofing around with this stuff and it seems to be conflicting with Tweakable Everything for obvious reasons I guess. Removed it and it works just fine.

Why is the the waste transfer instant? My reaction was like "well, that was fast...".

So far I've tested the MX-1 reactor.

Running at 100% with the radiators retracted vs deployed seems to make very little difference on the launchpad at over 100x timewarp. Temperature's stuck at around ambient.

Edited May 8, 2015 by void_error

[Streetwind]

Timewarp of x1000 and higher does not simulate heat (and in fact resets everything to default temperatures). This is stock behavior, not anything that Near Future does.

You need to stay at x100 or below for heat to matter.

[void_error]

Also, it would be nice to have less decimals in the Fuel Transfer message... right now it's a bit overkill.

Another nice feature would be to transfer fuel/waste the "stock" way.

[BFGfreak]

I was thinking, would it be possible to have the reactor have a "core temperature" in addition to the stock temperature? The core temperature would require proper radiators to cool it but it won't generate stock heat unless you overcook the core, in which case the part will just begin to meltdown until it reaches 100% damaged at which point there's nothing you can do except watch your ship burn up from the amount stock heat generated that puts the LV-N to shame.

[void_error]

If it hasn't changed since 0.90 then the radially mounted tanks won't feed into whatever they're attached to

[Streetwind]

That is because that functionality requires another mod, CrossFeedEnabler. It is no longer bundled with NFP. But if I understood Nertea right, if you install it manually the tanks should work with it.

[void_error]

That is because that functionality requires another mod, CrossFeedEnabler. It is no longer bundled with NFP. But if I understood Nertea right, if you install it manually the tanks should work with it.

If I remember correctly, last time I 'fixed' it I didn't use the crosfeed enabler, I just edited the CFG file. MM Patch time again... if I can remember what I changed.

- - - Updated - - -

EDIT: It was back in 0.25-ish, the cfg files were slightly different.

[Nertea]

New test versions!

X.5.2

• Reduced temperature tolerances and emissivities of all fuel tanks
  
• Fixed tech locations for stock
  
• Fixed tech locations for CTT patch
  
• Added crossfeedenabler patch
  
• Fixed PB-ION patch not providing correct values
  
• Switched all directThrottlEffects to powerEffects (fixes FX playing after flameout)
  
• New balance numbers for all electric engines, including heat values
  

X.4.9

• Improved formatting for reactor repair and fuel transfer messages
  
• Radiator tweaks, constrains transfer based on heat content difference
  

[ModZero]

Hey Nertea, are the Assembly-CSharp, UnityEngine and TrackIRUnity dlls in heatcontrol in your last download intentional?

[Nertea]

No, they'll create error messages on loading but they will be fine. I don't have a lot of time so for these dev versions I might have forgot to clear it out.

[Sufficient Anonymity]

Just a heads up \Extras\Hydrogen NTRs\ is empty.

[ouion]

I found a bug which cause the parts to not appear on the tool menu(all the parts) and hows its on solar?

[Honeybadga]

• 
  ...
  
• Added crossfeedenabler patch
  ...
  

Are you saying crossfeed enabler is working in 1.0.2?

[Nertea]

I found a bug which cause the parts to not appear on the tool menu(all the parts) and hows its on solar?

I'm not sure I understand what you mean about Solar (go to the other thread, it's released), but any "no parts appear" is 99% an install bug.

Just a heads up \Extras\Hydrogen NTRs\ is empty.

Intentional at this point, I haven't done the revised versions yet.

Are you saying crossfeed enabler is working in 1.0.2?

Maybe? I don't have it installed, I just made sure the patch targets the right tanks. If it isn't updated yet, unless Nathan changes something really significant, this patch will work.

[Psycho_zs]

I've relaunch all reactors to space, first look:

MX-2 with 8 XR-500: Radiators heat up while reactor is offline (never was powered on)

It would be more informative if menu readout included both core temperature (internally simulated) and shell temperature (stock).

- - - Updated - - -

This affects: GR-EXP, GR-4, XR-500

GR-1 and XR-2000 work fine so far.

I will power up MX-1 and see what happens...

- - - Updated - - -

Results for MX-1

Can you add some debug output to reactors? Core heat generation, core-radiators flux, core-shell flux.

Any plans on connecting electric production with heat flux? Now heat production spools up instantly, but electric is not.

[Streetwind]

Psycho: the radiator behavior is actually quite consistent. You need to regard them as active cooling units in that configuration. For example, the GR-EXP conformal radiator simply causes a -50 internal flux in whatever part it is attached to, while creating a +50 internal flux in itself. In other words, if the parent part does not currently produce heat, it is being actively refrigerated by the radiator.

Now, Nertea wrote this:

• Radiator tweaks, constrains transfer based on heat content difference
  

Which I haven't yet seen happen, but then again I haven't had more than a couple hundred degrees in temperature diference yet in my testing. Yeah, seen it happen, works as intended.

(Yeah, I finally have time to start testing as well! I'm already starting to fill a textfile with comments and ideas. This is the part where poor Nertea goes "Oh f... my life" )

To expand on radiator behavior, as far as I see it there are four possible implementation models:

1.) Passive heat sink. The radiator is attached to a parent and passively exchanges heat with it through conductive flux. Because the radiator has a much better emissive constant, it tends to reject more heat than other parts on the ship, and therefore becomes a thermal sink for heat to flow towards.

2.) Active heat sink. The radiator is attached to a parent part and actively takes over said parent part's positive internal flux, up to the limit of what it is capable of. In the absence of positive internal flux in the parent part, the radiator is inert and behaves like a passive heat sink.

3.) Active refrigerator. The radiator is attached to a parent part and actively removes heat from it at a constant rate. Whether or not the parent part currently produces any heat is irrelevant. If it has no heat flowing into it, it will simply become colder and colder as the radiator continues to work.

4.) Decoupled. The radiator is attached to a Near Future reactor, and both interact with each other outside the stock heat system via Near Future's own plugin.

Model 1 is how players attempt to cool their LV-N's with wing panels in stock KSP. Model 2 was my original suggestion. Model 3 is what's currently implemented for testing. Model 4 is what we have had in all past versions of Near Future up to and including .90.

I'm actually really curious as to why Nertea chose Model 3 here. Is that preparation for future content...?

Edited May 9, 2015 by Streetwind

[Streetwind]

Okay Nertea, some thoughts and observations:

Electric engines:

- Heat output is definitely noticable, but not an instant dealbreaker... yet. Experiments to find a worst case scenario are ongoing, though the lack of large active radiators for big reactors complicates things (see below).

- You missed some Isp changes. If I have more time later, I'll doublecheck all the values and PM you.

Radiators:

- "Current thermal radiation" field causes output to display as if truncated

- GR-1, XR-2000 don't have any internal flux draw in active mode See bottom of post for update

- All radiators glow a little even without any heat load

- XR-2000: this "auto-glow" only affects the frontmost panel section

- Tau radiator doesn't have any convective or radiating flux, regardless of temperature or active/passive mode (how is that even possible? )

Reactors:

- Core life counter is a bit borked, it counts to 3600 seconds... only visible on the M-EXP due to the much longer lifetime of other reactors. Also, display issue only, it still ticks down 1 minute every 60 seconds.

- I'm getting that old silly thing with the M-EXP's radiator attachment nodes causing the radiators to be misaligned when attempting to attach.

- With the values being what they currently are, reactors equipped with active mode radiators and sandwiched between BLOK Heat Insulators reach temperature equilibrium only above their nominal operating temperature. This causes a reduction in Ec/s output. The M-EXP sits at 47/50 Ec/s, the MX-4 at ~307/400 Ec/s. I did not test the bigger reactors due to lack of working active mode large radiators (see further up).

So right now the recommended set of conformal radiators is insufficient for their matching reactors. Either the nominal temperature is set too low, OR the passive heat exchange between radiators and reactor must be inhibited. The reason for stabilizing at high temperatures is that there's a significant flow of conductive flux from the radiators back to the reactor. I suppose they must have this high conductivity to work in passive mode during testing, so if the choice is made to go with active mode radiators, their stats could be adjusted to inhibit passive conduction.

Gameplay:

- Reactors really take a loooong time to spool up now. Might be too long.

- I'm also missing an indicator telling me how far along in the ramp-up process it is. Imagine a new player who's never used one of these before, he just sits there and watches the Ec/s number climb for three hours. He has no idea where it'll stop, or how long he's supposed to wait for it... How about drafting the "status: 100% load" indicator for that job? I assume it currently is set to show how well the reactor still runs with a damaged core, but that shouldn't be a problem. It can do both at the same time.

- Slight confusion in regards to the power setting. Right now, it instantly responds to player changes of the setting via a simple division of the power output, which implies that it's a throttle for the power generator. But it also changes the core lifetime, which implies that it is a throttle for the reactor. If it was a throttle for the power generator, it shouldn't change core lifetime; if it's a throttle for the reactor, it shouldn't respond by instantly dividing the output. It's especially confusing during ramp-up, where it takes the same amount of time to ramp to 30% as it takes to ramp to 100%, depending on your power setting.

I expect that the aim is to have the long ramp-up time be a motivation for the player to not constantly switch it on and off, but at the same time give the player a tool to control their power production and uranium drain. I think that could be implemented in a more immersive fashion, though. Tying into the above suggestion with the status field displaying the power-on ramp, how about this:

Have two ramp timers, a slow one and a fast one. The slow ramp can stay at 2-3 hours, the fast one would be more like one minute (to traverse the entire spectrum from 100% down to minimum 30% or vice versa). The slow ramp is the power on/power off process, as it is now, and it gets displayed in the "status" field. It is the definitive limit of how much power the reactor can produce, and therefore constrains the upper bound at any given time. The fast ramp is tied to the power setting slider. It is not a divisor to the current reactor status anymore, but rather an actual throttle that's constrained on the upper end by the reactor status.

Example: I set my reactor to 50% power setting and then press start reactor. After reaching 50%, I throttle down to 30%. After reaching that, I throttle up to 100%.

- Current system: reactor reaches 50% output after 3 hours. I can then throttle down to 30% instantly. Following that, I can throttle to 100% instantly, too.

- Proposed system: reactor reaches 50% output after 1.5 hours. Then it takes about 20 to 25 seconds to throttle down to 30%. Finally, it takes another 20 to 25 sconds to throttle back up... but only to 50%, because the slow ramp timer still contrains the entire system at that point. It'll take another 1.5 hours to get all the way to 100%.

...I'm not sure if I actually explained this well or if I only succeeded in confusing everyone If you have questions, ask!

TODO:

- doublecheck all electric engine numbers

- more electric engine heat testing

- more reactor with passive radiator testing

- toy with heatpipes, insulators and conductors

EDIT: Stumbled on some more active mode radiator weirdness.

- When attached to normal parts, all radiators work actively and cause negative internal flux in the parent part

- When attached to a reactor, only the GR-EXP and the GR-4 work. All others do not cause negative internal flux in the reactor, and do not produce positive internal flux themselves. However, they do claim to be doing so in the "Current Heat Input" field, which displays the amount of flux that should be occuring (but isn't).

Edited May 9, 2015 by Streetwind

[Sufficient Anonymity]

hydrogen-125-2 listed as hydrogen-125-1 in .cfg

[Nertea]

Ok, see there's this problem now. I can't really just keep iterating and testing and redoing another system and testing again. This isn't very interesting or fun for me. Also, this system is starting to become needlessly complex, which is partly my fault for allowing all this feature creep. I'm going to write up a post about the features I particularly want in the system (which is LESS than there are currently) and I'm going to allow comments on it. I'm not implementing anything until we've looked a bit at it, but to all those that want a really realistic thermal and reactor sim, you're going to be disappointed.

hydrogen-125-2 listed as hydrogen-125-1 in .cfg

Thanks, fixed.

[riocrokite]

Ok, see there's this problem now. I can't really just keep iterating and testing and redoing another system and testing again. This isn't very interesting or fun for me. Also, this system is starting to become needlessly complex, which is partly my fault for allowing all this feature creep. I'm going to write up a post about the features I particularly want in the system (which is LESS than there are currently) and I'm going to allow comments on it. I'm not implementing anything until we've looked a bit at it, but to all those that want a really realistic thermal and reactor sim, you're going to be disappointed.

Thanks, fixed.

I agree, for heat radiation and dissipation I think that early 3rd or 4th iteration was perfect and simple before we 'discovered' that stock tanks act as radiators and are unbalanced. Then all workarounds were more or less complicated and they created more problems to resolve etc. Then I saw wall of text in the thread and it was too much for me;) (no pun intendended, actually it's great that people do throughout tests and propose solutions, just from the point of view of reader/modder that want to digest it for every iteration).

IMHO regarding core for reactor meltdown last time I've checked it was somewhat 'complicated' but should be perfectly balanced and intuitive (nominal and overheat temp etc, engineer reparing to 75% however if less than 10% it's FUBAR).

edit: in the end I would rather see NFT use simple heat system even if it's unbalanced with stock parts and wait for someone to do MM config for stock modules for less heat dissipation even if it means decreasing atmo reentry heat in KSP to less than 100% than NFT trying to be solution to unbalanced and not mature heat system currently implemented in ksp.

Edited May 9, 2015 by riocrokite

[Fraz86]

I agree, reactors have become needlessly complicated. I've been contemplating a simpler option for reactor heat, which largely disregards realism in favor of straightforward "stockalike" gameplay that syncs well with the vanilla heat system and encourages creative heat management.

Reactors would be given a high maxTemp (e.g., 2500K, matching the LV-N) and heat production (enough to exceed 2500K without good heat dissipation). This would create a need to protect the spacecraft from the heat generated by the reactor, by either (1) installing a full complement of radiators (which are purely passive heat sinks) to keep the reactor cooled to a temperature safe for nearby parts that have lower maxTemps, or (2) get by with fewer radiators by carefully regulating the flow and dissipation of heat through the rest of the spacecraft using insulators and heat pipes. Radiators could be buffed to compensate for the high heat production of the reactors.

The advantage of this setup is that it would not require anything new in terms of game mechanics. No need for users to attend to new concepts like nominal and critical temperatures. Max temp is all that matters, just like re-entry and the LV-N. No need for a new interface; part temperatures can be monitored using the stock interface. It also gives players the option to simply install the recommended number of radiators and not worry about heat management, but leaves more creative options (insulators & heat pipes) available for advanced users.

Edited May 10, 2015 by Fraz86

[Streetwind]

Ok, see there's this problem now. I can't really just keep iterating and testing and redoing another system and testing again. This isn't very interesting or fun for me. Also, this system is starting to become needlessly complex, which is partly my fault for allowing all this feature creep. I'm going to write up a post about the features I particularly want in the system (which is LESS than there are currently) and I'm going to allow comments on it. I'm not implementing anything until we've looked a bit at it, but to all those that want a really realistic thermal and reactor sim, you're going to be disappointed.

To be honest? I'm not surprised by this at all... merely surprised that it took you this long to assume this stance You were always very open to community input, to the point of not even coming forward with defining what you had in mind yourself. And in the absence of knowing your intent, I just start brainstorming and writing things down in the hope that some of my thoughts would end up being useful to you.

Still, I don't think the several iterations we had here were entirely wasted. At least I personally benefitted a lot from reading the discussion here and also from playing with the parts in active and passive variants. Without it, the stock heat system would still be largely arcane to me. Perhaps a few others will agree with me in saying that it has given us an excellent base on which to have the discussion that will follow.

[RedParadize]

If I may interject. From a outsider point of view, what you got is already a giant leap foward. My boss, when it come to advancing a project and submitting it to the client, always say it a "step by step" thing. In fact, he say "baby step by baby step". Simplicity is always the best way to start. If you roll back to something more simple, keep the stuff you have made so far, you might want to implement them in future version. Who knows, Squad might implement heat management at some point, might open new opportunity.