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

[Nertea]

Awesome.

*downloads*

Edit: Why the hell does dropbox do a popup asking if you want to register every time I click on a new dropbox download link for the first time?

Edit2: What's the heatcontrol part?

Edit3: What's the best one to keep a nuke engine from overheating?

Edit4: I'm trying to place the radiators directly on the engine (or specifically, the 1.3 meter inline nuke engine from, uh, KWrocketry I believe) and I'm not sure how well it's working, or if I'm doing it right.

On the engine or near the engine. They suck heat from the part they are attached to, so if they're on the engine they'll cool it directly, if they're on the next part they'll cool it indirectly by cooling that part.

That made a huge difference. A quick test shows that LV-N powered "toss a hundred twenty tons to Jool" monsters will still be challenging, but more modest payloads (on the order of an orange tank) to Duna are much less nerve wracking. (A good place to be I think, Jool should be a challenge.)

I'll recheck the base configurations as soon as I can, I'm especially curious to see how the Sundiver performs near peri.

Also, if Heat Control is (AIUI) intended to be installed separately, shouldn't the folder be renamed to be in line with the other NF mods?

HeatControl isn't a NearFuture series mod, it's a standalone part. Putting the NearFuture tag in front to me means that it should synergize 100%. Not strictly true of the content in HC, though NFE will depend on the HC dll to run its conformal radiators.

For the first release, they're going to be bundled.

I'm stuck at work and can't test Hopefully will have time tonight but no promises...

...meanwhile, there's this fun mod I just found: http://forum.kerbalspaceprogram.com/threads/121987

If the pull request for colored lighting goes through I might try and make a custom config for NF Propulsion.

Don't bother, I actually (before I saw that) have been upgrading the glows and emissives of all the engines. The result is somewhat similar and I have full control over it (no dependency required).

[jonmer]

suggestion:

more heat pipes with different heat transfer capability (and mass) (including lower capability)or a slider to reduce heat transfer and\or action group support to disable heat transfer.

usage:

the Performance of the radiators can be improved by connecting heat pipe directly to the radiator from the part they are connected to(driving the radiator to near overheat).

however without ability to set the heat transfer on a low enough value the radiator explode.

[Fraz86]

Did you end up leaving the heat pipe ratio at 1.25? Even with doubled heat production, I would still recommend a ratio of 1.0, as I'm afraid serial heat pipes are fundamentally exploitable otherwise. I'll do some testing when I get home.

[Streetwind]

Don't bother, I actually (before I saw that) have been upgrading the glows and emissives of all the engines. The result is somewhat similar and I have full control over it (no dependency required).

Really? Is that in NFP already and I just didn't see it because I was focusing too much on the heat overlay during testing? Or is that up-and-coming?

Still, it might be worth to include a little "un-patch" for Engine Lighting, since people like me are going to want that mod for other engines, and right now it works by blanket-hooking into every ModuleEngines and ModuleEnginesFX it can find. If your engines generate their own lighting, it's best to make sure that they don't get double effects.

Meanwhile, some quick and dirty testing, only had half an hour today but here goes:

- everything related to turning radiators on/off now works properly on my end, as do the Tau radiators

- heatConductivity change on toggling issue did not change for me, I still need to quicksave/quickload to update the radiators after deploying

- New bug! (hooray!) Actually, this is a bug that's been in previous versions as well, and I just didn't notice until today. Basically, all radiators except the Tau work as solar panels generating ~0.8 Ec/s when deployed. They even generate the most power best when oriented edge-on to the sun, which is kind of amusing. I think this might be related to how Squad changed how solar panels are defined in 1.0 with the new power curve being internalized and all that stuff. Interesting to note: just as actual solar panels, this effect is directional. The GR-1 for example will orient itself edge-on to the sun with the "built-in solar panel" facing away from the sun, and therefore it will not generate any power - although you can still see that it has that ability in situations where it deploys at 180 degrees away from its proper orientation and needs to turn first. All the other radiators face their "built-in panel" towards the sun. Maybe a quick and easy fix would be to flip the self-orientation target for all radiators except the GR-1 by 180 degrees, so they never face the "built-in solar panel" towards the sun?

[billkerbinsky]

On the engine or near the engine. They suck heat from the part they are attached to, so if they're on the engine they'll cool it directly, if they're on the next part they'll cool it indirectly by cooling that part.

maybe it's my poor VAB skills but "on the engine" winds up being a pain. What I've been doing is to build a stack: insulator | Z-4K battery | engine and radial-attach the radiators or heat pipes to the battery.

Instead of the battery I think I'd rather use some sort of dedicated flat-stack part with high heat conductivity (radiator plumbing module or some such).

[Nertea]

Really? Is that in NFP already and I just didn't see it because I was focusing too much on the heat overlay during testing? Or is that up-and-coming?

Still, it might be worth to include a little "un-patch" for Engine Lighting, since people like me are going to want that mod for other engines, and right now it works by blanket-hooking into every ModuleEngines and ModuleEnginesFX it can find. If your engines generate their own lighting, it's best to make sure that they don't get double effects.

Up and coming. Will probably be killing Engine Lighting effects with a little MM patch. Fun fact - all the engines generated light before, it just was more subtle.

Meanwhile, some quick and dirty testing, only had half an hour today but here goes:

- everything related to turning radiators on/off now works properly on my end, as do the Tau radiators

- heatConductivity change on toggling issue did not change for me, I still need to quicksave/quickload to update the radiators after deploying

So I'm no longer thinking this has anything to do with me. Logging the heat conductivity value indicates that it never changes ever from 0.001. So it's not that. I can't think what would be changing the conductivity, because I don't know how it's modeled. I'm going to stop spending effort on this.

- New bug! (hooray!) Actually, this is a bug that's been in previous versions as well, and I just didn't notice until today. Basically, all radiators except the Tau work as solar panels generating ~0.8 Ec/s when deployed. They even generate the most power best when oriented edge-on to the sun, which is kind of amusing. I think this might be related to how Squad changed how solar panels are defined in 1.0 with the new power curve being internalized and all that stuff. Interesting to note: just as actual solar panels, this effect is directional. The GR-1 for example will orient itself edge-on to the sun with the "built-in solar panel" facing away from the sun, and therefore it will not generate any power - although you can still see that it has that ability in situations where it deploys at 180 degrees away from its proper orientation and needs to turn first. All the other radiators face their "built-in panel" towards the sun. Maybe a quick and easy fix would be to flip the self-orientation target for all radiators except the GR-1 by 180 degrees, so they never face the "built-in solar panel" towards the sun?

Way easier to fix than that. Just force generation to zero!

Did you end up leaving the heat pipe ratio at 1.25? Even with doubled heat production, I would still recommend a ratio of 1.0, as I'm afraid serial heat pipes are fundamentally exploitable otherwise. I'll do some testing when I get home.

I set it at 1.05, and even better, you can set it in the cfg now! MaxTransferTempScale.

suggestion:

more heat pipes with different heat transfer capability (and mass) (including lower capability)or a slider to reduce heat transfer and\or action group support to disable heat transfer.

usage:

the Performance of the radiators can be improved by connecting heat pipe directly to the radiator from the part they are connected to(driving the radiator to near overheat).

however without ability to set the heat transfer on a low enough value the radiator explode.

Maybe next version.

[Fraz86]

I set it at 1.05

Ah, that seems reasonable. It would require a lot of heat pipes to exploit a 1.05 ratio, and at that point, a radiator would have lower mass. Though, perhaps an increase in heat pipes' cost is warranted, considering that radiators are quite expensive. Somewhere in the 500-1000 range feels about right.

[Railgunner2160]

Can I get a link to the HeatControl download please?? I'm having a little trouble trying to find it.....

Got a NTR driven tanker that needs some help with heat management, and that's after I spent the last 6-8 hours trying to figure out what was causing my rocket to start flipping around an imaginary CoM constantly.......

[Fraz86]

Can I get a link to the HeatControl download please?? I'm having a little trouble trying to find it.....

Got a NTR driven tanker that needs some help with heat management, and that's after I spent the last 6-8 hours trying to figure out what was causing my rocket to start flipping around an imaginary CoM constantly.......

It's included in the NFE dev download.

https://www.dropbox.com/s/9osrqe6c051v91t/NearFutureElectricalX_4_13.zip?dl=0

[Railgunner2160]

My thanks!

[cipherpunks]

Why the hell does dropbox do a popup asking if you want to register every time I click on a new dropbox download link for the first time?

It does that for me also; will try to counter that with GreaseMonkey or similar addon, cause it nags me.

Moreover, Curse shows me 3 different captchas every time I visit - drives me nuts; sometimes I refrain from downloading mods from there because of that.

Edit: Kerbalstuff just nags me with single captcha of same kind. Barely bearable. Need to crack that one too.

[smjjames]

I don't need to do captchas when downloading from curse or kerbalstuff.

Edited May 20, 2015 by smjjames
Dang iPad spellcheck

[Nertea]

NFE X.4.14

• More minor fixes. Maybe this will be the last test?
  
• Fixed deployable radiators generating power
  
• Heat pipe now has action groups to activate/deactivate
  
• Heat pipe heat transfer rate can now be tweaked downwards
  
• Heat pipe costs 1250 now
  
• Unwrapped and half textured 3.75m insulator
  

NFP X.5.RC1

I'm quite certain that this will be the last test for this one, hence the designation RC1

• Improved FX lights
  
• Improved thrust transform positions
  

This has a few visual issues that occur when installed with EngineLight. They should be fixed with the next EngineLight version that will let me turn off that mod's modules with the MM patch which is already included this version.

Edited May 20, 2015 by Nertea

[DerekL1963]

That made a huge difference. A quick test shows that LV-N powered "toss a hundred twenty tons to Jool" monsters will still be challenging, but more modest payloads (on the order of an orange tank) to Duna are much less nerve wracking. (A good place to be I think, Jool should be a challenge.)

I'll recheck the base configurations as soon as I can, I'm especially curious to see how the Sundiver performs near peri.

OK, I got a chance to run through the base (LV-N) configurations. With Sundiver, it's now possible to build a vehicle that remains cool enough to maneuver significantly near peri. (Though providing enough D/v to do will be a challenge, but one outside the scope of this discussion.) Braking into orbit on Moho's dayside was quite doable. With the Quad Adapter, Duna level burns were straightforward enough but Jool level burns required more careful attention to thermal design. (I should have written down the burn times for these.)

You now have to pay attention lest you overburden your vehicle with radiators (it was difficult to have "too many" before) but you can still blow yourself up if you don't install enough. Even when you have "just enough" radiators, there's still a noticeable performance hit (D/v) that you have to account for. With the reduced number of radiators required, you now have to pay more attention to where they're located as well.

TL;DR version: While the previous version was playable, this version (_X13) is vastly improved and more balanced in that it's harder to shoot yourself in the foot (though it's still possible) while more options are available for players that are into optimized designs.

[Gkirmathal]

@Nert and anyone else who might be interested. Regarding the Dv for LqdH2 with NERVA's (stock LV-N or from mods) with CRP I mentioned weeeeks ago.

Did some very simple math on the difference in old and new density, the divider is about x5.6457.

Just for my own test, using the old quantities from the main big 1.25/2.5/3.75 tanks and multiplying it by 5.6457, gave the Dv results as from NFP 0.9.

Very logical really.

One question: I am interested to know how the current LqdH2 fuel quantities were calculated vs model dimension. Do the quantities now correctly reflect the physical tank volumes and thus fuel tonnage? (My math is rather a bit rusty though so if one might keep it simplified if math is needed hehe )

[Nertea]

Quantities are scaled to volume (1 unit LH2 takes up 1L), but I've artificially increased the volume by 1.5x to help out a bit. So a tank with volume 100L currently holds 150L of LH2

[Gkirmathal]

Quantities are scaled to volume (1 unit LH2 takes up 1L), but I've artificially increased the volume by 1.5x to help out a bit. So a tank with volume 100L currently holds 150L of LH2

So in 0.9 NFP, the LH2 tank quantities (with that incorrect LH2 density), vs. tank volumes, were incorrect then?

If I might ask Nertea: what are the in game dimensions in meters (h and r) of, lets say the hydrogen-25-1 model?

I would like to refresh my geometry skills a bit and like to do some head crunching. Seems like a good place to start

[Nertea]

In 0.9 NFP, they were correct in that they were all consistently fudged, but they were fudged.

The hydrogen-25 model is identical in dimensions to the Jumbo-64, so it has h=7.5 m and r = 1.25 m for a cylindrical volume of 36-ish m3. The hydrogen tank (and all tank volumes that I do) are calculated off of the actual tank mesh, which is less because it has that pill shape.

[Gkirmathal]

Interesting stuff! So volumes were also consistently fudges, as well as the fuel densities (that was obvious), as for game balance purposes I recon?

Glad that you gone with CRP now

About the example, volume wise give or take it's roughly 35-36m^3?

From an other discussion about the subject I had with someone.

If the dimension of a tank stays the same, but the densities changed (lowered) wouldn't the fuel quantity rise by the same factor at which the density changed?

Is this thought correctly?

[Streetwind]

If the density gets lowered, then the fuel amount lowers proportionally, not rises. Density is defined as how much mass a certain volume can hold, for example 25g/cm³. So if density decreases, there is less stuff in the same volume.

EDIT: A different way of looking at it: in KSP, density describes the mass of 1 volume unit (which, in contrast to most things in KSP, is completely arbitrary and has nothing to do with physics whatsoever). Since tank contents are configured in volume units, lowering density does not change the amount of units shown as stored in the tank. However, those units weigh less, so the contents of the tank weigh less as a whole, so you get less dV.

Numbers for LH2 tanks are chosen for gameplay reasons, not game balance reasons. Subtle difference! Using fully realistic liquid hydrogen densities and WYSIWYG tank volumes would not be mechanically unbalanced, but it would be somewhat annoying to the player because it results in very large and unwieldly vessels.

Edited May 21, 2015 by Streetwind

[Nertea]

More specifically, if you decrease density, you can't store more units in the same volume unless you compress it. Which increases density . And most fluids have a limit to how much you can compress them.

So there's a distinct lack of bug reports for the last dev versions, which I LOVE. Awesome.

Of course I find a large bug - there's an issue in the volume estimation I used for the hydrogen tanks, discovered while working on configs for CryoEngines. The rest of them (argon, xenon) are fine, but numbers are changing a bit for the H2 tanks. 2.5m size line went up in capacity, some others went down, notably the middle-size 3.75m tanks.

Edited May 21, 2015 by Nertea

[cipherpunks]

Today I attached 2 heat pipes from nuclear lightbulb to procedural tank it was stacked beneath, and attached 2 deployable radiators to that. That was all sitting above PF interstage, covered by fairings. There were some more stuff above that, covered by PF.

After leaving kerbin atmosphere, I noticed that radiators (undeployed) gloved red. After some time they exploded. Log said they were burned up upon reentry. Note that lightbulb was never activated. Also note that according to log, only 1 radiator exploded.

I have FAR and DR installed. NF versions are prior to last (updating now).

What is the logic in this, and what exactly might be the culprit of such strange behavior?

Edited May 21, 2015 by cipherpunks
add img

[PickledTripod]

@Nertea, or anyone who knows about that subject: Where can I find documentation about Firespitter/Interstellar Mesh Switch, and how to make a part that has multiple models and textures combined into one with it, like the Octo-Girders in NF Construction? I can't find specific instructions or a tutorial about Mesh Switch, either on both plugins' very scarce documentation (unless I missed some obvious link ), or in the Mod Development forum thread. I'm a Unity noob (I've used PartTools to make a few working fuel tanks and that's it) so I have no idea where to start if I have to figure this on my own. It's not entirely related to Near Future but I figured you'd know and might be willing to give a hand to a newcomer?

EDIT: Nevermind, I found Firespitter's complete documentation... The link isn't especially obvious, but still, sorry to bother you all.

Edited May 21, 2015 by PickledTripod

[Streetwind]

So there's a distinct lack of bug reports for the last dev versions, which I LOVE. Awesome.

Apologies, I haven't actually had time to try them out yet...

After leaving kerbin atmosphere, I noticed that radiators (undeployed) gloved red. After some time they exploded. Log said they were burned up upon reentry. Note that lightbulb was never activated. Also note that according to log, only 1 radiator exploded.

I have FAR and DR installed. NF versions are prior to last (updating now).

What is the logic in this, and what exactly might be the culprit of such strange behavior?

Deadly Reentry is technically incompatible with Near Future radiators. The way it wraps them into a second thermal layer makes them cook themselves to glowing slag.

However, DR should be able to detect that it isn't supposed to modify the radiators. It specifically offers that functionality for cases like this. And it has worked fine so far. Not sure what would cause it to stop properly detecting...

1.) Can you reliably reproduce that behavior?

2.) Can you try to remove Deadly Reentry and re-stage the launch to see if the error persists or disappears?

[MatterBeam]

Deadly Reentry is technically incompatible with Near Future radiators. The way it wraps them into a second thermal layer makes them cook themselves to glowing slag.

However, DR should be able to detect that it isn't supposed to modify the radiators. It specifically offers that functionality for cases like this. And it has worked fine so far. Not sure what would cause it to stop properly detecting...

1.) Can you reliably reproduce that behavior?

2.) Can you try to remove Deadly Reentry and re-stage the launch to see if the error persists or disappears?

It's got nothing to do with Deadly re-entry.

In a fresh install with only KSPI-E, NF and Hyperedit, I placed a single Tau radiator (the fin-like one) on a spaceship with pod, inactive MX-1, undeployed solar panel and a battery. It rapidly heated up to 1300K despite there being no current flow and no heating sources. Rest of the ship was a cool 300K.

I believe it's something related to the 'infinite heat transfer' problem mentioned earlier in this thread.