Phineas Freak

Do note that you have to horizontally flip the texture to get the correct view. You can check the rest of them here.

@Mad Rocket Scientist The RD-703 is a single-chamber version of the RD-701 so don't forget to also include it!

@Iso-Polaris Because it is not working with the latest version of Scatterer (v0.300).

You are missing a "powerEffectName" field in the "ModuleEngines*" module. If your part config does not have a global engine configuration then the "ModuleEngineConfigs" will not apply it's patches. The fallback "ModuleEngines*", since it is missing the field, will not apply a plume. In the end, no plume will appear.

Can we see this RealPlume config?

This config syntax is invalid, since you need a MODEL node to host them. The correct one would be: MODEL { model = Bluedog_DB/Parts/Apollo/bluedog_Apollo_Block3_MissionModule scale = 1.0, 0.8, 1.0 }

You can't, at least not the complete and "ready for consumption" package. You will have to download the source code, recompile it's code locally and drop the new binary in the place of the old one (from KSP 1.1.3).

The S5.92 has a nozzle diameter of ~0.85 m while the S5.98M has a nozzle diameter of ~0.95 m. So yes, it is a bit smaller in diameter but they have very similar lengths (~1.03 m vs ~1.15 m)

@Alcentar As i was making some configs, i noticed a small bug: [ERR 14:54:45.257] Module ModuleEnginesRF threw during OnLoad: System.ArgumentException: The requested value 'LiquidEngine' was not found. at System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase) [0x00000] in <filename unknown>:0 at System.Enum.Parse (System.Type enumType, System.String value) [0x00000] in <filename unknown>:0 at ModuleEngines.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at SolverEngines.ModuleEnginesSolver.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at RealFuels.ModuleEnginesRF.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 Specifically: The requested value 'LiquidEngine' was not found. There is a typo in your configs: the correct EngineType definition for the liquid engines is LiquidEngine and not LiquidFuel. I searched all your configs and almost all the engines are affected. The only one that was not is the RD-191 (that did not include the EngineType field). Edit 1: if you don't mind, add the S5.98M in the list. It is visually similar to the S5.92 so modelling it should be relatively easy. Edit 2: i failed at basic "configing". The engine definition is correct and i am wrong. Don't change anything!

Just place them on the designated points of the payload/interstage adapter. Right-click the adapter and disable the auto-shape option for custom-shaped fairing forms. With a bit of work you will get every fairing shape and size that was ever used in a launch vehicle. Alternate PF packs also help a lot. Procedural Fairings For Everything is highly recommended, especially for RO. Depending on the definition, ullage can be: The empty space in a fully-filled propellant tank. You cannot fill a tank and expect it to have a 100% utilization (the Centaur upper stage comes close with ~92%, the ACES upper stage will have ~95%). It is also required for cryogenic fuels, since they turn from liquid into gas (and gas requires a larger volume to expand without ruptuting the tanks). The condition of the propellants while in microgravity. Liquids tend to form spheres in microgravity and this means the propellants will be away from the engine inlets. @Nittany Tiger explains it in depth. The utilization for the procedural parts is there as a way to adjust the propellant mass ratio to make it possible to create replicas. It depends on the tank type (default, cryogenic, service module, balloon, all theoretically have different utilization factors) and on the application (main propellant tanks, life support storage, ACS propellant tanks etc). The default value of 86% is a nice average value between all these. 95% puts it in the same category as a balloon-type stage (Atlas-Centaur), a bit unrealistic for your every-day launcher.

@Meltdown The MM conditions that you have specified are...weird: Basically, you are adding a module that requires RealFuels (ModuleFuelTanks) but you do not allow the MM patch to apply it if RealFuels is installed. ? Also: 1. Deleting the PROPELLANT nodes is not required. A better way is to patch them, rather than doing double work. Example: @PROPELLANT[LiquidFuel] { @name = Kerosene @ratio = 36.699904 } @PROPELLANT[Oxidizer] { @name = LqdOxygen @ratio = 63.300096 } 2. The resource flow rules are not needed. The engines in KSP respect the stack priority by default.

No, only the audio and visual stuff. The rest of the functionality (per-axis thrust, always full thrust, thrust by throttle) are all included in the base ModuleRCS (since the ModuleRCSFX inherits from it).

@Meltdown Since it is a curve, more points can help but the actual difference will be so small that it is not even worth thinking about adding them (RO for example strives for realism, yet this kind of accuracy is useless). Besides, how are you going to model the engine? You need hard data on the nozzle shape, chamber pressure and temperature, propellant chemistry (both for the reactive propellants and the exhaust products by mass) and more. TL;DR: two points for the atmospheric curve are fine. Do not bother for more.

We have: MagicSmokeIndustries (target mod) Sol Mods (custom mod) So the mod order is good. Can you test if the the tech tree patch loads as a semi-final MM config? @TechTree:FOR[zzzSolMods]:NEEDS[MagicSmokeIndustries] { @RDNode:HAS[#id[largeUnmanned]] { @id = IR @title = Infernal Robotics @description = Mechanics have been a thing for a while, so why not use them with rockets?. @cost = 20 @hideEmpty = False @nodeName = node44_IR @anyToUnlock = False @icon = RDicon_robotics @pos = -1500,800,0 @scale = 0.6 !Parent,* {} Parent { parentID = science3 lineFrom = TOP lineTo = BOTTOM } }

The fact that the patch might not work for various reasons (typos, mod loading order etc) does not mean that there was not a problem with it's syntax... You have a patch that modifies the tech tree. Where is that patch placed? Directly under the GameData folder or inside a custom one?

@ThePhoenixSol In your original part patch you had: @PART:NEEDS[MagicSmokeIndustries][partName01|partName02|partName03...] This is syntactically wrong, as MM expects: @PART[partName01|partName02|partName03...]:NEEDS[MagicSmokeIndustries] As @Starwaster pointed out. The part names go in between the PART and the NEEDS/FOR/AFTER checks.

That's how the liquid rocket propellant science works: high Isp --> low thrust, low Isp --> high thrust. Do not try to use hydrolox for heavy lifting, use it for efficiency, low mass, high energy orbits. I do not think that resource conversion is something that RF will ever do since it is out of scope. There is a WIP mod that converts the stock resource converters to work with realistic resources though: https://github.com/jbengtson/RealISRU

There is an easy way via a command line switch: Create a shortcut to the KSP binary. Open the shortcut properties and append the switch "-single-instance" at the end of the path. ? Profit!

@KGas- Inc Forget it, i interpreted your original post wrongly. I do not know why there is that difference.

@KGas- Inc SpaceDock has a version for KSP 1.0.5 but i am not aware for any version for KSP 1.1.3. Although i am not sure if there were any changes after the KSP 1.0.5 release, the model files are the same.

Who said that they did not change? There have been many model changes between the KSP 1.1.3 and the 1.2.2 versions by @raidernick to fix various problems with the colliders. And even if i am wrong, the current behaviour is the expected one. So, what's the actual problem?

@Ser I have been wearing the RO glasses for too long and did not realize that the case of the stock RP configs is easier to deal than the one for RO. In any case, yes, checking only for the basic ModuleEngines is easier, better and safer. @Nhawks17 New and updated global patcher: @PART[*]:HAS[@MODULE[ModuleEngines]]:AFTER[zzRealPlume] { @MODULE[ModuleEngines],* { @name = ModuleEnginesFX } }

In the US they are using the term astronaut but in Russia they are using the term cosmonaut. Since he was trained in Russia he will be a cosmonaut.

Yep, that's the way @Ser did it! Just an extra check so that AJE continues to function as expected. "My" way is a bit more complicated at first but easier afterwards. You define the global patch that i showcased and then for the plume config you use: @PART[turboFanEngine]:FOR[RealPlume]:NEEDS[SmokeScreen] //J-X4 "Whiplash" Turbo Ramjet Engine { PLUME { name = Turbojet transformName = thrustTransform localRotation = 0,0,0 localPosition = 0,0,-2 fixedScale = 1.8 energy = 1 speed = 1 } @MODULE[ModuleEngines*] { %powerEffectName = Turbojet %spoolEffectName = Turbojet-Spool } } The complicated part is to make sure that the global engine patcher works and that no one inserts a "@name = ModuleEnginesFX" inside the @MODULE[ModuleEngines*] node. The engine module patching is then taken care automatically by the global patch for all possible parts that use the AJE module.