magico13

It's kind of out of the way and I haven't actually documented it so it's easy to miss

Sounds totally plausible that it's ScrapYard. I'll try it out and will let you know if I get it fixed. Well, there's already a full list if you open up the "advanced" option on the regular part selector.

It should work in sandbox without any issues. Let me know if you need any help or have any questions about it since it's more geared toward career so you might need to tweak some things to get it where you want. The current version works for all releases of 1.4, including 1.4.2.

The reason it happens is because the chute state doesn't match at recovery and with a new chute in the editor. I already have a plan for this since I also play with RealChute and have the exact same issue. I have to add new functionality to modify values when adding parts to the inventory. A stock part with the same issue is fairings.

Sounds like ScrapYard (and a bit KCT), not this. Are you using the Override Funds option of ScrapYard? That's not fully operational and one of the issues is that you must have the funds for all of the craft without any discounts from ScrapYard. Also I don't think that option works correctly with KCT, so I don't recommend using it.

Yeah, the way it works is by simulating the keyboard pressing w, so I'm not surprised it acted weird when alt-tabbing

With KCT that can happen when a vessel is completed, which can definitely happen during flight.

Two main reasons, the first being that people wanted to use simulations without having to pull in all of KCT (even though you could just click a button and turn off all the other features) and second because then the simulations could be improved/reworked without being tied to KCT being improved/reworked. Since simulations are handled by a different mod/author I don't have to spend dev time working on them and keeping them up to date. Similar reason to why the inventory was swapped over to a separate mod called ScrapYard. KCT is now primarily just the feature of adding time constraints to things.

It was part of the update that is looks like they didn't mean to ship as-is. I think they meant to log to the debug log, but instead they are logging to the message app. From the changelog for 1.4.2: * Fix contract parameter completion to catch errors and contract parameters now log info messages when their state changes.

From a ScrapYard perspective your first question is going to be much tougher to handle than your second. For your second question you could check the modules on the part to see what fuel type it is and can write up a module template for it. If you post a craft file that is two of the tanks, one for one fuel and the other for the other fuel, then I could write up a template that you can use for that. Oh Scrap would still see them as the same part though in terms of generation, since it mainly looks at part builds, which is handled by name. It's possible to swap that over to be more restrictive and restrict on module. I can make that user or mod configurable.

Yep! I modified my launch script to (hopefully) detect any failures after igniting the engines prior to releasing the launch clamps, instead of staging everything at once.

I wasn't expecting this mission to go that great, but I wasn't expecting it to go badly this early! More reasons to double check your abort sequence... https://gfycat.com/gifs/detail/TeemingApprehensiveChihuahua

Modules look the same, but I wonder if it's FAR overriding the drag cubes. What was the issue you were seeing with RealChuteLite? If that was active StageRecovery should have calculated the parachute effects pretty much exact.

It doesn't seem to be recognizing the parachute. Do you have a mod installed that replaces the stock parachute module? Can you send me the craft file or the save file with this vessel in it? I don't necessarily need to load it, I just need to see what modules are on the parachute part.

I haven't looked at the logs yet, but KCT and Oh Scrap don't have any interaction, even through ScrapYard. The KCT build time is likely remaining high because you haven't "applied" the inventory to the vessel in the editor. By recovering the parts they've just been added to the inventory but parts aren't pulled out of the inventory until you either A use the "select" option from the inventory window or B "apply" an inventory part to a part on the ship in the editor. For the plane you're talking about you likely just need to use the "quick apply" option from the inventory UI. You should see the KCT build time almost immediately update to a lower time.

If you didn't already see, some people were reporting that the current version is working fine for them in 1.4.1 as well. But depending on how risk averse you are you may want to wait for an official 1.4.1 update, but LGG's got a very long list of mods he's updating at the moment so it might be a while.

I like it. Remote has authority by default, but local has the ability to override that, which puts the power back in the user's hands. An issue I thought of with my original hypothetical was CKAN. CKAN doesn't check the remote (as far as I'm aware) so it wouldn't be notified of the compatibility being updated so the mod author would have to make a new release anyway or change the ckan metadata. That's partly why I always use the min/max versions and specify an entire 1.x release, which it sounds like you've seriously improved in this avc release, so that's definitely welcomed. So whether remote has priority or not, if the author is using the version file for ckan then they have to update, so that setting doesn't matter to them.

Sorry, I just decided to read through what bugs you had fixed after you posted the release, saw that comment and then thought of that situation. I honestly haven't used KSP-AVC in years (other than the mini-avc bugging me every time I start up my current game) so I wasn't even sure what it would do before and just wanted to know if that situation was correct. Personally I don't care which one takes priority, like what @Jebs_SY said both ways have their advantages and disadvantages so as long as it's documented I'm fine with either way. Even though I don't use this, I am thankful that you put in the time and effort to update it.

Done. Kinda. You can't import the same craft with crew twice into a game or it throws an exception on save, but you can import them once per save without issue. If you bring it in twice you have to terminate one of the flights. I copied a vessel with about 7 kerbals from one save to another and it worked just fine and even imported a vessel with Jeb in it from December of 2016 that I apparently had sitting in my export folder.

Say there's a situation where the local config has a KSP version of 1.4.0 but the mod still works fine on 1.4.1. The mod author doesn't want to push a new release but also doesn't want the nagging "wrong version" pop ups to occur, so they update the remote config to use a range of KSP 1.4.0 to KSP 1.4.1 to hopefully fix all the players being nagged each startup. Does this mean that the mod author cannot do this and instead MUST release a new version just for updating the .version file?

On the page before this one

It used to be supported but it broke when they started doing better crew assignment checks back in 1.2 and I just haven't gotten around to fixing it. The crew information is still exported, it's just not pulled in during import. I might be able to play around with that tonight if that's something you want re-enabled.

It's been working fine for me. I had to exclude the KSP folder from windows defender since mods are getting flagged left and right for some reason.

The way that ScrapYard and KCT both operate is very part-based and knows little to nothing about the connections between the parts, so as of right now everything would happen at a part level only. Like you mention, that does encourage using the same launchers because the parts they're made of will keep getting used and will contribute less to the overall build time, but it also encourages building things like falcon heavy using more of the same parts used in existing launchers. If you can recover those booster stages it helps even more since parts from the inventory count as 100 additional uses. You can even prebuild a bunch of launchers, build the payload separate, then scrap one and edit the other and merge the two together to fully utilize your build queue and shorten overall build times (just make sure you're pulling the parts from the inventory).

If you notice any parts that no matter how many time you try to apply the part it won't "stick", then make a note of the part and any modules listed. I know of at least two modules doing this: RealChutes and the stock procedural fairings. I have to implement a new feature to get those to behave correctly. I can't promise I'll get every module working 100%, but I also won't be able to try if I don't know what modules are misbehaving