Patch testing script appears to not account for versions

[DoctorAnsem]

I accidentally loaded a map with the most recent SP version, that was still testing for 1.0.0 but it loaded the SP map anyway. Since it was built with the older version of the tools the result was wacky, for lack of a better term. It didn't seem to load the effects config, but it did load at least some if not all the components of the map itself.

[PrismaticFlower]

SP (tries) to follow Semantic Versioning, which put more succinctly than that page means the version numbers are of the form "MAJOR.MINOR.PATCH". And have the following key properties.

• Different "MAJOR" versions represent breaking changes and are always incompatible with each other.
• "MINOR" versions represent feature updates. A higher "MINOR" version is always compatible with lower "MINOR" versions. (But the inverse it not true.)
• "PATCH" versions represent bug fixes or small things that do not affect compatibility in anyway.

So v1.0 maps loading on v1.1 is the expected and supported behavior.

Now this is still a bug (and a bad one at that imo) obivously because the old v1.0 map should have loaded successfully without any problems. (The storage format for munged materials did change from v1.0 to v1.1 but v1.1 still understands how to load v1.0 materials, or at least it should.) The format effects files are stored in was unchanged, although additional files were added to support color grading regions but they shouldn't affect the global effects config.

All that said just to make sure, this map was definitely munged using v1.0.x's tools not v1.1.x-preview.y's tools? Assuming that it was however. I do have a map with v1.0 files in it that I test loading in the new versions still to make sure everything still works, however the map is my old modded Mygeeto reference map so it only has PBR materials in it. Should I be looking at normal_ext materials instead do you think?

Also I have no clue why the effects config would fail to load, the only thing that changed from v1.0 to v1.1 about it was the ASSAO integration, I'm pretty sure if it's missing from the config it should safely default to being off, but maybe I need to take a closer look at everything and make sure that is what is happening.

[DoctorAnsem]

this map was definitely munged using v1.0.x's tools not v1.1.x-preview.y's tools?

Actually, you got me there - I didn't think about that at all. Yeah it was munged with the latest preview tools, but there was actually something more to this than I initially realized. The effects config was loading up fine. It's just that for some very odd reason, an older build had not saved all the effects in it (why that might have happened is beyond me) and it threw me way off because the effects looked like nothing I would have set them to. Fortunately that isn't an issue anymore.

There is one curious thing though, which is the terrain. As it was munged with the latest preview tools, it should have worked, shouldn't it? It did with the preview builds - now with the new version it turned up blood red.

But yeah, if the intended behaviour was to load the SP map then I guess that's what happened and there's not much of a bug here at all, except the terrain and they all need to be re-munged anyway so it's nothing really.

[PrismaticFlower]

The preview versions of v1.1 had been storing the terrain's normals in a texture it sampled per pixel. I didn't feel the potential for a slight visual improvement was worth the memory and performance cost so I switched the terrain to store it's normals in it's geometry. (As stock does.) I suspect that is what caused the problem, the order of texture bindings to the shader also changed because of this.

Looking at the shader now any v1.1 preview terrain would have it's height maps bound to the diffuse maps slot in the full release. And height map's only have the red channel so that is probably where the red coloring of the terrain came from.