NathanKell

They are rotating. They're rotating constantly to orient perpendicular to the camera, otherwise they wouldn't look round, they'd look oviod. You can use the EFFECTS node to set up lots of small particle systems in a line, yes.

Makes sense to me. Wish I could help with blender, but never touched it myself. If you were using max, now...

Also, SRBs explode all the time. Challenger, most infamously, but there have been a fair few Titan UA120x and USRM explosions IIRC. Ares I was about reusing STS hardware (although in fact they ended up not reusing hardware, it was all new-build "derived" hardware unlike DIRECT/Jupiter....)

Makeone: TweakScale does not play nice with KW engines, I'd presume because of the combination of (1) non-1.0 scales for the MODELs involved and (2) multiple MODEL nodes. Northstar1989: more a point for the RSS thread, but yes, I do plan to play with asteroids. Haven't had a chance yet.

I shouldn't clog up the thread further, but Saturn V is *not* an evolved Saturn I. Saturn I (originally C-1) was a cluster of Redstone tanks around a single Jupiter tank, and was an interim heavy LV bunged together by ABMA out of spare parts (quite literally). The original upper stage was to be "a complete Titan I." What you're talking about is that Saturn V was developed from the Saturn C-5, which was one of a suite of Saturns designed around the F-1. While it was designed by the ABMA team, and certainly used experience from the V-2, it was not directly derived from the V-2 in the way that Redstone (and thus Saturn I) was.

Confirmed the issue on a completely clean KSP install with only RSS and Overhaul 9. Doesn't even have ATM.

Reddragon: Mark Wade (of Astronautix) has about 99 bones to pick with NASA; I'd take everything he writes with a (decently-sized) grain of salt. For example it's far from clear that solid-boosted hydrolox is all that great of a thing, let alone that a lifting body RV is useful (if you don't need crossrange, wings are worth less than nothing). SLS would have been better than STS, but then again almost anything would have been. While solid-boosted hydrolox is cheaper than kerolox-boosted hydrolox (that's why NASA scaled back from liquid to solid boosters for STS), what's expensive here is the hydrolox part. A pure kerolox LV is actually cheaper, IIRC, and certainly less dangerous for crewed missions. Solids and crew are a bad mix.

And the J-2 and M-1 were for LUNEX (the sustainers for the small/medium and the large SLS launch vehicles). The 120" SRMs (research on which led to UA120x SRMs) were the stage-0 boosters for SLS. The RL-10 was to be the lander's descent/ascent engine. Project LUNEX on Astronautix. Note: LUNEX was insanely optimistic regarding both time and hardware. Don't get your hopes up.

The Army Ballistic Missile Agency was what Von Braun's group was called, from between the time the Army snatched them up in '45 until they got transferred to NASA and renamed Marshall Space Flight Center. They were placed in Huntsville, Alabama, near/at the Redstone Arsenal (hence their first project was called the Redstone missile). Jupiter was their last missile project; they began designing Saturn ("the one after Jupiter") for the Army's launch needs for Project Horizon (the Army, like the Navy and the Air Force, had a lunar exploration plan). C.f. Von Braun, Project Horizon. Good writeups here: http://falsesteps.wordpress.com/?s=army+saturn&submit=Search

Uh, please please don't start adding duplicate copies of PF. As the post above (and e-dog) said, the old parts are still there. They've just been set as unavailable. Use the above MM patch to make them available again.

dtobi: two issues with this (1 per PM). 1. KM_Gimbal (and presumably your other assemblies) are compiled against .NET 4.0. However, KSP is written for (and ships with) 3.5, and any 4.0+ features will fail. (I did more research; I misremembered it as 3.0; it is in fact 3.5). Could you recompile for 3.5? 2. KM_Gimbal force-activates engines, which messes with staging. You note earlier in the thread that you'd fixed the issue, but I still saw it occur quite regularly. THIS is the line that causes it; if I disable that whole check, things seem to work normally, and I confirmed that the gimbal still activates correctly when an engine is activated by action groups rather than staging. Therefore I suggest removing that whole method.

Read the post right above yours omg

If it's not in GameData, it's in one of the assets files in KSP_Data. You can use a Unity assets browser to open them.

gesia: I played around a bunch with the NTRs Friday night and was unable to replicate your issues, implying very strongly you have a broken install. Further, even with a mass of 6.6 tons (the lowest-TL NTR--Raptor831, make sure you increase TL as desired, just like any other engine--high-TL NTRs have much better TWR and Isp), you can get a quite crazy amount of deltaV. Of course, it would help to use Balloon Cryo tanks, but even regular Cryo tanks you should have a mass ratio asymptotically reaching 27.77, yielding (without payload) ~30km/sec of dV at 900s Isp. Raptor831: Sweet, thanks! The most up-to-date version of the file is in the second post, although as always it defaults to RftS. There should not have been any significant changes since the one you last used (only swapping over to KM_Gimbal, which probably shouldn't be done for Stockalikes anyway). Tell you what: why don't you create a new thread for "Stockalike RF Engine Patches" and I'll link it? Since I think you just volunteered. You can make the ratios whatever you like...many engines use many different ratios. Even the last sheet you sent me has multiple ratios: KL is 2.3,2.4,2.5, MMH is 1.6, 1.65, or 1.7, AZ is 1.6, HL is 5, 5.5, or 6, UDA is 2.6, UD is 2.1. Interestingly enough, IIRC Bob Braeunig ran the numbers and found an EDS-sized stage, if nuclear, would perform better with LCH4 than with LH2, due to the density and thrust advantage. Obviously for high-dV requirements you'd be better served by LH2, but for medium dV, considering you get a density advantage and that LCH4 is only mildly cryogenic, it begins to look *very* good. The one issue with NTRs, however, that I'm just thinking of: unlike stock engines, which have 30% the TWR they should (roughly), NTRs have about 200%+ the TWR they should, so useRealisticMass=false, for NTRs, is bad news (although it does keep them in line with stock engines when changed for Kerbal dV requirements...). Basically, KSP vastly underforms with chemical, and vastly overperforms with nuclear. (Heh, not even considering the density*Isp advantage--when you include that too...) Elouda: Sounds like basemass was not set to -1 in the MODULE. Do so, and the part's dry mass will not be touched. What do you mean by "right click window on the part itself"? Of course any changes won't get applied to what's in the Editor Parts List; that's a different object (the original prefab part) than what you placed on your craft and changed. However, if behavior changes between RF v5.3 and swamp_ig's changes, you might want to PM him or post on the PP thread. If those configs *do* have basemass=-1, sounds like swamp_ig broke the "override basemass" feature

PP does, it's because swamp_ig had a typo (should be 2.1.4). 2.1.5 is in fact the most recent.

jsimmons: cool!

rbray: still having the RSS problem. I'll try some clean installs today. pingopete (and everyone else): you need to change your ATM config BoulderCo.cfg to this: ACTIVE_TEXTURE_MANAGER_CONFIG { folder = BoulderCo enabled = true OVERRIDES { BoulderCo/Atmosphere/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = false } BoulderCo/CityLights/.* { compress = true mipmaps = true scale = 1 max_size = 0 make_not_readable = true } } }

AB looks right, actually. It might be a bit bright during the day, but it's perfect in twilight/night. I thought the petals actually attached to the trunk (the same place as those wires/guides/actuators).

camlost, those prop engine stats I posted earlier (from dirt_merchant and me) any use?

To expand, as IIRC your earlier post mentions too, there were really two separate Nova (meta-)studies. The first was prior to ABMA's absorption into NASA; it was studying a direct ascent lunar booster, an "in house" competitor to the Army Ballistic Missile Agency's Saturn series. With ABMA's folding into NASA, NASA settled on using Saturn, and also switched to LOR (rather than direct ascent, or EOR-direct ascent). The second was the set of studies (both in-house and from contractors) for larger million-pound-payload boosters. These are more what's thought of as Nova-the-super-booster.

Not not not suggesting/requesting/etc; just clarifying. ModuleRCSFX does fix the problem with Squad's code that prevents RCS on a stack-mounted part from working.

That should work. But you can also set overrides in the module definition; that way you don't have to create a new tank definition. MODULE { name = ModuleFuelTanks volume = 160 type = Default TANK { name = MonoPropellant utilization = 1.25 } TANK { name = XenonGas utilization = 50 } }

Volt, you're not going very fast. Seems about right.

RaccoonTOF: Cool! Yes, I absolutely want any work you've done on RealEngines. And any you plan to do. OtherBarry's not going to get to it for a good bunch of weeks (besides being busy, the Mod Bundler is higher priority) so if you want to look into that and have a chance, you're more than welcome to. With at the very least your values in hand I'll post a new thread for the RE pack, since it really needs its own place for updates/discussion/etc. Zyglrox: I'm including them in RO. One less link to click = 1 less headache for me when users miss clicking it. :]

Still getting the issue where the 2D clouds are completely black....