magico13

That's a log I'd like to see. I've seen something on my side regarding an NRE with KCT when it's disabled for a save which I'm thinking might be related. You could try disabling build times instead of fully disabling it, but it's possible that will have the same error. It's actually surprisingly hard to disable functionality when much of what you do is event based. I popped in here to see how similar some of the functionality of the ScrapYard will be to this (if and when that ever gets worked on and finished) and while it looks like the two will likely be incompatible I think there's enough different that it won't be treading too much on existing territory (for what it's worth, it wasn't my idea to have the ScrapYard include resource storage in the first place). I saw there was some talk of including support for StageRecovery. It's pretty easy to do. You just need to include this wrapper in your mod and create a function that will be called when a stage is recovered. The Vessel is passed to the function (along with some other stuff that you likely won't care about) which you can parse for the resource data like you would normally. The API example in the StageRecovery thread is pretty straightforward (toward the bottom in a spoiler called "API") and provides an example function based on what KCT does.

Some of this already exists in that you can "Duplicate" any craft that's building or is in storage (press the "*" button and then the "Duplicate" button). You can also save any craft by using the edit button and then saving it in the editor (that's actually the only button I left available, so that you could make edits and save it as a new version, or overwrite the existing craft file in case it's something that should be in future versions of the build). A "rebuild last launched" could be handy, but more often then not you either already have it saved or it is saved as the "Autosaved Craft" (I need to verify if the craft gets saved as that when you launch or if it's only for simulated craft). The new window feature is super low priority but something I would like to have eventually as it would help with the overall integration with the stock game. Possibly little known feature that's half Stock's doing and half mine: If you revert to the editor after pressing Launch then the vessel will return to storage Doesn't work in no revert saves, but does for sure otherwise. I purposefully designed the launch system to work that way (the vessel isn't removed from the inventory until after flight starts and the persistence is loaded, rather than before switching to the flight scene). It led to some fun where launching from the Tracking Station wouldn't remove ships for a version or two As for sounding short tempered, I worry sometimes because it's very difficult to determine the tone of someone else over the internet and I generally don't want to sound combatative. It's hard sometimes when I feel like I've been answering the same question for months. I'm pretty sure that the most requested feature has been recovering straight to storage in some form or another. Generally people are OK when I explain that the part inventory covers almost exactly what they're asking for, but then other people want it to not take a bunch of extra time. I finally caved but just haven't had the time lately to add it since it isn't a necessary feature Which reminds me, I spent a bit of time working on what's needed for RSS and KK support (with different KSCs having their own sets of build lists and upgrades) and it basically resulted in a total rewrite of how data is stored to the save file. I'm gonna do my best to not break existing saves, but there is a slight chance. The good news is that the new system will make more sense and that the actual ships will be saved with the rest of their data (currently, ships in lists are saved in a different section of the save file from their KCT specific data and are linked to each other based on their order of appearance. The new system will save the ships as a subset of their KCT specific data, which makes a lot more sense). In order to allow a transition from the old system to the new one, I'll have to load the old data from the save, add it to the default KSC, delete all the old data, then save it the new way. It's shouldn't be hard and it will be tested somewhat thoroughly, but I figured I'd at least mention it. TL;DR: I said nothing that important in this wall of text, I apparently am just feeling like talking. I think I'm excited because I actually got to do some modding over the weekend and fixed some bugs

When I said "watching for their recovery" that doesn't necessarily mean actually watching the craft (though generally if people are having issues they'll watch it in map mode or the tracking station), watching includes just looking for the message to appear. If you focused on the stage then StageRecovery would never kick-in. Is the modified part a separate part from the stock chutes, or just a modification to the stock part's config? Since RealChute includes ModuleManager configs to overwrite the stock parachutes I'm wondering if your config changes are just being overwritten. The editor helper would quickly make that clear with a properly weighted test part (I believe an empty solid booster, a command pod, and a single parachute is not enough to drop the velocity to within safe levels with stock parts, but with your modified part it should be). If the editor helper isn't reading the stats correctly then your configs are definitely being overwritten by RealChute.

May I suggest the RealChute mod? It will let you adjust parachute stats on the fly in the editor so you can land at whatever speed you want with your cargo on any planet. It also works flawlessly with StageRecovery. With that out of the way, let me address your particular problem. From what scene are you watching for their recovery (flight/map view, or the Tracking Station). If it's during flight then it should recognize the changes no problem. If it's the tracking station then StageRecovery assumes the stock stats because I lose access to a lot of information outside of the flight view (though I think I may have found a solution to that which I will be adding into the next version). Map mode and flight are the only "safe" views to use with modified parts for the time being. If you are in map mode or flight and are still having problems, what does the editor helper say? Do you see what would be reasonable speeds for your modified part compared to stock parts? If the editor helper isn't detecting the changes then there's definitely something wrong happening.

No worries, I'd rather hear similar reports twice than never at all! Why wouldn't you just warp to the right time and then launch the craft? But beside that point, recovering straight into an inventory and refilling resources is a confirmed feature that will be in the 1.1 release, which I feel I have mentioned many times recently. I have not yet decided how to handle refilling resources with regards to time. It either won't require any time, or will require a small amount of time. With the rollout feature, requiring time doesn't seem important. In general, check the known issues and GitHub issues to see what are known problems and what is confirmed for future releases (and even which release they'll be in!) Many of the GitHub issues even have links to corresponding forum posts, and are a great place to discuss the implementation of a feature. You can make issues to report bugs or suggest features and it won't get lost to the many pages of posts on the forums. Any changes I make related to a particular GitHub issue will automatically be tagged so you'll be able to track the progress easily. With Milestones you can see how close the next version is to release. I apologize if I sound short tempered, I'm not feeling particularly well right now and I have some tests later this week that have me a bit stressed out.

Thanks for the report, though it's already in the Known Issues. I can't fix it (and it would be a simple fix) until I fix the other bug where once you start researching a piece of technology you lose access to it. The reason you can't simulate it is because that uses a totally different method for placing the ship on the pad (identical to pressing the launch button in a stock game). It's been mentioned a few times in the thread, but until I can make it so you can still complete part testing contracts when researching the tech I won't be able to fix it.

This seems like a reasonable compromise to me. Your engineers gain familiarity with how the parts work still but they have to be "custom ordered" to fit. I've got that listed as a bug on GitHub and will probably be looking into it today.

Gonna be streaming again in a few moments! This time setting up a remote tech network, doing some fine print contracts, and maybe a Mun landing if we have time!

So when I was working on a new feature (automatic recovery of launch clamps as soon as they are unloaded) and was using completely Stock functions I was seeing this same behavior (for stationary, landed launch clamps on the launchpad). So I think it's a Stock bug with determining the location of an unloaded craft, but it apparently only sometimes happens. I've been considering tying into the Trajectories API since I don't really like taking code from other places, but that would require Trajectories be installed as well for that enhanced functionality. Since the Trajectories license is MIT, I may borrow that implementation from them so as to not require a dependency for what should be considered normal functioning. However, since SR doesn't "kick in" until vessel destruction, the trajectory would have to be computed when decoupling or first unloading rather than at destruction (since that won't happen until below 22km). The other thing I've been considering doing is something a la TTNeverUnload and have the option for stages that would be recovered automatically (or ones you manually flag to remain loaded) continue having physics applied. That way they can actually land, and if you're like me and use kOS you can have your craft land automatically back at KSC. Also, then the percentages will be accurate and only parts which have actually been destroyed won't be counted (and deadly reentry will work). That would likely be disabled by default (lots of people probably don't want to have a bunch of parts loaded at once). The only problem I'm having is determining when parts are dropped. I've found functions for determining when things get decoupled, but not how to access those "new" vessels. Either that or I need to wait until they unload, then manually load them again and flag them to not unload again.

I do actually play with this and RemoteTech so I know how you feel. Ones in orbit around Kerbin aren't too bad if you make sure to open the omnidirectionals in the VAB, but you can't target dishes directly in the VAB. In the advanced simulation configuration there is a button called "Delay move to orbit". Activating that will give you three seconds on the launchpad before moving to orbit, which may give you enough time to target the dish somewhere useful. <edit> RT used to have a feature where if you turned on one of the debug menu settings (infinite EVA fuel I think) you would always have communications. That feature would be ridiculously useful during simulations if it still worked, but last I checked it didn't. Does RT have it's own debug menu? </edit> @NathanKell, I will give you a more elaborate response after I get to work. In short, the only procedural parts that are taken into consideration are tweakscaled parts. Everything else counts as one part (since they're stored by part name). <edit> I haven't given much thought to procedural parts since the only ones I've ever used up until now have been Procedural Fairings, which I generally don't recover (except the bases). It's still fair to me to have the reductions in time due to the part tracker (repeated uses) since they're still fairings, but I can see where the inventory might be a bit weird. Procedural fuel tanks and wings is a bit more questionable, but in general I tend to prefer simplicity and gameplay over strict realism. Since I don't want to have individual tracked items for tanks that are 1.5 meters long, 1.55 meters long, ... cluttering up lists and occupying massive amounts of the save file (if I saved the whole confignode), I'm personally in the favor of not treating them too differently. At the moment you still have to pay for them at full price and you still have to build them (maximum reductions in build times are only around 1/10 for ships built entirely from the inventory. When you mix parts it suddenly takes much, much longer than that because newer parts are far more heavily weighted). Tweakscale was an exception because the parts suddenly start varying wildly from their stock versions, but for the most part are in discrete sizes. I personally don't like tweakscale and never use it except for mods that require it, like Infernal Robotics. As for multiple launch sites, I've added an issue on GitHub for it and will try to get it in the next release. Which probably won't be until after next week at the earliest, as I have some exams coming up and definitely need to do better than I did on my last ones. </edit>

Well, currently KCT does absolutely nothing about them good or bad, but as mentioned a few posts above KCT doesn't break KK, it just requires a bit of workaround to work properly. As for RSS, I haven't tried it so I wouldn't know. I know that the reconditioning aspect doesn't make any sense with multiple launch sites, but the rollout mechanic that will be added into the next version does to a degree (only allowing one vessel to be rolled out doesn't make sense if they're going to different sites). I am curious as to what people who have used KCT and those mods together have to say about their compatibility. I do want to add specific support for those systems, but it hasn't been a high priority yet because I haven't had too many requests for it. Regarding RSS support, I hadn't given it much thought since Regex's campaign system was supposed to use a mass based timer for each pad, so KCT wasn't going to end up being paired with RSS in 99% of installs. I do wonder how KCT should handle multiple launch sites. Should each one have their own build lists and storages? Or should they share all of those and have reconditioning and rollout times for each site instead. The latter is what I would likely do at the moment, at least for KK. RSS' dedication to realism would incline me to have individual build lists and storages per KSC (ones without VABs/SPHs wouldn't have VAB or SPH lines, obviously). Edit: I did see this message in the RO thread and would like to comment on it. While KCT relies on part cost for determining construction time (well, technically "Build Point" values) all of that information is available in any game mode, not just career. As a result, KCT works perfectly fine in a Sandbox game. The upgrade system relies on the Tech Tree (for now), but in Sandbox mode you're just given a bunch of upgrades (45 to be precise, which is less than what you'd get from a full tech tree + the starting 15) which you can spend however you want. That number can be changed at any time so that users can give themselves more points for completing tasks they feel are worth upgrades (like landing on the Mun, or Duna, or sending a probe to Venus). To me, Sandbox isn't necessarily "Have everything all the time!" but is instead "Play however you want", so KCT is designed to still be played with in Sandbox.

I'd like to see the log file for that so I know precisely what the error is and how to avoid it in the future. I was afraid something like that might happen at some point if people removed mods and still had craft in the list/storage. The fix is relatively simple if you've done anything in the save file before. Just find where the craft is in the SPH storage (ie, it's the 3rd item in the list). This is referred to as SPHWH# (where # is the position in the list, with a zero index, so # = 2 in this example). Just delete the entire SPHWH# section and rename all the later ones (SPHWH3 becomes SPHWH2, SPHWH4 becomes SPHWH3, etc). You'd also need to remove the whole Item {} section from the SPHWarehouse section. If you get me the log file I can probably just write a quick patch to let you scrap it normally (and get what parts still exist back in your inventory).

Nope. My code is most definitely broken I think. Yep, just looked at it and that section is outside of the try/catch block. Crap. Definitely will be fixed, or at least less broken, next update. Sorry about that :/ StageRecovery will have the same issue if you use the flat rate model (which is not the default for SR but is what KCT uses). If you use the default Variable Rate model in SR the problem will stop, but you also have to make sure you're going slower than about 6-7 m/s to get high refunds.

I presume that this is the issue. When you're not in the flight scene, the game unloads A LOT of information which has caused me many headaches in the past. It seems that how I check for probes is likely the issue here. It should work no problems if you remain in the flight scene, but will probably not work properly in the tracking station (or space center) views. Here is the problem: (((ModuleCommand)module.moduleRef).minimumCrew == 0). You can see that I access the module.moduleRef, which doesn't exist outside of the flight scene. As a result, there's a crash and KCT stops trying to recover anything. It's better than the old days where it would crash your entire game and make you have to restart KSP! I'll see about fixing that up. I might be able to access the info I need from the ConfigNode directly. Here is the link to the issue I made on GitHub for it: https://github.com/magico13/KCT/issues/15 I have not personally tried this but I am told that it works. I was under the impression that KK was getting a selector in the Space Center scene and that one of the devs (or someone vaguely related to the project) was going to be implementing something directly into KCT and would do a pull request when they were done. I'm under the continued impression that none of those things have happened yet I would like to support KK directly at some point, but the priority is very low at the moment (especially because I don't play with it personally, yet)

I take back everything I said about making the arm structures one part. Those designs/the versatility are cool enough that I would rather be given those options than save on part count

Which makes me wonder how well the small docking port will fit on this (if at all). That would definitely be necessary for this sort of usage.

Well, it will get deleted either way, but you should have received a notification saying that it got recovered as long as the parachutes were actually enough to recover it. What was the periapsis? It's possible that it was no longer considered sub-orbital, but that might not happen until the periapsis is > 70km (I'm not positive where it makes the switch internally) Having a probe core actually INCREASES the amount of funds you receive, so it's actually a good thing to put a probe on it, so that shouldn't have messed anything up. Getting StageRecovery might help, but the code they use is nearly identical, so it's likely that the same issue would occur. If you could turn on Debug Messages in the settings and send me the output_log file if it happens again, I'm curious if there's anything strange going on. Next time keep an eye on the funds counter, if it suddenly goes up when the vessel gets deleted then things are working as intended (or check the inventory before and after). Edit: Rather than a double post, I will extend onto this one. I've done a bit of rearranging of goals after realizing that I was going to end up having to rework a lot of stuff immediately after making it. The total simulation overhaul and presets have been pushed back to being in the same update as the upgrade overhaul (I am liking the idea of a tech tree like way of doing that. Either with an extension to the stock tech tree or with my own completely new GUI [not preferred, but then I can charge funds/science/reputation/arbitrary points]). The reason being that I would end up writing all the code for them and then immediately have to rewrite it after overhauling the upgrades. As a result the upgrade overhaul is a bit higher on the priority list now, but is still delegated to after the 1.1 release (which will now focus primarily on vessel rollout and recovery). As I mentioned in the GitHub issue, landed simulations may find their way into the 1.1 release in some form and I may do some preliminary overhauling of the simulations before the big changes.

It is fully supported in Sandbox and even more so in Science modes. In a Science save it should work nearly identically as career mode, minus anything involving funds. Meaning simulations won't cost anything, but upgrades are still earned from unlocking nodes and can be purchased using science. I haven't personally played with Science mode, so there may be an extra bug or two. If so, please let me know!

Well, instead of trying to remember everything I want to do in the future (or saving it in a text document on my desktop, which I am barely on anymore) I decided to put my todo list on GitHub as a series of issues (and I figured out what Milestones are and how to use them!). So now you can see what is on my todo list and can comment on them. The RealFuels bug is on there and I'll take care of that. So is recovering vessels straight to storage (I need to figure out what to do about fuel levels, I will probably have a GUI that lets you fill things up to whatever level you want [obviously still paying for it], then you can rearrange it as necessary after launch/through edits) If you view by milestone you can see what I want to get done for 1.1 (I may need to push some of it back if I want to have a release anytime this year...) and for after 1.1. I will add more things as I remember them. View it here: https://github.com/magico13/KCT/issues?q=is%3Aissue+is%3Aopen As for making new parts faster than parts that have been to space. I don't think I'm going to end up doing that since it will make recovering parts less of a good thing and will likely require a rewrite of the inventory system, which is definitely not going to be happening (other than with ScrapYard integration). I'm pretty sure you can make recovered parts take longer to build if you really want by reducing the InventoryEffect to less than 1 (but not zero). You could also just disable the Inventory Effect entirely by setting it to 0, meaning recovered parts won't affect anything.

Please do and let me know if you see anything like that again. That's not a mod that I want to have incompatibilities with (since I'd like to eventually have support from the Realism folks).

Well, that's actually what does happen, so that's a definitely strange issue :/ Launch works by saving the vessel ConfigNode (a direct, unchanging copy of the vessel in the editor) to a file and then starting a brand new launch with that file (identical to starting a new flight by clicking on the launchpad). I wonder what RealFuels does differently that causes that to happen :/

If you're sharing textures then it might be fine to include both sets in the same mod. Have all the tiny pieces but also a prebuilt arm structure (the propeller shield + propeller isn't that big of a deal). That way if people want to do something funky with the arms they can (like make them really long/have weird angles) but if they just want a single part to connect them they can do that too. With shared textures is won't take any more RAM and adding a single extra part won't make anything too crazy. It's also like two extra parts per arm, which isn't really a big deal so you can probably leave it as-is without any concerns

Don't forget some sort of antenna for use with RemoteTech. Unless you would prefer we use the Stock ones. Either way, I would fly the f--- out of that. It looks so fun! It's like the BoxSat of drones! I also wouldn't mind science equipment/a single science package for doing the stock science experiments with it without having to mount them on the sides (but once again, the stock ones would work fine as well). I am wary of having a bunch of smaller parts (since that would inflate part counts, and each part has physics applied to it). Would it be possible to merge the primary mount, structural piece, and engine mount into a single part? That would reduce the part count from 3 to 1 for each engine. Maybe do the same with the propeller and shielding? I'm not a fan of a lot of little parts that have to be combined every single time (in the same way) to be functional (like when KAS required you place the winch AND the connector onto the winch every. single. time.) and having to search through the parts list for everything. Things to consider for later down the line

Yeah, I didn't see it on your thread until I was already done writing this fix, otherwise I probably wouldn't have. I did check your thread like, last Friday, because your fixes are immensely helpful but didn't see this in there yet! I can see why you chose offRails rather than OnRollout, though won't that cause it to activate every time a vessel is loaded into physics range? Though I doubt that will be an issue 99% of the time since it's for such a short time. I wondered why no one had done this yet, since it's such a simple fix so I decided to do it. Guess you beat me to it! Hopefully Squad does something similar for 0.90 (and fixes all of the other bugs you've fixed. The decoupler one is driving me nuts! The Kerbal X doesn't even work in the Stock game because of it). Like I mentioned in the post, the only reason I even decided to release this after seeing yours was in case someone could learn something from it or wanted to do something more with it. If for whatever reason you decide you want me to remove the download, I will

@FreeThinker Maybe I'm misunderstanding what you mean, but doesn't the inventory and part tracker systems cover that? If you recover a part then the next time you use it it takes much less time, and the more often you use a part (through multiple builds) the quicker that part takes to build (representing increased familiarity with the part). In fact, due to the fact that time increases with the square root of cost, if you only have one line it is always faster to build more at once. If you have two lines you can split the construction in half, scrap them, and then build the whole thing and you MIGHT see a reduction in time (depends on if you were using inventory parts in the first place). You can already select which line you want things to be on by reordering the constructions in the build list. By default it's first come-first served, but then you can rearrange as needed. Do you want reused parts to take longer? I actually think there's a way to do that in the time settings, but it won't actually have much effect since you can choose to use new parts each build (after the ScrapYard is implemented then you'd have to pay more each time for new parts and that becomes a feasible gameplay mechanic [pay more for faster builds, or less for slower ones]) Like I said, maybe I'm just misunderstanding what you meant, in which case feel free to correct me