Zyglrox

@NathanKell: You deleted the old link, but forgot the new.

Weird, works for me. Worked with 2.1.0, didn't work with 2.1.3, works again with 2.1.5.

@NathanKell It's probably better to link the post from OP, because it's not a full Soviet Pack rescale, only several parts, and if someone loads BobCat's sample rocket, it will be all broken. So people need to see which parts are needed. However, if you are ready to maintain it, then by all means include it in RO, it's just a bunch of MM patches, no big deal.

Of all the orbital launchers currently used, two have the most launches: Soyuz-U and Proton-M, leaving everything else far behind. However, it somewhat bugs me that RealEngines pack doesn't have Proton second/third stage engines, RftS pack is very "anti-Soviet" in general, and realism patch for BobCat's rockets from the second post is outdated and doesn't work. So I decided to clean up the config that I use and share it. Soyuz-U and Proton-M parts rescale for use with Realism Overhaul Soyuz-U: 7t to LEO from Baikonur Proton-M: 21.6t to LEO from Baikonur Requirements: BobCat's Soviet Pack, Procedural Fairings. Basically, you only need 6 parts to build these rockets (assuming you make interstages with PF): GameData\BobCatind\SovietPack\Parts\Proton\Proton_core_oxidizer_tank\ GameData\BobCatind\SovietPack\Parts\Proton\Proton_second_stage\ GameData\BobCatind\SovietPack\Parts\Proton\Proton_third_stage\ GameData\BobCatind\SovietPack\Parts\SoyuzU\Soyuz_U_firststagelateral_booster\ GameData\BobCatind\SovietPack\Parts\SoyuzU\Soyuz_U_Second_stage\ GameData\BobCatind\SovietPack\Parts\SoyuzU\Soyuz_U_Third_stage\ Config with crafts here: https://www.dropbox.com/s/3n4dbzshkweyvzf/RealisticSovietPack.zip (crafts contain parts from PF 3.02) If you don't like anything, simply don't use this. If anyone's interested, stats taken from here: Soyuz, Proton

Haha, thanks. It's actually not THAT much harder to do stuff in RSS, since basic principles are still the same. Actually, it's my second nice-looking station out of dozens boring-looking-not-screenshot-worthy stations before it. It's a replica of ISS ROS with proposed future modules (Nauka and 2 power modules). Lack creativity? Build replicas!

Real Solar System + Realism Overhaul ~420 km orbit, passing over Mediterranean Sea:

Nathan, I'm sorry for littering the thread with small updates, but after some playtesting, the [stationHub] part from 3 pages ago doesn't need mass rescale (default 1.5t is fine), just size rescale. The real "UM" ISS module weighs 4t, that's true, but if we look at hub as a simple structural element (which it is), then 4t for a docking sphere of Zarya/Zvezda is way too much, that pushes full module weight over 25t and makes them not launchable with realistic Proton/Delta4H/Ariane. (building an ISS copy now, so... )

Achievement unlocked: Build a rocket that is perfectly designed to break the physics engine in ways that KJR cannot hope to fix. @ferram4 Thank you, I didn't know mass is such a huge factor. I thought it only affects CoM and aerodynamics. The decoupler is 0.6t, structural elements are 1-2t each, so yes, they have some mass but of course it can't compare with the 284t in the fuel tank below. As I said earlier, removing any of the two structural elements makes the rocket behave as it should (and I also forgot that you can add extra radius to fairings), at least now I know what was broken, so thanks for the explanation.

Yes, using 3.01. I tried to change node size to 3 anyway both in procedural fairings and procedural parts configs, to no effect. Will try 2.xx version later to see if it's procedural fairings causes troubles or not. Nope, with PF 2.4.4 and node size 3 it's the same. Even without procedural fairing parts at all it's still the same.

Here it is, no control input at all, just turned SAS on and going straight up: The small reaction wheel in the payload section can be turned on or off - it makes no difference. If I change the part with "KSP" letters from structural element into a fuel tank, no difference too. If I remove that part, the rocket controls just fine with no flexing, as it should. Yup, similar symptoms. And yeah, struts between upper stage fuel tank and fairing base don't help too.

I can't seem to understand how the recent versions of KJR work. So, I'm using full RSS/RO modpack, all latest versions. Some (not all) of my rockets are very fragile, what's strange is that they are not the largest and have relatively low parts count. For example (imagine Atlas V 501): 1. payload 2. decoupler 3. procedural structural element 4. procedural fuel tank 5. engine (upper stage) 6. decoupler 7. procedural fairing base 8. procedural structural element 9. procedural structural element 10. procedural fuel tank 11. procedural interstage adapter (for shrouding the engine) 12. engine (first stage) For some reason, this rocket can't handle any control input at all, it immediately starts flexing and spinning around like it's made of rubber. This is not a "bad aerodynamic flip" thing, the rocket in this regard should be fine. There's no ASAS module which interferes with gimbaling. I tried to mess with different config options (particularly, use volume not area, mass ratio for stiffening, uncomment "a's") and it didn't help. Now I have been away from KSP for several months, but I remember older versions of KJR and similar rockets in the 0.22/0.23 working flawlessly, so I even put config values from an older version of KJR (angular section) and it still didn't help. But if I remove the "9" part which is a simple 3.8x3.8m cylinder, the rocket suddenly becomes very rigid, as it should, and responds and behaves perfectly. I just can't understand why one simple part breaks the connections in such way, is it KJR, Procedural Parts or other issue? And how can I tune the KJR config to glue these things better?

No, both 2m regular and Sr clampotrons are currently size2 in the configs. (and that's cool that they are compatible because they resemble a docking system with active/passive roles). However, 2m SDHI clampotron is left at size1, which is used by small 1m ports. I wouldn't have reported wrong node if I didn't check first.

The 2m clamp-o-tron from SDHI won't dock with the regular 2m clamp-o-tron because it has the wrong node size. This should be added to [sDHI_ParaDock_1_ClampOTron] part in SDHI.cfg: @MODULE[ModuleDockingNode] { @nodeType = size2 } There are also IACBM docking ports incompatible with clamp-o-trons: [sDHI_ParaDock_2_IACBM], [iACBM_1.25m] and [iACBM_2.5m], but if this incompatibility is intended, they should be left alone (more realistic that way).

By the way, why move the LES to engine packs when it could live in Parts\Stock Resizes? Just curious. It's not even from propulsion category, it's a simple resize of a simple utility part with realistic size/mass/thrust, shouldn't differ with any engine pack.

Since Squad has made a launch escape system: @PART[LaunchEscapeSystem] { @rescaleFactor = 1.6 @mass = 4 @RESOURCE[SolidFuel] { @amount = 150 @maxAmount = 150 } MODULE { name = ModuleDecouple ejectionForce = 10 explosiveNodeID = bottom } } Apollo LES weighs around 4t, Soyuz around 7t. This one weighs 4.2t loaded and pulls Mk1-2 pod away with 8G's. Oh, and can't believe this part got forgotten. Seriously, how does one build space stations without it? @PART[stationHub] { @rescaleFactor = 1.6 @mass = 3.5 } With 6 docking ports it weighs 4t, just like the real node module.

May I suggest using size 4.0 as default? Larger parts snap much better in the editor, smaller ones tend to snap to the wrong nodes, often giving several seconds of frustration before you can properly attach and resize them. This also goes for all procedural parts. It's not a big deal, just a little bit more convenience.

Hi toadicus. If delta-v calculations are enabled in VOID, and if RealFuels is installed, every engine not configured for RealFuels spams a lot of errors: https://www.dropbox.com/s/6as6y1jtws2ff4z/output_log.zip Aside from error spamming, the calculations themselves work fine, but if using a bunch of such engines (i.e. sepratrons), the game can take a performance hit. Switching delta-v calculations off stops the errors. This was the same issue with Engineer Redux, until Padishar fixed it today: http://forum.kerbalspaceprogram.com/threads/72062-Test-of-continuing-KER-developments-0-23-5?p=1160511&viewfull=1#post1160511 Since VOID uses Engineer code for calculations, could you also include the same fix in the future VOID versions?

In fact, yes! Totally fixed now. Sorry for bothering, not a RF issue in the end.

Thank you! Works great, no more errors.

VERBOSE_DEBUG_LOG was off initially, and errors were generated. If I remove KER or just switch it off, the error flood stops, of course. VOID causes the same thing with delta-v display switched on.

Why do I need to update Procedural Fairings if the problem exists WITHOUT Procedural Fairings installed? OK, I installed PF 3.01 and it just broke Procedural Parts - now I can't change tank shapes anymore. Anyway, here's a simple craft: https://www.dropbox.com/s/bxpoysbj2hiw24p/srbtest.zip Procedural Parts + RealFuels + Realism Overhaul, nothing else. Just a pod, a decoupler and a procedural SRB. And clamps. It looks like this:

The one from KSP_Data, right? I also enabled VERBOSE_DEBUG_LOG, if that matters. https://www.dropbox.com/s/6as6y1jtws2ff4z/output_log.zip

Thanks, got it. diameterStepLarge = 1.0 That was not obvious at all to figure out, but it works.

No, I use the 2.x.x version from a ~week ago, and the rocket on the right doesn't have any Procedural Fairings parts in it at all, just pod, heatshield, decoupler and SRB.

Sorry, but how do I "activate" RSS step parameters? I deleted Keramzit folder, unpacked new ProceduralFairings, and when I add a fairing base, for example, large/small arrows still give 1.25/0.125 increments in diameter. Do I have to edit cfg's? Can't find anything related there. Oh, and since fairing bases don't have decouplers anymore, is the difference between fairing bases and fairing base rings purely cosmetical now, except their different weight?