magico13

I won't get a chance to look at it tonight, but thank you for the specifics. I can test that particular scenario to see what's up, and if I can come up with a fix then I can test it against that scenario to make sure it works. Thanks!

As mentioned on almost every page, I'm already working on that and it's requested very frequently. The primary issue with it is that in-flight vessels are very different from craft files and converting back to a craft file is fraught with bugs. I've got a WIP version of it than can be opened in the editor, but for some reason can't launch again, so I'm working on that issue (might not be being removed from the FlightState correctly). Needless to say, it'll be in the next release but might have some interesting bugs.

Unfortunately it's a known issue that I've added code to fix, but it apparently only works half the time (worked fine for me in testing). Here's the github issue for it. The workaround is to make sure you have launch clamps that can top off your fuels (stock ones and some FASA ones) I'm curious as to if it's specific to any tanks/fuels. It shouldn't be, but my testing with a procedural real fuels tank (non cryogenic) with liquid hydrogen worked correctly (several hour build had full tanks, but 2 hours on the pad and it was empty). I'd love to be sent craft files and save files since I don't use Real Fuels myself and so can't test it very frequently.

We've got a better way of handling that issue in the simulation rewrite that's coming up in the future, but in the mean time if your game crashes during a simulation just load up the save and go into the Tracking Station, VAB, or SPH and everything will resync. In the future that should happen when you load the save. As for the issue with procedural fairings, they should be calculating correctly during an edit, so I'll have to make sure that code is working correctly. It sounds like it's not :/

Ok, good to hear. I'll have to see if I can figure out a way around that issue. Regarding the log, in the same folder as the GameData folder there should be a KSP_Data folder, inside that is the output_log.txt file. As for the KCT debug messages, in the KCT settings (Open the KCT GUI, press the Settings button, go to Global) there's a setting to turn on debug messages (Enable Debugging).

No, that all sounds correct. If you've also go the toolbar mod installed you'll need to make sure to make the button visible, but even without that you should be getting messages about successful/failed recoveries. You could send me a log file and I'll check if any of the debug messages are being displayed. It's possible that somehow the mod isn't being loaded correctly. I haven't tried it on Mac OS myself, but I also haven't heard anything indicating that it doesn't work on a mac. To find the log file for your system, check this link here.

The strategy could definitely be related. I haven't gotten a chance to take a look at the log yet, but I'll let you know if I see anything when I do later. Edit: I should have been more specific about which log, sorry, but in the future can you send me the output_log.txt file from the KSP_Data folder? Additionally, it doesn't look like you had the Debug Messages setting enabled since I'm not seeing any of KCT's debug messages, meaning I don't know how many funds it's taking for simulations, but it's possible those just aren't showing up in the KSP.log. If you use any of the dev versions then they will automatically act as though that setting is enabled.

If you're using the hangar mod then there definitely is an issue related to that. Are you using procedural parts at all, because they might have an issue too now that I think of it. You can either send me a log file after turning on debug messages in KCT's settings (that setting will be needed to diagnose this), or you can try using any of the debug versions past build 54, since it's probably related to a bug I've fixed in build 54. Sorry for any inconvenience caused by it. You might want to cheat back in those funds. I was working on something like this in the past, and expect to see it come up at some point in the future. I've only had it set up for all or nothing though, not with a configurable percentage, and destroyed parts are lost for good since there's not a way to get a list of parts that were destroyed on a flight (though you might be able to listen to an event that fires when a part is destroyed). I don't know yet if the all or nothing scheme is how it will be when it's released though.

This comes up a lot. The short answer is "I'm working on it". The long answer is "Check the forum threads for my previous responses". Something similar should be in the next release if I get it working correctly. I was just about to suggest that. It's the only thing that was looking like it had any issues prior to the game loading. It might be worthwhile to send the log over to them.

Yeah, if you load up a career save first then it should work for any save for the rest of the session. It's also fixed in any development build since #50 (which apparently was Dec 31st, I really need to get that update out)

It'll happen with any time warp, but it should be specific to Sandbox (no Funding instance available). I've got it fixed in the development builds already

Many times the subject of treating subassemblies separately has come up, but it's never been worth the complete rewrite needed, especially since it would end up working virtually identical to the current system. In fact, it would penalize you guys more than the current system since the current system doesn't care about the connections between parts. For any examples I'm going to assume the subassembly is a launcher, but it would work identically for a payload. If you want to mass produce subassemblies, you are more than welcome to! Load up the editor, go to the subassembly tab, click the one you want to build and it will put it in the editor (no need to switch around root parts). Then build as many as you want. When they're done, scrap them for parts (thus adding them to the inventory). Now, when you build new ships use that subassembly and it'll pull those parts out of the inventory. The jump in time will likely be small compared to that of the pure payload, especially if the payload isn't using any parts from the inventory. Alternatively, if you've already built the payload as well, then scrap a subassembly, edit the payload using the edit function, then add the subassembly to the payload in the editor (making sure to pull new parts from the inventory), and build that. It'll take less time than scrapping both (but make sure you "edit" the more expensive one and attach the cheaper one). Not to sound like a jerk, but these features have existed for many, many months. If I treat subassemblies differently then the part inventory will have to care about connections, which means a lot more work for less freedom and otherwise identical performance. KCT won't be getting any sort of feature like this, but whose to say it won't end up in KCT2 some day (where undoubtedly people will ask for a less restrictive system ) Edit: Also, the more standardized you make things the more you reuse identical parts, meaning each subsequent build gets shorter (per the part tracker after 4 builds the time to build a part is half the original time, 16 builds makes it a quarter. The part inventory essentially adds 100 free builds)

Sounds exciting! Wonder what that could be? I don't know, that's a pretty big if! I actually think there's a way to do that. Older KCT had kerbals be put specifically in the seat you tell them (though you couldn't easily tell which seat was which). 0.90 messed that up for KCT, but there's still functions in the KSP API to define precisely which slot to put a kerbal in, I just don't know if they work properly. I'll probably throw this mod into my mix when it gets going. If I can turn things off then I definitely will. Phase 1 is nice features without major gameplay changes but phase 2 might be too much for me if I'm feeling like playing casually some day, but most of the time I'd probably enjoy the extra challenge as long as it's a planning challenge (like life support) and not a babysit all the kerbals because they need to go on EVA every day or else go crazy kind of "challenge".

If I'm understanding what you're suggesting properly, then why don't you unlock a second build rate and build your launcher/payload separately, then scrap one of them (for instance, the payload), edit the other (launcher), and then add those parts to it (so add the payload to the launcher). Totally doable with the current system, it just requires some planning. Also, you can then build a bunch of standardized launchers, store them, then just build payloads as necessary and edit the launchers onto them (or scrap a launcher before building the payload and use the inventory parts to build the whole thing at once). Let me know if you need any help with it, and watch that you don't accidentally go over the launchpad/VAB limits in edit mode since there's a bug that will cause you to lose everything if you try to build it.

Yes and no. Running 64 bit KSP on Linux won't be any better than running 32 bit KSP on Linux, but when you've got < 4 GB of RAM then you're not able to dedicate as much to KSP (since your operating system and other programs will be taking some of that). Linux is generally much lighter than Windows in terms of idle memory usage, so you'd still have more RAM available to KSP when running Linux. But yeah, the bigger upgrade would be to get more RAM, if possible. And no, you can't download more RAM (until 3d printing gets really wild)

Probably not. This just calculates experience. If final frontier doesn't hand out ribbons until recovery, that's on them to change. There isn't a way for me to make other mods think the kerbals are recovered without probably breaking something, but Final Frontier could easily calculate ribbons while flights are active.

As mentioned by several others, I use Kerbal Construction Time (link in sig ) to test things (even when reverts are turned off in the save). I will admit that I have been cheating lately and have turned off costs for simulations and unlocked the Body Tracker so that I can test my Duna lander around Duna before I send my OKS station there. 23,000 funds for an unlimited time simulation in orbit of Duna was a bit too cost prohibitive at the moment. The cool thing is that I can also turn off build times (with basically one click) so that I just have the normal game + optional simulations. Works great on Sandbox so I can test things in orbit without dealing with build times or installing hyperedit, but works just as well in a hard mode career game.

Well, I think I found the problem. It's an old issue that I thought was fixed by the developer disappearing and no longer updating their mod, but alas, Tarsier Space Tech is the cause. NullReferenceException: Object reference not set to an instance of an object at TarsierSpaceTech.TSTProgressTracker.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioRunner.AddModule (.ConfigNode node) [0x00000] in <filename unknown>:0 at ProtoScenarioModule.Load (.ScenarioRunner host) [0x00000] in <filename unknown>:0 at ScenarioRunner+ .MoveNext () [0x00000] in <filename unknown>:0 Edit: Incidentally, it's in the same vein as the issue that breaks KCT caused by Kerbanomics. In both cases, the OnLoad encounters an error and stops processing ANY of the remaining OnLoads in any other mods, which breaks any mods that need to read data from the save file. Unfortunately, I don't know of any way to protect KCT from that, but I might be able to find a way.

In your sandbox game, don't forget to upgrade your build times (or turn them off in the settings) As for career mode, that's pretty strange. I'm probably going to need to see your output_log.txt file to figure anything out (if you love me you'll turn on the KCT debug mesages in KCT's settings window first). I don't know of any incompatibilities, per se, but I know that Kerbanomics has an issue that breaks KCT (and several other mods) when it goes wrong.

Unfortunately a few other people discovered that not too long ago as well. The good news is that it's already fixed in the latest dev version. The bad news is that it's still an issue in the release version.

By chance you aren't doing your testing of this on Kerbin, are you? Because Kerbin has oxygen so they don't need external oxygen. I believe the same is true for Laythe.

I tried to take a quick look at the log to see if anything stuck out to me, but I don't know FMRS' typical output. Assuming the last change from Flight to SpaceCenter you did was the recovery with issues, KCT is reporting that all the parts were recovered and said it saved to persistence. Some other things worry me though. You have, and I kid you not, 5 different versions of ModuleManager installed ranging from 2.5.0 to 2.5.8. Additionally, something is seriously up with your copy of PreciseNode because in all of your flights you have minimum 1447 NullReferenceErrors being repeated. That's far below the typical ones I saw which were between 8000 and 36126(!!). That's for one flight scene. I'd be very surprised if that didn't impact performance. Unfortunately I couldn't tell what version of PreciseNode you have. I wish I could be of more help :/

Note that there was a recent change in the naming of the primary .dll for KCT from "Kerbal_Construction_Time" to "KerbalConstructionTime", so you'd have to update the MM config accordingly.

The two have no interaction with each other whatsoever. Meaning they both work fine together, but things won't likely seem balanced. From what I understand, EPL has much shorter build times than KCT. I also recently started playing with MKS + EPL, but haven't gotten to the EPL part yet. I haven't even figured out what the supply chain for making RocketParts is yet with MKS.

Currently the VAB/SPH upgrade levels are not taken into consideration (and there aren't time requirements for upgrading them) but in the future they will be. I have a bunch of Dev work that I should be doing but have been working on other projects, one of which is a Duna orbital station using OKS. At the very least it shouldn't take too long for me to implement upgrade time requirements and Claw recently discovered a nice way of turning a Vessel into a craft file, which opens up recovering into storage as an option. .at e I'll try to get those working this week.