MaxRebo

You don't have to make install into the final directory. On Windows, I usually make install somewhere else first to verify the results before manually copying them to the actual install location. If you want to install directly into your main KSP instance no matter what, then put the whole path in quotation marks like so: make KSPDIR="C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program" install Also note that the usual Windows backslashes \ became normal slashes /. Backslashes are special characters in Unix-derived shells, so you'd have to "escape" them by putting double backslashes \\. Much easier to just go with Unix path separators (the normal slashes) instead, which Microsoft has always supported because not doing so would have horribly broken the C runtime API. Single ' or double " quotes do have slightly different semantics, but they'll do the same thing in your case. You associated correctly. The reason your install is in Program Files (x86) is because Steam is a 32bit application. Steam doesn't try to find out what architecture its games run on, so everything lands in the same steamapps folders no matter what (unless you move them somewhere explicitly). Then there's also the fact that KSP has both 32bit and 64bit version packaged in the same install dir, in which case Windows convention apparently dictates that the 32bit version should take precedence when deciding which Program Files folder to install to. So Steam actually did the right thing by accident. And yes, it really does seem like KSP is attracting a lot of players that hold or are about to earn some kind of IT degree...

Ha, I'm indeed a fan of both (I own all 6 OST albums), although I didn't yet come up with a truly fitting playlist for the soundtrack editor, so I'm not really using it right now. Unfortunately, I'm currently not really in a position to commit myself to a mod. With BROKE being in this not-quite-so-stable state right now it would probably also require continued support to make sure you can get through the series without issues. Sorry...

I'm deliberately holding off upgrading to 1.1.3, so I wouldn't know. Judging from the vast number of mods that broke with the update I wouldn't be surprised if BROKE was affected as well. However, disappearing BROKE UI and exception spam when "Warp to Next Morning" were known (and 100% reproducible) behavior in BROKE Beta 5 under 1.1.2. From what I've seen of the API, that would definitely be possible. However, you'd have to code the Funding Modifiers yourself (or bribe someone to do it for you...) BROKE is mainly a framework after all. Kindof like Kopernicus, it doesn't do much by itself other than the few barebones FMs it ships with.

I realized a little later that this actually happened on an install that had Beta 4 running, which I was about to migrate a save from. It might well be that part of this bug has been fixed with the Beta 5 FMs through whatever strange side effect. As far as I can tell, it did not happen even once with my Beta 5 setup, and just now I "failed" repeatedly trying to cause it using KCT time warp. So, no need to question your sanity over this anymore

Strange, I've been trying this many, many times just to be sure it doesn't before I post, and to date it hasn't done that even once for me... well what do you know, just now it did. Is this dependent on the moon phase or something? I'm liking those a lot. If I wasn't so short on time that I'd rather spend it playing KSP than developing for it, I'd definitely try and come up with a barebones implementation for the science and maintenance FMs. Selfish of me, I know especially since Magico is probably at least as busy if not more...

The problem with this is that they're still no true quantum struts, i.e. end points must have a clear line of sight and it's next to impossible to get them to attach to directly adjecent parts if there's not at least a tiny little bit of empty space in between. I guess just strutting the outer-hull corners of each outer part together (to get visuals similar to hull plate riveting on real life ships) would be worth a try, but I believe the dampening must be directed roughly towards the root part (as in following the part hierarchy tree - not necessarily physically pointing towards it) for maximum efficiency.

I'm getting this exact same behavior with all craft made of very heavy parts, even if there's not that many of them. I'm 99% certain it's a stock/Unity physics bug that is actually unrelated to the exceptions you're seeing there (as there's usually no exceptions when it happens to me - I've also had this happen with non-B9 parts as long as they're heavy enough). Depending on the context of your craft, you can work around the issue by introducing as many dampening joints between the heaviest parts as you can (i.e. struts). Probably not an option with that pretty nice looking ship of yours there as it's too "solid" to allow for that in a natural way. Things you can try is decreasing max physics delta in the settings or maybe even uninstalling KJR since it might be messing with the physics in an unexpected way (or alternatively, cranking up KJR's dampeners to insane levels). There's also the ever so slight chance this will go away by itself in 1.1.3, as they're addressing the numerical stability issues of the physics integrator to get rid of the decaying orbits. If we're really lucky that will take care of this phenomenon too.

Ha, same here

@grosser_Salat I was not sure of this before, but just now it happened to me too so I took this opportunity and actually tried: If you really want to recover to storage no matter what, quicksave before you hit the VAB or SPH recover button. If the vessel ends up above the roof then just quickload and recover again. It usually spawns below the ceiling after 2 to 3 tries. Even with lots of mods driving up loading times between screens, this procedure should still be a lot faster than editing the save. (you did enable quickloading... right? )

It happens. Nothing much you can do about it short of editing your save file to translate them down below ceiling level - which is very complex and highly error-prone and I'd strongly advise against it if you're not a seasoned KSP player experienced at messing with mod internals. Just scrap the recovered ships and rebuild them. Scrapping a recovered vehicle gives you back full part value + resources left in the various tanks, and scrapped parts go in the inventory and greatly reduce the time necessary to rebuild the ships. Magico has promised to address the issue in a future update.

Just a small heads-up, in case you didn't find the time working on this yet and/or didn't find out yourself by now: The problem only manifests if you use the "Warp to Next Morning" button. Specifically, the faux quarters/years appear when KSP starts slowing down the time warp from >=1000x. If the next morning is close enough that only 100x warp or less is being applied, then nothing bad happens. Other means of timewarping (KAC, KCT, manual) don't cause this no matter at what factor they're being applied. Avoiding "Warp to Next Morning" like the plague, Beta 5 works absolutely flawlessly.

Yeah, take your time. We're well aware this is still more or less WIP, and I went back to "daily" funding with beta 4 for now, so there is really no pressing need from my side. Not that there could be one that would out-prioritize real life anyway. RL 1st always!

@magico13 The issue doesn't seem to be resolved (entirely). When I resumed where I left off last friday, at first it seemed like everything was working as expected now. I only got the "New Day!" entry in the log when timewarping to next morning once. Then I timewarped to next morning a second time, and BAM - the faux new quarter + new year entries were there again (day 421 is neither a new quarter nor a new year, right?). In addition, I now also get an exception that kills the BROKE UI and makes it impossible to return to the main menu (loading a save works though and that seems to reset the effects of the exception). Here's the relevant part of the log: I disabled the reputation funding and space hotel FMs, and that didn't change anything. Neither did removing them altogether. Happens with just quarterly funding and payroll. Are you sure outdated FMs were the underlying problem? /update It appears setting payment to full-auto so that the BROKE window never pops up unless opened manually seems to completely get rid of this behavior... /update2 Finally hit my first New Years (outside of time acceleration no less). Payment on full-auto did not help this time. Getting the above exception plus NRE spam with full GUI lockup, i.e. Alt-F4 being the only way to get things under control again. Relevant part of the log: /update3 I narrowed it down to the ArgumentNullException being caused by Payroll, and the NREs by Quarterly Funding. Disabling those makes New Years go smoothly. But with no moneyz being passed around

Nice! No hurries though. I'm dealing with it for now by scaling down the government and payroll FM parameters to make more sense for a daily billing, and in a way that's kinda nice too.

I don't think I noticed that before, so I think it's the Beta 4 update that suddenly started to present me with [LOG 15:37:28.487] 5/27/2016 4:37:29 PM,BROKE,DEBUG: New Day! Year 1, Day 420 - 3h, 23m, 37s [LOG 15:37:28.487] 5/27/2016 4:37:29 PM,BROKE,DEBUG: New Quarter! Year 1, Day 420 - 3h, 23m, 37s [LOG 15:37:28.487] 5/27/2016 4:37:29 PM,BROKE,DEBUG: New Year! Year 1, Day 420 - 3h, 23m, 37s almost daily when timewarping very fast at the KSC, making me swim in more Kerbucks than I could ever spend in a whole full career in a matter of days. Actual billing is supposed to happen quarterly, right? At least that's what happened for me with Beta 3, even though all three messages popped up every time rather than just the appropriate one. I looked at the commits and I'm aware you didn't make any changes since Beta 3 that could cause something even remotely similar to this behavior, but I swear it never happened before today's update - it's not like timewarping a few days while waiting for the KCT build queue is something I only started doing today. What could be going on here?

I could be wrong, but given that SCANsat creates the maps on-the-fly every game load, I'd say it's very likely they will update automagically. I think the mod only stores map coverage in a save, not actual data. /edit or did you mean deformable / in-game changing terrain? Not that I'm aware of any mod that does that, but I'd say in such a situation all bets are off...

@silvermistshadow People have been doing that and similar stuff by building the hull out of structural wing elements and/or procedural wings. Far from ideal (and ridiculously fiddly), but it's possible.

@ferram4Thank you for taking a look. The actual plane this was made from is somewhat different; for one it wasn't actually meant to leave the atmosphere (only a few ballistic dips over 20km to get some early-mid career missions). The many wing parts near the middle in particular are there to aesthetically accommodate a few parts I removed to make it just stock + B9 pWings (cosmetics over functionality...), and the B9 engines I actually used aren't nearly as overpowered as the Whiplashes for the task. This was just the easiest plane to stock-ify. I get no bad oscillation with 3 quantum struts per wing, which is good enough for me. I'll take a look at the wing mass anyway; I left it rather high to make the wings less susceptible to aerodynamic failure which inevitably is a thing at those speeds, but it sure seems like a worthwhile thing to tweak, so thanks for that insight.

@ferram4Sure, here it is (stock + B9 pWings) For some reason, when I double-checked the behavior under Kindelberger, the oscillations are almost just as bad as in Kleinhans. It might have had something to do with me having forgotten to activate the AoA flight assistant when I tested with Kleinhans. Strange how problems start to disappear when you're forced to look at them in-depth... anyway, at the very least you'll be able to say if those oscillations are to be expected, at least under KSP's wonky physics integrator and no KJR, when subjecting that wing shape to supersonic speeds. /edit yep, I'm now almost convinced the problem was me derping out all along.

@ferram4 I think I might have found my issue. Preparing one of the planes for you by removing non-stock/B9 pWings parts meant replacing the B9 quantum struts I used to stiffen the wings with stock ones (I use KJR only for physics smoothing because the joint strengthening feels cheaty). The wings still started oscillating and finally exploding at the slightest touch of a control to compensate roll forces at about mach 3, but that was a noticeable improvement over mach 1.5 with the B9 quantum struts. So I tried slapping triple the amount of them on, and that resulted in my plane going over mach 3 under 5km altitude without major problems (like they did without moar struts in Kindelberger). Turning on all joint re-enforcing in KJR had the same effect. Is this an expected change of Kleinhans (more drag? more lift? anything that can cause more stress to lifting bodies?) Because if it is, I think I can live with trippling struts on all my SSTOs. If not I'll gladly upload my smallest test craft that has the problem.

@ferram4I can't seem to reproduce the instability problems of my designs using B9 procedural wings by approximating them using just stock parts. The stock equivalents work as flawlessly as my B9 designs used to under Kindelberger, they just look a lot uglier. Guess that means I'll be staying with 0.15.6.3 for as long as possible, because I'm not willing to ditch the B9 procedurals. Thanks for trying to help anyway.

@Mine_TurtleI'd try reverting to 0.15.6.3 Kindelberger. Kleinhans has completely borked every single one of my planes (which always worked flawlessly through many FAR iterations up to that point), and I have yet to figure out what to do differently to make them work with the new FAR. The dev dll didn't change a thing for me. If your plane works in Kindelberger, then that just means like me you'll have to learn FAR all over again.

FAKE!!! Look at that totally obvious CGI. There aren't even any stars! Just give it a rest you government shill, Kerbin is flat and 6000 years old. It says so in the Kible. Your conspiracy is so obvious!

I know how to code. In fact, I do it for a living. This was intended as I lighthearted remark. Maybe if you weren't so preoccupied with reading entitlement into everything you wouldn't have overlooked I obviously don't want it "bad enough".

When I manually edit the craft file to adjust the position of parts, what am I doing differently then from what a text box handler would be doing in the editor? Also, I concur with @Fwiffo on pretty much every point. Though the main reason why I'll always prefer manual input is because with floating point, a+b-b != a. When moving things around in the editor to try out different stuff, this error can potentially sum up pretty quickly. Especially with KSP wheels' notorious sensitivity to imbalances, this can become problematic for space planes. Or are there some safeguards against that already built into the stock gizmos? Whichever variant you want to pursue, don't feel too pressured to come up with something. It was just a thought. At least from me you shouldn't take it as a feature request. Which is what I don't understand