magico13

I find that difficult to believe since it only does any work when you take screenshots, and all it does is rename some files (unless you also have conversion to JPG turned on, in which case it would need to use a bit of RAM and I could imagine it might not release the RAM properly). I'll entertain the idea if you supply logs and proof that it's Sensible Screenshot causing the crashes and not something else. If you're getting crashes, I'd ideally like to see the whole crash report, but just the logs will suffice. I'd also like to see the settings you're using for Sensible Screenshot, a mod list, info about what OS you're on, and what you're doing during these sessions (ie, taking screenshots about every minute during a flight to the Mun). If during that hour you never take a screenshot, then I don't believe Sensible Screenshot is even related. If you're taking thousands of screenshots then I could believe it. If it happens when you take a screenshot under particular conditions (in flight, over the Munar Poles biome, with a particular craft) then I could definitely believe it then. So far you haven't given me any info to work with, other than a claim that has a good chance of being related to something else. If you can reliably crash it, then the reproduction steps would be very helpful. As you can imagine, there are virtually limitless differences between any two KSP games (mods installed, missions being run, operating systems, KSP versions, game settings, etc) and often times bugs require a specific combination of things to go wrong.

Yeah, definitely doesn't appear to be working properly with multiple ships. I'll maybe get a chance to look at that tomorrow. Getting something to happen when hovering over a GUI element isn't as trivial as I would have hoped :/

Presets are now released for Beta testing. It's slightly save breaking and there's quite a few changes I haven't gotten around to testing, so I really do not advise trying the betas yet if you're not ok with some save breaking, but I'd like to get a couple Presets to include in the next release, so people should try it out

Hello everyone! KCT's got a new dev version out (build 121) with the new Presets feature! It needs quite a bit of testing. There were a good number of changes/new features that I haven't gotten a chance to play with yet (simulations for instance got their costs completely changed). This update is slightly save breaking. All of your settings are pretty much invalid now as they've been moved into the Preset system. It doesn't attempt to automatically create a new preset based on your settings, so you'll need to set them up again if you weren't using the default. Your old settings shouldn't get deleted, but no promises (back them up beforehand if you need to reference them later). Setting up new configs is MUCH easier now, and you can have different sets of configs for many different play styles. I need to write up some documentation on the wiki for Presets (and maybe for KCT in general), but if you have questions please ask them here!

Presets are coming along nicely. Hopefully they'll be ready for testing tomorrow (Sunday)! Just need to add in the general settings somewhere and make it so you can save new presets based on your current settings. I'm curious what your thoughts are. I'm trying to not make it too hideous or difficult to work with, but GUIs are not my forte. The keen eyed of you will notice there are quite a number of new formulas and settings. The whole settings infrastructure was rewritten pretty much from scratch.

That's just because the .version file says it only works for 1.0.2. I can't change that after a release. Actually. If I change the one on my server it might actually realize it works on your end as well... aaaaannnndd DONE. Changed on my end, which might make it not say it's incompatible, but I don't know for sure.

I'll try to make things as clear as possible to prevent any further confusion. 1) KSP deletes the craft due to it being in atmosphere and unloaded. This occurs if the stage is 22.5km away from the active vessel and is at an altitude below ~23km. If altitude > 23km but distance >22.5km, the stage is unloaded and NO physics is applied to it, other than acceleration from gravity (but no atmospheric drag). This is when SR starts its calculations. 2) If the current surface velocity of the stage is > 2000 m/s AND the save game has reentry heating enabled, SR does a check to see if the stage is burned up. The process is outlined in the OP. It is possible that this is an "unrealistic" speed, since atmospheric drag may not have been applied to the stage like it should have been and so the stage is going faster than expected (due to being >22.5km away but above 23km altitude for part of the trajectory). 3) SR calculates the terminal velocity based on parachutes and vessel mass. For RealChutes it uses the exact formula. For Stock it uses an approximate formula that can be off by up to 2 m/s in testing (in either direction), since I don't know how to calculate it exactly anymore and I needed something quick for 1.0.2 (the old method worked in 1.0) 4) If the calculated terminal velocity is >6 m/s (the Low Cutoff setting) then it attempts powered landing. First it checks for a pilot or probe with SAS capability. If that's found, it calculates the total thrust to weight ratio based on active engines and the amount of delta V the ship can provide. It then consumes either enough fuel to drop the terminal velocity to 4m/s (at a rate of 1.5 times that of normal, to represent inefficiencies in piloting. AKA, it requires 1.5 times the terminal velocity in delta v, which is about 300 dV without chutes and can be as low as 50 dV or less with some chutes) or it consumes ALL of the fuel and calculates the new terminal velocity. 5) After determining the final velocity it sets the Speed Percentage based on where the velocity lies in relation to the Low/High Cutoffs. If V>High Cutoff, then 0%. If V<Low Cutoff, then 100%. If Low<V<High then it calculates it based on a quadratic. 6) The latitude and longitude at deletion is used to calculate the Great Circle Distance from the KSC, giving the Distance Percentage between 98% at KSC and 10% on the other side of Kerbin linearly (depending on Tracking Station level actually. At Level 1 it's 10% at 1/4 of the way around Kerbin, at Level 2 it's 10% at 3/8 of the way, and at level 3 it's 10% at 1/2 way around). 7) The Speed and Distance Percentages are multiplied to give the final percentage. The total part values are calculated and funds equal to Total Part Value * Final Percentage are awarded. Kerbals are "recovered" (set back to Available and un-killed in their flight log). Science is recovered at 100% rate. And the success message is created, along with firing of the Success event in the API. There you go. That's pretty much everything SR does to recover a craft. The main steps are checking if burned up based on current surface velocity, checking parachutes, then checking powered recovery if needed, and finally calculating returns. - - - Updated - - - The chutes don't have to be opened, it's just a recommendation since the physics bubble is large enough now for some things to hit the ground. Carefully setting the chute parameters so it doesn't predeploy until close to the ground (like 5km) is one workaround. Or just drop them from high enough up that they won't hit before getting out of physics range.

I'm curious what examples you have and what problems you see with it. Mods don't tend to put things in other folders for no reason. Even so, I'm not sure why it would be that big of a deal if they did.

Ah. Unfortunately I'm not really sure if I'll ever be able to get it to work 100% correctly, since it tries to do things that KSP isn't really a fan of (turning Vessels into Ship Constructs), so there's a good chance it won't work for your particular ship then :/ Especially with other mods, there's a lot of things that can go wrong. What exactly are you trying to do? There might be a way to do it a different way. You said you're trying to edit the root part, but for what reason? If you just want to turn the nav ball around, you can right click on the thing you want to control from and click "Control From Here". If you're trying to swap out parts, you might be able to use KIS (unsure, I haven't tried it). Ships with things docked to them seem to have more issues, so you might try making a quicksave, then undocking everything you can and then editing it, but there's a good chance other mod related issues will prevent things from working properly. You can send logs if you want, but I'm not sure that I'll be able to really figure anything out right away to fix it.

It should work fine with 1.0.4, but I haven't really had a chance to check. I'll take a look at it either tonight or tomorrow (maybe add support for air brakes as well if I can), but it should still be working about as well as in 1.0.2

I'm actually using it in a pretty realistic career mode by roleplaying a corporation that just buys parts that are developed by other people. Basically, I turned off science and turned on part purchases and just unlock nodes that the R&D center would allow me to based on level. I hate grinding out science so it's made the game much more fun for me

Air brakes are not actually included in the calculation currently. I'm not even sure I'll be able to figure out a formula to use to include them, but I'll add it to my to-do list anyway. SR looks only at parachutes and engines. If the message doesn't say you're below a safe speed, then you need more parachutes. If it says you're below a safe speed but it also says that it's burned up, that's because it was going too fast when ksp deleted the craft. You can use the tool in the editor to see what the calculated terminal velocity will be.

I haven't messed around with it too much lately. My dev time has been spent on my other mods and I've been otherwise preoccupied with other projects and/or work. But it's fairly safe to give it a try since it makes a quicksave (a new one) before it tries to bring the ship into the editor, so if something goes wrong you can always revert back. There's still the Kerbal issue in that it will likely kill any kerbals aboard, but a quick EVA should keep them safe.

I used Load On Demand extensively in 0.23 and 0.23.5. I'd get RAM related crashes every now and then, but after it added texture compression it was never an issue. The absolute best part of it was the lightning fast load times, which is the main reason I used it. Even the new DDS textures on a Stock game don't compare against a highly modded 0.23.5 game with LoD. I really wish Squad would come up with a better way of handling texture loading. I'd like to see that long before a Win 64 version, as I see the 64 bit version as just a temporary fix to the real problem. There's no reason we should HAVE to use more than 4 gigs of RAM when we're only using 1 gig of textures at once. Once 64 bit comes out and people start getting crashes from hitting their system limits of 8 gigs, or even 16 gigs... then we'll just be having this discussion again of "My game crashes when running a bajillion mods!". Plus, the complaints about load times.

I kind of like that idea for clearing out the inventory. It gives a tangible benefit for clearing it out, while not being cheaty. Players who use reusable craft with the same parts extensively won't have an inventory that's worth much, but they benefit from reduced build times already. Players who don't pay much attention to the inventory will likely have a lot of parts in there, so clearing it out will let them speed up their main rates and continue having speed increases as their career goes on. If other people like the idea, I can probably get it in the next update pretty easily and provide a formula for it so people can tweak it (or disable it entirely). I'm thinking the rewards should probably taper off as you "sell" more parts, as it shouldn't be a main way of getting upgrades. Which means the total value "sold" previously will have to be a variable in the formula (if it were linear, then that wouldn't be an issue), which shouldn't be hard to do.

Altitude is ignored. In fact, there's not even an approximation for calculating a landing site, it just uses the latitude and longitude where the vessel is deleted at. I've wanted to try to include support for the Trajectories mod to give somewhat accurate landing site predictions, but I haven't thought of a good way of that working (the big issue is that there's a large amount of time where the stage doesn't experience atmospheric drag because it's unloaded and above 23km, so if you do the calculation when it's deleted then that's pretty inaccurate. The best time would be when it gets unloaded, but I need to see if I could even have Trajectories run a calculation on it then) FAR and RealChutes will actually have better Vt predictions than Stock does. For those, it uses the same formula that RealChutes does to calculate the parachute size you need, but in reverse to solve for the velocity. For Stock it uses a formula fit to some data points for various parachute sizes/mass vs. terminal velocity that I went through and tested in 1.0.2. I probably need to make changes to it for 1.0.4. If you do notice that a piece of information is missing, let me know and I'll mark it down to get included in future updates. I'm not personally a big fan of random failures since there's not much you can do to prevent them from happening. There's a possibility I could add support for a random failure mod like Test Flight or DangIt if they include failures for chute opening or engine firing, so that there's a possibility of a random failure happening based on those mod mechanics (I know I could do this with Test Flight as I've worked with the API for it a bit).

If it burned up, it will say it was burned up. If you need more parachutes, you'll know because the terminal velocity is > the Max Cutoff Velocity (both of which are listed in the message). There's even more info in the Flight GUI rather than the smaller popup messages. Where it might not mention anything is if you're trying to do powered recovery of a probe that doesn't have SAS or a ship without a pilot. For that it will just say the terminal velocity is too high.

Cool, looks like I won't have to do that myself then The error that KCT pops up with isn't necessarily an error within KCT, it just means that KCT didn't get a chance to load it's data (which is frequently caused by errors in other mods). If you're trying the 64 bit Windows Community Hack, for some reason KCT hasn't been working properly in it and it's not a priority for me to fix (since it appears to work fine in every other version of KSP, including Linux 64 bit), as Nori has kindly pointed out. You're always welcome to send logs, but there's a chance they won't contain any helpful info. Just saw your update (prior to actually submitting this response). Glad it seems to be working now. If you've got any other issues in the future, don't hesitate to ask (but do provide logs )

Hmm. It could be Kopernicus/RSS related as I've seen a few issues with Kopernicus in virtually all my mods. As for the log file, the post I linked contains the info, but I'll also quote it here to make it easier to find.

FMRS is a mod that does some kinda cool save file trickery to let you fly multiple things at once. If you check out the video on the first post by Scott Manley, it covers StageRecovery and FMRS. http://forum.kerbalspaceprogram.com/threads/80292-1-0-2-Flight-Manager-for-Reusable-Stages-%28FMRS-v1-0-00%29 Unfortunately I don't think I can see those pictures. They appear broken to me. As for the problem, it could be that the changes to physics range in 1.0 (now 22.5km instead of 2.5km) means that your boosters are actually hitting the ground instead of being deleted (StageRecovery can't handle those) but if your chutes are armed then that shouldn't be a problem. It could also be an installation error. If you're not seeing the icon in the toolbar in the Space Center or VAB then that sounds like a bug (but make sure it's not just hidden in the Blizzy Toolbar Mod, since it only appears in one or the other). If none of those sounds right, then could you send me a log file and I'll see if it's even being enabled.

I think sarbian has a mod that can do this. Others are reporting similar behavior. I'll have to look into it as something may have changed with XP internally between 0.90 and 1.0.2. All Field Experience does is call the Stock function that calculates XP, but for some reason that's not working exactly right. I haven't gotten far enough in my own game to see the bug occur (I don't get to play very often, so I'm not all that far along) so I haven't been able to test it. If anyone has a mostly stock save that as the problem, please send it to me. As long as the Kerbal/Vessel in question doesn't have any mod parts I think I can load it and test.

Hmm. An interesting idea. Not sure if it makes sense to be part of KCT proper, but could be a modlet that becomes part of the whole Space-Time Continuum modset. Hmm. It is strange that Kopernicus would cause that, but thank you for taking the time to figure that out. Definitely helps me to test possible fixes. Has anyone tried KCT with 1.0.3 yet? I'm about to try it myself but figured you all would notice issues before I do

I've seen it reported at least once before, but haven't gotten enough info to pin down anything. KCT has a kinda weird way of handling KSC upgrades and I might actually change it since I can imagine some other cases where the current method would cause issues. Right now KCT waits until a building is upgraded, then downgrades the building and applies the timer. Unfortunately, downgrading a building triggers the building "upgrade" event, but there's a workaround in place to prevent it from then further downgrading. Apparently, something somewhere breaks that workaround. I might instead override the upgrade buttons to call my own function, which will be incompatible with any other mods that do that (none that I know of right now, but the overriding of the Launch button has caused an issue or two in the past). Good idea! Not sure how easy it is to add a popup tooltip (without switching over to TriggerAu's Plugin Framework) but it should be doable. I might try to switch over to that framework at some point anyway. I'll add an issue on GitHub to remind me to at least do the tooltip.

RSS fix should be up, with a few other features that I had been working on as well. It didn't go through an extensive testing period, but it was mostly bug fixes anyway. Let me know if you find any issues in 1.1.8 and if so I'll get a new update out to correct them Most of the work I've been doing has been in the Presets branch and isn't ready for public consumption yet (unless you like GUIs that are missing two thirds of the content needed for them the be remotely functional and settings that don't actually change anything )

RSS used to still keep the planet names, so using "Kerbin" still worked for Earth. I'll get a fix out tonight but until then there's not much you can do to fix it.