Gkirmathal

Very interesting to watch, thanks for sharing! Never seen this one Though I find the throwing away of the nuclear stages a bit concerting. But maybe it was just the zeitgeist from the 60's till recently. Still think B-NTR tech could work if governments and a large part of humanity can overcome their fear of having such systems launched and in operation. But we would first have to get to the stage where we have orbital 'tugs' systems, which only need to be refueled in orbit. So we don't throw away spend stages as useless scrap like we still do nowadays for the most part.

My physics has become rather rusty over the years, but I would be very much interested if you, or one of the residents, could generally work it out in some detail. If real life and time permits it of course. What I would also be interested in is the theoretical power consumption needed, for lets say one fuel conduit and how many fuel conduits would be needed to make an effective resign.

Interesting thread and I had a thought about something I read in regards to this and NEP. Lately I have been wondering something, this is in regards to an article I read about the continuations of the former Russian RD-0410 NTR program and the way they tested the fuel elements of the reactor. Link: http://ieeexplore.ieee.org/stamp/stamp.jsp?reload=true&arnumber=6076211 Due to safety regulations they could, obviously, not test a 'hot' fuel rod in a 'hot' engine environment. Hot as in fueled with nuclear fuel. As you read, they used induction to heat the fuel rod to simulate the operating temperature of a 'hot' nuclear environment and it had good results. As of now I will use the term fuel conduits, instead of fuel rods. This made me wonder whether the following might be feasible: a moderate thrust/~600>900ish ISP engine based on induction, in which induction heats the above described "fuel conduits", clustered as they would be in an NRT configuration. Thus to replace the nuclear reaction as the heating source, by induction, so where each fuel conduit is wrapped by a coil. Would this in theory be feasible? What could the energy reqs be and would such system be capable to achieve similar ISP ratings NTR systems could have had?

@RaendyLeBeau, wow nice to finally see the release, models look superb! While redesigning my interplanetary ship design, to incorporate the the sigma pod I noticed it has an integrated heatshield. Thus making the design with connected living space a bit impractical, as heatshield are not design to be passed through While I like the fact pods have all the stuff integrated, would it be possible to incorporate InterstellarMeshSwitch, or just to release pods and heatshields as a separate parts as an alternative download option?

Higher TW if i'm correct, if a NEVRA had 825 isp it would have had somewhere in the region of ~600isp on methane and ~450isp on NH4. There are some good sources to be found on google, regretfully I hadn't bookmarked them Some info: Interplanetary transportation » Nuclear rocket This was the thread, old one, which had a lot of info: Space Science & Technology » Fluorine

@Joco223 if it is not too much trouble, it would be great if you can add it Was trying out if I could've add methane for a dual mode NTR, Nertea's NTR engine models lend very well for for it I think.

@p1t1o thinking theoretically of course: the calculation would only address the vessel as a whole. Not on a part-to-part basis like it is the case now, so the number of calculations being done on a 100 parts ship, would be less. Thus performance would theoretically be increased, even for a single threaded process. Unless thresholds are reached, as Paul mentions them being differential equations, than of course performance still goes out of the window on high part count ships. Whether this can be actually be done within the constraint of Unity, that is a whole different discussion

@Joco223 I'm rather interested in methane fuel for KSP, but I was wondering to reduce part count and for simplicity; wouldn't Interstellar Fuel Switcher be something you could add? I was personally looking into it for my own use but couldn't figure out the correct volume proportions for methane to make a good fuel switch cfg.

What I personally don't get, for as long as I have been playing KSP, is why Squad can't change the part-to-part physics, so that it somewhat work in the following fashion: 'inline connected parts' to be excluded from 'part-to-part physics calculations' and only until a certain threshold is reached, only then the phycics calculations on these inline connected parts is started. For example extreme centrifugal forces, or aerodynamic forces, etc, would trigger physics calculations on those parts. Thus large constructions could be much smoother as those extreme scenarios are not common, space stations for example.

Interesting thread. A few months ago I was looking into the Russian RD-0140 project, which ended around 1994. But I found out, research on the fuel elements did continue till the end of the 90'ties. PDF with short surmised research: Russian Nuclear Rocket Engine Design for Mars Exploration, by Vadim Zakirov, Vladimir Pavshook One of the more striking things was that Russian scientist tested out a production reactor fuel element, with a 'twisted ribbon design' which increased ISP significantly over more conventional fuel element designs like used in NERVE/DUMBO. This was due to 'surface' contact ratio begin higher compared to NERVA fuel elements. They tested this in an ingenious way in my opinion: via induction, to simulatia reactor heat. Why test a full reactor when one can simulate the conditions this way. I found it rather ingenious. Check out the pdf it is a read worthwhile.

@Shadowmage, question I'd really like to start using LanderCore parts of SSTU, but I am uncertain which other parts of SSTU (shared Assets/Data & Props) LC relies on. Which parts of SSTU can safely be removed, so one is only left with all the LC stuff? If it is not too much to ask of cource

@Table as a good 'stopgap' solution before 1.1 comes, have a look at "Dynamic Texture Loader" I run it with forced OpenGL mode, on a heavily part modded ksp and it saves me 200mb on start. The dynamic texture loading also works well when doing lots of building and test launches. Without it ksp process would hit 3gb within 1.5 hours, with it it gave me 3+ hours.

@toadicus Sorry to be of burden. Last November I thought I understood after @Kerbas_ad_astra. Now (im late to 1.0.5) am looking at it again. I think I really need the mathematics more simplified, as I have trouble wrapping my head around it somehow. My math is not good enough anymore to understand the functions explained in the Mechanics part of the ReadMe. Additive range mode goal is 40Gm nominal range to show in game, from Kerbin (KSC lvl3), so up to about Dres SMA. The calculation, how Kerbas_ad_astra got to 800Mm, I understand: (4.00E+10)^2 / 2.00E+12 = 800Mm nominalRange = 800000000 simpleRange = 40000000000 > 40Gm simple mode range (this works when put in simple mode) maxPowerFactor = 4 maxDataFactor = 6 In game this give these results, from the above cfg: Nominal range = 23.8Gm > no way near to 40Gm Maximum Range = ~56Gm Can you please explain, as (stupendously) simple as still humanly possible , how to calculate nominalRange as shown in game with additive range mode on. Simple mode works perfect btw. Again sorry to be of burden to be asking this again

Be able to switch it "off" would be nice. But as intermediate solution for now, to turn it "off" would be: set min/max temp to 14000. There is nothing in KSP which can get that how anyway.

Take a look at Hoojiwana's post. I adjusted the blackBodyRadiationMin to 1600 and blackBodyRadiationMax to 14000 in Physics.cfg. The effect is very nice and it results in hot running Nuclear engine's getting a much more subtitle glow effect. Only con is that as this is a global variable, it effect all parts the same way. And if I am not mistaken this was introduce to give parts which have no heat map textures a heat-a-like effect. So changing blackBodyRadiationmin to a higher temp, makes parts which have a lower max temp not to glow at all. What I really wonder is if this variable can be modded via a plugin?

@RaendyLeBeau would your models fit, aesthetically speaking, in combination with the docking ports and chutes from Vens Revamp? Would it be possible to screen shot some of those combinations, if it is not too much to ask ofcrouce?

You may have saved my 2 wasted day searching for a solution! Going to test it as I type. If it indeed works, I think it should become documented. Yes, this indeed works like a charm. Good intermittent solution! Setting it per part as you mention would be the best solution. Do you think this possibly can be done with a custom written plugin?

Hey folks, After a long time staying with 1.0.4 I decided to update last week. While playing around I noticed something that for me is very immersion breaking in KSP, that is the newly introduced blackbody glow. For those who don't know what it is, it is that 'reddish shader/overlay' (not the heatmap texture!) for all parts when they start overheating. Currently the shader effect starts even when an engine like the LVN is still 1500K away from it's max temperature, around 900K. From that to 2500K it glows, overlaying the models org engine heatmap. Which is tbh rather not a good looking combination. My suggestion is to: make this effect configurable to a % of the max temp of a part make toggle-able like the F10/F11 overlay or to be able to completely disable it On a personal note, to be honest the feeling is rather extreme, I find it so immersion breaking I'm contemplating to go back 1.0.4 and sadly miss out on all the good mods being released atm.

Ah thanks, that explains. <snip> intermittent solution found see below <snip> @Nertea I posted this issue on the Dev & suggestion section and 'hoojiwana' came up with an intermittent solution. The blackbody glow shader is controlled in Physics.cfg by the following variables: blackBodyRadiationMin = 798 // Temperature at which a part's thermal radiation becomes visibile blackBodyRadiationMax = 7000 // Temperature at which the black body radiation gradient ends Tested with setting the min to 2750, it works very well. Only con is that it is for all parts. Could this be possibly be controlled with a custom plugin, to be able to set it on a per part basis?

@Nertea I've updated to 1.0.5 and engines heat animation now works I still have one question regarding them though, is the heat animation suppose to look like this? As in the whole engine model + adapter being mapped? This inherent to 1.0.5 heat system & animations or because of it still being a WIP? This is 1.0.4 btw, difference is clear. The models still make my jaw drop every time I design a ship with them edit off topic: Oke, I checked several ntr mods I had installed and all show the same red model glow, besides the models heatmap, at high temp. Thus it's inherent to 1.0.5. Is this a ksp setting, overlay of sorts that can be disabled? I find it rather immersion breaking to say the least.

<snip> scratch that for a second....brainfart moment. Figured it out...had been staring too long at it and couldn't see the obvious: division by 60 minutes xD

Just updated ksp to 1.0.5 (finally!!), also updated to the newest version of USI LS, but I noticed and it was confirmed by reading here, that the supplies consumption got changed. To be honest I need some help figuring out how the new consumption is calculated. Old version was peanuts to determine: nr of supplies / 1.08 (6h/daily consumption) / nr crew = days worth of supplies. For example: a module had 75 supplies and 1 crew, by the old system that gave 69 days of supplies. Can anybody explain how to manually calculate the current supply consumption, with x nr of supplies?

Forced OGL is the only way I can play nowadays...but I did run into another stranger thing after finally updating to 1.0.5 from 1.0.4. For some reason my 1.0.5 has worse memory leakage with 1.0.5 versions of EVE and Kopenicus. Related to them yes I know, so using the 1.0.4 version of EVe which give no issues. Without those two, no ram leakage, albeit having higher starting ram usage due to those new parts.

Well I couldn't see a difference after installing it on 1.0.5. Yes, still to do with ram usage, as I use a lot of mods! KSP 1.0.5 seems much worse for me than 1.0.4, there seems to be some major leak where each scene switch adds 100+mb, but no odd exceptions in output_log. Read this in more cases after 1.0.5 was released, was on of the reasons I stayed with 1.0.4.

@blackrack Finally updated ksp to 1.0.5, but does the Skytone Mapper you released some months ago functions in 1.0.5?