Engine Parts Discussion

[NathanKell]

The VSR discussion here ( KSP-RO/RP-1#978 - also relevant to RO ) reminded me.

So...there are a lot of duplicate, same-stat parts. Now, there are mods to fix that, but here's another proposal that was made a while ago that I want to put forward again, especially given what's going on with RealEngines.

And that is, remove all existing engine PARTS. Instead, RO should only create one PART for each engine, and then select the best model for it.

Now, that's probably too extreme a version of what we should be doing (there are some times where you might want a couple different visual models of a thing hanging around, e.g. for specific LV partsets you might want a specific engine PART), but it's a thought. And in particular that neatly solves the VSR-engines problem, i.e. if you have a "real" engine mod (RealEngines, FASA, BDB, SSTU, whatever) then the stock engines would seamlessly not bother anybody.

[PhineasFreak]

Does MM checks the existence of MODEL nodes in alphabetical or sequential order, i.e.:

PART
{
    name = MyPart

    MODEL:NEEDS[BluedogDB]
    {
        model = path/to/BDB/engine/model
    }

    MODEL:NEEDS[RealEnginesPack]
    {
        model = path/to/RealEngines/engine/model
    }
}

Does the above mean that the part will use the RealEngines model if both mods are installed or the BDB one?

And as you note, if both mods are installed how can we select via MM the model that best fits us/the user?

[Theysen]

Can we set a flag via a MM patch to exactly enable such a mode - if possible at all - so the user can decide? Would be the best option imho.

[smartdummies]

I would love to have RO remove all engine parts and create its own. But instead of selecting the "best" model, which would be different depending on who you ask, I suggest using the variant feature KSP introduced in 1.4 and add the models from the install mods to the RO engine and allow the user to select the one they wish to use. I have a proof of concept to demo this using the LR-79 from RaiderNick and FASA at https://github.com/smartdummies/EnginePOC.

[smartdummies]

Apologies in advance for the rambling nature of this.

I have a branch on my fork that combines several engine (Aerobee, A4, AJ10 Early, AJ10 Mid, LR91, and LR105) into master parts and uses the models from the mods as variants. Please note that I do not have the plumes working on all models and this is something that will take code to correct as I have not yet been sucessful doing so through MM patches. I also have done the same for the quad block RCS thrusters (but the aforementioneed plume issue still applies) and I believe that I can do the same for antennas and science parts if need be. The parts I did were to test various scenarios - The LS91 is complex with the vernier engines and I have all supported mods working correctly. The AD10 Early and Mid were done as the SSTU engines used a different thrust transform and all models apply the thrust correct.y. The A4 shows the ability to adjust the mass (the shrouded version is now 150 kilos heavier as per the comments in the config files from Tareobee mod) and the LR105 (I only did a couple of mode for this one FASA and BlueDog) show having the Kerosene in the FASA model but not in the BlueDog. I did the RCS thrusters to verify that this can be extended beyond engines and as there are places in the definitions in the variants to disable events and animations I believe that this can be extended to the science and antenna parts as well. Command pods are also a possibility (I might have to live with the fact the for ones like RN Vostok and Voshkod he has extra nodes that would have to be defined on the base part and then just hidden in the center for models that don't use them).

I feel that this has several advantages:

• Removes part clutter since there will only be one part listed in the VAB instead of one per supported mod but sill allows the player to choose the model that they prefer
• Eases maintenance as there is only one place that needs to be touched to change any statistics for a part. This also ensure that all supported mods use the same definition for for that part. This means that things like TestFlight configs, antenna powers, etc. only need defined in one place and there is no longer a possibility that some parts are missed when adjusting stats
• RP-1 would enjoy the same reduced maintenance as each part is only one part now so the placing and costing them requires only doing so for one part and there is no longer a need to make sure that all engines of the same type are purchased when purchasing one of them.

Unfortunately there are a few downsides

• I am using the B9PartSwitch mod to remove all shrouds from the engines. I have learned a trick or two that might make it possible to have the shrouds added back but for now the B9PartSwitch is a new requirement
• I am using the KSPF mode from Electrocuter to set the resource amounts on the per model basis. This mod addds the functionality for controlling the resources and properties of any module in the variant definition. This might be able to be used to add the SSTU engine clustering to all engines but I have not yet checked that out but it is a new requirement. I may end up using this to get the plumes correct for each model as those are still a work in progress - I am looking at his code if if I continue down this route I see what needs to be added to include this into his mod but again it is a new requirement
• Save compatibility is an issue as this is creating new parts and replacing all the parts from the mods. Ideally if I can figure out how Squad deprecated the parts they redid but still allowed them on existing craft without them showing in the VAB/SPH that would be great but otherwise this would not be save compatible.
• All parts woud have the same configs. I mention this as the RN parts are very specific replicas such as the Baby Sargent engines where the only available config is defined by him. In what I am proposing because his parts would simply be a different model on the Baby Sargent part all the configs would be available.

With all of that said I believe that this is worth pursuing. But before I continue sinking time in it I wanted some feedback as to whether or not this is a path that the RO team wanted to go down. @NathanKell @pap1723 @raidernick if you could take a look at the PartConsolidation branch I have in my GitHub fork (https://github.com/smartdummies/RealismOverhaul/tree/PartConsolidation) and provide feed backI would appriciate it. If this is something you would like me to pursue then I would feel a seperate brach would be benificial as this will take a bit of time to complete, but I would think that I can get it done for a 1.7.3 release.

[raidernick]

I believe I explained myself about my feeling on this on the discord well, but for anyone who didn't see it, I'll sum it up here. I don't feel that RO should do anything beyond configure parts to have realistic values. It shouldn't touch what parts show up as this can cause false bug reports about things not working and break the individual part packs that rely on using that specific model from that pack only to have it disabled by this and use a different model.

I suggested this be put into ROengines instead as the premise is very similar and it should remain it's own mod not merged into the core of RO.

[Capkirk123]

Seeing as ROEngines has gained PatchManager as a dependency, and come to be a standardized engine pack for RO, I think this issue can be considered resolved?