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

[Streetwind]

This is an unfinished in-dev version used for testing. The entire reactor/radiator system is getting a rewrite. The glow animation is simply not yet re-implemented.

[Nertea]

Yay testing! I'll try to compile a new version with more fixes this weekend.

I gave this a whirl yesterday, but haven't had internet access since, so now's finally time to report.

I actually couldn't get heat generation to break at high timewarp. When exactly is it supposed to happen? I took a MX-4 that was idling at 10%, with 120W heat output, and provided 125W worth of radiator power. Took this to max (stock) timewarp for half a minute straight and the SystemHeat readout didn't even twitch upwards - in fact, it continued to dissipate a small amount of previously accrued heat as expected, and then sat firmly at zero.

Well that's cool . Not exactly reproducible on my end and it's kinda a critical mechanic.

The new capacitor window works... almost as I had envisioned it. When actually using this first draft, it occurred to me that I was missing some easy-to-glance visual feedback as to the overall status of my various capacitors while scrolling through the list. The text-based charge indicator has the data, but is hard to see without stopping and looking directly and individually at it. I'm gonna think it over again for a bit if there's an obvious improvement that can be fit into the available space...

...and hoo boy is the UI broken if you try to deal with both capacitors and reactors at the same time But you probably knew that already!

I didn't know about the broken bit, but I'll add that to my fix list. Just let me know about your ideas re: the capacitor window and I can implement them probably, it's much faster to work on than the reactors.

Other than that, I am going to echo Tellion's sentiment of missing that beautiful radiator glow And, also, I was surprised to find that I really missed the action button to toggle all available radiators on the reactor. Didn't even think of that before I actually tried to do it! I know that it may be a little more tricky, now that radiators can be attached anywhere, but it would be really cool if you found a way and a spot to add a "toggle all radiators" button again.

I think I might have fixed the radiator glow. I removed the toggle all button because it's probably just better for the player to handle them with action groups now, as I can't just assume they're surface attached to the reactor.

[Streetwind]

Oh, right. Well then, here's a detail report on how to completely bork the UI in a few easy steps

- Launch craft with capacitors and a reactor attached

- Open the capacitor panel. Note how it looks perfectly fine and can be moved around perfectly fine.

- Close the capacitor panel.

- Open the reactor panel. Note how it looks perfectly fine and can be moved around perfectly fine.

- Close the reactor panel.

- Open capacitor panel, then with it still open, also open the reactor panel.

- The reactor panel now overwrites the capacitor panel instead of showing alongside it. The window also cannot be moved anymore (but it can be operated fine).

- When you close the reactor panel again, the capacitor panel reappears. It can again be moved.

- The same effect also appears when opening the reactor panel first, and then opening the capacitor panel. You don't actually see the capacitor panel being open, but the reactor panel becomes stuck and cannot be moved anymore. When you then close it, you get to see the capacitor panel.

And now it gets really weird

- Open both capacitor and reactor panels, so that you have the stuck reactor panel.

- With the reactor panel still open, rightclick a capacitor and select to toggle the capacitor panel, effectively closing it in the background.

- The reactor panel can now be moved again!

- However, the act of moving the reactor panel even one pixel after doing this breaks the capacitor panel.

- Close the reactor panel and bring up the capacitor panel again in some way (order of operations is no longer important).

- Observe how the outer border is now downsized to fit the dimensions of the reactor panel, which is smaller than the capacitor panel. Some UI elements are outside this border and thus are no longer accessible. (However, for what it's worth, the elements that are still accessible do still work).

I haven't tested extensively how long this persists, but I believe reloading the scene (i.e. going to the space center and then back to the vessel) should fix it.

Bonus bug:

- With the capacitor panel still open, go back to the space center

- Go into the VAB, construct a new vessel that has at least one capacitor on it

- Launch this vessel

- Upon arriving on the launchpad, the capacitor panel is already (or still) open!

This actually persists for as long as you play. You can go to the map, fly different existing vessels that do not have capacitors, launch multiple vessels without capacitors from the VAB... but as soon as you launch one with capacitors, boom, there's the UI!

[Nertea]

Thanks. Yeah I had seen the persistent bug before... I think I just usually don't test both systems at once. Shouldn't be hard to fix....

[Angelo Kerman]

I'm starting to look at your new SystemHeat plugin. For heatRadiated and heatRadiatedExtended, are the values in terms of units of SystemHeat radiated per second? I have a liquid droplet radiator in the works for the Supernova fusion engine that radiates heat but consumes glykerol slowly over time, is that something that's possible? I guess I could derive a class from ModuleGenericRadiator to do that but if the module lets you consume a resource in the process of radiating heat, that would be cool.

Edit: what is the conversion rate between units of SystemHeat and Kilowatts?

Nicely done, Nert!

Edited February 13, 2015 by Angel-125

[Nertea]

I'm starting to look at your new SystemHeat plugin. For heatRadiated and heatRadiatedExtended, are the values in terms of units of SystemHeat radiated per second? I have a liquid droplet radiator in the works for the Supernova fusion engine that radiates heat but consumes glykerol slowly over time, is that something that's possible? I guess I could derive a class from ModuleGenericRadiator to do that but if the module lets you consume a resource in the process of radiating heat, that would be cool.

Edit: what is the conversion rate between units of SystemHeat and Kilowatts?

Nicely done, Nert!

Yes indeed, the idea is that it's extensible for many uses. If you look at ModuleGenericRadiator, there are some skeletal bits (not fully implemented yet) that allow a radiator to consume a user-defined resource while cooling. The idea is to provide relatively robust heat storage, convection and radiation modules with support for mods to add heat easily.

The plugin will get tested as part of NFE for a while and then when it's ready it will get split off. This won't happen until post-1.0 though, as the expected atmosphere changes may well render some of my convection and radiation code useless. In the meantime I would not recommend using or relying on this too much .

The conversion is currently 1000x, 1 unit is one MW (kW got large fast).

[Angelo Kerman]

Very cool! I guess for the time being I can make something exceedingly simple for heat management that has the same units as SystemHeat, and then replace it with your system once it is ready. Or better yet, I'd be happy to help test the mod and if you'd like, fix bugs if you are busy.. Really looking forward to SystemHeat though, thanks for creating the mod.

Edited February 13, 2015 by Angel-125

[Nertea]

There's a compiled test version a page or so back bundled with the NFE test. I'll be uploading a new one with some fixes in a day or two as well. Pull requests/suggestions are welcome.

[Nertea]

Reactor meltdown is a lot better, but very flickery at high warp.

Version v0.4.0x2

• Fixed radiator glow
  
• Attempted fix for reactor meltdown
  
• Stock RTG now works with decaying pach
  
• Decaying RTGs don't start decaying until mission start
  
• Decaying RTGs now produce power
  
• Fixed reactor/capacitor windows not cooperating
  
• Fixed some UI issues
  

[Joshwoo70]

Will the decaying thing be a patch?? I want rtg's to be infinate

(Will be testing the new version.)

[Streetwind]

Yes, it's an optional patch - in fact, it won't even be installed if you don't intentionally take an extra step. Just like the Hydrogen NTR config in Near Future Propulsion.

Though if you're here to test, it would be a good idea to, you know, test it

[Captain Sierra]

Loading up a new install with the full NF suite and the experimental above. Stand by for reports of everything I manage to break (I run MPDT tugs with 7 2.5m engines to Jool and back, I WILL break stuff).

[Streetwind]

Ah, weekend! How have I missed you.

Observations with the new testing pack:

- UIs work fine now, with the minor exception that they still (both) stick around to the next launch when you leave them open while changing scene. *shrug* I could live with it.

- Capacitor UI shows a minor bug, thankfully it's visual only. I'm sure you can spot it here: https://dl.dropboxusercontent.com/u/44754370/screenshot49.png

- Radiator glow is indeed back, and behaves exactly like I would expect it to. Pleased!

- I still cannot get heat generation to bug out at any (stock) timewarp factor with a MX-4, no matter the setting. Will try some other reactors later.

- Stock RTG now works with decay for me, as intended.

- I think the core temperature readout in the reactor UI has outlived its usefulness. The measurement no longer has meaning - even with the safety off and no radiators whatsoever, it stops growing eventually and just sits patiently while SystemHeat accumulates. Ergo, might as well toss it entirely, and either save the space, or put a SystemHeat readout there. I can see that you're still internally scaling core lifetime off of core temperature, bt it might be worth scaling it off of thermal output instead - that way, there's even less of a reason to have core temperature around anymore, and the lifetime readout doesn't slightly lag behind the reactor operation status anymore.

- I recommend cutting SystemHeat storage values for all reactors by 75% or more. Right now I can cruise around the Kerbin system in a vessel with dual DS4G's (not exactly known for their low power draw and short burn times...) and a MX-4 reactor with just six GR-EXP radiators. You know, those meant for the 0.625m reactor, which have next to no weight or heat rejection ability... and I find myself thinking that I can get away with even less. Just because I can buffer so much SystemHeat and just slowly bleed it off while coasting in between burns. The reactors are kind of balanced with the mass of their radiators included (and the engine balance scales off of the reactor balance), so you might not want to let people cheese it quite this much.

Edited February 20, 2015 by Streetwind

[Nertea]

Ah, weekend! How have I missed you.

Observations with the new testing pack:

- UIs work fine now, with the minor exception that they still (both) stick around to the next launch when you leave them open while changing scene. *shrug* I could live with it.

- Capacitor UI shows a minor bug, thankfully it's visual only. I'm sure you can spot it here: https://dl.dropboxusercontent.com/u/44754370/screenshot49.png

Just to confirm, it's the -300 that's wrong, aye?

You also mentioned some changes you wanted to see in the UI in general?

- I still cannot get heat generation to bug out at any (stock) timewarp factor with a MX-4, no matter the setting. Will try some other reactors later.

That's good, but I can

- I think the core temperature readout in the reactor UI has outlived its usefulness. The measurement no longer has meaning - even with the safety off and no radiators whatsoever, it stops growing eventually and just sits patiently while SystemHeat accumulates. Ergo, might as well toss it entirely, and either save the space, or put a SystemHeat readout there. I can see that you're still internally scaling core lifetime off of core temperature, bt it might be worth scaling it off of thermal output instead - that way, there's even less of a reason to have core temperature around anymore, and the lifetime readout doesn't slightly lag behind the reactor operation status anymore.

Fair enough, I'll look into it.

- I recommend cutting SystemHeat storage values for all reactors by 75% or more. Right now I can cruise around the Kerbin system in a vessel with dual DS4G's (not exactly known for their low power draw and short burn times...) and a MX-4 reactor with just six GR-EXP radiators. You know, those meant for the 0.625m reactor, which have next to no weight or heat rejection ability... and I find myself thinking that I can get away with even less. Just because I can buffer so much SystemHeat and just slowly bleed it off while coasting in between burns. The reactors are kind of balanced with the mass of their radiators included (and the engine balance scales off of the reactor balance), so you might not want to let people cheese it quite this much.

What you say is true, but it's linked with the meltdown stuff... less storage -> less buffer -> timewarp issues. Once I solve that issue I can safely decrease the storage of the reactors.

[Streetwind]

Just to confirm, it's the -300 that's wrong, aye?

You also mentioned some changes you wanted to see in the UI in general?

Yeah, it shows the maximum discharge rate in that spot even if the capacitor is manually set to discharge more slowly.

And yes, I've been thinking about it, but I'm not quite sure how I'd pull it off. I was thinking that the visual feedback would be better if instead of the two small numbers showing charge/discharge rate and current capacity, there was a resource bar instead. The bar would be green while charging or sitting idle, and a different color when discharging. That way, you could tell your capacitors' status at a glance even when scrolling quickly. The number fields do work, mind you - it's just that they don't jump into the eye as much. But the problem is: where would you place such a bar? Just removing the number fields doesn't free up the necessary space.

Ultimately it's a luxury problem So don't worry overly much about it.

(Also, see the private message I sent you January 9th.)

Bummer about the reactor meltdown thing... I wonder if it's computer performance dependant? I don't know what you use, but my PC is colossally oversized for KSP. 16 GB RAM, 4x4.2 GHz CPU, Radeon R9-280, all-solid state storage.

Could you perhaps give me exact reproduction steps? Maybe I'm simply not testing the same thing as you are.

[Nertea]

Effective reproduction for me is MX-1 reactor + 2x XR2500 radiators, crank timewarp to max, boom.

[Streetwind]

XR-2500? I don't have any of those. I do have XR-2000's and XR-500's, with the respective cooling capacities according to their names. And yes, I doublechecked, this is directly from the latest download. If you mounted two XR-2000's, then the MX-1 will overheat because it still has a megawatt of excess heat generation. No wonder it will melt down then.

To test this, I went and mounted two XR-2000's and two XR-500's (totalling the 5000 MW that the MX-1 needs). Launched, went into a high orbit, cranked MX-1 reactor to 100% and timewarp to maximum: it's rock stable. Not even a single errant unit of SystemHeat generated when it shouldn't. Core integrity remains at 100%.

Is this a case of "unable to see the forest for all the trees", or are you using different parts from the ones you shipped?

[Nertea]

I didn't remember the name offhand. It shouldn't overheat though, it should throttle unless you remove the safety. That's the problem.

[Streetwind]

...oooh! Okay. I already noticed the safety isn't really working so well (particularly it isn't throttling the reactor down in response to folding the radiators in), so I more or less automatically proceeded to just toggle safety off by default. That explains why I wasn't getting any safety-related bugs

I see what you mean now, though. For starters, the reactor overshoots its safety target, even without timewarp - it settles at a slightly higher heat output value than there is cooling capacity. Example: 480 kW cooling -> safety sets the reactor to 481 kW output. And then, it feels like it almost "forgets" the safety at random when changing timewarp levels. For a split second right at pressing the button, the reactor will throttle up further before it "remembers" the safety switch and stops. Unfortunately, because (as mentioned above) it doesn't actually throttle down again, it keeps that too-high setting and causes a meltdown.

My suggestion for fixing this would be: teach the safety its lost skill of throttling the reactor down to meet its limit again. It used to be able to do this in past versions of NF Electrical - I used it to control my reactor throttle through radiator folding If you do this, then the timewarp problem will autocorrect itself for the most part because the heat output will not get stuck at an ever-increasing value.

There's still the issue with overshooting the heat output target, but that might be fixed by letting the safety try to hit a value of 99% of available cooling capacity instead of 100%?

Edited February 23, 2015 by Streetwind

[Nertea]

Hah, that's really what I'm completely trying to do. It's not as easy as all that, the methods are completely different than they used to be in order to handle shipwide placement.

[Streetwind]

But you're a programmer! All you have to do is hit a few keys and then it all works! Easy peasy! Right? Right?

*ducks and runs!*

On a more serious note... in my completely kitten-eyed worldview of amateur scripting, I'd try to create a tracking variable for the current vessel's total cooling capacity that's visible to the safety routine. Everytime a radiator anywhere on the ship is told to toggle, it calls a method that updates that tracking variable with the proper new number.

Then there needs to be a mechanism that tells the safety routine to check that variable. Easily done when toggling a radiator, but, hmm... when the vessel goes on-rails... it needs to be something that doesn't get called every x ingame time units because that will quickly become expensive... maybe something that triggers when the reactor adds to the vessel's SystemHeat storage?

Edited February 23, 2015 by Streetwind

[Streetwind]

Oookay, even dumber idea: can you hijack the timewarp keybindings somehow? First I thought about just mapping a function to the same keys, but then I remembered that players can rebind their keys. So you'd need to actually poll KSP as to what timewarp +/- are currently mapped to...

But if you had the ability to do that, you could force a safety update everytime a timewarp key is pressed.

[Psycho_zs]

Good news everyone!

Stock will have a new heat distribution system in 1.0 based on energy transfer and the thermal mass of parts with their content!

http://kerbaldevteam.tumblr.com/post/112636052913/devnote-tuesday-is-it-march-already

[Streetwind]

That unfortunately doesn't fix the issues present here. =/ What Squad is implementing (as far as I understand it) is a new way of heat flowing away from very hot parts, like engines, which is currently very buggy/idiosyncratic. It is not a way that lets you manage heat as a resource.

What Nertea wants to do is to have a heat producing part, and a heatsink part, and for the heat to flow from the former to the latter... and ONLY from the former to the latter. Also, this flow needs to happen regardless of where these two parts are positioned on the ship.

If he were to go and use the stock system, you'd run into the following effects:

- Turning the reactor on will heat the entire vessel to quadruple-digit temperatures, including the cockpit

- Every part on the vessel automatically acts as a radiator

- Specialized radiator parts will be very poor at being radiators because there is no dedicated resource flow, while things like giant orange tanks will be very good radiators just by virtue of their sheer size

- You're once again reduced to mounting as many parts directly onto the reactor as possible, which we specifically want to move away from

- It'll be near impossible to code a reactor safety throttle, as there is no way for the reactor to know when each arbitrary part that's an arbitrary number of heat transfer steps away over a series of parts with arbitrary heat transfer capapbilities will start to overheat, which will lead to players melting their parachutes and science instruments off at random

So yeah, this isn't the system you want here. A real life reactor isn't cooling itself by letting the heat permeate the rest of the ship either. It has special, dedicated coolant loops that take the heat directly from where it is produced and deliver it directly to where it is being removed, without affecting the rest of the construction in any way.

[Nertea]

Yeah, I do really wonder what they are doing exactly. We shall see what they end up with and maybe I can use it, maybe I can't.