magico13

I'll get an update out today. Might not have any more features than the current version, but I'll at least get it to a functional state Edit: I "updated" Re3. All I ended up doing was change the keys to Alt-F6 instead of F10 and recompiled for 1.0.2. Tested it out and it worked about as well as before. Discovered a fun glitch where you can duplicate half a ship. I need to take some time to properly work on it, but I'm halfway through a new KCT feature.

I still can't find anything. I'll sleep on it tonight and maybe try the 64 bit hack tomorrow and try to figure out if its a mod incompatibility or a 64 bit issue. Until then, I'd try the save file editing.

Hmm. Now I'm definitely confused. I don't see anything erroring. Please turn on the KCT debug messages in the settings menu, as they might help if you upload another log later. In 32 bit windows I can't reproduce it. Starting a new save works fine for me. I'd try modifying the save file as I outlined earlier, but otherwise I don't have any ideas :/ - - - Updated - - - Fixed now in the dev versions Also moved KSC upgrades into Tech with tech nodes. Much, much nicer.

Sounds like the firstStart variable isn't being set to false. Two options, remove SCANSat and make a new save, or open up the save file in a text editor, search for "firstStart" and change it from True to False (though, going to the SpaceCenter might also fix that part) and also search for "TotalUpgradePoints" and set that to 15.

It looks like a SCANSat issue breaking the initial OnLoad. Do you still get the proper 15 total points? If so, just ignore the error (but report if it happens in existing saves). Otherwise I'd try removing SCANSat, starting the new save, then add SCANSat back in later.

I haven't used the community hack since it first was discovered in 0.23, but the log file should be in KSP_Data and is called output_log.txt. There shouldn't be anything especially messed up as a result of the 64 bit version, but the reason it stopped being released was because it was prone to random errors, so who knows! If you get me the log I'll gladly see if I can find anything

Just to inform you, KCT's been updated to support Regex's KSCSwitcher (along the same lines that KCT worked with RSS in 0.90). Also, I'm working on adding preset configurations into KCT. Once that's done you'll just need to include a preset .cfg file and don't need to worry about overwriting any other configs. I also plan on making it so that if someone chooses to use a preset, and doesn't manually change any of the settings, then any changes to the preset file will automatically be applied (so if you rebalance later), but if the user changes any of the settings they'll be on a "custom" config which won't be changed. Once I get it all set up I'll be back to provide examples. It will be pretty straightforward to change to, but would also be a good time to consider using some of the other formulas that I opened up.

I've changed it since then to use the reflection based method. if (KCT_Utilities.TestFlightInstalled && KCT_GameStates.TestFlightPartFailures && GUILayout.Button("Disable Part Failures")) { KCT_GameStates.TestFlightPartFailures = false; foreach (Part part in FlightGlobals.ActiveVessel.Parts) { bool tfAvailableOnPart = (bool)KCT_Utilities.TestFlightInterface.InvokeMember("TestFlightAvailable", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part }); if (tfAvailableOnPart) { foreach (string failureName in (List<string>)KCT_Utilities.TestFlightInterface.InvokeMember("GetAvailableFailures", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part })) { KCTDebug.Log(part.partInfo.name + ":" + failureName); KCT_Utilities.TestFlightInterface.InvokeMember("DisableFailure", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part, failureName }); } } } } if (KCT_Utilities.TestFlightInstalled && !KCT_GameStates.TestFlightPartFailures && GUILayout.Button("Enable Part Failures")) { KCT_GameStates.TestFlightPartFailures = true; foreach (Part part in FlightGlobals.ActiveVessel.Parts) { bool tfAvailableOnPart = (bool)KCT_Utilities.TestFlightInterface.InvokeMember("TestFlightAvailable", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part }); if (tfAvailableOnPart) { foreach (string failureName in (List<string>)KCT_Utilities.TestFlightInterface.InvokeMember("GetAvailableFailures", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part })) { KCTDebug.Log(part.partInfo.name + ":" + failureName); KCT_Utilities.TestFlightInterface.InvokeMember("EnableFailure", BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Static, null, null, new System.Object[] { part, failureName }); } } } } If/when I get into doing more interactions with TestFlight, I'll clean that up some more, but for now it appears to work with the modified TestFlight I have.

It's a side effect of letting you close those sub-windows in the first place. Mildly technically: most of those buttons are a "toolbar", but clicking a button on a toolbar can't be detected (I just know which button is "active"), so to close the sub-windows I check if the activated toolbar button is the same one that was active last GUI change. Unfortunately, clicking any other button also triggers a GUI change. Basically, I have to switch back to buttons, or use a Toggle that's reskined to be a button. It's been bugging me too, so maybe I'll make that change really quick and have it in the dev version (which now support the TestFlight mod! You can disable part failures during simulations) I'll check it and report back in a moment. E: Which window? The main one? Or the rename window? E2: I know the reason. It's the code that keeps the window centered. I'll fix it, for at least that window. Not sure what's wrong with rollout. I'm not seeing anything there. E3: Fixed the rename window in the latest dev version. There were two codes fighting to keep it centered and neither was happy with each other. That could happen in one or more other places as well. If you find more flickering, let me know which windows are doing it and what other KCT windows are open. Thanks

It seems pretty easy to work with now that I have an idea of what I'm doing. I almost never work with PartModules, so I wasn't sure if what I was doing was correct. But it listed off all the possible failure modes when I asked it to, so I'm assuming things are working properly I'll do a bunch of random launches and see if I can get things to fail/not fail when I want them to. I'm just doing this currently: foreach (Part p in FlightGlobals.ActiveVessel.Parts) { if (p.Modules.Contains("TestFlightCore")) { TestFlightAPI.ITestFlightCore coreMod = p.Modules["TestFlightCore"] as TestFlightAPI.ITestFlightCore; //disable failures foreach (string failureName in coreMod.GetAvailableFailures()) { KCTDebug.Log(p.partInfo.name + ":" + failureName); coreMod.DisableFailure(failureName); } } } E: Hmm. Failure still occurring. Might need to do something else. E2: Might try out the interface instead. Will report back if I have success or problems. E3: Nope. Supposedly disabled failures are still being triggered using that method instead of the hybrid method. It will gladly tell me all the possible failures, but using those I can't actually disable them. I think it might be on your side. When you disable a failure you lower and trim the name: failureModuleName = failureModuleName.ToLower().Trim(); When you check if a module is in the disabled list, you don't: PartModule pm = fm as PartModule; if (!disabledFailures.Contains(pm.moduleName)) {...} I bet there's some case issues there, since the names that I'm getting have capitals in them, meaning it will never find them in the list if they're made lowercase.

Since I don't know how long enneract will take to get HoloDeck to a functional state, and because I feel bad about not getting around to this earlier, I'm gonna take a look at this now. Won't be in a full release for a while, but it'll be in dev versions of KCT. I just need to figure out how to disable or enable failures on a whole craft. Still learning how you've got the API set up. In case it matters, I'm planning on using the hybrid method. Sorry about the confusion/delay. The past few months have been an interesting time and plans keep getting shuffled around. E: Looks like I just get all the failures on a part, loop over them, and disable them by name. Then to reenable failures you get all the failures and enable them by name. Correct? E2: Next question. How exactly do I get the ITestFlightCore for a specific part? I'm assuming it's related to a PartModule maybe? Still trying to wrap my head around this E3: About to test if this code works. If so, then I think I've got the hang of it. Doing things like keeping partial data will be harder, but at least letting people disable failures makes sense. E4: HAHA! It works Alright, consider the ability to disable/re-enable part failures to be in the next dev versions.

You should have let me know you already had set up a thread Obviously, if you need any support from me, let me know. And if it wasn't already obvious, you can freely use anything from KCT. We need to talk about managing the launch button. Minimally I'll be adding something to the KCT API so that other mods can register callback functions for a popup window (so default KCT will have "Build" and "Cancel" but HoloDeck would add "Simulate" or whatever). I might do it as a separate .dll instead, especially if the API is a ways out. Without testing, I still think ContractConfigurator's method of spawning ships will be better than the current KCT method of moving vessels from the launchpad for orbital/landed simulations. You also can avoid limitations due to building upgrades and funds that way. Annoyingly, you'll still have to do whatever you're doing now for normal simulations. Looking forward to when this gets to the level of functionality KCT's sims are at, so that I can replace them with this. Even more looking forward to when this surpasses KCT's

Thanks! I think I found the problem right away. CraftHistory for whatever reason totally breaks KCT. I forgot all about that. Unfortunately the only fix is to not use CraftHistory and KCT together. I'll add an issue on GitHub to remind me to look into that more. E: Looks like the author knows about the issue and has a fix in progress.

Errors in KSP are always a fun adventure. I had one last night with FAR where my wings weren't applying any lift (or drag). Took me 15 minutes to figure out why my plane wasn't taking off like it did during a simulation. A restart fixed it, but it was definitely weird. I haven't heard anything from him lately, but I just checked his thread. He'll probably submit a PR sometime this weekend into the dev branch, which I'll pull. A full release with compatibility might wait until after presets are done. I too would like to see compatibility and CrewQueue in a nicely working state. Unfortunately Google Drive is saying I need to request permission to view that file. You probably need to change the sharing options, but I'll request access as well.

I'll look into it, but I started a new career last night and didn't have any issues with that contract completing. If you want to send logs I can take a look, but if it's just that contract and not others than your workaround might be fine. Yes and no. At some point I want to improve that system, but it's quite a while down the list. Pre-building parts can be done by building something and then scrapping it (a good way to use up time that otherwise wouldn't be used). Selling parts only would make sense if you didn't already get the funds back when you recover or scrap vessels. I've, a couple times now, rewritten the inventory system so that once you buy a part you don't get the funds for recovering it until you sell the part again. Eventually one of those rewrites will be added to KCT. Maybe when I add the API in, since I'll need to rewrite a bunch of stuff anyway.

When the NetKAN bot detects it, which is usually within an hour

I'll need (minimally) log files before I can even attempt to figure out what's causing the issue you're experiencing. I'm likely going to be doing a bug fix update later today, so there's a chance that could fix whatever issue your experiencing. Edit: And now that bugfix update is released! Pretty small amount of changes, but should fix the most noticeable bugs present in 1.1.6. The KSCSwitcher support was a straightforward port of how it used to work when KSCSwitcher was a part of RSS. v1.1.7.0 (5/16/15) - Fixed issues when loading tourists - Supports Regex's KSCSwitcher now - Fixed issue with creating a new save after loading one where KCT is disabled - Fixed bug with facility upgrades failing when loading Space Center from Flight scene - Updated StageRecovery, Toolbar, and KAC wrappers. Future plans: I plan on working on Presets now, or at least moving more of the settings into the save (either as a file in the save folder or into the save file itself). Then, it looks like the API is the main target. I'll probably have a release when Presets are done (especially since RSS is likely going to use them and if I can get presets out before RSS updates then that'd be nice for everyone involved), but the API will take a while. There's a chance that I'll do an update with a partially complete API so other mods can start doing things, then release a fuller update later. With the API, you all won't see any substantial changes from your end, but I'll have to rework a lot of sections of code. It's a fairly big project, but it should help clean up some of the poorly written areas of KCT and will allow other people to do some cool things by extending KCT.

I considered trying to get at that function through reflection, but it's always a pain to do properly. I figured others might want to use the new events in the API for some reason, and it should be pretty plug and play for you, if you decide to include it. If you want me to make the changes for you and do a PR I can, otherwise I'll try to quickly go through what you'd need to do. 1. Include the StageRecovery Wrapper in KK (and change the namespace to that of KK's) 2. Where you add GameEvents in the KerbalKonstructs.cs file, add if (StageRecoveryWrapper.StageRecoveryAvailable) { StageRecoveryWrapper.AddRecoveryProcessingStartListener(OnVesselRecoveryRequested); //This uses the already existing function in KK that change the space center instance when something is being recovered StageRecoveryWrapper.AddRecoveryProcessingFinishListener(SRProcessingFinished); //This requires a new function for now, but it will just link to the OnVesselRecovered function } 3. You'll need to add one tiny function for resetting the space center, but we'll call the already existing OnVesselRecovered function in it so you won't need to make changes in the future. void SRProcessingFinished(Vessel vessel) { OnVesselRecovered(vessel.protoVessel); } And that's it! If SR isn't installed, it won't do anything, but if it is it'll set the SpaceCenter instance when SR goes to do calculations, then reset it at the end. If you make changes to how the normal recovery works, it should change for SR based recovery as well. Note that the SRProcessingFinished doesn't say whether or not the recovery was successful, just that it finished processing. If you want to do anything on only a successful recovery, you'll need to add a new event listener with StageRecoveryWrapper.AddRecoverySuccessEvent(). I should note that I haven't been able to test it a whole lot. It occurs to me now that it might be possible for the RecoveryProcessingFinish event to not be fired if an error occurs during recovery processing, meaning the SpaceCenter instance would get "stuck". Except, thinking about it the code still continues when it catches the most common errors. Other errors would indicate a more severe problem anyway, so I don't think that will be an issue. Just something I'll need to watch out for. If you decide you'd rather just expose the GetClosestBase function, we can talk more to figure out a way to do that. Thanks - - - Updated - - - SR can only work (and does only work) when vessels are unloaded and destroyed as a result. If they're still in physics range, that's on you to recover. Make sure it didn't also land and just can't been seen in the map because it's listed as "debris" (so, in the map/tracking station modify the filters at the top until you can see debris).

Finally done with finals, so here's a quick bugfix update. It should fix issues with powered recovery (now requires 300m/s of dV [if you aren't using parachutes as well]), should now support RealChute Lite in FAR without requiring the full RealChute mod, and should hopefully eliminate the issues with huge distances from KSC being reported. I also added some things to the API that should make KerbalKonstruct support super easy, but it will require a change on their side. CKAN usually takes up to an hour to update, Curse has a bit of a delay as well, but KerbalStuff and Mediafire are updated (alternatively, you can always get them from the build server). Changelog: 1.5.6 - (05/15/2015) - Non-parachuted stages now have a fixed Vt of 200 m/s - Powered recovery should work properly now. Requires 300m/s of dV to work. - Added OnRecoveryProcessingStart and OnRecoveryProcessingFinish events to API, for Kerbal Konstructs support. Fire when first starting recovery code (after determining viability for recovery, but before Vt calculations) and at the end of recovery code (doesn't include information about recovery, just for cleaning up) - Support for RealChuteLite in FAR - Hopefully fixed issues with ridiculous distances from KSC. If not, now logging lat/lon of stage and KSC, to help debug. Edit: Also, @oversoul, I tested the same parts in this update (without RealChute or FAR) and everything worked (parachute pre-deployed or not), so hopefully whatever issues there are resolved.

You may be interested in the edit function, through the * button As for Kerbal downtimes, check out CrewQueue. It's still a work in progress, but enneract's work is generally high quality.

Are you running 1.5.5? 1.5.4 doesn't work in 1.0.1 or later. Have you tried the development version? If that's not the problem, could you send screenshots of an example stage and its failed recovery? I just finished my last final so I'll be able to take care of these sorts of issues again

The function KCT calls to launch a ship is the same one that launching through the launchpad uses, so can you try removing KCT and seeing if launching things through the launchpad dialog will cause the same problem. There are literally hundreds of thousands of errors being logged in your log file, mostly Deadly Reentry but also I think some things with FAR. I'll have to check it out more later.

It should be safe to remove. Your log will contain warnings that it can't find what mod owns the KCTData scenario, but that's not a big deal. You can also just turn it off on a per-save basis in the KCT settings if you want. It doesn't use much, if any, RAM, especially when disabled. Also, to everyone, look what's on this list

Yes! I'm still quite interested in getting a nicer logo, for the purposes of a banner on the main post and because I want to get it printed on a T-shirt (not entirely sure why, I doubt anyone would recognize it but it'd be fun to have). I won't be in contact much today, but if you do get any good results you want to share with me let me know and we can talk more

KCT's inventory doesn't recognize any parts in KIS containers. Its not too big of a deal, nothing game breaking, just a bit weird since you'd imagine parts in the KIS inventory would be taken from (or added to) the KCT inventory. It'll require a bit of special code to handle properly, that I may or may not add since it's not a priority at the moment and every specially handled case inevitably becomes a giant pain later on.