As of KSPCF 1.24.5, the patched ConstructBilinearCoords() methods by the MapSOCorrectWrapping patch will have the side effect of removing the Mohole (big hole at the north pole of Moho) because Squad choose that "this is not a bug, it's a feature".
To prevent that, we can acquire references to the Moho MapSO instances (biome map and height map) and fall back to the original stock implementation if the method is called on those instances.
This not only affect Moho : that patch on a stock install results in all stock bodies getting a significantly different terrain at the poles, but due to how performance sensitive those method are, checking all stock MapSO instances (there are 40 of them) isn't really an option.
Also note that the fix need to do reference acquisition from a PSystemSetup.Awake() patch because that's the only way I found to ensure we always run before Kopernicus. Failing to do so will result in Kopernius itself calling the patched methods without the bail-out on Moho active, resulting in incorrect placement of the anomaly marker, and potentially other weird issues.
And on a side note, my opinion is that this patch doesn't belong in KSPCF and the whole thing should be handled by Kopernicus as the stock ConstructBilinearCoords() implementations are only an issue in the context of planetary system modding, and the side effects shouldn't be something players not using Kopernicus should have to deal with.
See forum post and reddit post
As of KSPCF 1.24.5, the patched
ConstructBilinearCoords()methods by the MapSOCorrectWrapping patch will have the side effect of removing the Mohole (big hole at the north pole of Moho) because Squad choose that "this is not a bug, it's a feature".To prevent that, we can acquire references to the Moho
MapSOinstances (biome map and height map) and fall back to the original stock implementation if the method is called on those instances.This not only affect Moho : that patch on a stock install results in all stock bodies getting a significantly different terrain at the poles, but due to how performance sensitive those method are, checking all stock
MapSOinstances (there are 40 of them) isn't really an option.Also note that the fix need to do reference acquisition from a
PSystemSetup.Awake()patch because that's the only way I found to ensure we always run before Kopernicus. Failing to do so will result in Kopernius itself calling the patched methods without the bail-out on Moho active, resulting in incorrect placement of the anomaly marker, and potentially other weird issues.And on a side note, my opinion is that this patch doesn't belong in KSPCF and the whole thing should be handled by Kopernicus as the stock
ConstructBilinearCoords()implementations are only an issue in the context of planetary system modding, and the side effects shouldn't be something players not using Kopernicus should have to deal with.