Phineas Freak

@Nhawks17 With the current system your best bet is to apply all patches as usual (:FOR[RealPlume-StockConfigs]) and after that (:AFTER[RealPlume-StockConfigs]) to apply patches for any specific parts (like the AJE ones). But this will easily break or become obsolete if new parts are introduced. A better way is to do what @Ser did: @MODULE[ModuleEngines*] { @name:NEEDS[!AJE] = ModuleEnginesFX %powerEffectName = Turbofan %spoolEffectName = Turbofan-Spool } This will set the engine module to be the FX one only if AJE is not installed. You will have to hunt down and check every part though (old or newly added) and apply the conditional check. That's why i offered the idea of decoupling the part from the plume patches. It is more work now (you have to remove the engine patches from every plume config) but you will never have to worry again for interop problems. If a new engine module type is introduced then you just add it to the global engine patcher as an exception.

Any engine module patching should really be moved outside of the plume configs. Apart from helping avoid problems like these it makes the patching easier. Global patcher template: @PART[*]:HAS[@MODULE[ModuleEngines*],!MODULE[ModuleEnginesRF],!MODULE[ModuleEnginesAJE*]]:AFTER[zzRealPlume] { @MODULE[ModuleEngines*],* { @name = ModuleEnginesFX } } BTW, the engine patching has no place inside the plume configs. The plume configs may depend on the FX engine module but ultimately it is a plume config and not a part config. We have the same problem with the RO plume configs too.

@Firemetal Since we are in a beta testing cycle, i would suggest to: Install only the required mods that are updated for KSP 1.2 at first. Start adding the rest one at a time if possible. Make sure that the mods you are adding are known to be compatible or working. Avoid mods that are not required for now. You can install them later.

Judging by the huge amount of mods that you have and errors stemming from KerbPaint and BDA i would suggest to test at least without these two for a start. There is an updated version of KerbPaint from @linuxgurugamer but it seems that BDA is not updated for KSP 1.2 yet. Offtopic: what's up with the KAX parts? KAX_medCockpit.cfg medCockpit.mu medCockpit_txr.dds They are normally placed directly under the parent GameData folder?

The only safe way that at least i have found is to revert to the VAB. It gets worse each time you try to revert to launch and sometimes the kick is bad enough to break apart the launch vehicle.

@Temeter i do not control any of the heat animations. In fact, these are one of the rare fields that are never touched by RO. When you say "brighter" what do you mean?

@Kramer If your config is the same as presented here then you are missing a closing bracket at the end of the PQS node: Edit: the KSP log files are your friends in such situations. This error will definitely show up when Kopernicus tries to compile the body config.

@Starwaster If @Aelfhe1m means the stock "Mk-2R" then it's internal one. The parachute parts do not have a maximum skin temperature pre-defined so DRE is needed to patch them (neither stock nor RO include these fields).

My mistake, i have fixed it locally and haven't push the fix to the mainline yet... It is probably because of the low maximum temperature of the parachute materials (the casings themselves have a maxTemp value of 1073.15 K). You won't see a big improvement but you will never have a crash (well, there is that 0.1% chance that something will go wrong). Nice to see more people helping and i really like the "all-up" testing style that you are managing!

The STS one was just a variant of the AJ10. There are many variants of this engine: AJ10-101/104: Thor/early Delta/Vanguard upper stage. AJ10-118F/K: Delta II upper stage AJ10-137: Apollo CSM main engine AJ10-138: Titan III Transtage upper stage AJ10-190: STS OMS/Orion MPCV main engine The problem with these is that they differ in appearance (nozzle size and mounting hardware) so you will need to make a model for each of them. The LR-91 is the Titan II second stage engine: https://en.wikipedia.org/wiki/LR91. You can say that, along with the LR-87, it's the Titan II (and later) propulsion solution. Please, consider these as suggestions, not requests. I'd hate to hear that you burned yourself out by trying to do a lot in a short period of time!

Did you test it with the latest RO from the repository? AFAIK there is a compatibility patch for the ModuleRCSFX ("RO_RCS_Fixes.cfg"). You need to either use the tech tree config from the KSP 1.1.3 RP-0 release or compile your own from the RP-0 "tree.yml" database (but requires a Perl interpreter). BTW, for the reentry tests make sure that you have RealHeat installed. There were some cases of false bug reports regarding the heating model that were caused by the missing RH mod.

This is shaping up nicely! If your roadmap also includes engines like the LR-87, the LR-91, the AJ-10 etc then i will be sold so hard...

@pap1723 The EVE configs definitely need to be adjusted for the smaller scale. For the Scatterer configs i am not so sure but when i tried the opposite of what you are attempting (using SSRSS for RSS) none of them worked. I had to remake them from scratch. You may be SOL if that's the case. I would suggest to start from the EVE clouds. They are fairly straitforward to make/adjust using the GUI.

@spec111 Try and disable the fairing auto-struts.

@ikeel_u Then we need a detailed mod list and a KSP log file. Especially since the full RSS/RO/RP-0 suite is not yet updated for KSP 1.2. For a start, you could try to install only: Kopernicus RSS RSS Textures Modular Flight Integrator and see if you still have problems. All the above mods are updated and you should have no problems.

They are both RO and RP-0 ready.

@ikeel_u Do you have Modular Flight Integrator installed? If so, is it the latest version?

@politas BTW, this thread should be tagged as "permanent".

Speaking of Russian engines, i have not ever seen someone making the RD-100 series (derivative of the German Ofen-B series). These can help fill some gaps in the early rocketry age, especially since this is a realism pack (not worrying about balancing or exact purpose "in life"). The nice thing is that they are visually very similar so you can get almost all the varants at once, from V-2 to Bumper to R-5. Your engine pack is fantastic! If someone has not started yet, i am making an offer to add proper RO support for them. Edit: sample engine link

@linuxgurugamer OK, the RO and RP-0 compatibility patches are ready and awaiting approval: RO compatibility pull request RP-0 compatibility pull request

@leudaimon Yep, that's what i am doing right now. With some fudge factors of course, like the Mk1/Mercury pod comparison.

Then i should change the mass to almost double of that. Thank you for pointing this out!

@linuxgurugamer The first step would be to make it compatible with RO. Then, after it is compatible with RO, we add the tech tree support that is RP-0. It is not something that a modder should include with a mod but it is taken care by the KSP-RO team. I will make a proper PR to include support for your mod for both RO and RP-0.

@Sol Invictus Because it is not "EVA propellant" anymore: And because this is a testing patch, the amount of the propellant is overkill (approximately 6 Kg!)

@linuxgurugamer Something like the following patch will do the job: @PART[K2Pod]:FOR[RealFuels] { !MODULE[ModuleFuelTanks],*{} MODULE { name = ModuleFuelTanks type = ServiceModule volume = 350 basemass = -1 TANK { name = ElectricCharge amount = 75 maxAmount = 75 } TANK { name = MonoPropellant amount = 15 maxAmount = 15 } } !RESOURCE,*{} } Do note that it is supposed to be included with RF. Remove/replace the FOR pass if it is going to be included with your own mod. BTW, the two screenshots that @xel'lotath posted over to the K2 Command Pod thread are a bit misleading: the user has installed the RSS/RO/RP-0 suite of mods but your mod is not supported by them (it is getting a generic RF support but has improper RO support). Edit: just saw your reply on the K2 thread.