magico13

Hm, impact speed isn't colored by which region of the speed limits you're in, I should do that (I didnt add the colors, it was a pull request (an awesome one)). The stage is landing faster than the minimum cutoff so there's a chance of losing parts (but you still get the funds). Basically if you recover 75% based on speed, there's a 25% chance per part that the part is too damaged to be reused and has to be sold for scrap metal. If you want the all or nothing system KCT used, go into the SR settings and change to the flat rate model or turn up the minimum cutoff. But basically you need more chutes. It should be noted that SR's calculations are higher than reality with the new aero, but chutes are also really unbalanced in the new aero. Real Chutes still works precisely.

It shouldn't conflict with HyperEdit, but I also haven't tested it in 1.0 yet. The changes to the editor may have broken the part of the code that loads the ship when the editor loads, or it might be a problem with the craft you're trying to use. If something else uses F10 that might also be an issue. I won't likely get to test it today, but I'll try to get it updated tomorrow.

Ok, well instead of working on homework I decided to work on Sensible Screenshot. You can now define the file names yourself in a config file, including the full DateTime format and a bunch of other in-game variables (check the OP for the full list, in the spoiler tag). Additionally, you can automatically convert the screenshots into .jpg files of whatever quality you want (between 1 and 100, default is 75), which uses way less disk space but might take a bit more time on slower computers. I've put up an album with some comparison pictures and their file sizes. When a particular piece of information (such as the active vessel name) isn't available, it will usually be replaced by NA (as in, Not Applicable). Times should be replaced by 0 if they can't be determined. I didn't test every possible configuration, so let me know if you run into any issues. Also, since sometimes the game might add spaces into a file name (such as for the "Kerbal X" craft), I've added the ability to automatically replace spaces with whatever character(s) you want. In the example in the OP I've used the # symbol, but the default is an underscore: _. I hope that's enough features for now

Actually, I fixed that during this update. Upgrades should wait to complete until you're in the Space Center. E: Woot! 1000th reply to this thread! E2: I should clarify that I didn't fix chrisl's issue yet, just that I fixed the issue with being outside of the Space Center scene when an upgrade completes causing you to "lose" the upgrade. I'm going to also use this post to shamelessly plug another one of my mods. Sensible Screenshot just got a big update which makes it so you can automatically rename (and convert) your screenshots to unique file names that can contain specific in-game information, like KSP version or Save name, or Active Vessel name and biome and situation and parent body, or the current in-game time (obviously in addition to the out of game time).

Ribbons and actual experience are pretty different though, unless FF also adds experience to Kerbals as they do things. Field Experience will actually level your Kerbals as you go, meaning your Pilots will unlock additional SAS modes, Scientists will start earning more science, and Engineers can repair more types of problems, without first having to return to Kerbin.

It is not a known issue, so thanks for the report! It should be that when you turn on Instant KSC Upgrades any in-progress upgrades should complete right then and there. If that's not the case then I'll have to fix that. I'll take a look at that later when I've got a bit more time

Since this mod just takes the "screenshot0.png" file and renames it rather than handling the actual process of taking the screenshot, the mod using .jpg instead of .png will have the same result as if you were to rename the file yourself. I'm not in a position where I can test that right now, but I don't know if that file would then open properly. I may be able to find some open source way of converting the image that I can include in the mod, or I might be able to override the default KSP screenshot behavior, but it won't be in the next update most likely. I'll take a look at it though and see what I can do. E: It appears as if Unity has this: "Texture2D.EncodeToJPG", which will require me to load the .png into memory, then convert it to a .jpg, then delete the original .png. Definitely doable and I can even let you set the quality. Consider it implemented for the next release (since it's pretty straightforward), but you'll have to wait a few days most likely and I'd rather get the custom naming done first.

If you're trying to launch ships by clicking on the launchpad, that won't work. At best it will start a simulation, at worst it will cause issues like you described. With the full KCT active, you have to build the ships first and launch them through the main KCT window. If you just want simulations though, you can turn off build times in the settings (open the main KCT window in the Space Center, press the Settings button, then go to Game settings and uncheck "Build Times"). Then you can use simulations by clicking the KCT button in the editor, but you can launch vessels like normal with the launch button or through the launchpad. You might want to restart your game after turning off build times, but it should be fine if you don't. If you're still having issues, let me know!

I'm not sure that I will be able to change the format (at least not easily) since that would require either overriding the screenshot behavior or converting the image files to a different format. Unfortunately it's not nearly as simple as renaming a file, especially because .png is a lossless compressed format while .jpg is a lossy compressed format (meaning jpg purposefully leaves out image data). There are many free tools available for converting images between different formats that you might try instead, alternatively, Imgur and many other image hosting sites will host png files (some may even prefer it). I've got at least three copies of the same 80 screenshots or so because I would periodically backup my screenshots folder, but there was also a mix of screenshots from different KSP versions. It's a nightmare. This thankfully will prevent that from happening in the future, which is why I wrote it

Not currently. It's on my list of things to do, but I can try to get it done later today and post it as a development release.

Oops, fixed! Thanks

Beta testing was going well so I decided to do the full release. Not too much changed from 1.1.5, just a couple GUI fixes and other bug fixes. The complete changelog is below. IMPORTANT NOTE: StageRecovery is now required for parachute based recovery of parts into the inventory. I warned you all about this before the release as well. It's totally optional if you don't care about recovering parts from dropped stages and KCT can work just fine without it. Changelog: v1.1.6.0 (4/29/15) - Update for KSP 1.0 - KSC Upgrade time halved by default - KSC building upgrades now wait until you reenter the Space Center scene to complete - Removed chute based part recovery, now requires StageRecovery for that - Removed April Fool's joke references - Possible fix for random explosions that happen when switching vessels during simulations - Improved functioning of the KCT toolbar button+GUI - Windows that are meant to be centered are going to be centered, $DEITY damnit! - Build List is (again) movable when using Blizzy's toolbar Also, I think all of you are wonderful people and I couldn't have asked for a better community to work with!

@Gfurst, I think that's pretty much how it's going to turn out (or similar to it). KCT has been hosted on GitHub for about a year now and I've on occasion had people submit fixes or improvements (mostly enneract). That might be a bit more frequent in the coming weeks/months. The API is currently winning, probably due to enneract's post a page back, so that will likely be my first target. That will then open things up so that enneract can do the GUI overhaul as a meta-mod and HoloDeck can take over as the simulation provider (the way HoloDeck worked last time I tried it, in January, was pretty nice. A definite improvement over KCT's current system). We're sort of building our own little "constellation" it seems (like USI's Constellation of mods), with mods built for one main purpose but all communicating together. It's possible that other parts of KCT will split into separate mods later down the line as they grow too big for KCT. Like you said, the changes made for the API will likely streamline future development, which is a good reason to do it sooner rather than later. I might do presets at the same time since it might not be too hard to add it in. The next thing that's winning is integration with other mods, which will likely wait until after the API comes out since other mods might instead integrate with KCT, but I might do some of that at the same time as the API. Kerbal Konstructs is the biggest one (and most challenging), but the places where there are conflicts were designed for future KK support, so it shouldn't be too bad. May/June look like they're going to be very interesting times for KCT E: Might as well throw CrewQ into that mix and call the whole thing the Space Time Continuum of mods. (cause KSP is a space game, and they all focus on time as a resource, except StageRecovery and my modlets, but shhhh )

Oops. I probably broke that when I was trying to fix some other GUI related issues. Good catch! I'll get that fixed up and probably will release the update tonight. Might make the window draggable again when using Blizzy's toolbar since it doesn't make sense to leave it locked in the top right then.

Well ok, that might solve all the problems then Holodeck was essentially what I was going to do for the simulation overhaul. But ContractConfigurator has some nifty methods of creating a ship in orbit that I'd like to use rather than the HyperEdit inspired (*cough* acquired *cough*) method I'm using now. It could also be used to put a vessel landed on a planet. Basically you create the vessel, then you'd switch the scene to Flight focused on that vessel, which would already be where you want it to be. Smooth as ice and no random jerky toss into orbit. Normal launch simulations would work how they normally do. I'd honestly rather rely entirely on Holodeck for simulations rather than having two methods of handling it (similarly to how I'm removing KCT's parachute recovery code and relying on StageRecovery in the next update). If you want to do the UI as a meta-mod then I'll make the API happen (I was going to work on it anyway since some other people have requested it, but I might up the priority). I'll have to move a lot of stuff out of the GUI code for that anyway, so that should make your life easier. We can talk about this more later. I also have finals coming up (one next week, some more the week after). Afterward I'll still be working, but for the early part of the summer I'll have a decent amount of freedom. At the end of the summer I'll have qualifying exams, so I might be missing for a month or so in preparation for those.

Very strange... It's possible that they're hitting the ground before they leave physics range. You could try deploying the parachutes when you decouple the stages. Alternatively, if you are deploying the parachutes I would try not deploying the parachutes when you decouple.

It might need to be turned up a bit by default since the stock heating isn't too dangerous and SR seems to overestimate. I might try setting it to 2250 m/s and seeing how it goes from there. Part of the issue is that once the ship leaves physics range (which is now 22.5km) it no longer has drag acting on it, so the reported speeds at actual deletion are higher than they should be (gravity still speeds them up, but the atmosphere doesn't slow them down at all). With Deadly Reentry the settings were about right, giving generally less than a 50% chance of a stage burning up if dropped from suborbital speeds. Mostly it's supposed to prevent you from slamming things into the atmosphere at Mun return velocities to try to get around reentry heating (since SR will recover the parts, science, and Kerbals). Oh, by default it's 2% chance of burning up per 10 m/s over the limit in the settings. With a heatshield, it removes a percent equal to the remaining heatshield ablator (so if it's unused, 100%). So at 3kms, normally it's 100% chance but the heatshield reduces that to 0%. At 2.5km/s there's a 50% chance, but a heatshield reduces that to -50% (which is just 0%). At 4km/s there's a 200% chance of burning up, and a heatshield reduces that to 100% (so, you're still screwed)

Alright, the poll is up! It addresses two things: 1) What should be the focus of the next update, and 2) How should I continue development. I've put some of my thoughts into the poll options, but will elaborate a bit more here. What should KCT focus on next? - Integration with other mods, such as Kerbal Konstructs, Kerbal Alarm Clock, and TestFlight. This was my original plan for the next update. - Improved/Reworked Simulations. The whole system needs rewritten since it's basically unchanged since the first pre-release over a year ago. The rewrite would allow you to start on other planets, would smooth the initialization, and would make the whole thing more configurable and make way more sense. Additionally, I can make it so you can start a simulation at any time, especially during and existing flight. - The UI overhaul. This would be a lot of work to do and I'd need enneract's help for it, but the end result would be awesome. I'd have to rewrite about half of KCT or more (again) since I have too much going on in the GUI code that would need moved. There'd be almost no new features and I'd likely have to remove a few features to get everything to work with the stock GUIs. It might also break mod compatibility in some instances (imagine if two mods decided to take over a stock GUI. I've already run into trouble with other mods that take over the launch button). I'd expect this no earlier than the end of the summer (so, August). - An API for other modders to integrate their mods into KCT. Pretty much no matter what I'm going to be starting on this, but if you all want me to focus on it as the primary component, I can try to kick out a fully functioning API. This will actually require changes that will allow for the UI overhaul in the future, and might allow for a different mod to do the UI overhaul while KCT remains with it's weird GUIs. - Preset configurations. I was also planning on doing this soon and forgot to add it to the poll. Basically, since KCT is so amazingly configurable I want to provide several preset configurations that you can choose from at the start. This would move 99% of the configuration options into the save file (or save folder), aka the Game settings, instead of having the separate Time and Global settings. So you could have one save with really quick build times and another with slow ones. And you could have one save where all the rates are defined by Stock upgrades and another where they use the Upgrade Point system. Other mods could provide presets (like Realism Overhaul) and don't have to worry about overwriting your configs. Basically, this needs to happen eventually and if you want me to do this please choose the "This is not an option, it's another question" option (which is really another question ) The second question: How should I (magico13) handle future development of KCT? - By myself. This is what I do now. I take your input and mix it around with my ideas of where to go next and I make that happen. Since I'm working on a PhD right now, I don't have loads of time to spend on new updates. But I also tend to interact with the community fairly often and don't have a habit of going dark, and I tend to take your suggestions and try to act on them. I think so far I've been a benevolent dictator This is by far the simplest method for me to continue with development, but it obviously has some disadvantages. - Pass off KCT to another developer. I don't really want to do this because I enjoy working on KCT. I've brought it to the point it's at now and it's one of my greatest accomplishments. But I also know that I don't have the time to develop it into the amazing piece of software it could be. So I could put it up for adoption and let someone with more time, or more skill, or more vision continue development on it. But if that person falls short as well, it could totally kill the mod and I might not be able to come back to catch it before it falls. It's a risk, but it might have the greatest reward. - Form a development team. This is kind of the compromise between the other two options, but brings with it it's own challenges. Organizing people is hard. Organizing people without ever meeting them face to face is even harder. And when they're at wildly different skill levels and have wildly different methods it can be a serious challenge. The mixed styles can result in a discontinuous feeling in the final product: for instance, the other developer(s) might want a stockalike feel for something they're working on and integrate it into the stock GUIs but I prefer making a new GUI where I know I can do what I want. Suddenly there's this big disconnect between these two elements, and that can honestly make it more jarring to interact with than my crappy GUIs. There have been games released in the past where different developers have worked on different parts of the game and none of it feels cohesive. Those games don't sell well for a reason. But, if we can all work together well, some really amazing things can happen from this. - The question that follows from this is how big of a team should it be? Just two people, or should we go bigger? Two is manageable, but 5 or more could do a whole hell of a lot of work (Squad's game dev team is less than 10-15 people and they made this whole game) Edit: The extra info included in the poll options are very clearly affected by my opinion, and for that I apologize. The poll likely won't be a totally fair poll as a result, so if people want me to rewrite it to be less biased then I can do so. Edit 2: If it wasn't obvious, you can select multiple options. I will pick the top one or two to focus on (depending on how long they take to complete). If you pick UI overhaul, that'll be by itself, but I can probably mix the Simulation Overhaul and Other Mod Integration (as an example, there are other valid combinations as well). Link to poll: http://strawpoll.me/4235203

It might actually work with 1.0, but I've been too busy to test it out yet, so I've kept it listed for 0.90 just in case. It does make a backup of the save file before it does anything, so if you want to test it out it should be pretty safe. Regarding the claw, I have no idea what will happen. It seems to work (sometimes not that happily) with docking ports, so it should probably work with the claw as well. Only way to find out is to test it! I don't know about folders, but I can at least make it so you can put the ship name in the filename. Then you could do some scripting magic to put those into folders yourself if you wanted. As for in-game time, definitely planned as an option when I add the config file (in two ways, raw UT in seconds or as the Year X, Day Y, Z:A:B format)! That is quite a bit, but I plan on adding all of it except the really precise info (altitude, speed, etc). I might add that in later if people really want it, but you might have to settle for just the ORBITING, LANDED, etc. string for now. I didn't think of KSP version, that's a good idea though! As for the IncrementalNumber, I've only been putting that in when two files will have the same name, do you want to always have an incrementing number option? That's actually slightly more difficult I think, but is doable.

With the default settings there are only a few places that building levels matter (you can have 2 build rates per VAB/SPH level). But I've also made it possible to totally redefine the whole KCT system to be entirely based on building upgrades if people want, which I discuss more in this post and the one linked in that post. In that second link I actually provide an example config file that totally replaces the upgrade point system with the Stock upgrade system. I just noticed neither of those link to the guide on how to change those settings or what options you have, so here is a link to that.

Based on recent feedback I'm going to be posting a poll later to help me figure out what you guys want me to focus on during the next update (after the 1.0 one, which is pretty much done). There are a lot of things that can be worked on, and usually I work on which ones I want next, but I definitely want to do what you guys want (after all, you guys get to play with it more than I do!). So even if that's a GUI overhaul, if that's the most requested then I'll find a way to make that happen (in which case, enneract I'll be contacting you again ) So look for that later today, probably within a few hours. I won't be able to do any work on anything big until after finals, so the poll will be open for a few weeks.

It works the same way that it did for Deadly Reentry where there's an increasing chance of burning up as you go faster than the "DR Speed" setting (which by default is 2km/s). If you have a heatshield on the craft then you're safe up to 3km/s. The silly thing is that it doesn't actually matter where you put the heat shield, since I don't do a bunch of tests to make sure things are blocked by it. I'll admit that I didn't rigorously test it since it worked fine prior to 1.0 with DR and I just had to change a few lines of code for it to work with the stock system instead, but it should work the same way. So to save them either drop them with a lower speed so they don't go above 2km/s, or fit a heatshield. Or turn off the DR Speed setting by setting it way up or to 0

As long as there's SAS then it should work, and its only for powered recovery. No probes needed for parachute based recovery. E: Actually, with the change to that in 1.0 I'll have to double check that that works.

And just because I can't get enough with this whole modding thing, I just wrote a new Modlet called Sensible Screenshot which makes your screenshots use a unique, date and time based, filename rather than the default "screenshot_#" format. No more trouble when merging Screenshots folders when backing things up! If you want to try that out, please do so!

I just added Sensible Screenshot to the first post. What does Sensible Screenshot do? I'm glad you asked! Sensible Screenshot gives your (new) screenshots unique filenames based on the date and time they're taken. No more accidentally overwriting files or having multiple copies of the same screenshot when you go to merge Screenshots folders! If it picks up any interest I'll add a config file that will let you define the naming scheme yourself so you can use your favorite date format, or even include the active vessel name or save name in the filename. Let me know what all of you think!