Starwaster

Apologies for the necroposting but I just had an idea.... if multiple docking ports cause lag then it has to be because of the module code in the part. How about a docking port that stops being a docking port after it's docked? It would require a custom plugin and a custom part. (the part code would be identical except for the addition of a parameter in the MODULE code for the port which signifies that this is going to be fused later) The way it would work is that in the VAB, nothing happens, the part is treated normally and ignored by the plugin. When an actual craft is spawned that has two of these ports connected OR if a craft is docked and results in two of these ports connecting, the MODULE{} code that identifies the part as a docking port is removed. The two parts would just like any other static part. The only real downside I can see is that 'you better mean it' if you use these because they're probably not coming apart again. (technically I suppose it's possible, it's trivial enough to identify that these two parts WERE docking ports using their names but then a mechanism needs to be put in place to not only identify the parts, determine that you want to separate them, reinsert the docking port module code and then separate the craft, all of which adds complexity that might not be wanted)

Hey great! I didn't even mean to. Yeah, you can abuse the hell out of this mod. If I ever get around to trying out Deadly Re-Entry I'm going to use it to make heat shields with too..... be nice if I can do it by making a part that I can retexture. I forget if you can specify new textures just in a part config file or not... anyone know if that's possible? betaking, see my previous post / image. That giant tank in the middle has 21 2.5m tanks, a bunch of struts and girder, control stuff, + solar panels on the outside. During launch I would definitely say that it is laggy. Once in orbit I don't *THINK* that performance is being impacted very greatly but I'll take another look at that next time I get in the game and tell you what I think. That said, there is a spherical fuel tank mod out there filled with all sizes of spherical tanks....

+1 this The fairing base rings need to be slimmer. Especially if we're going to use them as interstages and they're forming the base for some engines. Also, I'm still noticing some situations where fairings get broken when reloading the craft, or when returning from the launchpad. It seems like it happens when you have mismatched bottom/top parts. Either different sized parts or the versions I made with builtin decouplers. If I stick one of those in the bottom and a normal one on the top, it works ONCE. Then if I have to reload the craft I then have to replace all the fairings that are broken. Also, I made an absolutely GIMUNGOUS fairing... On the bottom we have ring fairing that has a quad adapter attached and four nuclear engines. The top is a ring fairing facing down and a clamp Sr. on top because this is supposed to be a drive section for a Duna mission. Next I attached the procedural fuselage because I didn't want this being jettisoned. That's it for the inside. Everything else is attached to the fairing. Four lift units - 3.5m KW tanks, Griffon XX. I think I filled them with LH2 + LO2 to keep them light. Or it might be Liquid Fuel + LO2. Two feed into the others and I jettison those after about 1 minute, 5km up. This was built in a single session with no testing and made it all the way to apoapsis (80km) on the first try. There were however issues with control up in space and I was not able to orient it for its first orbital burn. Ultimately I ended up abandoning the giant fairing idea. I may revisit it however as Duna Voyager drive section mk2 is being a colossal PITA to get into orbit right now. Now that I think I have a handle on the control issues I might just come back to this... Oh, right, so inside this is just a stack of 3x2.5m tanks filled with pure H2 (for the Modular Fuel Tanks Real Fuels mod) then six identical stacks attached radially to the center tank. Other goodies like control units, antennas (for Remote Tech 1) In fact it's carrying a LOT less fuel than you'd think looking at that giant thing in the middle.

@ialdabaoth, is it possible for Hybrid engines to accept more than two propellant configs? I was trying to reconfigure the big KSPX nuclear engine to accept some new nuclear fuels I'm making (see prev.) but I'm finding the hybrid module seems to be conflicting. It only accepts its hybrid configs (LH2 or LH2+LOX) and ignores anything else I try to add with CONFIG{} Also, would it be possible to do propellants as an alias? Such liquid H2 & slush H2? Performance would be identical so it should be possible for a single engine to accept either one in the field. Failing that, using CONFIG{} is it possible to add other modules like if I did something like CONFIG { MODULE { name = ModuleGenerator isAlwaysActive = true INPUT_RESOURCE { name = ElectricCharge rate = 0.5 } INPUT_RESOURCE { name = SlushH2 rate = 1 } OUTPUT_RESOURCE { name = LiquidH2 rate = 1 } } } Would that work do you think? (ignoring for the moment where the LH2 is actually going to go... assume another tank is waiting to accept it, or maybe it would go right to the engines? I'm not sure about that part. Also, another question about ModuleGenerator, what happens if one INPUT_RESOURCE is unavailable? Do the ones that are available get consumed regardless of whether all are available? And what if there ISN'T a place for the output to go? Are inputs consumed anyway?

I'm going to release my fuels here once I figure out how I screwed up the KSPX nuclear engine. It'll be slush H2 (slush SHOULD totally be usable without requiring a reconfig of the engine but I'm not sure how to go about that or if it can be done... maybe create a separate tank for liquid H2 and then a generatorModule to turn the slush into liquid? Too complex? Even doable using only the Real Fuels configs?) and ammonia. Slush is marginally denser so it'll provide a little extra deltaV. Ammonia provides a lot more but lowers overall isp and if you want to get a lot of it into orbit, it's a bit of a pain. Probably a lot more than it needed to be because of poor rocket design on my part. According to Project Rho, NERVA style engines can use a very wide range of fuels with varying performance hits. Methane was actually the second best performer but decomposes in the chamber to some nasty compounds that would render the engine unusable unless the fuel rods could be purged of all the gunk. Ammonia was third in raw performance but is second in desirability because it has a much slower boil-off rate and decomposes into hydrogen and nitrogen in the chamber. http://www.projectrho.com/public_html/rocket/enginelist.php#id--Nuclear_Thermal--Solid_Core. I might do them all eventually but only if I can figure out how to implement the harmful side effects of some of them. Water would be plain dumb, it doesn't make a good propellant and it's too heavy. Unless it were an emergency and you could get some from an ocean. That would be interesting actually. "Lost on Laythe!". Not sure what other mods you'd need for that but you could hypothetically with the right mods set it up so you could totally do wilderness refueling. FYI, it was mentioned in 2010: Odyssey 2 (or both?) that Discovery used ammonia as a propellant. This was a good thing as Discovery had been in orbit around Jupiter for so long that hydrogen would have boiled off, especially under the environmental conditions that Jupiter imposed.

No, that's what you're supposed to do. Or to be more precise, the zip file (I see no rar file anywhere) contains a gamedata folder. Drop that into your KSP folder. If you are asked if you want to merge folder or if you are asked if you want to overwrite any files or folders then the answer is YES. Otherwise important files/folders will be skipped.

Electricity already isn't well scaled. And it feels like this mod sucks up too much of it as it is. And what aggravates it further is that it's not even really possible to say with a reasonable degree of certainty 'X amount of electricity = Y amount of real life electrical unit of measurement'. Are we talking about watts or amp hours? And at how many volts? Most applications we should be ok just throwing a single RTG into the mission. Maybe a second one for manned missions with extra requirements but the stock RTG pulses its power output rendering it useless for situations where IRL it would excel. (referring mostly to ion engines here, one RTG is more than enough) finally, I'm not really THAT cranky.. I just forgot this is teh intarwebz and that I need to do some kind of emote or something cause you can't see my face or hear my voice... here ya go. [/RANT]

Please make a Karmony end cap that looks like the ring but without the recess

Why would you use soil when you can use hydroponics? Or is this about artificially introducing some arbitrary level of difficulty in the name of 'balance'?

@Sarbian I just downloaded your latest dll file. Looks ok so far, seems like even less oscillation than before. I'm not sure what you changed so I don't know what I should be looking for regarding testing. Sorry if you said and I missed it, I looked over the last few pages. One thing though: Landings. I just initiated autolanding procedures for KSC. The good news is that it put me right back on the launch pad. So if you did anything to the landing code, good for you. However, it left me hovering at 500m above the pad. I had to abort + 'land anywhere' to get it to touch down... It was almost as if I had used the hold vertical option to hover. I've not seen anything quite like that when landing....

It starts its turn at 5km because not everyone agrees about where is best to start the turn. The people who made the mod thought that was a good value (and it often is) so that's what they put in there. But they also know that not everyone agrees on where is best to start the gravity turn which is why they put in the ability to edit your ascent path. Your ascent path has always been your responsibility to determine before each and every launch and you should get in the habit of checking your ascent path before each and every launch because in addition to everyone not agreeing what's best here: Not all rockets will do well on a given ascent path. As for loss of control and blown up engines, that's also not a bug. As others have stated, damage could have resulted in your inability to control your craft. Another possibility is that one of the GUI windows had focus. That's not specific to MJ, that's common to most GUI interfaces. As for your engine blowing up, all MJ does is lower the throttle so that you're not incurring heat buildup past a certain point due to excessive throttling. But there are other sources of heat besides the throttle. Just today I was launching a difficult payload and the ullage retro rockets on two spent stages played their exhaust plumes over two of my engines as they were jettisoned. The engines were already hot and they exploded. That wasn't a problem with MechJeb, that was a PEBCAK issue and you better believe Starwaster went back to the drawing board and got his **** together and fixed his rocket so he could go to space today.

Bottom line is that turning it off is exactly what you're trying to do but you're trying to impose a realistic penalty for doing so. So turn the thing off and add module to the tank part that eats electricity. MODULE { name = ModuleGenerator isAlwaysActive = true INPUT_RESOURCE { name = ElectricCharge rate = 1 } } Change rate to whatever you think it should be and call it a day.

The 60s you say? That's funny, I think that's about where Kerbal technology is at right now. Thanks for the information provided (I saw the same at Project Rho, I recommend it to all KSP players and modders) but I'm more interested in whether the values for the relevant parts in the game and in this mod are accurate, since I shared a concern that others have voiced that there was something wrong in the mod that was robbing the LVN of the performance it should be achieving in-game. I no longer have that concern; liquid H2 performs close to what it should IRL. The problem is that people just aren't carrying enough of it with them because they don't realize that while efficient as a fuel that it's not very dense. So I think the correct answer to those concerned about LVNs and how they perform with Real Fuels in this mod is it's performing as it should and they need to carry a lot more H2 with them. The isp could be bumped up to 1,000 without straying very far from the engine the LVN is supposed to represent. That will net you a 17% increase in the ÃŽâ€v of a given spacecraft. Another solution would be the addition of more fuel types appropriate to the LVN. To that end I've been experimenting with adding liquid ammonia as a fuel type. Ammonia can be used in nuclear thermal rockets (NTR) like the LVN. The downside is a substantial reduction in ISP, down to 520 from 850. (IRL ammonia's greater molecular mass translates to lower exhaust velocity) The upside is that you can carry more fuel with you in a given tank. I don't have the exact numbers right now but my fuel lasted about 5 times longer and (more importantly deltav was substantially increased as well) Unfortunately ammonia being so much more denser than H2 made it a lot harder getting my ship into orbit. Probably it would be better to send it up with empty tanks and then fuel it in orbit. I also was toying with adding solid ammonia which would allow carrying even MORE fuel but to be realistic, the tank mass overhead needs to be much higher to take into account the necessity for heating and thawing the fuel so it can be pumped. Something else I want to try is slush hydrogen and metallic hydrogen. That would get performance back to H2 levels (for slush) but you can carry more of it without dealing with the weight issues that ammonia has. I saw mention that metallic hydrogen also offers increased efficiency as a fuel type but I need to track down some actual data on that.

Unless tanks are grossly overweight then it's probably not that big a deal. Look at how massive some of the Saturn stages were. I haven't seen anything in that neighborhood yet but then the largest tanks I've used were 3.75 (from the KW Rocketry pack) Rocket tanks are really massive. And I'm leaning back towards something I said in my earlier post which is that we just need to get used to carry massive amounts of H2. I mean really, NERVA has to be considered our entry-level nuclear rocket... that's all it ever was IRL with better rockets down the pipeline. Or research different nukes using different propellants like ammonia. I have no idea what the performance characteristics of that would be though.... Probably some information about it to be found at ProjectRho...

Hmmm. I always do that anyway to keep mechjeb from collapsing my parachutes.... (sometimes I have to do that because I'm low on fuel or I'm landing something so heavy that I'm using chutes and retros) I start from 50 all the time. However, I give MJ2 a head start by going to each craft and controlling from the docking port that's doing the docking, targeting the opposing docking port and using the Smart A.S.S. (Engage the Smart A.S.S.!!!! sorry, had to say it...) to manually point towards the target. Do that on each craft. It worked better on versions of MJ2 prior to KSP .21.x but lately it tends to immediately drift while switching craft whereas before MJ2 would still be active on the inactive craft keeping its port pointed at you. Not sure why it's not doing it anymore I can still make it work if I turn on SAS afterwards and let it stabilize a bit.

I had it put me on an escape trajectory out into the Kerbol system proper.... thankfully I usually F5 before doing things like autolanding

Only in a vacuum are they correct so make sure that your final orbital payload is the only one being tested. (for the nuclear testing I assume that is the case...) LOX is lighter and counts less towards thrust than the chemical oxidizer, therefore more of it has to be burned per second to attain the thrust rating specified. When I first started playing I thought some propellants were too heavy so I tried decreasing their resource densities and found that they got burned through even faster. I think that's been discussed previously elsewhere.... Also, I suggest the following for the nuclear engine. This won't affect any of its performance issues being discussed currently but is more canonically correct for ModuleManager: (replaces everything up to the line that starts with @atmosphereCurve) And code tags have to be in caps (CODE) @maxTemp = 2200 @MODULE[ModuleEngines] { @maxThrust = 333.6 @heatProduction = 300 !PROPELLANT[LiquidFuel] !PROPELLANT[Oxidizer] PROPELLANT { name = LiquidH2 ratio = 0.99999999999 } PROPELLANT { name = nuclearFuel ratio = 0.00000000001 } Finally, some thoughts on the LV-N issue. I've been researching everything I can on NERVA but it's a bit hard because some of the specs I've found on NERVA rockets were for proposed future versions. So I tried to focus on the actual engines that were tested and versions of which would have ended up on Saturn rockets until the project was defunded. The following pages I'm finding most interesting. So far discussion is focusing on things like fuel tank mass and fuel-tank mass ratios, but none of that really affects anything but your final TWR So I was curious as to just how the fuel consumption of the LVN (especially the modified one in this mod) actually would stack up against real life counterparts. It's hard to find information about that because there's so MUCH of it available and for things like wiki entries I'd LIKE to be able to trace down sources so it's taking me a while There is wiki page that lists specs for a NERVA-2 engine very close to what we have in KSP except that it had a thrust rating of 333.6 kN. Information is provided not just for the engine but for the entire Saturn third stage it would have driven. I had to make some assumptions on how much of the consumables were H2. For simplicity's sake I went with 100%. The result is that it consumes 120kg of H2 per second. I changed the thrust for the LVN (for this mod) to match and it burns through 1,831 kg of H2 in 1 min, 23 sec. That's about 22 kg/s so it's consuming quite a bit less. The stock/modded version with 60 kN of thrust (the equivalent of NERVA1) consumes about 5x less. Quite a big discrepancy but it's a discrepancy in our favor since it means the engine is much more fuel efficient than we're giving it credit for. We're just not carrying enough H2 around. Given how light it is we can carry quite a lot of it. My test ship had 6 drop tanks that it jettisons in pairs as they empty. (using fuel hoses to route fuel as appropriate) I do question though whether or not H2 should maybe be made denser, but then we start getting into volumes, so how much do we actually know about fuel tank volumes? I've seen the term 'kerbos' bandied about as a hypothetical unit of volume as opposed to just using liters, kL or m3. But I never really understood why that was. Is it because we don't really know what these tank volumes represent? Or are there other reasons? Edit: Linking to referenced pages http://en.wikipedia.org/wiki/NERVA Another interesting page; this one talks about the engines that were part of the von Braun Mars proposal. In performance they seem close to NERVA1 and KSP's LVN and list a fuel consumption rate of 8.5 kg/s http://www.astronautix.com/engines/neralpha.htm

Do tracked vehicles work underwater?

I once had a (I thought) beautiful design for Duna that was a two section craft with clamp Sr's and I left the drive section in Duna orbit, went down, had fun then blasted off into orbit... and the drive section was GONE. I was sure I put it in a stable parking orbit. I've heard of craft just up and vanishing before but what I think happened was it got classified as debris. And I had set debris to 0 because I was having all kinds crashing problems at that time. Oops.

Re: the discussion about MechJeb and where the craft is controlled from, that's definitely something that the player should have to decide on a case by case basis as the situation with his craft changes. (that in response to a few remarks about MJ deciding what part the craft is being controlled from; the only really relevant part being whichever one the player chose) @Sarbian, on the subject of the roll control in autodocking, I had a devil of a time getting two ships docked because they have to be lined up with each other with pretty much no degree of tolerance. (they dock side by side using two docking ports fore and aft). Each ship kept trying to roll several degrees off and I wanted to try using the roll feature but I wasn't sure what to put in there. If it says 0 degrees, what is that in relation to? Does it already try to line up a certain way with the other docking port and you're telling it to orient a different way relative to that port? Or is it relative to something else?

KSP needs to look for the existence of other ksp.exe in memory and abort if there's already one running. This morning I accidentally held the enter key down too long. Not sure how but that's the only thing I can think of that makes sense because when I returned expecting that KSP would be up and running, instead I saw that multiple (almost 10) instances were trying to execute. Needless to say, none of them were successful....

Are you kidding me? We have to keep throwing Kerbals at the Wall of Science until one of them sticks!

Deadly Reentry 7.8.2, for KSP 1.12.* - The Barbie Edition What Deadly Reentry does! (especially with KSP's new handling of thermodynamics) Deadly Reentry balances part thermal properties (max temp values of skin and internal as well as various conduction properties: skin-skin, skin-internal, emission, etc) If parts get too hot then they may catch fire. (or begin to melt; depends on if they are logically flammable or not). This begins to happen at 85% of its max temp. Some parts have had their max temp increased to compensate. Basically, think of the 85% mark as being a soft failure point leading to hard failure. As of DRE 7.6.0, this is implemented on a per area skin damage system (X+-, Y+-, Z+-). As the exterior is damaged, the interior becomes more exposed to direct reentry or supersonic heating. (the interior usally has less resistance against heating) Parts and Kerbals that experience excessive G forces for excessive periods of time may fail/die. Download latest version! (official release) If you find this mod helpful and want to throw some money away, feel free to click the donate button below! ialdabaoth (who is awesome) created Deadly Reentry 2, based on r4m0n's Deadly Reentry; this is a continuation. This continues NathanKell's work on Deadly Reentry continued, and he might contribute more at times. License remains CC-BY-SA as modified by ialdabaoth. Also included: Module Manager (by sarbian, swamp_ig, and ialdabaoth). See Module Manager thread for details and license and source: http://forum.kerbalspaceprogram.com/threads/55219 Module Manager is required for DREC to work. INSTALL INSTRUCTIONS: If you currently have Deadly Reentry installed, go to KSP/GameData/DeadlyReentry and delete everything (files and folders). Also delete any old versions of ModuleManager (modulemanager.dll for example) in your KSP/GameData folder. Extract this archive to your KSP/GameData folder * ModularFlightIntegrator is not currently required or used by Deadly Reentry as of about DRE 7.2.2. USAGE INSTRUCTIONS: Be careful how you reenter. Make sure your craft has a heatshield (the Mk1 pod has a built-in heatshield, as do stock spaceplanes; the Mk1-2 needs a heat shield from the Structural tab). For a low Kerbin orbit reentry, try for a periapsis of about 10-20km over Kerbin. do not deploy your parachute until speed has dropped below ~350m/s. (typically you should be at a safe velocity by the time you reach an altitude of 7km) Note: Deadly Reentry no longer interferes with chutes. Both stock chutes and Real Chutes have adopted their own implementations of punishing deployments at unsafe speeds. The above warning still applies except you don't get to blame Deadly Reentry about it. Compatible shield/reentry packs! Deadly Reentry Frequently Asked Questions. Changelog: Old Legacy Changelogs! DRE menu icon created by lajoswinkler Download (latest official) Source on Github

Ensure that your ship design has properly balanced RCS. Ensure that ship is being controlled from the port that you wish docking to occur on. (or that it is being controlled from a part that is aligned with said docking port) I think Sarbian's version addresses some docking issues and if you turn on caps lock (in latest KSP version only) it will help with RCS balancing but I stand by my first statement: Balance your RCS. Give the automatics something it can work with

Then there's something odd going on either with your installation (i.e. mods) or with your craft design. Every time *I* put a Sepratron or a KW Rocketry ullage motor (or any other SRB I've put on for retros) on a stage that's being decoupled it's never failed to fire. I have designs that depend on that behavior to prevent damage to the next rocket stage or payload. I have one rocket that has six SRBs that separate and each one of them has four motors (2x top & bottom) that push the spent SRBs away and down. The stage consists of ullage motors on SRBs & radial decouplers joining SRBs to main rocket body & next stage motor so it gets activated and propels next stage... all activated on one spacebar press, no having to time between multiple presses or anything