magico13

Figured it out, it was a really stupid mistake. I started caching the build rates a little while back because of changes to support Custom BarnKit, which resulted in building levels not always reporting correctly and causing the build rates to get messed up when outside of the space center scene. Except I accidentally cached all the SPH rates with the VAB rates because I forgot to change one thing when copying the code over from one to the other. Should be fixed in build 20, and thanks for the report

Finally had a chance to test this with KCT and it was definitely an adventure. A few things: you accidentally shipped a CrewQueue.dll in your release, the files not being renamed to match the classes/namespaces is pretty confusing (and there are files that should be deleted as well), the APIProxy should probably be public and not private since the wrapper is using GetExportedTypes which only shows public types, the wrapper was specifically looking for private Properties and Methods in the getProperty and invokeMethod calls despite all the actual members of APIProxy being public (even with the class itself private), and to top it off the wrapper was trying to get an Instance property that doesn't exist and made all the calls to any of the wrapper properties/methods instantly fail. I'm guessing you mostly just renamed all that stuff, so I am not at all surprised that KCT supposedly wasn't working with CrewQueue, since that wrapper was apparently designed for an entirely different API. The good news is that I managed to fix that in KCT so that the wrapper does hit all the right points and properly filters the list to exclude kerbals who are on vacation. KCT build #19 is tested against CrewRandR and appears to work fine with it Feel free to copy the fixed wrapper back over from KCT, but if you change the APIProxy to be public then switch back to GetExportedTypes from GetTypes (and let me know so I can do it locally)

Alright, no worries. Just wanted to make sure you weren't going to try to do it by hand. Profile links are already a thing in the existing tool. We had considered avatars but decided against it. Hadn't talked about post count at all previously. I look forward to seeing the end result

Are you going to do it by hand or write a program to do it? I really don't recommend doing it by hand since it quickly becomes unmaintainable. Once isn't so hard, but fixing the order later is a pain. That script only requires you to write the descriptions and does everything else for you, including formatting. If you send me the descriptions in any format you'd like I can set them up for the script and send the whole formatted list back with the descriptions file set up correctly.

Here's the program, but without a descriptions file. I posted this a whiles back. It's just a python2 script and I can walk you through it if you'd like (it's been a while so I don't remember all the features and quirks off the top of my head). https://github.com/magico13/LightGreenGroupUpdater

@Endersmens has some pretty serious IRL stuff going on (he updated a few pages back) so it's kind of in hiatus. I've been considering trying to write up a website where descriptions could be crowdsourced by other members and the list would be updated daily (I'd also like to track rep over time, but that approaches a "tracking" line that I'm not sure I want to cross), but that's nothing more than an idea in my head at the moment. That and I'm bad at making websites. I've always thought it was a little silly that the descriptions were made by a single person, crowdsourcing them makes more sense to me.

I gotta say it's weird for someone to call me a "modding celebrity" since I wasn't aware that I was actually known

Not to diminish your efforts, but perhaps to enhance them, but the old software made getting rep easier because you could get up to 5 per "like" instead of the constant 1 you get now. Though the "likes" seem to flow more freely with the new software, so perhaps it is easier now but just requires more people. Personally I got almost all of my rep on the old software (I think I was at 900 or so when the switch happened).

You will be able to add ScrapYard to an existing save and theoretically will be able to remove it later without issue (other than some build times being out of whack, such as when editing a finished vessel). But while ScrapYard is in development the inventory might get broken between builds and have to be cleared out. If you wait until release that shouldn't be an issue and you can drop it into an existing save without any problems. Note that the inventory being broken between builds isn't necessarily save breaking since you can safely delete all that data from the save file manually if need be. It shouldn't cause any permanent breaks as long as you're ok with the occasional editing of the save file to delete a chunk of text. But backup the save often.

Following this and will make KCT work with it. This falls under one of the requirements for the theoretical "Space-Time Continuum" mod set that I've got going in my mind (a set of mods that give time a meaning in this space game ) Edit: KCT dev build 17+ theoretically supports this, but I haven't tested it yet. Edit2: Scratch that. 18+ should work since if there was a manifest already then it wouldn't pull from the modified list. That was fixed in 18. Still haven't gotten a chance to test it yet though.

I can certainly take a look at it. Enneract is the one who put it into KCT in the first place so I never actually knew if it worked, but I don't anticipate it being too difficult to support. Edit to add that I'll definitely make it happen. KCT's purposefully never interacted with Kerbals and I had been considering taking over CrewQueue for a while to handle that side of things. With that said, if you find you need to shed some load in the future, let me know.

No, it's a percentage represented as a number between 0 and 1 (1 being 100%, 0.5 being 50%). For Earth, to simulate 500km away you'd set it to 0.958. It's 98% at KSC and 10% on the other side of the Earth, which is 20000km away, and it's linear for all values in between.

There are a number of discussions about this (I should just put one in the OP). Try searching with the search bar in the top right. I generally recommend upping it to 6 km/s or so. Depends on what you think is a speed that is reasonable to start having a chance of failure, since that velocity is the start of failures and not a hard limit. I don't use RSS so I can't say anything for sure.

Quick progress update on ScrapYard and KCT. I spent some time this weekend trying to get a few more core features into ScrapYard, focusing on the part tracker and coming up with a way for other mods to use the inventory without a hard dependency on ScrapYard. With regards to the part tracker, there are three of them that all appear to be working. The "Individual Part Tracker" uses a Module that's applied to all parts to uniquely track them from the time they're placed into the editor to the time they're recovered. It also tracks how many times that exact part has been recovered, which is persistent across builds. In other words, you can recover a part and then use that exact part in another build and each time it's recovered that will be tracked within the part. The other two part trackers fall under the collective name of the "Like Part Tracker", which doesn't track things on an individual scale but instead just by name (so two very different shaped procedural parts would count as one thing in the Like Tracker). That tracker tracks the total number of uses of a part (if you use 9 of the same engine in a build then that counts as 9 uses) and the total number of builds using that part (that same 9 engine build would count as 1 build, but building it twice means 2 builds and 18 uses). Regarding the API, I've got a very initial, untested (but theoretically sound), build of KCT locally that is set up to use ScrapYard. There are a few hangups that I'll need to come up with a way to address. Scrapping doesn't work yet (just need to add a few more methods to the API, but that should be easy) and editing vessels wouldn't work right either. Once I track down those situations and double check that all the places that would use the inventory now are using ScrapYard, I'll release an Alpha build with that. I say Alpha and not Beta because ScrapYard might still have some breaking changes on its way with regards to how modules are stored (storing only limited info instead of an entire module) and with how parts are pulled out of the inventory (happening while building instead of at build time). The good news is that if you don't want to play with the potentially breaking ScrapYard changes, that's fine since KCT won't depend on it at all and you don't need to install it In short, progress is going well and I'm pretty on track with the schedule outlined in the ScrapYard Trello. I hope to have an Alpha level release of KCT + ScrapYard in the next week. Beta level release is still scheduled for May 1. I haven't followed KSP 1.3's progress that closely so that might shift plans a bit (in case you are wondering, KCT will not support other languages. If/when the rewrite happens, then it will be written for localization from the start).

KCT follows the game settings, so if you have the "Display Kerbin Time" setting active then a day is 6 hours. If you turn that off then a day is 24 hours. If you've somehow got a "day" defined differently then that probably won't work with KCT since it only knows of 6 hour and 24 hour days.

StageRecovery and/or FMRS, depending on how automated you want things to be.

Buy another copy and give it to a friend/do a giveaway. You support Squad directly by purchasing another copy, and indirectly by bringing a new person (or multiple new people if others hear about it and decide to buy it on their own) to the game who might themselves purchase the DLC. That has the potential to have a much larger effect than just paying for the DLC for yourself.

That's not something I can fix on my side, at least not on my own. You could try reporting it on the Final Frontier thread, but make sure you mention that it's happening with KCT. The problem seems to stem from the fact that KCT changes kerbal states (assigned, available, etc) in a situation that FF isn't expecting, so FF doesn't have some data loaded. They either need to catch that error and handle it themselves so it doesn't propagate up, or they need to recognize the situation and handle it so the error never gets thrown in the first place.

Sounds like something is throwing an exception during the Start method. I'd need a log to have any idea of what. If you're not sure where the log is, check about halfway down this post:

With the fixes the latest FMRS added, I was able to finish a video showing the basics of how integrations between FMRS and StageRecovery work in "auto" mode and when you use this mod to define which mod handles stages. I'm a bit rusty with making videos, but hopefully it helps explain what this mod can do and why it might be important to you.

As the author of the other main mod this is associated with, I'm reserving this post I'm going to use this post to describe how StageRecovery works with FMRS both with and without this addon (which is shipped with FMRS). By definition, setting "auto" with this mod will do the same thing as not having it installed, which is why "auto" is the default. Without this mod/"Auto" mode: When using the default settings of StageRecovery and FMRS, FMRS will handle all stages with parachutes, probes, or Kerbals exclusively while FMRS is active. If you close the FMRS window or make FMRS not active, then StageRecovery will handle ALL stages as if FMRS were not installed. FMRS has two settings that can affect this behavior: one which makes FMRS not handle parachutes at all and another that defers parachute recovery to StageRecovery. If either of these are active then StageRecovery will handle stages with only parachutes (so no probe or kerbals on board) while FMRS handles probes and kerbals (again, only if FMRS is active). With this mod: By changing the "Recovery Controller" on the decoupler it sets which mod will attempt to handle everything up to the next decoupler in the part list (which is also how StageRecovery tracks stages in the editor, so you can use the highlighting feature if you're not 100% positive what's included). Using this you can have StageRecovery recover something with a probe core and FMRS handle something with parachutes (even if FMRS's settings defer chute stages to SR), or you can use "none" to have neither mod attempt to handle recovery if you really don't want something recovered. The settings you make should be saved with the craft. If you use sub-assemblies they should be saved with those as well. There are a few cases where things might act different than expected. Please report your findings here in this thread. For instance, if you designate FMRS to handle a stage but FMRS is disabled, StageRecovery won't try to handle it. Is that incorrect behavior? Not necessarily, but you are all welcome to discuss what should and should not be handled in edge cases like this, and I in fact encourage these discussions. The following is a video showing how the two mods interact without RecoveryController (or in "auto" mode) and how RecoveryController allows you to have substantially more control over how your stages get recovered.

New release, v1.7.1. This release adds support for a mod called RecoveryController that will ship with FMRS. What this mod does is allow you to designate stages to be recovered by StageRecovery, FMRS, "auto" (what it does now), or "none" (no mods recover it). You can set (and change) the recovery controller while building the vessel and in flight. This is a brand new thing and there's a non-zero chance for bugs. If you test it out, let me and @linuxgurugamer know. Once the thread is set up for it I'll link it here and in the OP so you can give us feedback. It's a pretty exciting new feature and is the kind of integration I wanted to have with FMRS a long time ago Edit: Link to RecoveryController thread:

I'm pretty sure it was doing it at the equator as well, but I'll test that again. There's a bunch of rotation related stuff in the code I'm using and I've tried changing parts of it to see what happens, but it's had pretty much no effect. I'll ping Nightingale about it if I can't figure it out and end up going back to that mod at some point.

Yeah, it was mostly just me taking about various design considerations and the history of my mods, plus showing some other stuff I have been working on. I'm gonna do another stream next month and it's all recorded.

April development live stream is going to start in about 10 minutes (at 12pm EDT) and will run for up to 3 hours depending on how I'm feeling (got a bit of a headache starting) and if anybody shows up As I've mentioned in the past, the development itself probably won't be super interesting (unless you like staring at shoddy code, in which case it will be VERY interesting ) but you can chat with me live about stuff (KSP related or not). This month I'm going to be focusing on ScrapYard and KCT. https://www.twitch.tv/themagico13 Edit: Stream finished! Thanks for stopping by!