Al2Me6

This is highly unlikely to have anything to do with Waterfall.

This has been fixed in RF v13.5.3; apologies.

This looks absolutely amazing. Kudos.

Ah, I see that my experiments made their way here. This was indeed made with RealPlume (it'd be hopeless with stock), though I did not spend any time at all looking at the particles themselves -- that'd wait until after I see if the approach works. Performance would indeed suffer, though I don't think the SL parts of the WF plume would need to be particularly complicated, so I can't imagine it being that much worse than the status quo. If it does happen, though, I will leave it as an optional feature for those who want the eye-candy. I spent perhaps an afternoon working on that; you're right that a proper approach would take a lot more time (that I do plan to spend at some point). The issue I encountered is that particles have physics and WF doesn't -- I suspect that I'll have to have two emitters, one producing particles with reduced physics inside the mesh, and another one producing 'normal' particles for the smoke trail. It remains to be seen if this actually works in practice though. Testing and tuning will also be particularly gnarly. If anyone is interested in helping making this work for Realism Overhaul, I am happy to clean up what I have and put it on my gh. This is a config error. The engineID key (see, for example, https://github.com/Tantares/TantaresLV/blob/09849b35da1ef9dc40b9bf9e975f6fed7b413b11/GameData/TantaresLV/parts/PROTON/_waterfall.cfg#L423) was moved inside the throttle CONTROLLER in Waterfall 0.6.0, so with the current configs all four modules are reading from the first ModuleEngines, hence the observed behavior.

It will be updated when we are ready. You answered your own question. I personally suggest working through the command-line CKAN installer, it's a lot easier now (only one 'mod') with the express install package. Yep, the easy way is to edit this file. https://github.com/KSP-RO/RealismOverhaul/blob/d81d50848d60e1a7cb69b2b7de6cb15e4b621090/GameData/RealismOverhaul/RealismOverhaul_Global_Config.cfg#L308

While I did make the forum post, the mod should be credited to KSP-RO contributors as a whole.

https://github.com/LGhassen/EnvironmentalVisualEnhancements/pull/11

And how will help that anything? Atmospheric drag isn't applied during timewarp or while the vessel is unloaded. Sure, it works for a few more kilometers while you're at the vessel, but you're just moving the problem elsewhere.

Principia does not model decay due to atmospheric drag.

That looks AMAZING.

RSS-CanaveralHD An add-on to RealSolarSystem that provides high-quality, realistic textures for the Cape Canaveral area. It builds on work by Katniss218 and AnticlockwisePropeller, combining their advantages and alleviating some drawbacks. Notably, a decal is placed under the visible static so that there is terrain (rather than water) underneath. Note that this mod does not provide any additional launch pads. The stock KSC and the stock launch pad are repositioned to the visitor center. CanaveralPads A package of KerbalKonstructs configurations that adds historical launch pads and structures to RSS-CanaveralHD. Most of the configs were provided by Discord user Aviation365, while the LC-39 asset was provided by Katniss218. Pads and statics provided: Note that many of the pads have changed over the years. All necessary buildings are provided, but some are clipped into the ground. To adjust pad configurations, offset the underground buildings by 100m upwards and offset existing buildings underground, as necessary. Further note that the LC-39 asset shipped here has been modified to be compatible with Modular Launch Pads and other very large crafts. Album Installation & Dependencies Both mods are available on CKAN and are part of the high-res RP-1 express graphics package. Release zip files can be found at the mods' respective repos (linked below) for manual installation. Dependencies of RSS-CanaveralHD: RealSolarSystem Dependencies of CanaveralPads: RSS-CanaveralHD KerbalKonstructs Tundra's Space Center OSSNTR Source Code & License License: CC-BY-NC-SA 4.0 https://github.com/KSP-RO/RSS-CanaveralHD https://github.com/KSP-RO/CanaveralPads Thank You RSS-CanaveralHD and CanaveralPads are maintained by the KSP-RO team. Many thanks to @Katniss218, @AnticlockwisePropeller, @NathanKell, @Aviation365, and @Al2Me6 for their contributions.

It would be helpful if your screenshot actually showed the position of the maneuver... I'd guess that your actual trajectory wasn't the same as the flight plan because you didn't rebase.

Sorry, I never looked at that part. I do configs for RO only and that part isn't used in a 'conventional' RO install.

That is in fact an RP-1 question and not an RO question. Regardless, the answer is: since a few versions ago, there is no uncrewed science to be gained below 40km altitude. The only flying low science on Earth are the crewed supersonic experiments. This was done to discourage flying a Cessna around to take pictures, since that doesn't make sense.

Honestly, don't bother with this part because its transforms are kind of broken. I tried and had to give up: https://github.com/vevladdd/RO-Waterfall/blob/master/RealismOverhaul/Waterfall_Configs/SXTContinued/sxt_lem.cfg#L15

Downgrade to ModuleManager 4.1.4, this is a known issue. See https://github.com/sarbian/ModuleManager/pull/171

Ah, sorry. Please take your time.

You can, though it's very difficult to make it look good while the rocket is moving. I've got a stationary setup working, that's about it. There's really nothing special to be done, just add a RealPlume or stock effect like you normally would. This is what my attempt looks like: @Nertea, I don't mean to be pushy, but could you take a look at https://github.com/post-kerbin-mining-corporation/Waterfall/pull/80 when you have the time? Thanks!

Release of version 0.2.0: Complete rewrite of the highlighter. Known issues have been resolved. Greatly improved support for ModuleManager syntax.

After several months of work, the newest releases of Realism Overhaul, ROEngines, and ROCapsules now provide official support for Waterfall. Thanks for all the amazing work you've done on Waterfall, Nertea, Zorg, et al.! A few screenshots taken by yours truly with Waterfall + RO: https://imgur.com/a/mxkFjHJ

I've been told that the new version (3.4.3.2) produces the following logspam: [EXC 20:48:48.947] TypeLoadException: Could not resolve type with token 0100005a (from typeref, class/assembly EditorLogicBase, Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) EditorExtensionsRedux.EditorExtensions.OnGUI () (at <a5212d5164ff40c8840dd8c9f42ef3c9>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Would it be more clear to design your plumes to be expansion-compatible with other plumes and offer an optional patch that reduces the expansion coefficient to make everything expand later?

This. Is. Stunning!!!

Hmm, Earth uses the Kerbin template: https://github.com/KSP-RO/RealSolarSystem/blob/f527765729f0ba0e1c671ba151566dea31063a4a/GameData/RealSolarSystem/RSSKopernicus/Earth/Earth.cfg#L11-L13

Would there be a way to fix it? I understanding there's some kind of templating system involved. It is indeed not too obvious in this screenshot, just a few squares near the Cape. I believe it might be more frequent/severe for other bodies, though (Mars's moons are affected, I think).