magico13

Well, this seems to be the problem: NullReferenceException: Object reference not set to an instance of an object at ShipConstruct.LoadShip (.ConfigNode root) [0x00000] in <filename unknown>:0 at ShipConstruction.LoadShip (System.String filePath) [0x00000] in <filename unknown>:0 at FlightDriver.Start () [0x00000] in <filename unknown>:0 which indicates to me that maybe the craft information got corrupted somehow. Hopefully it's just local to that craft. You might be able to scrap it and rebuild it still. Have you tried launching a brand new ship, rather than one from storage? I would suggest doing that and also trying a new simulation. Could you go into the KCT settings and turn on the "Enable Debugging" setting for me, that way the log will contain more KCT specific info should you send me another. Thanks! One other thing, it might just be that the simulation backup file hadn't loaded (since you went from space center to flight directly) so I'd try loading up the VAB or SPH first, then going back to the Space Center and launching.

I don't personally know how to calculate a trajectory change to land back at KSC (though it's certainly calculable, but I don't know the math orbital mechanics well enough). Delta V is easy enough to calculate, SR already does calculate it and use up the appropriate amount of fuel for powered landings. Maximum distance percentage you can get is 98% (even in the stock game being landed at KSC nets you 98%, only runway/launchpad get you 100%). I agree it would be cool, and I was originally planning some sort of hand wavy system of reducing distance by using fuel, but I feel I should probably do it somewhat accurately if I can.

And if you're feeling particularly adventurous, the latest KCT development builds should support CrewQ. Note that the new features I'm working on don't work properly yet, but there's a bunch of bug fixes for existing problems. (aka, don't use the recover to ship storage feature yet. The KSC button doesn't do anything in the main GUI yet either.)

This doesn't make any changes to normal recovery mechanics, so it's probably not the cause. I'll take a look at any logs you provide if you want, as they might contain some info. Does that happen even if you recover from the launchpad? Also, does it happen on a new save? If so, you can easily figure out which mod is causing it by either randomly guessing which mod it is and removing that from your list, testing, then repeating until you find which one caused it, or you can do it the faster way by using a binary search. For that, you'd remove half your mods and test. If the problem persists, then the faulty mod is in the installed half, if it goes away it's in the other half (in which case you reinstall that half and remove the currently installed half, so you can keep retesting). Then keep dividing your mods in half and retesting until you find the one mod that causes the issue (or at least you will have narrowed it down quite a bit). If it's an interaction issue then this might not work properly, in which case log files might provide some clue, or you just have to test all combinations.

Probably. Do you have tweakable everything installed as well, since people were reporting that as being needed to get the lag. If you use the latest development version from the build server then you should see that lag pretty much eliminated. I'm on my phone and links aren't working right, so here it is: http://magico13.net:8080/job/Kerbal%20Construction%20Time%20Development/

Since the stages don't actually ever reach the ground (if they did, StageRecovery wouldn't be needed) it's not as simple to check if they're splashed down or landed on solid ground. However, I have been planning on adding in support for the Trajectories mod for more precise landing calculations, in which case I should be able to check if the predicted location is in the middle of water. Ideally I'll be able to query the PQS system for that, otherwise I'll have to assume that the water biome is entirely water and everywhere else is land. It should be doable though

Side effect of how simulations are handled vs. launches. Simulations go through the official stock editor checks but builds don't. The reason I didn't disable builds for craft with unresearched parts is because of part testing contracts. As soon as you start researching the node the part you need to test is in, you lose access to it unless you've got a craft with the part on it saved. When I can get around that, I'll lock down builds, but it's a low priority. That should be possible to do. It'll be a rough estimate though, since things can sometimes get recalculated and with the different build rates I'll have to do some math trickery to get semi-accurate estimates. Which things specifically are rolling over to negatives? Is it just buying upgrades with science and/or funds? Or are there multiples? I'll see what I can do about them. Someone had alerted me to a similar issue on reddit. Here is a link to the github issue about it: link. We've got a potential solution set up in the dev build, but it's untested. If you would be willing to try out a potentially unstable build (new features aren't working correctly, but normal gameplay would be fine) I'd love to have that fix get tested (direct link to the .dll, link to the build server and change log. For reference, the current released version corresponds to build number 50)

That should be an issue only after 29 upgrades (plus or minus one if my math is faulty) because that will cause an integer overflow, then again all math being parsed by KCT uses doubles and not integers (though theres probably a cast to an integer in the GUI code, maybe in the actual code as well). Can you verify for me at what amount it rolls over? A simple fix is to use a larger integer (64 bit ints can be quite large, over 9 quintillion) but I'm not totally sure why you would need to buy 30 upgrades. Also, that should hit the maximum value fairly quickly (7 upgrades).

So the way I have recovering to the inventory working at the moment is that it takes at minimum the same amount time as it would to roll the vessel out (based on mass, even for planes currently), with it taking double that time when you recover on the other side of Kerbin. It obviously at minimum must require the amount of time it takes to roll out a vessel, otherwise recovering to the inventory would somehow be quicker than rolling the vessel back (which would be a logical prerequisite). The biggest issue I'm having with it is that when you go to relaunch it messes up the game. I'm not totally sure why yet, but it works to the point where you can edit the ship in the editor to swap out parts/refuel the vessel (which you have to do manually at the moment). I was trying to get time requirements for upgrading buildings working properly, and while I can calculate the time amount and prevent upgrades until it's complete, I've run into an issue with trying to actually have the building upgrade when it's done. With school+work I haven't had as much time to focus on figuring out those seemingly simple issues.

If StageRecovery is recovering something, that means KSP deleted it, so turning off StageRecovery would just mean those would be deleted without recovering any parts. If you want to do drop pods without extra mods then you'll need to drop them low to the ground and stay within physics range until they land (by circling and staying within about 2 km). If you want to add extra mods you can either add one that increases the physics range (like BDArmory, which doubles it) or FMRS which will let you switch back to when you dropped the pod so you can land it manually (and then it merges the save states into a final one).

Well, firstly you're running a development version of KCT, and more specifically you're using a development version that wasn't supposed to be used for normal gameplay as it purposefully breaks upgrading buildings. So I would advise either switching to the release version or build 64. Although that log also states that the latest version was the one you were using, which hasn't been the case since January 6th so that must be an old log file. Looking at that log I otherwise couldn't see anything related to the issue. Let me know if you happen to find anything in your testing.

I honestly don't know. Since it gets recovered at 100% science value, it should be considered as "recovered" instead of transmitted, but I'd highly recommend a quicksave first because I don't know for sure that it will work properly. Don't forget you can use Alt-F5 to save multiple quicksaves. Let me know the results if you test it!

You must be confused because the rates have always worked how you described it working in 0.90. The only change in that system since it was added in PR3 was that the initial rate dropped from 1.0 to 0.1 and you went from 0 upgrades initially to 15. The first line was always 0.05 and the second is 0.1 (third is 0.15, 4th is 0.20 and so on) Were you perhaps thinking of purchasing upgrades, which doubles in cost each time?

Hmm, that's a weird place for it to have issues. Can you upload the full log (not the KSP.log but the output_log.txt file from KSP_Data if you're on windows) and a mod list? Did you change any settings at all, or are they on their defaults? The only things that I can think of that could be null when they shouldn't be are the Space Center and the ProtoVessel on the vessel, both of which shouldn't be null, but it's possible that another mod somehow changed one of them (maybe Kerbal Konstructs/Kerbinside, or RSS) or something strange happened that will hopefully be in the log.

The method by which DR is supported is pretty weird. SR checks if it's installed, and if it is then it looks at the speed the vessel was going when deleted by KSP and assigns a percent chance of burning up based on that speed. It's the DR Velocity (something along those lines) in the settings. By default it's 2000 m/s (remember that KSP doesn't apply physics to unloaded craft, meaning air resistance won't be applied at any time and it isn't destroyed until about 22 km, so it'll be going way faster than it should). If the vessel is going slower than 2000 m/s then it's perfectly fine, if it's going 2100 m/s then there is a 10% chance of burning up, at 3000 m/s there is a 100% of burning up. If you have a heat shield it will reduce the chance by whatever amount of shielding is left, meaning you can be completely safe up to 3000 m/s, but above that you start getting a chance again up to 4000 m/s at which point no heat shields will protect you. It's a rather arbitrary system but it prevents you from dropping things into the atmosphere at high speeds and taking advantage of the physics not being applied. If you want to make things burn up more often, just lower that speed in the settings. The chance of burning up should be 100 x 2 x [(srf_speed / DR_Velocity) - 1], which in other words is 2% per 1% that the surface speed is faster than the DR Velocity setting. As an example, if you set it to 1500, then 2000 m/s will have a 67% chance of burning up, rather than 0%. I should point out that it's totally independent of the actual DR settings since the system is really arbitrary.

Hmm, very interesting. Though it looks like he's also just managing the control locks, so I'm not too sure how it's different from manually doing it. Enabling any of the KSC locks will still freeze time in the Space Center (unless they fixed that in 0.90). When I fixed the window position to the top right I actually removed the control lock associated with that, so time no longer freezes when you hover over the window or click the buttons. You can click through them, but you'd have to move the camera to make it happen.

Then there's likely another mod having an error that then breaks the loading of this mod (most likely case). If you have Kerbanomics or Tarsier Space Tech installed (definitely the latter one) then it's likely one of them. Kerbanomics has an issue that only occasionally comes up and can be fixed, Tarsier Space Tech has an issue that can't be fixed without recompiling the mod. If you don't have either of those, or removing them doesn't work, then I'll need to see an output_log.txt file. You can use this post to find it, but if you have any questions let me know. If you're using a windows computer then it'll be in KSP_Data, which should be next to GameData (well, near it) in the KSP folder.

I haven't tried, but I think the limit is around (2^31)-1, which is 2,147,483,647. However you'll hit the memory limit if you try to have that many vessels. Your game will also lag a lot. Also, that's per list, so you could have that many building in the VAB, building in the SPH, and stored in the VAB and SPH. So effectively 4 times that, so 8,589,934,588 or so across the lists I had originally planned on putting in limits, but decided against that. There's a chance there will be limits once I integrate into the stock upgrades a bit more. Probably not next release. a) I also was noticing that it's annoying to not be able to see (at least) the class without going into the Add screen, so I'll try to add that in. It used to be that whatever state you left it in would be the state it starts in, but since I changed it to be in the same place as the other "Stock" windows I didn't want it to always be in the way. I don't think I'll make it persist in the next update, sorry. c) Would "ready to launch" be the same as the storage, or just those that are on the pad and/or rolling in/out? I could maybe move vessels that are on the pad to the very top of the list. I might be able to allow you to collapse the build/storage sections separately (but with my GUI skills it would likely look/act weird). I can probably make it so you can resize the GUI height, but I don't actually know how to do that and I'm not going to make it a priority at the moment. I haven't seen that before, but I'm going to guess it's related to tweakscaled/procedural parts having their masses be detected wrongly (which includes RealChutes). It could also be related to the launchclamps? The way KCT calculates the mass for the vessel in that instance is by asking all the parts what their mass is, then adding the mass of all the resources (loop over the ShipConstruct.Parts, summing part.mass and part.GetResourceMass()). The parts are possibly reporting their masses incorrectly then. I'm not sure what I can do to fix it, or which value is correct! I meant to add something like this in the past. I can see one issue that might come up, and that's when times get recalculated when a vessel is completed, but otherwise this should be a fairly simple addition. I also meant to add a way to launch while the launchpad is being refurbished, at the penalty of having the remaining time doubled and then added onto the new time. I'll keep that in mind when I'm working on things later. Speaking of which, sorry I haven't made much progress lately. I keep planning on doing things over the weekend, but I end up getting distracted and playing games with my fiance (this past weekend it was Starbound, the prior was Hyrule Warriors). During the week I've got school and work, which occupies an annoying amount of time. Believe me, I would much rather be working on KSP things

Glad to hear nothing's super messed up then! Simulations should act like normal flights, but sometimes weird things happen and some bugs could have cropped up and caused issues, which is why I was curious about what specifically was different. Let me know if you do find anything definitely wrong in the future!

If you don't have the toolbar mod installed then it will automatically use the stock one, but I was just thinking that I should add a manual override into the settings, so I'll get that into the next release.

Like seronis said, simulations are identical to real launches except that you can't quicksave or quickload. All KCT does is copy the save file, then overwrite the save file with the copy when your done. If something's working properly in sims, but not in real flights, then it's likely just confirmation bias since the situations are identical. I'm curious as to what kind of things are happening during the real launches that are causing failures but aren't happening during simulations.

The 6km repeat for the shiny spots makes me think they're related to Krakensbane, the code that resets the origin of the universe every 6km to be right where you are (thus avoiding loss of precision in floats). It's possible that the light spots are in fact a single light spot that is teleporting. Have you ever driven back one or two light spots to see if they're still there? I have a feeling they might not appear in exactly the same place if you go back, but that's just speculation. Btw, this is a great read! Looking forward to the rest. You seem to be making good time. I don't think I could do it! Though it does make me want to try to do something similar using kOS, but that would be a lot of code to write.

Maybe "Alt"+"," (or < if you think of it that way). While they're at it, I wouldn't mind an "Alt"+"." to go to max available warp. Edit: I am an idiot. Alt+ the warp keys is for physics warp, so Alt+. wouldn't work. Though Alt+, would still work in physics or normal warp.

Bought the game during 0.20.2. Landed and returned from Mun during that version. I think my Duna rover was also this version. 0.22 - First Minmus landing, rescue, then a second rescue, then return. Sometime around here I sent an ion probe to Moho but ran out of fuel. 0.23 - Started working on Kerbal Construction Time. 0.23.5 - Jool 4 mission in Alternis Kerbol (Pol, Mun, Laythe, Minmus). First Eve visit, but just probe landers and a remote tech network (with Alternis Kerbol, so no Gilly trip) 0.25 - Started doing Twitch streams. 0.90 - Returning to Duna, this time with a manned lander and OKS station. Not yet transferred, still doing orbital construction. SoonTM I didn't get to play much of 0.24.

But without launch clamps unlocked yet, it isn't practical to launch a vessel and have it only half full of fuel. I agree that this isn't how it should work. It should be fully fueled when the "launch" button is clicked, and then once it's on the pad it's up to the launch clamps to keep it fuelled.