I would like to confirm that it is still not possible to place a realchute radial parachute to a craft in flight properly using KAS. As stated in the old issue report regarding this, the problem seems to remain the same. The chute is placed in the vessel, but with no model. If you activate the chute via staging, a crash is triggered. Using the latest versions of KIS/KAS Realchutes and KSP.

Tried to attach the chute and got error:

191206T215412.412 [ERROR] [RealChute.Libraries.TextureLibrary.TextureConfig.TryGetModel] [RealChute]: Could not find the ModelConfig at the index [-1] in the library
191206T215412.413 [ERROR] [RealChute.Libraries.TextureLibrary.TextureConfig.TryGetCanopy] [RealChute]: Could not find the CanopyConfig at the [-1] index in the library

Indeed Real Chutes doesn't like the way KIS spawns the parts. I'll get back to it when have spare time (from KISv2). If anyone could give more details in the meanwhile, it will be very appreciated.

FYI @ChrisViral

I'll actually look at real chutes and KIS code this weekend and see if I can come up with an exact cause, but I probably have a decent theory, as follows:

I don't know how familiar you are with real chutes, but it has 2 models for the actual parts. A main chute model, and a drogue chute model. There are also 2 canopy models; one having a single chute and the other with a tripple chutes. The default is the main chute model for the parts, and the single chute for the canopy. I'd reason to guess based on the error that when the part is initialized in VAB/SPH the ModelConfig and CanopyConfig index is defaulted to 1, and this is not happening in KIS. Unfortunately, I'm not sure how the VAB initializes parts, and haven't looked yet at how KIS does it, nor am I sure if KIS would have access to those parameters.

I'd rather see KISv2 though honestly, and since I don't see anyone else but me complaining, and stock chutes still work fine with KIS and realchutes installed, I'd be happy to beat my head on the issue for a while and let you keep working your magic on v2, and if I can't nail anything down, let you know I've given up and you can decide then if you want to spend time on it.

After a very quick glance at realchutes chutetemplate.cs , it looks like the initialization for chutes is explicitly different for ineditor vs inflight. This is probably a real chute 'issue.'

KIS initiates parts in flight in a bit not right way. There are reasons for that and it cannot be easily fixed. Most parts are just fine with it, but there can be an edge case. Probably, this is what we see here. Anyway, in KISv2 this part of the mod will be fully refactored to be in sync with the stock game containers. Let's hope it'll solve the issue.

As long as the problem persists, let's keep this issue open for the tracking sake. It would be really interesting and beneficial to see if it reproduces in v2. And thanks to for doing all this investigation! :)

After digging around a bit, I can see in real chute that when in flight, part initialization is skipped leaving a lot of parameters unset. I don't see anything that could be done from KIS's end to change that. I posted in issue over there. I am trying to work out a solution myself, as both KIS and Real Chute have a new version in development, and it probably isn't worth diverting either developers attention. This issue doesn't break KSP when both mods run, only when placing one of the parts added by real chute. This should probably be closed.

Hello! I think that I am experiencing this very bug. Here you can find a zip file with a short video describing the issue and the KSP.log and Player.log files.
As you can see the radial chute disappears when attached. In the video it is not shown, but if I try to deploy the parachute, it does not open and complaints "cannot open because stored inside fairings", or something like that.
https://www.dropbox.com/s/ufn0cv3tmhvkiim/Realchutes%20and%20KIS%20interactions.zip?dl=0

Some additional info:
OS: Windows 10 x64
KSP: 1.9.1 (heavily modded)
KIS: 1.26 (installed via CKAN)
Realchutes: 1.4.8 (installed via CKAN)