magico13

@Artfact Easiest thing (if those are the only nodes you're currently working on and you want both unlocked) would be to temporarily go into the KCT settings, turn on Instant Tech Unlock, Save the settings, then open it back up and turn that setting off again. That'll automatically finish any tech research that's in progress, but future nodes will still require time to unlock. Perhaps I'm misunderstanding the situation and you're just asking how to cancel a tech node (so you're not accidentally "cheating"). Removal of that ConfigNode from the save file should be sufficient to do that. I should probably add a way to cancel research on a tech node and return the science for it. If that doesn't work for some reason, or you've still got questions, let me know!

I'm not 100% sure what you're asking, but I'll try to answer it anyway. If I don't actually answer your question, let me know and I'll try again If you recover things manually (by clicking the recover button in flight or in the tracking station) then Stage Recovery doesn't do anything at all regarding those vessels. So if you drop a stage (stage == vessel == parts you dropped) with parachutes and it lands before you leave physics range (22.5km) then you have to recover the stage manually and Stage Recovery does nothing. When Stage Recovery comes into play is when you leave physics range while the stage is still in flight and hasn't landed yet. When that happens KSP totally deletes the craft; killing any Kerbals inside, destroying all the science on board, and treating the whole thing as "crashed", meaning you would get 0 funds back. Stage Recovery intercepts that process and calculates whether the stage would land safely. If it calculates that it should land at a slow enough speed, then it recovers all the Kerbals and science, calculates the total value of all the parts on the stage and then returns a fraction of that value back to you. The fraction is determined by how far away the stage is from KSC (same as with Stock) and how fast it would land. If it would land slower than 6 m/s, you get 100% (without range penalties). If it would land at 12 m/s or more then you get 0%. If it would land between 6 m/s and 12 m/s, you get an amount following a quadratic polynomial (the closer to 6m/s, the more you get back). The values for the funds you get back are entirely compatible with the stock recovery, because they're equal to or less than what you'd get if you recovered the parts manually. They're usually less, since you can't get 100% (98% is the maximum, since I don't check for "landed at the launchpad or runway" like Stock does) and there are penalties for speed. Stock recovery and Stage Recovery should absolutely never interact with each other, so you'll never get a "double recovery".

There's so much going on in that log that it's hard to say for certain what's happening. Firstly, the log is huge because Deadly Reentry is throwing an error on every FixedUpdate during Flight. There are literally about half a million or more of those errors from Deadly Reentry (I count 145 thousand in once Flight scene alone, the others are typically closer to 20 thousand), but they're likely not too serious (but DR might not be working at all). Real Fuels throws an error that would explain why the KCT error message came up, but not until after some weird behavior where you go from the Flight scene to the Space Center and then to the Space Center again. However you got to the space center scene is probably related to the issues, as switching scenes prior to a scene fully loading can cause issues. It looks like you crashed a vessel? Here's the first NullReferenceException mentioned in the final Space Center scene, which explains why the camera is totally messed up. I'm betting it's related to the fast scene change, since the OnLevelWasLoaded probably got somewhat messed up since the persistence wasn't read in the short Space Center scene. But that's just a guess. NullReferenceException at (wrapper managed-to-native) UnityEngine.Behaviour:set_enabled (bool) at FlightCamera.EnableCamera () [0x00000] in <filename unknown>:0 at PSystemSetup.SetSpaceCentre () [0x00000] in <filename unknown>:0 at PSystemSetup.OnLevelWasLoaded (Int32 level) [0x00000] in <filename unknown>:0 And here is the eventual Real Fuels issue that halted any persistence loading in that last scene, triggering KCT's message. NullReferenceException: Object reference not set to an instance of an object at RealFuels.RFUpgradeManager.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 I'd maybe turn on KCT's debug messages and keep playing as normal. If you find this happens more often, let me know and I'll see what I can figure out. It seems like you got to play for at least a little while without anything too catastrophic happening, so at the very least it's not totally game breaking - - - Updated - - - This is totally possible. The way KCT checks if there was a loading issue is by setting a flag true during Start and setting it false at the end of OnLoad. It checks the value of the flag after some number of FixedUpdates happen, and if it's still true then OnLoad didn't complete. If it takes too long for OnLoad to finish in the first place, then it could very well pop up the error message prior to OnLoad completing, despite the fact that nothing is actually wrong.

You might need to warp manually and use Kerbal Alarm Clock alarms. The way warp is handled should work with any setup, but there might still be some hard coded stuff still in there from the original system (which was completely hard coded to the stock system).

People have reported no luck with the 64 bit build before. I've looked at logs, and nothing was even being reported in them, so I have no clue whether or not it actually worked or if it was a false positive. KCT itself doesn't have any active 64 bit restrictions. If I find the time, I'll take a look at RF again. Especially since KCT is a recommended (and maybe soon a dependency of) RP-0 (the career mode version of RO).

I think I fixed those issues. Also added the ability to have each tech node go at a different rate (so you can do FIFO or all at once). It should be that if the rates are all the same, no buttons appear. If the rates are different, buttons appear to let you reorder things. I'm tired, so I didn't test everything. I didn't get around to playing with loading different saves and fixing whatever bleed over was happening, sorry Edit: (7/25/2015, 12:04AM) I don't want to post three times in a row. That seems like a bad thing to do. Added Kerbal Konstructs support. You set the launch site at build time (will probably eventually add the ability to set it at launch, but this is easier) and each launchpad has its own rollout and reconditioning queue. One caveat, resuming a save will require you to enter the editor and select any launch sites you might decide to use (just for a moment, you can just click all of them). I might be able to fix that, but I think it's semi-KK induced. This does open up the possibility of having multiple launchpads in the Stock game now that KCT supports any number of individual launchpadIDs. May or may not make it to release. Will probably save it for next version.

For me or for you? Very frustrating for me. I've got the hard drives now, but haven't gotten a chance to do a full format and verify that they're not dead on arrival. If any of them are, I'll have to go through the several week long process of trying to RMA them. If it's just one dead, I'll buy a new one in the mean time and then have 4 in the final set up. I'm still working on dev versions though (they're getting pretty stable now! Mostly just polish at the moment), and hope to push out a full release this weekend if NathanKell would stop making requests already

I'm pretty sure it's because you have to sign a NDA + other contracts + legal things, and it's a billion times easier to do that with just 18+ year olds instead of trying to also handle all the laws about minors. I'm pretty sure it's just a legal thing.

Ah, I think I know why. The tech tree itself hasn't updated after the nodes are enabled. I might just try to find a different way of getting which nodes are enabled, since referencing the snapshot is easy but apparently not updating frequently enough. More playing around in the Object Browser I guess :/ It used to save the position, but when I switched to using the Stock toolbar as the primary I forced it into the top right with the other windows (and it has exclusivity applied). Then an update or two later I made it so you could move it if, and only if, you were using Blizzy's toolbar. I can probably re-enable the position saving and just add a check for if the user has stopped using Blizzy's toolbar (otherwise the window will get stuck at wherever you put it when you still had the toolbar mod).

The good-ish news is that you are actually using the latest release. The bad-ish news is that it seems to actually be a KCT issue, but might also be a Real Fuels issue. KCT logs a bad error when loading up the Space Center, but Real Fuels logs one upon entering the VAB, which then causes a KCT error as well (but KCT may have caused the Real Fuels one in the first place...) You might try the development version, but I'm not sure if the cause of this issue is fixed. There are enough internal changes that it might be. Additionally, I know someone mentioned issues with Kerbal Konstructs. Could be related? If you turn on the KCT Debug messages in the KCT settings it might help me pinpoint where exactly the error is happening.

I'll add in those workarounds tonight, thanks for coming up with them. As for "Tech nodes in progress and count of nodes" that should be fixed. KCT is now counting in-progress nodes automatically and shouldn't be double counting anymore (which is why there's a save game in the TechDisableEvent). If that's not the case, then let me know, but that should already be fixed. Looks like the thing I'll take a look at most tonight is switching saves within one KSP session. It's not something I do frequently, so I don't catch those bugs as often. There used to be some really bad bleed over, especially when creating a new save (since OnLoad isn't called because there's no preexisting save file). There are definitely some other places that could use polished up. If you notice them, jot them down, and I can try to fix them up before release. I'm thinking mostly of GUI issues. Things like the build list still having the VAB or SPH button highlighted but that sub-window no longer being open, requiring a double click to open it again. Or window sizes being off. Etc. I have a bad habit of not spending enough time on polish :/

Ok. Think all the mentioned issues are fixed now. Update your Presets again since I changed how reconditioning is calculated (another RP-0 request). Just need to add "*abs([RE]-)" to the end of the line to get it to behave how it does currently. All the KCT presets should reflect the change. The change allows rollout and reconditioning to be calculated completely separately from each other, with a bit of careful formula construction at least. I'd like to lock things down sooner rather than later, so if there's any other suggestions make them soon! I'll probably push a release as soon as I can get the build server up and running, which will hopefully be this weekend (I'm spoiled and like not having to do it manually anymore )

The update checker has actually been removed in the next version completely (but I may add it back for development versions). The reason it's having issues right now is that my server is down (since last Friday and will be until probably Sunday, maybe later) because I had a hard drive failure and if I lose another drive then I lose all my data. I've ordered replacements (replacing my 3 rather old 1 TB drives with 3 brand new 3 TB drives), but I'll have to set up the server from scratch again. For now, AVC and the built in checker won't work at all.

The current topic of discussion is actually that simulations don't appear to be working at all. When I get home from work I'll make it top priority. Thanks for the report and being patient As for the RP-0 Preset, that's all (mostly) NathanKell. Expect some changes to it when he gets a chance to play around with more of the settings. I'll add it to my list, hopefully related to the other issues you're seeing. Two bugs are less fun than one E: The reason that save command was added was to get around the fact that when you close the RnD screen after purchasing a node, the game thinks that you still have those nodes unlocked, but KCT gives you points for the nodes that are in progress, meaning it double counts until the next save. My shortcut was to just save it manually. Apparently that has the fun side effect of breaking everything!

For some reason it looks like it's swapping in the KCT save and then the game is saving. That's definitely not right. If I get a chance I'll try to take a look at it myself tonight. Thanks for testing that for me. If I weren't at work I'd test it myself right now.

What if you simulate for, say, 3 hours and go back to the Space Center instead of reverting? What does the save made by KCT have as the UT= string (you'd have to check when the simulation is running) and then what does the persistence.sfs UT= string say after revert? I did change how the backup save gets made, but that's still made before the simulation even starts.

I'm pretty sure this should be doable. Like you said, I should at the very least be able to make them less destructible. I had some code before that would temporarily set everything to indestructible when you launch to get around the issue of everything exploding when the vessel is spawned, but it sounds like I'll need to come up with something a bit different from that for this. No estimate on an ETA as it's the work week again and I've got some other things I'm working on.

Ah, I knew I was forgetting to fix something. I'll get that fixed tonight. You are correct, it should be less than or equal to zero is treated as 1000 years. As for the rest of that check, it should stay in the function that's specific to calculating simulation costs, as it's simulation cost specific and the ParseColonFormattedTime is used elsewhere (most notably in determining the UT to start the simulation at, which was the reason it was originally written). It should be set null when switching to the MainMenu, but it should be reinitialized right away in Start once the Space Center starts loading... I'll look into it further, but I don't remember having issues with it in my testing. Might be related to using the toolbar mod?

There was a KCT related issue logged, but KCT itself seemed to be working properly. Maybe an issue with assigning the function to be called when the button is pressed. Let me know if you see it again. [LOG 01:30:27.868] [KCT] Adding Toolbar Button [EXC 01:30:27.870] NullReferenceException: Object reference not set to an instance of an object KerbalConstructionTime.KerbalConstructionTime..ctor () KerbalConstructionTime.KCT_SpaceCenter..ctor () UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelWasLoaded(Int32) E: Could be because it tried to access the loaded preset prior to the preset being loaded. I've added an extra check to make sure that can't happen. E2: Should hopefully be fixed now. Additionally, just added a new Formula for the RP-0 devs. It makes it so it costs funds to rollout a vessel and takes the funds in 10% increments of both time and funds. So if it costs 10k funds to rollout and takes 2000 seconds, then every 200 seconds you'll be charged 1000 funds. If you can't afford it, the rollout pauses at the next 10% increment until you can afford it. NathanKell wanted it so they could use it for the final integration costs, while the normal costs are just the raw materials.

It should be treating zero as 1000 earth years for cost, and infinity for the actual time limit. I'll have to double check that. I spoke with NathanKell earlier and he asked for a way to charge funds for rollout, so I'm gonna try to add a formula for that tonight as well (default of 0) Also, if you type in more than 1000 years it should still only charge you for 1000 years.

I think I've got that fixed now, along with a couple other bugs. I also added two new (relatively simple) Presets and slightly modified the default one (the simulation cost formula was ridiculous for the Sun because of the mass difference). I've posted a dropbox link to the .dll, but the Presets can be downloaded from github. I also have added a half-working attempt to override RemoteTech. It seems to work fine when there are no antenna, but when there are antenna on the craft it only half-works. You regain the ability to move, but not to enable SAS or stage. With no antenna it works perfectly. My attempt to unregister any antenna it finds apparently wasn't good enough to fix that issue, but thankfully the SPU has a public OnDestroy function I can call through Reflection (the antenna's is private, but doesn't seem to help much anyway when I replicate it manually).

If it was working properly you'd receive the point when you purchase the node, but I realize now that isn't going to work correctly with how I've got it coded. I'll have to tally up the in-progress nodes when I calculate the total number of upgrades. Since that entire system was rewritten, there are bound to be a few glitches. Also, have you been having your global settings resetting? I'm pretty sure that's been happening to me and I'm not sure why. I'm planning on spending some time today on fixing the reported bugs, and maybe playing around a bit more with simulations (to either disable RemoteTech, or to change how the code that puts the ship in orbit works, or both)

Just press the * button after the craft has been recovered to edit the craft in the editor. Then replace the broken wheel. No clue whether or not that will work properly, as KSP may not allow broken wheels in the editor. You may have to add it to the list of things that are "fixed" when recovering to storage. Here is a walkthrough I wrote that explains how to do that. Alternatively, you can send me the before and after craft files and I can do it myself. Either way, that's probably something that should be reset, so if you do end up adding it yourself, please send me the config you come up with so I can included it in future versions

I've looked into the RT API and there doesn't seem to be an easy way of telling it "make this vessel controllable" or "disable yourself, please". I really want to find a way around that, but it's a secondary objective. I used to play with RT all the time and simulations with it were sometimes unbearable because I just needed to turn on an antenna. kOS can do that now, so I could always write a boot script to do it, but that doesn't work for everyone else. I'll try to look into it some more. I don't know if it will work with Custom Barn Kit. If KCT currently works properly with it, then yes it should, as all I did was make the checks not disable building the vessel in the editor, while the current implementation outright prevents construction of the craft. If it's working as it should right now, it should continue to work properly after the update. If you test that, please let me know, as right now I have no clue if it works properly. I added this in an edit above, but I'll mention it again and bold it. The build server is down. It will probably be down for a week or more. It had a hard drive failure (need to get home to verify, I'm at work now). I've purchased three new 3TB drives to replace the three old 1TB drives that were in there before, but they won't get here until the middle of the week, and then I'll need to set everything up again. Wow. That's gonna suck to do... And I JUST got ASP.NET applications running on it last weekend. I'll have to set up Jenkins again too. It'll be an all weekend project.

You should just generally assume there are bugs with that code, as it only works about 50% of the time, which is why KCT makes a quicksave before it attempts to recover. I should start keeping a list of situations where it definitely has issues to see if I can figure out ways around them in the future. Here's the list, as of right now: https://github.com/magico13/KCT/issues/82