Gordon Fecyk

Been there, done that, worked around it: Supposedly this was fixed in 1.2, but I haven't seriously tried to reproduce the problem. I can't reproduce the problem anymore. Back in 1.1.3, this seems to be caused by having a not-yet-deployed fairing or engine shroud, deploying said fairing or shroud, then EVAing a kerbal. That kerbal gets duplicated with an invalid part type when they re-board the affected craft. The workaround of saving / loading after deploying the fairing or shroud but before EVAing any kerbals seems to work. --

In my opinion, Kerbal Space Program is growing up. Gone from the confines of early access and having reached two major milestones since, it's discovering the 'real world' of PC and now console gaming. That world is not a pleasant one, and the 'new kid' is attracting unwanted attention. Reminds me of Grade 4 back home. And Grade 8, and Grade 10. And a few other milestones I'd rather forget. The tone was quite different here, because in early access there were very low expectations. Even I, who would gladly lash out at an established developer for not following best current practices on Windows, am holding back something fierce. I genuinely love the premise of KSP, and only the Steam edition makes installing it somewhat sane because Valve is taking care of the workarounds needed to run this game somewhat safely. So I just sit back, and if anyone asks for my professional IT opinion I suggest they get a Steam account and purchase KSP from there. That tone is changing with KSP's popularity expanding. We're attracting the console generation here, and they are used to the quality (ahem) of Call of Duty, Halo, Gears of War, Fallout, and so on with very large amounts of development time behind them. With more YouTube exposure we're also attracting the wretched hive of scum and villainy that is the YouTube Comments Section. And our teenage space sim franchise is learning the hard way that the real world sucks and groups of real people can and will be evil. How our community and developers respond to this will define it for good. It's time to live away from home and make the hard decisions. --

An xkcd What-If section titled, "Jupiter Descending" (Definitely needs more struts.) That linked to a Scott Manley video describing, what was then the most kerbal vehicles he built in KSP. I bought it shortly after 1.0.5, and after asking whether to get it from Squad's store or the Steam store. Months later, Scott built it! --

With an actual craft and an RT-10 booster, this is what I ended up measuring: Craft and sensors at 76 m on launch pad Time Apoapsis (m) Pressure (kPa) Temp (K) 0:01 62732 100.2166 310.66 1:01 62721 100.2174 311.39 2:01 62458 100.2169 306.91 3:01 62200 100.2166 302.74 4:01 62211 100.2175 299.37 5:01 62475 100.2173 304.72 The measured numbers don't always jive with the flight results, but the flight results do say time of day does have an impact. I am surprised Squad bothered to model this! More testing is required, but that's getting off-topic for this challenge. --

Like this? I paused on-rails time warp every hour and used physics warp at these points, then ran through another three hours and used no time warp to be sure. But if my craft files are different (coming from the Steam version) could other things be different as well? --

I just tried this again. I found out that the stock RT-10 Hammer SRB was not changed by RealPlume Stock or another add-on; its file date is unchanged from when I installed the 1.2.0.1586 build. Also the Kerbal 1-5 stock craft in this build seems to have the RT-10 thrust limiters set to 100%. Just took a look at the craft files from my 1.2 and 1.1.3 installations, and noted that the 1.2 version has 100% where the 1.1.3 version has 40%. I'm pretty sure I didn't change the stock craft files in my 1.2 installation. Also, I stuck a barometer on a probe sitting on the launch pad and left it for six game hours, leaving the pressure display turned on. 1000x time warp to six hours later, and the pressure value didn't change over that time. Assuming Kerbin doesn't have seasons because of its zero degree axial tilt, this seems like it wouldn't change ever. Is anyone up for hacking a craft file that suspends a probe on a 10 km launch clamp for a repeat test? Otherwise it doesn't appear time of day would have an impact on fuel economy. I can try again with the SRBs set to 40% thrust and see what happens. Here we go: The solid fuel consumption rate should match this time... I didn't show the resources tab during the ascent... ugh, but I ended up separating the main stage at a much lower altitude this time. This result had 45.29 fuel and 55.36 oxidizer remaining. Apoapsis was 81.258 km and periapsis was 80.269 km. This one had shock heating effects at around 23 km, but nothing that tripped a temperature bar. This one should be fine for a vanilla entry.

I was attempting a vanilla entry. I didn't do anything to the craft itself; this is the stock 1-5 in the 1.2 build. At least I think it is; I'll double-check when I get home later. I've read in this thread that the boosters were thrust-limited on the stock craft. Would RealPlume Stock be messing with the parts? If it's a problem with RealPlume or other visual mods, I'll try a completely unmodded install. Or does time of day really matter as you suggested in the original post, where the sea level air may be ever-so-slightly thinner? I'd be surprised if that was actually modelled in the stock game. In the meantime, if you still want to put the entry in, you could do it as a GOaP entry subject to verification. Though under those rules I could probably save more liquid fuel by using RCS to close my orbit, as others here have suggested. (Added) I reviewed Ediahlil's video entry and noted my solid fuel consumption rate was almost three times that of Ediahlil's. Either I messed with the SRB thrust limiter setting, or a mod I installed did. Let's file my entries under GOaP or outright disqualification until I get back to check. --

[12 FEB 2017] Regarding the wonky thrust limiter settings, this is from the RealPlume Stock Configs thread: Known Issues: Thrust limiting on engines get reset upon install. BEWARE IN THE KSP TUTORIALS Switching to a vessel with an engine as a root part will cause the plume to not show. So it appears this was my culprit. Any vessel loaded with thrust limiting has their limiting reset on load when RP Stock and SmokeScreen are installed. Now I know for future challenges regarding stock craft, tutorials and scenarios. [resume original post] If video entries are acceptable, here are two. I figured after six months of faffing about, this was a challenge I could actually take up. In both of these I relied on the SRBs alone to get started, just setting the throttle to zero until they were about to burn out. This is the same method I use for most of my SRB-assisted launches, where I use the cheap boosters to get to thinner air and let the higher ISP engines take over from there. I then let Jeb do his job of staying prograde, using the throttle to adjust my ascent profile instead of trying to steer. I crashed many a Kerbal X before realizing that the pilot can do a better job than me of steering. The first one (Might be glitched by a bad YouTube upload): LF was 63.32, OX was 77.39, AP was 86.398 km, PE was 80.166 km. No visible shock heating, but mach effects were observed before SRB separation. Midday launch, start of new sandbox game. The second one: LF was 68.27, OX was 83.45, AP was 82.059 km, PE was 80.608 km. Shock heating observed at 28 km, but nothing tripped the temperature sensors. Midday launch; pretty much reverted to launch from first attempt. (Added) I reviewed Ediahlil's video entry and noted my solid fuel consumption rate was almost three times that of Ediahlil's. Either I messed with the SRB thrust limiter setting, or a mod I installed did. Let's file my entries under GOaP or outright disqualification until I get back to check. --

Happening to me as well:

No wonder I couldn't find the setting. Yes, that seems to work well; thanks for the tip. And I can see why a cardiologist would recommend it as a stress reducer. --

How about a "hide this user's posts" option then? --

Were earlier versions signed? I want to see this on the Windows edition as well, for the sake of authenticity and liability. This is becoming a requirement for Windows Store and Mac App Store products anyway, so might as well get into the habit now.

This is from sal_vager's FAQ for this forum section: I've actually had EVA kerbals re-enter a pod they exited only to find a copy of that kerbal hanging on the ladder. I can spin them off, which is a waste of fuel. But it didn't seem to happen if I saved / reloaded before attempting EVA. The engine shroud came into play because I'd often have fuel to spare in a transfer stage, and I'd use that to start a descent burn. I'd then decouple that stage almost right before landing, and the subsequent stage had a shroud that was also decoupled. Just wanted to verify if the behaviour I'm seeing here is from this bug, and if the save / reload before attempting EVA worked around it. I wondered at first if the EVA Follower mod caused this, but then I remembered this didn't happen on craft without fairings or shrouds, and remembered Sal's FAQ. This is from the 1.1.3 build about two weeks before the 1.2 pre-release came out. --

Would using EVA Transfer instead of Kerbal Attachment System work around this? I haven't yet attempted a transfer across biomes, but my reading of EVA Transfer's docs suggests it doesn't actually join two crafts into one. Instead it enables a transfer interface between two crafts while keeping them separate. This way you'd have your drill craft in its separate biome from the ore tank craft. --

This is an easy one: KSP up to the 1.2 pre-release refers to whatever the current directory is when you launch ksp.exe or ksp_64.exe. It doesn't matter where the folder is then, because everything's referred to relative to the current one. If you fiddle with shortcuts to add parameters and mess with Unity's functionality, make sure you fix shortcuts after you move your KSP folder, such that the Start In setting matches where the game is. --

New shaders seem to work unmodified in 1.2.0.1539. Holding up so far. --

I know there are a few Avro Arrow builds out there that would fit the requirements. Any of them still fly in 1.1.3? --

My first space plane was a clone of this plane from Scott Manley's KSP Career Mode tutorial. It's a fairly early career mode plane, but still uses Ramjets to get up to 12 k. It required supersonic flight and high altitude flight researched. I practiced on the "HR-71 Manley" many, many times. Blew up the cockpit on ascent many times due to overheating. Blew up the cockpit many more times on descent; I imagine the sight of a de-capitated space plane diving into the bay north of KSC would've been horrifying to watch. Also stranded the thing in orbit once, running out of oxidizer. Finally learned how to ascend and descend properly. After that, unlocking Aerospikes helped improve things, and finally unlocking Rapiers made the thing laughably easy to get into orbit and back. The "HR-71" still flies about the same in 1.1.3 as it did in 1.0.5. Adding Ferram Aerospace Research made it easier to lift off and orbit, but much harder to land. From there, almost any space plane I've tried used a similar ascent profile as that one. It becomes like falling off a bicycle; you don't really forget how. --

And that's all I have to say. Except, of course, for, Thanks SpannerMonkey for updating this cool mod! --

Thanks, Kasper. Hm, I thought some of the tunes were produced in-house because there weren't official titles for them, things like, "KSP_Construction_1," "KSP_Menu," and such. Kevin MacLeod has to have an ID number for that music somewhere, then. All right, I appreciate this a lot. I'll go ahead and press YouTube for answers. If you want I'll give you the link to the currently-unlisted disputed video, but I'll pick another tune and re-upload it for public viewing when I get home next. Scratch that: I found a different tune and used that in a re-upload. The disputed piece is actually from your composer Victor Machado and in KSP it was simply titled "KSP_MenuAmbience." I flagged the original as 'Private' so Google's support people can see it but the AdRev trolls won't get any ad views from it. --

So... YouTube again. My most recent upload got flagged for using a tune from "AdRev Publishing APM (Publishing)." The tune? KSP's main menu background music. Not the main theme, but the thing that plays after the main theme. I forget if it has a proper name. Oddly, I used that tune a few episodes back without complaint. Just in case, I figured I should ask: Squad, is "AdRev Publishing" you? I marked said video as Unlisted and tried to dispute the claim, using Squad's FAQ for support. YT's dispute form broke saying the video didn't have a claim on it. Um... that's a problem for YouTube anyway. But I wanted to make sure using all of the tunes from KSP in a KSP video was kosher per Squad's copyright FAQ. --

Is it just a matter of replacing the part wildcard with the name of a specific part to disable autostrutting for just that part? I'm curious if this also would turn off wheel blocking for a given wheel part. Just looking for some short term hacks until 1.2. --

Is there a short-term hack to work around the wheel blocking? Back in 1.0.5 I managed to use larger wheels to make a somewhat more rugged rover with the RoveMate that still fit in the 2.5 m service bay. That worked in 1.1 pre-release and even went faster than the original, but not in 1.1.3. Yes, I'm breaking the rules by clipping the suspension into the probe body, but if someone were to actually engineer this they'd cut openings into the casing to fit the suspension. The RoveMate has no better logic than the OKTO and no reaction wheels, so it kind-of makes sense that there'd be an OKTO motherboard and a lot of empty space in that package. My understanding is wheel blocking won't happen in 1.2. Just looking for a short term hack until then.

Tilting the solar system like I'm seeing, instead of tilting the planets, offers a decent workaround, actually. I just didn't expect the terrain and surface of SSRSS Earth to be shifted such that Florida and Senegal were on the logical equator at the same time. I still have to launch at a different inclination to match the Moon or any other SSRSS body, so there's still a challenge to be had. Managed to do a return mission to the SSRSS Moon with my modified Kerbal-X on the first try, even if I had less fuel at Lunar orbit insertion. --

I deal with this kind of tech daily. IT wonks call it 'deduplication.' I saw it first on Backup Exec for disk-based backups and later saw it on Windows Server 2012 and 2012 R2 for normal file volumes. Only these go beyond deduplicating files: They deduplicate file clusters on disk, doing 'block deduplication.' It's pretty funny seeing a file with these attributes: Size 419 KB, Size on Disk: 4 KB. You can bet everyone offering cloud storage today is using some form of block deduplication. I imagine caching servers on Mars would save a ton of bandwidth and storage doing this when syncing with Earth servers, and the same thing would happen in reverse when Martian sites and services become popular back home... come to think of it, Backup Exec already does this for offsite copies of deduplication stores, calling it "optimized deduplication." --