unclepirog

I've used both simultaneously, haven't seen any difference in performance.

Me too

Not only Rus, but also Volga and early Angara and Feniks variants.

@Beale I'll second previous post author. 1.5m is more preferable than 1.625m due to compatibility with other mods. And 1.85m variant would make fine Soyuz-3 proposed launcher core. Also, talking about Soyuz rework, is there any plans for Soyuz-2.1v (larger diameter first stage core with NK-33-1 engine, http://www.russianspaceweb.com/soyuz1_lv.html)? It would be very nice "what if" addition, especially with "Volga" upper stage.

Btw, RL Zenit is capable to lift twice as much payload to LEO (~14t vs ~7t of Soyuz)

If anyone still interested in...

Yay! Btw, I'm on1.6.1 right now. Also, still playing 1.3.1 RP1 and 1.2.2 QRSS campaigns, but those felt back so far and modded so heavily, that I don't even bother to update mods used for them (there is always chance to break something, yk).

Just took a quck look to B9 code, as well as at KSP class reference. One wild idea (not sure if it will work, @blowfish can correct me). This structure: solarPanelRootGameObject - transform1 -- solarPanelTransform - transform2 -- solarPanelTransform transform1/transform2 are switched with B9, while DeplyableSolarPanelsModule are linked to solarPanelTransform gameObjects/transforms. Have anyone tried this? EDT: Question is, when does Module caches references to gameObjects (if it ever does).

Will they be separate parts, or alternate models as current "-E"-variants? Maybe parts mesh variants (stock variants, or B9, or whatever)? Thumbs up!

Wish I knew about "-E" meshes earlier! In my campaign I've rescaled some Soyuz (and all of Vostok) parts with MM configs, replaced some others with procedural tanks and wondered, if Voskhod in 1.25m is even possible... three or two (with huge helmets) in such a small capsule. It would be awesome if 1.5m would be adopted by @Beale as one of common sizes in Tantares (as @CobaltWolf did earlier in BDB).

Is it about scaling Soyuz parts up to 1.5m?

I`d prefer standalone hollow physical part (some kind of one piece jettisonable cargo bay cover). The reasons is: 1) we can put something (i.e. payload), inside; 2) glue something outside on surface; 3) use it somewhere else (as cover/skycrane for lander for examle);

Encountered same behaviour with 1.3.1 RP-1. Try to EVA all kerbals from craft before recovery attempt, in my case it worked.

In my heavily modded game it doesn't. However, in old videos of ancient times (see OP) it was. For example, in Scott Manley's video that can be seen at ~2:30.

Is there any chances to get compatibility with RealChutes?

At first glance it works fine now, thanks!

It may be problem with my installation, but I've just checked it two more times. KSP 1.6.1, BARIS 1.8.2, bunch of other mods (haven't touched them) stayed the same. KCT 1.4.0.69 with MagiCore 1.3.1.0: works as intended (at least starting new game, choosing KCT preset, adding vessel to KCT build list by "Launch" button, launching it). KCT 1.4.5.1 with MagiCore 1.3.1.4: don't, as I've reported earlier. I'll try pure unmodded install later, just to be sure.

What KSP version are you using?

Yeah, at least ages ago, at times of 1.3.1

@linuxgurugamer, @Angel-125 Not sure, if this should be posted here or on BARIS thread, but integration between these two mods seems broken. Going to start a new campaign, I've just started installing desired mods one-by-one, checking them after each change. After adding BARIS (tried both 1.8.0 and 1.8.2, no difference) to install with working KCT (latest 1.4.5.1), latter stopped to work: click on "Launch" button in VAB brings me to flight scene directly and won't add vessel to build list. After starting new game KCT didn't even offers to select preset. There's one meaningful exception at log (by KCT, so I'm posting these in this thread): Link to the complete log file (started new game, dismissed opened startup windows, closed game, that's all; exception message at line 24810): google drive I'll gladly provide any other info if needed.

Speaking of balance, it will be pretty good balanced with stock lab parameters, except dataStorage of ModuleScienceLab reduced to somewhere around 100-200. Science processing rate depends on maximum available data, so this config will provide 10-20% of stock science lab yield. Another way is to nerf dataStorage little less (~300-350), but fiddle with scienceMultiplier (rate of data to science), thus requiring constant flow of new experimental data to keep lab useful.

Option 1 is more in line with real Kvant-2 internal layout: cylindric scientific instrument compartment (ПНО) and airlock compartment (ШСО), so I'll choose this one (to shamelessly tune it with MM-pathes for WBI, StationScience and Jeb knows what 80 )

Yes, it is. I'm playing it on mac and everything is fine for me (so far I've got myself to Moon landings and couple of Venus and Mars flybys)

Vote to github!

That was fast!