Update MMPatchLoader.cs

[R-T-B]

The commit basically says it all here.

As to why this is needed: 1.8 has SIGNIFICANT drag calculation issues as noted here.

https://forum.kerbalspaceprogram.com/index.php?/topic/189064-investigating-significant-drag-and-heating-changes-introduced-in-180/

Substituting the old PartDatabase.cfg works around this issue, and new entries like the new boosters are auto-regenerated. However, this becomes unreliable with a modded install with ModuleManager, which often wipes the file completely and eliminates the users desired "static" settings (in this case, the 1.7 ones).

This added code checks for a file named "StaticPartDatabase.dbk" in the KSP root. If found, it uses this as a template instead of completely deleting/blanking the file. If the file is not present behavior is unchanged. This allows easily

I'm not sure whether you want to mainline this. I plan on releasing binaries with this patch soon (along with some prep scripts for 1.7 exporting, and yes, there will be telltale signs in the logs of my patchset) and could continue to maintain that if need be, but it seems like a good/useful feature. To be clear (doubt I need to say this, but...)

I hereby grant you all rights to use and customize this limited code snippet and general idea in all capacities as you see fit.

Original commit log entry follows:

Add static template support for PartDatabase.cfg, using filename StaticPartDatabase.dbk. This helps greatly when drag goes crazy as the user can sub in an older db or hand edit as needed.

This fork/commit is for pull request reasons only.

[sarbian]

This will be fixed in 1.8.1 in a few days and using a static db will not work for any mod with parts.

[R-T-B]

It does work with mod for parts, I'm using it that way now. If you do not believe me, I suggest you try it yourself. I was very careful to ensure that.

It's not "static" so much as a "template." Poor wording, perhaps.

The code placement is timed in such a way that it is inserted prior to the ModuleManager or Kerbal getting it's hands on the file. Thus, modded entries are regenerated prior to loading. I've tested it and it works with mods perfectly. The whole point of this is to make this work around work with mods. We can do without all this hoopla if we aren't running mods at all (ModuleManager included).

Furthermore, this has use beyond just 1.8.1 for tweaking values manually as an end user, or the next time they muck up a value (this isn't the first, we've been having ongoing problems with this file since 1.5 as OHara notes here)

I would kindly ask you to reevaluate. Of course, it is your choice. I sincerely hope my prior forum mistakes are not factoring into your decision. I am trying to do things right this time.

[sarbian]

I know how the cube are (re)generated (and why they are generated wrong in 1.8) so I know that if they are generated wrong for a stock part then they are also generated wrong for a modded part. As I said you are only fixing the stock parts and the modded part would have the same unbalanced drag. As for tweaking the values there are stock way to already do that (set them in the part config) and mods that allows to tweak them (like MM with te PHYSICS node edit) or straight ignore them with FAR.

[R-T-B]

I misunderstood you. I thought you meant modded parts would not work at all, period. I get your reasoning now, especially if there is already an interface to do this.

Of course modded parts will not be correct by the drag model, but it's better than almost nothing working, as an example.

Still, your reasoning about 1.8.1 being on the horizon is valid and understandable. Thank you for explaining. I wasn't sure how close to a fix we were, frankly.

Given the above, I will neither maintain a patch set nor keep this repository up. Thank you for your kind and rational explanation.