Fwiffo

@Galileo Thanks for gallantly picking up this mod! I did a quick code-compare to my baseline from when I did the last round of fixes for KSP<=1.1.3 and 1.2.x. Noticed a couple minor things and had some questions / comments: Is the double "Continued" in string big_rattles = "ShipEffectsContinuedContinued/Sounds/big_rattles"; intentional? I'm concerned that prevents the rattles sound from being played? Nifty new sounds! Did you swap them out due to any sort of copyright concerns etc, or did you just want to spice things up a bit with clips you liked better? The original vibrations.wav had a left--right panning in it, any reason you didn't carry forward the panning effect? Didn't like it, or didn't notice it? It would be awesome if the AssemblyVersion attribute in AssemblyInfo.cs could be maintained. I know this is a nitpick and a lot of modders don't do this. But for us Windows users at least, it helps when we want to quickly (and definitively) check which version of the DLL is present (without risk of relying on a potentially-mismatched, seperate .version textfile). If the suggestion catches your interest, I'm happy to provide source code and binary for a very simple one-liner EXE which can do this automatically every time you hit the Visual Studio build button. Might be nice to credit CoriW (and even myself if you're feeling generous!) somewhere in the readme, buried in the changelog, wherever, for the work he did maintaining this in the past. (No biggie on my part; I didn't do much except a few recompiles and some CKAN mangement) ps. For others curious, further audio changes I noticed include: Made atmosphere sound quieter and less pronounced (and less windy - though personally I miss the wind); new big_rattles wav (sounds "less like a roller coaster going up an incline" and "more like a mix of billiard balls and big metal plate wobbling"; split up dock and undock into separate clips; new rumble sound ("less like a campfire"); new small_rattles ("more rattly; less like typewriter"); tweaked thump_low. CFG defaults tweaked to make thump volume louder, stress volume quieter, and ResistMultiplier increased by 75% to ease effects in earlier. To be clear I'm not criticizing at all - quite the contrary, I'm grateful somebody went ahead and took over this awesome mod!

Might be nice if CKAN recognized this error and gave you a "Download it anyway, I know what I'm doing" option. Or had a switch to ignore SSL errors.

@Ruedii Sorry to hear, hope you can solve it. My own issues are due to the spacedock.info cert expiring.

I ran into this problem too, myself. Failed to download "https://spacedock.info/mod/219/StageRecovery/download/1.7.2" - error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Out of curiosity is there a way to temporarily tell CKAN to ignore this error accept all SSL certificates? I thought the there was some kind of flag you could pass to the .Net libraries. I tried installing the expired SpaceDock certificate to my Windows certificate store but not sure that actually did anything. Appended EDIT: FYI 1.22.3 behaved nicely when the SSL error came up, but I think (?) there might be a regression as all I did was drop in the new CKAN version (1.22.5) and now I get a Kraken exception right after it hits the SSL error :-S.

Thanks @HerrCrazi for corroborating. Here's the craft file I was working with that consistently reproduces one of the issues ("all struts get deleted on placement"). If you have time, could you see if it reproduces that problem for you, too? Load the craft. Try placing a strut anywhere on the ship. You can't. To resolve, delete the strut pair near the top of the craft, highlighted in green in this screenshot: Now you can place struts again. Trying to recreate the strut you just deleted demonstrates the "this strut gets deleted on placement" issue. I was also able to intermittently reproduce the "part you are connecting a strut to gets picked up" issue on this craft (once by deleting several parts from the craft and playing with struts), but haven't found a consistent set of steps to trigger it. I know this isn't a nice, small demonstrator craft - but it should be possible for someone to distill it down to a sample with fewer parts. I didn't, because I'm trying to spend more of my time playing and less debugging! (Seems like every time I fire up Kerbal lately I wind up spending more time tracking down and isolating problems than actually playing the game). The "inconsistent symmetry" issue is fairly trivial to reproduce by creating a simple craft like the one in the screenshot from my OP. The Undo issue is likewise trivial to reproduce.

Can someone tell me definitively how struts and fairings in the stock game are supposed to interact? I recently found myself fighting against KSP 1.3.1 to keep my struts where I want them. The game seems to treat these interactions inconsistently depending on the order you place/edit parts, whether you use Undo, etc. Some scenarios I've observed on a recent craft I was constructing: Connecting struts before fairings built Works fine Connecting struts through fairings after they are built Works in the editor most of the time, except: Occasional inconsistency within symmetry groups e.g. Sometimes when connecting the end of a strut to a surface inside a fairing, even though the "seed" strut I'm placing goes right through the fairing, I notice the mirrored strut terminates prematurely when it hits the fairing surface. The ship in question is symmetric across the relevant planes so there's no good reason I can see for the behavior to be inconsistent. Manually placing the struts individually at the same locations, without using symmetry, works fine. Trying to strut from a part inside one fairing, to a part inside a different fairing, usually doesn't work. Varying behavior, either: The game simply "deletes" the strut when you try and place it Or the editor "picks up" the part you are trying to pin the end of the strut to, detaching that part (and its children) from your craft (very annoying). Or it works in one direction but not the other (e.g. see above spoiler). Not sure if this is intentional. If so, it's a pretty naive attempt to prevent prevent the player from doing this as there are many ways around it. I've noticed cases where if you've already set up a situation like this (e.g. by running the strut before the fairing was built) then it totally screws up your ability to place struts anywhere on your craft afterward. All new placements start exhibiting one of the two aberrant behaviors above (strut is immediately deleted, or picks up target part instead of pinning strut). When I started seeing this, it seemed consistently reproducible. Reloading the game / craft didn't help. You need to delete the offending strut(s) to make new struts work properly again. Disconnecting and reconnecting a fairing base without deleting / rebuilding the fairing Doesn't seem to affect struts that pass through it Undo / Redo DISASTROUS results - seems to trigger "regeneration" of all struts in a manner that makes them consistently end at the first fairing surface they hit. Launching from VAB/SPH Maintains strut connections / orientations from VAB? (I know older versions sometimes reoriented your struts sending them flying out at weird angles but I think they fixed this one). Loading craft in Editor Maintains the saved strut connections (no "regeneration" trigger). Loading / Quickloading craft in flight Maintains the strut connections the way they were on your craft when you saved (I think). Much of the red behavior feels buggy and ill defined. If it's the intent that struts aren't allowed to pass through fairings, then all of the above user actions (except loading a craft in flight) should act the way the Undo button does - i.e. trigger strut "regeneration" and check for collisions, truncating them at the first surface they hit. Otherwise, the Undo thing really needs to be fixed, as well as the edge cases above. I'd be OK with defining different behavior for struts placed before / after fairings are built (this would seem to offer the player the most flexibility as to whether they want to strut through a fairing, or to the surface of one) but then the game shouldn't go mucking around with previously placed struts which I connected before I built my fairings. If it does want to re-evaluate my preexisting struts for new collisions (e.g. when placing a new part that may intersect the strut), then maybe it ought to keep track of which collisions existed before the operation began so those can continue to be ignored when the operation completes (particularly when less straightforward actions re-trigger said analysis). I think that would result in a more consistent and predicable player experience, where KSP wouldn't shoot you in the foot later by "helpfully" deciding on a whim to rejig your struts. I don't know if this behavior is new to 1.3.1. IIRC from the changelogs it looked like Squad was doing some work with struts in 1.3.0 and 1.3.1. I generally avoided stock fairings and tended to use Procedural Fairings instead (which seemed to behave in a more deterministic manner). But when the new release dropped, I decided to try playing without mods for a while (for unrelated reasons: to see if mods or the stock game was responsible for some performance issues I start to see after doing lots of launch / reverts in a row). The only mod I had loaded when I investigated all this was Kerbal Engineer Redux (KER) and I'm pretty convinced it's not causing the problems. I am not submitting a formal bug report, I just want to know how things are supposed to work and whether others are seeing similar behavior. (If so, I'd love it if a QA person from Squad could pick this up and run with it from here. Feel free to move this topic to another forum if appropriate).

Nope, it's not my mod, I just do random mod fixes here and there when I have the time and happen to need to fix something for myself. By all means, please go ahead! Let me know if you need anything from me.

Squad - listen up - if you want to kick your revenues up to higher orbit and breath some fresh excitement into your title, consider integrating VR support. I tried out Vivero's Kerbal-VR mod and even in its rough, jittery, demo-only form, being right there standing beside (and sitting inside) my rocket was breathtaking. It conveyed a sense of scale impossible to achieve viewing the Kerbal world through the rectangular little window of my flatscreen monitor. Now imagine grabbing rocket parts off the shelf and slapping them together with your bare hands. Science fiction? Nope - you can do stuff like this with Leap Motion's Kinect-like developer kit (which conveniently mounts to a Vive / Rift). Watch this video and imagine that's a StretchyTank grasped between their fingers. Imagine reaching out to your RPM displays and flicking buttons with your fingers, like a real Kerbonaut. It's been done before. The folks at FlyInside did a great job of bringing VR support to the popular X-Plane series. I challenge you to do better!

Maybe we should stick this thing up on GitHub somewhere so all our edits get consolidated into one, live, always-up-to-date copy...?

Nice article; thanks! Love the ASCII art, Glyph Kerman would be proud.

Hey @Padishar, just wondering, any chance yet to look at the issue I posted around Jan 7? Need any more info? (I did confirm changing the root parts to match doesn't help). I've noticed some edge cases where KER doesn't present correct results but am finding it a challenge to reproduce them consistently. Hoping that test case I provided helps narrow it down.

Yes. This happens to me most of the time. I thought it started before I upgraded to 1.2, but maybe it was after. When it happens, the blue shape outline thing also doesn't show up. I've been using the Interstage Fairing Adapter instead, as it provides other tweakables (Base, Top, Height, Extra Height) which don't break and can often accomplish the job. I also was able to fix the issue at least once by grabbing my whole ship, moving it over, then hitting Ctrl+Z. The Undo action made the base ring work properly again for a while (even after a KSP reboot?!). But it doesn't always fix it. Sometimes it causes the missing tweakables to get stuck shown instead, and they don't actually do anything. I'm going to try the build by @KortexM. Any chance on mainlining his fixes? For what it's worth, here's a screenshot:

Thanks everyone for chiming in. I've been away from the forums for a bit but was amazed at how much attention my little post got, and want to take the opportunity to respond. Point taken. Yes, I was harsh and critical. I just called it like I saw it. It kind of smelled like a bolt-on to make things a little easier for a programmer (or at least, reduce code touchpoints) at the cost of making life a little more annoying for some of their users. I could have been more tactful. But hey, it did spark some discussion. I'll take a free potshot from anyone offended. I love the community here, and the fact that people jumped in to call me out and defend the guy who, granted, was just trying to make things better. There's the free potshot :-). I get that, and I appreciate you providing some background. I was just circumspect of the rationale that new files and hashing had to be introduced in order to achieve the performance boost. Seems like it would be more polished (at least from a user perspective) to go with something along the lines of this: It keeps the pertinent information in the SFS where it arguably belongs, and if implemented correctly, has the handy side-effect of being slightly faster by eliminating the need to read all the bytes of the file to compute a hash. Granted, it doesn't do much for legacy savefiles (and the existing upgrade mechanism would be of limited help there since IIRC it doesn't kick in until the player actually loads the savegame). Despite accusations to the contrary, I do have some humble experience in this field, and can venture an educated guess (rife with assumptions!) as to how it wound up being implemented the way it did. e.g. New dev comes on board, doesn't want to dive too deep into existing, working spaghetti code around the savefile format, maybe hits some other snags, comes up with this hack approach instead which only requires wrapping a couple functions. Time pressure, testing constraints, other priority issues to get to, yadda, yadda. I concede it has merits - e.g. quick, easy and low-risk to implement; works right away on existing save files; no backward compatibility concerns or impact to third-party utilities, encapsulates changes and keeps them proximate to the Load dialog. But with some thought and care I'd bet the same ends could have been achieved minus the extra user-facing artifacts. I realize most users don't mind or care; fair enough. But some of us do. That's why I spoke up. Sorry if I hurt someone's feelings - if the person who coded it is here I'd be happy to apologize. I don't mean to belittle their efforts, and I'm grateful that they tackled the job of massively speeding up the lethargic load dialog. Exactly, that's what I suggested above and in the OP. I'm not advocating putting the hash in the SFS file, I'm suggesting it be eliminated altogether. (I can see where you're going about stuffing the file with a partial-coverage hash to detect dirty data, if you start by limiting yourself to making code changes only on the Load dialog side of things. But it just seems so much simpler to write out the needed information at the time of save). Ah, Snark, always there with calming words of wisdom. I hear what you're saying, and it's true: not working at Squad I'm not privy to all the factors. As someone who's released a lot of well-groomed code, I know you have fairly high standards in terms of polish and attention to detail. I might be overly sensitive as I’ve seen how easy it is to let a piece of software fall to patchwork when you start to "work around" existing code for fear of treading into it. I love KSP and don't want to see that happen. I hope the devs can appreciate my passion here. I know they're really invested in the game (and that's part of what makes KSP awesome). There were very likely practical challenges opaque to me. And I'm sure many folks will say I'm nitpicking. And maybe my inferences are ill-justified. But none of that changes the fact the file clutter ain't pretty. As someone who takes so much care in the pedigree of work they distribute, tell me you didn’t cringe just a little bit when you saw it? That is a fantastic suggestion, and this compromise would 100% alleviate my complaints. Should I add it as a low priority enhancement request on the bugtracker?

Thanks! Oh how lovely it would be if his enhancements could make it into mainline and from there to CKAN ;-).

Is 1.1.2.8p still the latest one which I should be using?

Yeah sorry about that. I was trying different things to fix it and forgot to switch the root part back before uploading one of the files. If you make the crew cabin the root, it doesn't seem to change anything. That's why I apologized for not uploading the best samples - there might be other subtle differences, but I don't think anything that explains the staging differences. I've seen the problem here and there, just haven't managed to capture a better, more isolated "before/after" reproduction of it on a simple craft (since I don't tend to notice right away). If I turn on All Stages, I just see a bunch of 0m/s ones: It's also on my todo list to investigate whether the KSP Undo feature is a potential trigger for this. EDIT: Also, I noticed if I drag the engine up into the next stage (4) a bunch of the stages come back. Note sure if that helps you.

I'm using 1.1.2.8p with KSP 1.2.1, and noticed it occasionally gets confused about my staging. I haven't tracked down exactly how to reproduce and correct the problem yet, but here's an example of two craft which are virtually identical. One shows the correct stages / delta-V, the other doesn't. I know there's a docking port, but I seem to get the same behavior if I replace that with a decoupler with crossfeed enabled - so I doubt the docking port has any bearing on the issue. I think it has something to do with the order in which I attach my parts. i.e. I suspect you can build two identical craft, but if you connect the parts in a different order in one of them it will cause the problem. I know these aren't the best samples, but I'm hoping someone can have a closer look and help track down this annoying problem. (If it does turn out to be something I'm doing wrong, then you should be able to show me how to modify MunBasey1b to yield the same staging info as MunBasey1)

I noticed this in the 1.2.2 changelog: +++LoadGameDialog When a game is saved it now creates an associated metadata file - called .loadmeta alongside the .sfs. This file contains a hash of the sfs save. When the loadgame dialog opens it will compare the hash in the .loadmeta file with the hash of the savegame, and if so it will use the data in the .loadmeta file for the load dialog details instead of parsing the whole save file. Ew. Gross. Really? You take my nice clean Saves directory and clutter it up with a bunch of garbage? Can I suggest the developers eliminate this disgusting, amateur hack and put the cached information in the sfs files themselves, near the beginning of the file? The dialog could just read up to the end of the cached data. That would provide the same speedup, without littering the user's folder with files that are meaningless to them. It should be trivial to do this in a way that maintains compatibility with old/new saves. That's my friendly and opinionated two cents.

So I completed a "Rendezvous" contract in a new savegame today, only to realize (rather, remember) with dismay that my kerbals couldn't wave to each other through the pod windows. I installed this mod, removed the "noload" suffix from DisableTransparencyInEditor.cfg, and edited my savegame to add this module to my two stock Mk1 Command Pods that were in flight: MODULE { name = JSIAdvTransparentPod transparentPodSetting = ON } But the windows still weren't seethrough. Then I patched the module into my stock mk1Pod.cfg file, with great results! Hey, I know that guy! One side effect; it makes more than just the windows transparent: The skin flickers in and out depending on camera angle. Has anyone made any magic beans to improve the look of stock parts using this mod?

Thanks kindly for the QuickStart EVE workaround!

Thanks @Kesa that was super helpful for me today! I started a new savegame and this cleared up my misconception that I had to spend a bunch of credits I don't have yet to upgrade my tracking station in order to complete my mission.

Yeah the same thing happened to me not long ago in 1.2.1. Never did find out why it temporarily didn't work or what fixed it.

Seems to work fine under it for me.

Picked up a 3Dconnexion mouse for modeling activities, and like you guys I was happily surprised to see it also works in KSP. Only problem is it's WAY too fast and twitchy. Even with the driver sensitivity setting on lowest. Has anyone had any luck slowing it down to a more reasonable speed? I tried the settings here but they didn't help. e.g. VAB_CAMERA_ORBIT_SENS only seems to apply to rotation using the right mouse drag (not to motions of the 3D mouse cap, and not to keyboard left/right/up/down "radial" camera movements). Would also love to know if there's a way to make the cap rotate the camera radially around my craft (like the keyboard arrows do) instead of yawing the camera. EDIT - Sorted it out in settings.cfg: SPACENAV_CAMERA_SENS_ROT = 6 // was 30 SPACENAV_CAMERA_SENS_LIN = 4 // was 20 SPACENAV_CAMERA_SHARPNESS_LIN = 8 SPACENAV_CAMERA_SHARPNESS_ROT = 10 Not sure what "sharpness" means (some kind of resolution akin to mouse dpi?). This thing is really helpful for precisely zooming right up to the offset gizmo to make super fine 0.001m adjustments.

Love this mod. Sorry if this has been asked before, but is there any way to adjust the line spacing between objectives, without mucking up anything else? See screenshot below.