NathanKell

Ok! I wish you luck then!

@sackfalte that sounds like an install issue then. Might some other mod besides RSS/RO be modifying your Remote Tech settings? Can you post a complete modlist and your GameData/ModuleManager.ConfigCache file? (you will need to zip it first). Your log would also help.

Before Sprite 7 has even arrived at Jupiter we take a risk and send another Jupiter mission. This one is much heavier, and needs the power of hydrolox to give the payload the 6.5km/sec ejection burn it needs. With that extra mass we can make a combined atmospheric probe and orbiter, not just a small flyby probe as Sprite 7 is. The mission is given the name Sylph 2. Sylph 2 is the second in a new line of "second generation" probes, like the Faerie line; Sylph 1 is a Venus lander and has finished integration, but will launch later. Note that the final image is from a few months later.

For that kind of reentry, just imagine a space shuttle reentry like this: Except tilted up even more so your angle of attack is about 90 degrees. For attached/detached: sure, here's a pic: In game it's like that; the shock angle is broadly similar for all detached shocks, but for attached ones varies heavily by mach number and part taper.

@Shadowmage sure! Note you may have to call SetConfiguration for it to update after you change scale.

@oktav I'm not terribly familiar with the yaml, only the resultant cfg code. However, you might be interested in the new generic TF config creator I pushed to the RO repo last ngiht. It drastically lowers the amount of information you need to set for each config. Example: https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/TF_LMDE.cfg As you can see, it takes only a minimum of 3 lines (burn time, reliability at start, reliability at end) to configure an engine. The script creates sensible values from those.

There's a thread in the Spacecraft Exchange for RSS Lvs, that might be a good place?

@Shadowmage you can use the stuff I created for tweakscale interaction, I think, just set ModuleEngineConfigs.scale to the number of engines.

@Rune excellent points. The thing with engines is actually a bug in the aero model. The aero model can't tell whether a part is tapered like a cone or like a funnel, all it knows is the taper angle. So engines are very streamlined. >.> That means that they don't create a detached shock (the aero model says "not blunt") when they are the frontmost part and so they get higher shock temps.

@sackfalte RP-0 is meant to be played only with the mods it supports. In particular it does *not* support any contract packs, so it's no surprise the contracts are not correct for it. (All comms devices in RO/RP-0 are designed to mimic real-world use, where the probe has a comparatively small antenna/dish and relies upon massive ground stations for communications with home. There are a few larger-than-real-life dish parts, but they're few and far between, and not costed for RP-0 IIRC)

@sackfalte if you do not have lots of multicolored dots over Earth in map view (the various groundstations) then you have an install issue. If you do, then the FAQ should be correct. You can test it in sandbox by sending an octo2 (Early Controllable Core) with a single Comm16 to the moon. Extend the antenna once you leave the atmosphere, and if you still have contact near the moon, everything is working as designed.

@plague006 thanks! Checks are failing, but I don't know if that's KS spillover or something wrong in the pull.

@Hotaru In that case the 'forward-most' part becomes the belly, which is plenty blunt. Forward-most is in relation to the airstream.

Please see the RP-0 FAQ https://github.com/KSP-RO/RP-0/wiki/FAQ The stated range in the description is correct. It's the range you get talking to Earth's DSN. The range shown in the tooltip is the "base" range if you will, it doesn't take the other node into account.

You don't need to make the nose as blunt as possible, just blunt enough to detach the shockwave at the speed by which it needs to be detached (or you melt).

So, first off as you could see from the shots, both those stages already have four engines. Second, I could add more, but that would increase the stage dry mass significantly and thus lower the delta V it can provide. In real life upper stages burn for a very long time indeed, and this launcher actually has a shorter upper stage burn time than Saturn V (the S-II burned for 6m30s and the S-IVB for just shy of 8 minutes, so a minute longer, total, than this). That's nothing compared to the EELVs with their 10-20 minute upper stage burn times on a single upper stage (SEC Centaur V or 5m DCSS). Once you're going 3km/sec or so gravity losses matter much less, so you can afford long burn times. While this LV is not optimized for LEO (where a shorter burn time would be better, say something like 2m45 + 4-5min), it's not used for LEO missions either, so that's no biggie. And once you're in orbit, who cares if your TLI burn takes 6-7 minutes?

@MatterBeam thanks! Here's a picture from Sylph 2 being integrated in the VAB, prior to rollout. You'll see its mission soon, as well as a crewed lunar orbital with actual pictures.

Yeah, the hoops in the RP-0 contracts may no longer be required; they work, so I ain't touchin' em.

@MatterBeam I launched direct to Jupiter when the window was available; only when fine-tuning my perijove did I notice that gravity assist available. I will later be sending a Voyager-alike out Jupiter-Saturn-etc. That said, in this playthrough I've mostly been avoiding assists entirely, doing direct transfers and captures Indeed I plan to do a direct transfer-direct capture at Mercury before too long. ------ After the success of Dalmatian 5 we move to even better things, made possible by the power of hydrolox! The Eucalyptus A stage is a drop-in replacement for Dogwood B and gives us about 50% more tonnage to play with for lunar missions. With it we perform a lunar orbital mission (Dalmatian 6) although only fragmentary photography remains, and we prepare a second Jupiter mission. Nearer home we launch Dalmatian 7, and an 8-and-9 combination mission, to train the new intakes to the astronaut program. Eucalyptus A upper stage in action Placing the Dalmatian 6 lunar orbit spacecraft into orbit. The additional TLI capacity of the Eucalyptus stage allows for a lunar orbital mission (~2km/sec of delta V aboard Dalmatian, and two weeks' supplies) rather than the 4/5 missions which only had a single km/sec or so and a week of supplies. Dalmatian 8 and 9 double-capsule rendezvous

Try uninstalling mods that are not required by RP-0/RO/RSS.

Always happy to (positively) surprise.

@FullMetalMachinist au contraire, I did write attached/detached shockwaves into the thermo model. (The forward most part creates a cone, with angle equal to the shockwave angle--and it will be attached or detached based on the taper of the part, and the temperature behind the shockwave will vary. If a part is not inside that cone, it creates its own cone, and so forth.)

Settings->Turn it off.

LaunchSites.cfg is only used by KSCSwitcher. You can still get KSCSwitcher from Github.

Ok, fine. Against my better judgment, since lightening the tone of this thread doesn't seem to be helping (also, do check the spelling Starwaster used, it ain't that): As a modder, I will see how stable any official x64 builds are and, if they are stable, I will of course unlock my mods for them. And happily use them. I challenge anyone to find *any* of the lockers who would not do that. Unless you mean to insinuate that the purpose of locking is anything other than preventing bugginess and can't-be-fixed support requests. As a dev, I of course make every effort to make KSP stable, but I am not in a position (in more ways than one) to comment on the stability of a platform that isn't even through QA yet. Frankly, I don't much see the point of this thread. It was never a problem of lack of reports of bugs that made x64 impossible to fix; it was that they were not fixable by Squad, let alone by modders. Nor will continuing to use a version of KSP that is unstable do anything for you other than giving you more bad behavior and more crashes...and more grist for forum conflict.