Cannot use BUILTIN map in more than one PQS mod: "Operation is not valid due to the current state of the object"

[gordonfpanam]

When I try to use the same built-in height map for more than one PQS object on a given world, Kopernicus will throw an exception when attempting to use that map more than once.

Body
{
   PQS
   {
      Mods
      {
         LandControl
         {
            heightMap = BUILTIN/[example_height]
         }
         VertexHeightMap
         {
            map = BUILTIN/[example_height]
         }
      }
   }
   Ocean
   {
      Mods
      {
         RemoveQuadMap
         {
            map = BUILTIN/[example_height]
         }
      }
   }
}

Doing this will cause an exception when Kopernicus encounters the second use of BUILTIN/[example_height] here. A more complete example is available in my Alien Space Programs fork.

I tested this with BUILTIN/kerbin_height_new and with BUILTIN/desertplanet_height at least, and get the same behaviour. This behaviour does not occur with external images. It also doesn't appear to occur with ScaledVersion { Material {} }, where I can use things like BUILTIN/KerbinScaledSpace300 for both texture and mainTex settings, and BUILTIN/KerbinScaledSpace401 for both normals and bumpMap settings.

It also doesn't matter when the second usage occurs; I could put VertexHeightMap before LandControl and get the exception to occur in the LandControl section. I could substitute an external file at any point and avoid the exception, as long as the BUILTIN object is used only once.

I wouldn't be trying such a thing, except this is what kittopia-tech spits out when I save a stock world's configuration for use later. I'm also trying to make a Kerbin clone without the Kerbin template to avoid issue #186. Using the built-in maps would save a lot of memory in-game, and disk space overall, when trying to clone the stock worlds.

I tested this as far back as Kopernicus 1.2.2-1, and every iteration up to 1.2.2-9 on KSP 1.2.2 and 1.3.0-4 on KSP 1.3.

[Sigma88]

@gordonfpanam could you try this version of Kopernicus and let me know if it solves your issue?

KopernicusTESTSolve190.zip

[gordonfpanam]

This is definitely an improvement. I can access BUILTIN/kerbin_height_new and BUILTIN/desertplanet_height more than once now.

Only I appear to have lost access to BUILTIN/kerbin_biome, BUILTIN/duna_biome, BUILTIN/duna_coloraddition and BUILTIN/pyramidcolor now. I have external maps for these so I could finish testing the others, at least.

Was this compiled for KSP 1.2.2 or 1.3? I tested this against 1.3.

This is the exception I'm getting for all four of these:

[LOG 08:13:14]: MapSO grabber: Tried to grab BUILTIN/pyramidcolor but body not found.
[LOG 08:13:14]: MapSO grabber: Tried to grab BUILTIN/pyramidcolor but could not find PQSMod of that type of the given name
[LOG 08:13:14]: Exception Was Recorded: Object reference not set to an instance of an object
  at Kopernicus.Configuration.MapSOParser_RGB`1[MapSO].SetFromString (System.String s) [0x00000] in <filename unknown>:0 

I have a chore to do so I'll check back in a couple of hours, and then do more testing for you. Thanks for making the effort.

[Sigma88]

@gordonfpanam yes I applied the fix only to greyscale textures but that error is triggered by colored ones

give me a second to add colored ones in the fix as well

here you go:
KopernicusTEST2Solve190.zip

both this and the version before are compiled against KSP 1.3.0

[gordonfpanam]

You sure you gave me an updated test version? I'm getting the same behaviour failing to load the colour biome and texture maps. The file sizes for the plugin DLLs don't appear to be different.

[LOG 10:29:27]: Parsing Target biomeMap in (Kopernicus.Configuration.PropertiesLoader) as (Kopernicus.Configuration.MapSOParser_RGB`1[CBAttributeMapSO])
[LOG 10:29:27]: MapSO grabber: Tried to grab BUILTIN/kerbin_biome but body not found.
[LOG 10:29:27]: MapSO grabber: Tried to grab BUILTIN/kerbin_biome but could not find PQSMod of that type of the given name
[LOG 10:29:27]: Exception Was Recorded: Object reference not set to an instance of an object
  at Kopernicus.Configuration.MapSOParser_RGB`1[CBAttributeMapSO].SetFromString (System.String s) [0x00000] in <filename unknown>:0 
  at Kopernicus.Parser.ProcessValue (System.Type targetType, System.String nodeValue) [0x00000] in <filename unknown>:0 

[Sigma88]

-.-

I saved the changes but didn't recompile the plugin

here you go:

KopernicusTEST2Solve190.zip

[gordonfpanam]

I'm sorry, but I get the same end result.

Maybe GitHub's messing with you. Just to be sure, how about a fresh recompile and name the file TEST3? Just to make sure GitHub's not serving me the previous version.

[Sigma88]

forgive me, there was a stupid error in the code

now it's fixed

Kopernicus.SMH.zip

[gordonfpanam]

That's much better. I have working configs, at least for DunaSpaceProgram, that use BUILTIN textures only. I want to test the others (Laythe and Eve) later on, but if they're anything like this they should respond better, too.

This will save a lot of space and bandwidth (and probably runtime RAM) while remaining faithful to the stock worlds, and while avoiding #186.

I'm testing from another PC currently, so please keep this link handy until I get back home.

[05 JUL 2017] All three Alien Space Programs configurations work using stock textures.

I wonder if this texture renaming issue was the cause of seeing nonsense like BUILTIN/BUILTIN/desertplanet_height in configurations dumped from kittopia-tech. That's more of a curiosity anyway; kittopia-tech hasn't been updated for 1.3 yet.

[Gordon-Dry]

I did a quick test of Kopernicus.SMH.zip with
http://forum.kerbalspaceprogram.com/index.php?/topic/162645-wip-13-realisticish-stock-planet-overhaul-development-thread/
and
http://forum.kerbalspaceprogram.com/index.php?/topic/158655-13-kopernicus-sigma-dimensions-realistic-rescale-11/

In both cases in main menu view this is triggered and spammed to the log:
d3d11: failed to create 2D texture shader resource view id=13097 [D3D error was 80070057]

There is another issue with WildBlueTools, not sure if there is a coincidence:
Angel-125/WildBlueTools#10

Log:
https://www.dropbox.com/s/gsi6vfzssso792v/2017-07-05-3%20KSP.log.zip?dl=1

[Sigma88]

@Gordon-Dry this is a development branch, there might be unrelated commits that cause that

does the issue come up with latest Kopernicus release?

[Gordon-Dry]

I went back to RLS 4 and it also happens there - after I was in SPC and then went back to the main menu ...

Update:
When back to main menu and then again into SPC the WildBlueTools issue is triggered.

[Sigma88]

@Gordon-Dry I don't think the error message comes from Kopernicus so untill the devs of whatever mod is throwing those error messages find the reason there's next to nothing we can do about it.

as soon as they find the reason let us know

@gordonfpanam

I wonder if this texture renaming issue was the cause of seeing nonsense like BUILTIN/BUILTIN/desertplanet_height in configurations dumped from kittopia-tech. That's more of a curiosity anyway; kittopia-tech hasn't been updated for 1.3 yet.

yes that was most likely caused by the same renaming issue

[andikisare]

@Gordon-Dry

and
http://forum.kerbalspaceprogram.com/index.php?/topic/158655-13-kopernicus-sigma-dimensions-realistic-rescale-11/

Well, considering you are using a mod that modifies many of the parameters of the stock solar system (Sigma Dimensions RR) and using a mod that replaces the stock solar system (RSPO), that is probably the source of the problem. Uninstall RR and I'm sure that'll solve your problem.

[gordonfpanam]

This particular problem is solved, so you can close it. But I'd like to know if other recent changes were also applied to this test build, as I want to test biome displayName (or displayname because SQUAAAAAD!) functionality

[Sigma88]

yeah I think they are,
if they are not you will need to wait for the next release :)