MaxRebo

But that's what he did: Since 1.1.2 runs with no crashes whatsoever for me (although far, far, far from being the largely bug-free experience it was in KSP1.1), I can only assume downgrading messed something up. I'm sure this goes without saying, but did you also fix the files after downgrading @Pesterenan? If you did, then I have no idea what might be happening to you. Your safest bet is reinstalling KSP completely. kOS v1.1.2 definitely doesn't crash KSP1.3.

Ok, I managed to track down the issue to no mod in particular, but rather every solar panel (including stock ones). No solar panels = no phantom drain at all, even under high timewarp. The relative amount of phantom drain appears to be roughly proportional to the panels' combined maximum power output, and it's not like the drain doesn't happen without timewarp, it just starts at a very low level. Each timewarp then makes the drain worse (I managed to get what should be ~0.05 to ~25 by timewarping at 50x for a minute or so). Only quicksaving/quickloading will revert the drain back to its "normal" low starting amount. Unloading the vessel so that Kerbalism's background simulation kicks in will make the drain disappear - until the vessel is loaded again. Removing Kerbalism eliminates the drain completely, so I'm almost convinced at this point that the issue is with Kerbalism, and likely with Kerbalism alone, i.e. no mod conflict. I don't know how methodical @ShotgunNinja's testing procedures are, but considering the drain is almost unnoticeable at first without timewarp and even smaller the less power generation the vessel has, the bug might have gone unnoticed until now - especially if it's a recent regression.

Generally yes. In a nutshell, the vessel's boot script first runs the framework file. Then all plugins it wants to use. They register their states with the framework via function pointers. Finally, the boot script invokes the framework's "master function" which then takes over control. One very common use case that exhibits the problem is first using a state defined by the SAS plugin (implemented in its own file) to hold some attitude (-> LOCK STEERING TO...), then switching to the "Manual Control" state (one of the very few states the framework ships in its main file) to do some manual stuff (-> UNLOCK STEERING). In general, locking and unlocking will happen in different files more often than not. This is probably a tough one, so good luck

I'm absolutely certain I don't. Unlocking really didn't work. It's been like that since KSP 1.2, never experienced anything like it with basically the same code back in 1.1 and prior. However, while looking at my code long and hard, I found a workaround. Immediately before unlocking anything, I first have to lock it to something. Then unlocking works. The lock can be created in many different sub routines that even may originate from another file, dynamically loaded into the autopilot framework (it has a plugin-based architecture). It's under these complicated context-juggling conditions (which I can't be bothered to find minimal reproduction steps for, sorry) that unlocking failed. If I first lock in the same execution context in which I want to unlock then it works. It's a few bytes more that I'll have to shave off somewhere else, but oh well.

So what is the correct way to unlock controls from cooked steering while the program is still running? I'm writing a MechJeb-like autopilot implemented as a state machine, and some states are supposed to leave certain controls on manual. Like a "hold orbital attitude" state should allow for manual throttling, and a "manual control" state should leave everything unlocked. However, neither UNLOCK STEERING nor UNLOCK THROTTLE do anything at all. I'd rather not re-implement everything in raw control - kOS diskspace is already limited as is.

I'm experiencing a rather massive phantom drain of electric charge. For example, my ComSat has 3670 EC worth of battery, and it won't even last through half the night side in Keostationary orbit at a drain of about 3~5 EC/s (it's different every time) with everything but the probe core disabled. Flight planner tells me I should have 0.02 EC/s drain in this configuration, and last well over 8 days in shadow. But then again, Kerbalism won't allow me to include basically anything in the planning simulation. I only remember having seen the option a handful of times, and don't even recall what parts they were on (probably ScanSat). The only mods I have installed which could conceivably interfere with Kerbalism are RemoteTech and the WildBlueIndustries suite (MOLE, DSEV, Pathfinder, etc.). Does Kerbalism have a way of getting a breakdown of EC consumption? I don't want to complicate the setup further by installing additional mods like AmpYear for this purpose, since that would be another interference for sure. Maybe Kerbalism isn't even involved in the conflict (if it indeed is one), but it's the main suspect for obvious reasons. Any ideas or pointers would be greatly appreciated... /edit additional info: the phantom drain appears to only happen when the vessel is active, and only if it has been time-warped at least once while active (5x appears to be sufficient to trigger).

What a very Jenkins thing to happen Thanks for the quick effort!

It would appear http://magico13.net:8080 is currently unreachable. Server down?

@Kobymaru @Terwin @DStaal @Gilph @jd284 Thanks all for the insight. Even with the ability to do disconnected bases (which truly is a godsend, and the most awesome thing about MKS for sure), I sometimes still want a few modules connected this way for reasons of aesthetics and immersion alone. Pretty sure at least their cfg's will need a rework for KAS 1.0, but the effort should be comparatively minor and IMO worth it.

@Kobymaru: ^ I'd still like some clarification of the above... I'd hate to see them go, especially with the much more flexible and robust KAS 1.0 on the horizon.

Small bug report regarding the port welding... with CLS installed, welding results in the two living spaces connected by the docking ports in question being permanently separated. Also, if there are passable parts that can't hold any crew between the docking port and the first crewable part on the "mother"ship side, then those get wrongly assigned to the "child" living space (see pictures below). In addition, when "Keep docking ports after welding" is enabled, there's a single exception being thrown during the welding: Here's the images: aaand the save, made on a minimal install (MOLE + Ship Manifest + Connected Living Spaces): MOLEWeldingTest.zip Just go to the tracking center and select the single station-type vessel in orbit (it's the above station), or just load the Quicksave. By the way, several MOLE parts that are supposed to be, are in fact not CLS-passable (like the Solar Battery Module in the above station, but from the top of my head also the larger of the two Interstage Service Compartments). I applied a custom MM patch adding the CLS module to the Solar Battery Module in order to get the results in the pictures above. I hope this helps. The port welding feature is just way too handy to pass up, and I'd rather not play without CLS...

I had no idea, lol Oh well, I'm actually kind of glad I didn't find it back then, because recompiling Science Funding paved the way for me to be able to patch up other mods that I want updated. I have no regrets

I'm not kidding myself into thinking I can be a maintainer at this point, so I won't make a new topic. But I do intent to keep using this mod, so I'll keep posting my updates here as new KSP versions come along (and compile PRs for @Ippo when appropriate - this time there simply were no code changes necessary).

I'm getting really bad log spam from AY on the Bigby Orbital Workshop part from @Angel-125's MOLE in VAB/SPH (in flight seems to be okay): /edit Looking at it again more closely, I think this is probably due to how MOLE does things as opposed to being a bug in AY. Should I take this there instead?

That makes perfect sense. I didn't really think about the not-implemented aspect of it, but now that I do, I fully agree.

@magico13 Just out of curiosity, was there something wrong with my pull request for the payroll FM? I personally thought this to be the more appropriate place to address the NREs, although the null checks in BROKE are certainly a good idea anyway. Just curious if returning an empty list instead of null violated some kind of interface/design contract...

Alright, I think I managed to get it working fine. The only other thing that I found is a rather fatal bug in the invoice collection logic that I just cannot imagine wouldn't have manifested in earlier versions: handling empty items / item lists was rather broken. The Payroll FM's ProcessYearly just returned null instead of an empty list, a recipe for relentless log spam if ever there was one... and while simple (non-multi) funding modifiers have no other reasonable choice but to return null if they have no invoice to declare, BROKE didn't take that into account and just added said null value to the list, resulting in any actual payment operation later on failing. Pull requests are out

You're completely correct... believe it or not, I was at the time not quite aware of the regex magic you could do with MM. I guess that makes the little project I wanted to start over Christmas obsolete

Just took a closer look at your post again, and... that version is WAY outdated. It was for KSP 1.1 if I recall correctly. Have you tried one of the more recent versions from the few last pages, like this one?

^ Yes, that. That has been necessary for as long as I can remember, at least as far back as KSP 1.0... And I stand by that statement. KSP v1.2.2.1622, Toolbar v1.7.13 , Infernal Robotics Core v2.0.7 (yes I didn't update to the drift fix yet) + WIP IR Rework parts pack. Works in VAB/SPH and in flight. I'm going out on a limb here, but have you actually loaded a craft with any IR articulators on it? The icon won't show up unless the active vessel in flight has at least one robotics part on it, and while it will show up in VAB/SPH regardless, you won't get the option to add the icon unless the loaded craft has one.

Right, I totally forgot there was two people on this project Alright, I should be able to get this done before Christmas.

Whoa, I actually didn't know of those... well since I'm not in a position to actually become a maintainer, I'm pretty much with you on phasing this out in favor of similar mods that fit the same bill. I'm still determined to get this working in 1.2 though, if just for the educational experience. The scenario is indeed created using KSPScenario, so that mainly leaves the instantiation business to take care of. I'll go with the "better instantiation" approach then, and maybe you'll accept one last PR for BROKE when I'm done?

I'm currently having a go at this @magico13, and while it doesn't look like KSP 1.2 broke anything, I already found a few very fatal bugs. For one, the scenario's OnLoad event gets fired before a valid/current instance of the BROKE KSPAddon is available (that might be a 1.2 thing after all, but I simply don't know), and that breaks the whole framework pretty bad. There are a number of ways to address this, but since I don't intent to take over maintenance from you or anything I'd like some feedback as to what kind of fix you'd like to see implemented. Personally I'd outsource the persistent state into its own, KSP API independent singleton. The scenario loads into this, and the KSPAddon reads from it whenever it's ready. I didn't yet try to check if the loading and KSPAddon instantiation are actually running concurrently (this is my first time coding anything for KSP, I know next to nothing about its inner workings), in that case some serializing synchronization primitive would be included. Thoughts?

@hvacengi Sure thing. And sorry, I kind of got sidetracked and forgot about filing the issue on github... but I'll gladly help testing now

I've just about had it with waiting, and since I finally had the opportunity to set up a Visual Studio 2017 environment, I gave this a shot myself. Turns out updating the references and a recompile was all it took. Here you go: ScienceFunding-v1.3.1 for KSP 1.2.2 I'll take a look at BROKE next, though that one will take a bit more work.