[0.25]KSP Interstellar (Magnetic Nozzles, ISRU Revamp) Version 0.13

[Fractal_UK]

Hi Fractal - found a little bug I think with the receiver and possibly transmitter. I can't get any faster than 12m/s in atmo with 4 receivers attached (on satellites). Possibly it has something to do with its reported area, and the fact I'm using FAR maybe?

Examples:

no rec

rec

McLovin the fixed Jool bug, thanks for the update dude!

I'd guess FAR thinks the thing is as large as it is when fully deployed and calculating drag based upon that.

Um Fractal_UK, im having a problem....

I loaded up my current active career and about half of my craft are now overheating, or hardly running due to the generators now only producing 4 and 10%....

The strange thing is I have craft of the same build in different locations and some are unaffected.

I had this too, has the way parts are upgraded changed, or was it borked before?

*edit* or is it just us?!

Getting low generator efficiencies like that with unupgraded reactors is very possible, getting a high efficiency needs either a high reactor temperature, low radiator temperature, or preferably both. You shouldn't be seeing anything different with regard to efficiencies and core temperatures since the change from 0.7.X to 0.8, though recent bug fixes could have a small impact. I'm considering having the radiator temperatures vary more smoothly with waste heat, so they don't just shoot up to max temperature instantly when there is a tiny bit of heat in the bar - that would make your rocket find an equilibrium depending on current power useage and improve generator efficiency.

I need to test this extensively though because I don't want to risk craft instantly overheating at high timewarp.

[Donziboy2]

Pictures say it all.....

If I retract them all I get 12%, all out and I get 4%......

Edited December 4, 2013 by Donziboy2

[CatastrophicFailure]

Perhaps I'm missing something that should be obvious here, but something with this mod is cutting off my keyboard & causing other problems. Just started playing around with it, and whenever I go to the map view & return my keyboard stops working, I loose all buttons in the right-click context menu, and I can't click anything at all if I exit to the main game menu. Exiting to KSC and reloading thru the tracking station gives me back control, UNTIL I go back to the map view.

Um, help?

[BigD145]

That's probably not this mod. Delete your KSP settings.cfg. When you start up KSP it'll regenerate those settings. Your keybindings are in there.

[CatastrophicFailure]

Actually it's something related to AIES aerospace, but probably a memory issue. Yet Scott Manley is able to run this with B9???

When does waste heat kick in in stock career?

[Eadrom]

Actually it's something related to AIES aerospace, but probably a memory issue. Yet Scott Manley is able to run this with B9???

When does waste heat kick in in stock career?

Scott stated early on in his interstellar quest series that he is using the texture reduction packs for the big mods he's using (stock, b9, kw reductions iirc). Another option you have is to remove parts form the parts packs you never use. Yet another option you have is to use this mod to reduce the memory size of all textures. A lot of people in the thread have been reporting amazing results. I am currently checking it out and it's working flawlessly so far with the bit of testing I've done. The most recent update will even tell you how much RAM it saved you by posting the difference between current texture RAM usage and pre-compression. Look in the debug log.

In regards to waste heat, that is KSPI-specific mechanic, not a stock mechanic.

[Makeone]

Pictures say it all.....

If I retract them all I get 12%, all out and I get 4%......

[...snip...]

What modules are those above the generator? Looks interesting...

[Lightwarrior]

New radiator behavior is... a bit strange.

As already mentioned above retracted radiators always have lower temperature => higher generator efficiency. WasteHeat is building up, but it is a problem only for fission reactors, fusion/antimatter can be shut down after burn and you will never need to extend radiators. This is strange and wrong IMO...

And BTW it would be interesting to be able to use oxidizer as fuel for thermal nozzles, i think there is no difference what to heat using reactor, except difference in masses, but this can only lead to lower efficiency (which will be still ok).

Edited December 4, 2013 by Lightwarrior

[Fractal_UK]

New radiator behavior is... a bit strange.

As already mentioned above retracted radiators always have lower temperature => higher generator efficiency. WasteHeat is building up, but it is a problem only for fission reactors, fusion/antimatter can be shut down after burn and you will never need to extend radiators. This is strange and wrong IMO...

I think this will only have a noticeable effect for the unupgraded fission reactors anyway but I think the temperature cap is being applied at the wrong time. Basically, I have to cap the maximum radiator temperature based on reactor temperature, otherwise the radiators might get hotter than the reactor and that makes no sense. When folded up, the dissipation of the radiators drops to 10% of the deployed value but the displayed temperature of the radiator isn't taking that into account at the moment so it appears to be cooler than it should.

This will only happen when there is a net build-up of WasteHeat, if you have sufficient radiators to dissipate all the WasteHeat produced, you will be better off with deployed radiators but you'll need to wait for the WasteHeat bar to hit 0 before you'll actually see that.

Edit: Actually it looks like it's just a copy-paste error that must've been made as a result of fixing the Jool Bug. I'll update the download link with a new dll shortly and put up a fixed .dll download, there is no need to redownload the entire mod for such a small fix.

And BTW it would be interesting to be able to use oxidizer as fuel for thermal nozzles, i think there is no difference what to heat using reactor, except difference in masses, but this can only lead to lower efficiency (which will be still ok).

It's quite deliberate that you can't do this, pumping hot oxidiser into a nuclear reactor is a good way to make the reactor explode.

Edited December 4, 2013 by Fractal_UK

[AdmiralTigerclaw]

Mayhaps the problem is that waste heat is being handled like a physical resource rather than as energy. In this case, you're treating the waste heat component of the code like fuel or oxidizer where specific amount fills up a bar like water filling up a bucket. And since that resource mechanism treats any given set of heat levels like one big bucket of X size, it doesn't really operate the way heat behaves.

If you can find a way to break away from the Waste Heat bar and abolish it, I would think that you'd be able to improve it.

Perhaps working the code towards objects that produce heat, like power production or capsules, send that heat outwards in a fixed amount, where as each 'part' has a value for 'sink' and a value for 'radiate' based on mass and model shape. I'd ask Ferram how he gets FAR to find the dimensions of unknown parts to assign aerodynamics to. But I think if you could produce a model like this:

Part Heat characteristics

- Heat produced / sec

- Sink value (how much heat can build up in itself based on mass, and perhaps material type.)

- Fail Value (How much heat over max Sink value causes the part to begin failing, perhaps calculated by the max-temp value kept in most part configs.)

- Radiate value (Determined by the shape of the part, how much heat the part radiates into space passively.)

- Heat Pump Flag (For radiators) Actively pulls heat from other objects on a connected craft.

How the model would work... If I can articulate what I'm thinking right.

A part, such as a capsule, produces a small amount of heat. The temperature of the capsule is a function of the heat it produces against its sink value. As temperature approaches the max sink value, the part transfers a greater and greater portion of that heat into a 'dispersal' mechanic.

Heat dispersal can do one of two things.

1: It can contact-transfer heat into another part of lower temperature value. (Heat ALWAYS goes from high to low.)

2: It can radiate into space. (Or get convected based on atmospheric pressure)

When heat transfers into another part, it increases that part's temp until its dispersal too starts to climb, pushing energy out into other components in a cascade that slowly falls off as 'distance' from the heat source increases. Ideally, this configuration leads to the heat dispersing until it reaches equilibrium. The heat transfers across enough parts that the heat sink effect and radiation effect neutralize all heat produced by the vehicle. Most ship configurations can handle natural heat production such as that from crew pods or solar panels. Thus, they need no special radiating mechanisms to disperse heat. It should be noted that elevated heat levels are okay, as long as they haven't hit the Crticial (fail) level.

However, with large thermal sources such as a fission reactor, heat would disperse through the ship much faster, causing temperature across the vessel to slowly climb, heating it up starting with the parts closest to the reactor first. If the heat builds faster than the dispersal mechanic can distribute it across the ship, temperature of a given part will reach a second 'critical temp' flag (fail value), where the part begins displaying the overheat alert... If the part overheats, it explodes/fails/stops working/whatever.

Radiators, which contain the heat pump flag, actively draw heat away from the rest of the craft, usually starting with the largest heat source. Thus, they don't have to actively rely on the heat dispersal mechanic to protect the ship and don't require the player to plop them right on top of major heat sources. (Makes sense right? All said and done, you'll be piping the heat out to the radiators somehow.)

The important mechanic here is the function of heat dispersal rate based on temperature. That is, to try again to articulate... The higher a part's temp, the more heat it pushes out in an attempt to find equilibrium. If the heat source is producing heat above a certain level that the part can't handle getting rid of, then equilibrium falls ABOVE the maximum thermal tolerance for that part. "Kaboom!"

I'd articulate this better if I could, I think I've fumbled around with words enough now that you can see what I'm getting at. Hot parts spread their heat around faster than cold parts. And it's all about where equilibrium is found

[Lightwarrior]

It's quite deliberate that you can't do this, pumping hot oxidiser into a nuclear reactor is a good way to make the reactor explode.

Yes, it was silly idea

If we assume that oxidizer is liquid oxygen even materials reactor is built of will be "flammable" in such conditions.

Edited December 4, 2013 by Lightwarrior

[Umlüx]

sooo...

i am still working with the old version where i can delete the additions folder so my solar panels wont generate waste heat.

if i upgrade now.. all my older solarpowered crafts without radiators will overheat. is that correct?

[Fractal_UK]

[Per part heat mechanics]

Obviously setting things up in this way is a lot more realistic but it opens up a large can of worms that I'd rather not get into. Once you start simulating heat flows across a vessel on a per part basis, you have a fairly complex numerical simulation going on, you need to decide on a lot of parameters for each part (parameters for specific heat capacity, convection, emissivity, reflectivity, conductivity, etc.) at which point the behaviour of the simulation is no longer intuitive - by using this kind of a simulation, problems in heatflow designs could become extremely subtle and very opaque to the player without extensive mathematical analysis of the heat flow properties of their ship.

Additionally, such simulations don't respond well to large changes in timestep occuring abruptly, e.g. as a result of changing time acceleration, especially when you're potentially changing the timestep by a factor of 100,000 - it will perturb the equilibrium and cause large shocks in energy flow until the simulation stablises in the new time acceleration regime, potentially blowing up components in the process. It's bad enough making the resource manager handle time acceleration properly as it is, nevermind having hundreds of independently simulated components doing that and it's not computationally possible to maintain a fixed timestep and perform the calculations at the required speed during high time acceleration.

Furthermore, you'd also want preferential heat transfer between components and would have to distinguish between things like reactor external and internal temperatures - you want the leftover internal heat going out via your reactor's heat dissipation system but you'd also need to have information about the temperature of the parts themselves, at which point you need multiple cooling loops, one for cooling reactors and primary energy systems and other systems for maintaining thermal equilibrium for the operation of electronic systems (and people) within the rest of the ship.

Basically, it's a nightmare of complexity.

I think the best compromise can be achieved by making heat dissipation from radiators scale with WasteHeat accumulated so you don't just get these sharp transitions in radiator temperature and consequently generator efficiency, you'll instead end up in some kind of thermal equilibrium which varies according to your reactor output.

sooo...

i am still working with the old version where i can delete the additions folder so my solar panels wont generate waste heat.

if i upgrade now.. all my older solarpowered crafts without radiators will overheat. is that correct?

There is no more additions folder, the waste heat system is added automatically to parts with the ModuleDeployableSolarPanel so that modded solar panels are now properly supported. You cannot now delete that folder to prevent the waste heat mechanics being applied but, if it helps, you can turn off WasteHeat generation all together by changing to "ThermalMechanicsDisabled = true" in WarpPlugin.cfg.

---

I've updated the download links for the mod with the radiator temperature problem fixed. If you already have Interstellar v0.8.2, it's not worth re-downloading the whole thing, just use this .dll fix, unzipping the file into your base KSP directory as usual.

Edited December 4, 2013 by Fractal_UK

[Umlüx]

thanks...

i do like the waste heat system in general. i just don't want to loose all my probes i launched before using KSPI.. maybe i'll stick to the older version a little longer until i work something out or replace the probes.

[Fido488]

I'm having an issue with the ISRU Refinery. I can't seem to connect the side node to anything in the VAB even with part clipping enabled and even when I don't use symmetry. Am I doing something wrong?

[Fractal_UK]

I'm having an issue with the ISRU Refinery. I can't seem to connect the side node to anything in the VAB even with part clipping enabled and even when I don't use symmetry. Am I doing something wrong?

You're not doing anything wrong, it's a KSP issue that I am struggling to find a solution to. It's the same problem as the stock 6-way hub part has that prevents it from being attached in certain orientations - if you start with part A and try to attach part B to it, part B will only attach along one axis top-bottom, left-right, front-back but not any of the others. Once you have placed the refinery, you should be able to attach to the side node, if that helps.

I believe, if it helps you, if you find the refinery part.cfg file, you can switch the order of the "node_stack_right = " and "node_stack_bottom =" lines in the file, at which point you'll be able to attach the refinery to other parts via the side node but not via the bottom node.

Unfortunately, since this is an issue with the stock game, I don't think there is anything I can do about it other than try to find a compromise solution.

[johnsonwax]

The .22 format makes it cheap and easy to provide two Refineries - each with a different attachment node. Clutters up the interface some, but other mods use this trick.

[Lightwarrior]

Thanks, with fixed dll it works much better.

But... seems like another bug:

0.625m generator attached to 1.25m fusion reactor gives ~1.2Gw generator output. And it really works while there is enough ThermalPower:

Edited December 4, 2013 by Lightwarrior

[AdmiralTigerclaw]

Obviously setting things up in this way is a lot more realistic but it opens up a large can of worms that I'd rather not get into. Once you start simulating heat flows across a vessel on a per part basis, you have a fairly complex numerical simulation going on, you need to decide on a lot of parameters for each part (parameters for specific heat capacity, convection, emissivity, reflectivity, conductivity, etc.) at which point the behaviour of the simulation is no longer intuitive - by using this kind of a simulation, problems in heatflow designs could become extremely subtle and very opaque to the player without extensive mathematical analysis of the heat flow properties of their ship.

Additionally, such simulations don't respond well to large changes in timestep occuring abruptly, e.g. as a result of changing time acceleration, especially when you're potentially changing the timestep by a factor of 100,000 - it will perturb the equilibrium and cause large shocks in energy flow until the simulation stablises in the new time acceleration regime, potentially blowing up components in the process. It's bad enough making the resource manager handle time acceleration properly as it is, nevermind having hundreds of independently simulated components doing that and it's not computationally possible to maintain a fixed timestep and perform the calculations at the required speed during high time acceleration.

Furthermore, you'd also want preferential heat transfer between components and would have to distinguish between things like reactor external and internal temperatures - you want the leftover internal heat going out via your reactor's heat dissipation system but you'd also need to have information about the temperature of the parts themselves, at which point you need multiple cooling loops, one for cooling reactors and primary energy systems and other systems for maintaining thermal equilibrium for the operation of electronic systems (and people) within the rest of the ship.

Basically, it's a nightmare of complexity.

It's really not, you're just making it so because you took what I said and ran it to the realism extreme.

Don't WORRY about all the heat nuances, but instead build a working by-part heat model on simplified mechanics. In the case of what I laid out in my previous post, heat production, mass, size (surface area approx.), critical temp, and heat pump flags. Make use of values that already exist in the stock part cfg files. They both have a mass and a max temp already. If you go talk to Ferram, I'm sure he knows how to get part size for a dissipation algorithm.

Next, dealing with time acceleration. Biggest mistake I think is assuming that you have to operate full computational cycles on every pass. Really, this isn't true. You don't have to fool the computer, you have to fool the user. If doing real-time calcs is impossible to enact at timewarp, DON'T enact full calcs at timewarp. All you need to do is give the player the illusion that this is going on. We're not machines... we can't tell the difference unless there's a big error.

In this case, every X number of passes, take a snapshot of the vessel's rates of change across all parts. Whatever the change rates are at that moment, you sample and hold. When Timewarp is started, suspend the physics passes on the heat engine and simply pull that data from the rate-of-change snapshot and apply it in controlled passes at intervals YOU set. To error correct, take a single physics check every x hundred or x thousand suspended passes and update the snapshot.

Further, to prevent spikes, have a normalizing code run at a desired interval or at start-stop points for time warp. You do this kind of thing with sound engineering to get rid of pops and crackles in an audio feed.

Even with the most outlandish designs people make, the a rate of change of a part should and will be predictable for an estimated period of time, time stamp or no. Even if you can't get accurate time stamps, you should be able to identify the largest time interval possible between stamps before the engine absolutely MUST throw one out there. (Otherwise I would assume KSP would just stop working and display garbage.) It should be simple to have the code go 'the maximum possible change in value for this interval is 'Q' no matter what. Anything above Q is flat out wrong. Cap all spikes at Q."

However, I'm working with a lot of assumptions and no clue what the code looks like. I'm assuming the code you can throw at this is close to the ability to mess with the engine KSP sits on. (A lot of mods seem to completely overwrite program functionality at the engine level. FAR appears to do that, but the keyword is APPEARS.) I'm not sure what your code limits are in terms of what functions you can call and your limits on what the engine lets you actually do to the code.

Perhaps it would be best to PM me, and we can have a discussion about setting up a little proof of concept testing algorithm on the side so you don't have to mess with the KSPI code unless we hit paydirt. I've got to get to bed now though. Written analysis final's tomorrow and I have make sure guys I'm in a project with got the changes I made to the presentation and we have time to finalize...

[ROFLCopter64bit]

Alright, great job with this. Love the mod. But, just want to say something regarding the thorium fuel source.

Thorium itself is useless as a fuel source. The way they make power out of it is making the thorium undergo beta decay twice, turning it into uranium-233, which is then used as a fuel source. It would be more accurate (and making me rest easy at night, for some reason) if you could do something like this.

Or, you can just do what you want. It's your mod. Infact, just forget this post ever existed.

This post will self-destruct in 5 seconds.

Hopefully.

[ExEvolution]

The radiators fail to radiate heat often when timewarping at the two highest settings causing the reactor to shut down as it overheats. Is there any way to fix this?

[BelgarionNL]

love this mod! although it was hard for me to understand how it worked since I constantly thought I installed it wrong because I did not see the science bar on my computer core, but those screenshots were outdated...

[pasty2k2]

The radiators fail to radiate heat often when timewarping at the two highest settings causing the reactor to shut down as it overheats. Is there any way to fix this?

Way around it I found was... go to another ship, warp until you get to where you need to go, then switch back. Ultimately this kills any "Revert" option though on your ship. I use haystack so its a lot easier to flip between vessels quickly, otherwise its a nightmare getting map mode to focus on what you want to see.

Not really fixing it, but it lets you continue at least?

[ExEvolution]

Well my mission already got screwed because the reactor shutdown and I don't have any kerbals on the ship to fix it

[db48x]

Thorium itself is useless as a fuel source. The way they make power out of it is making the thorium undergo beta decay twice, turning it into uranium-233, which is then used as a fuel source. It would be more accurate (and making me rest easy at night, for some reason) if you could do something like this.

That's like saying that gasoline is useless as a fuel source; you have to vaporize it first, then mix the vapor with air.

I figure there's probably a neutron source in there that you can unblock when you want to throttle up and produce power. Americium+beryllium sounds like a good choice to me; the americium produces alpha particles which strike the beryllium that it's mixed with resulting in neutrons. Gently apply the neutrons to the thorium and you've got your U233.