The engine works when you choose the correct “Engine” directory. When I was switching my project’s Unreal Engine version, I kept trying to say that the engine was at “**UE_4.19/Engine/” **instead ofthe correct location at “UE_4.19/Engine/Windows/Engine/”. That was just a dumb mistake on my part, but I’m still getting the same errors with the latest Gumroad release and this version of the engine. I’m seeing a good amount of errors that seem to have to do with “TSharedPtr”. It seems like a linking issue, but I’m not sure what I’m missing. I was hoping that the 4.19.1 UE4 engine would fix everything.
My project works just fine with the “Pro-1.0/4.19-TextureArrays” that I previously had downloaded from Gumroad. The only change I made was the switch over to the UE_4.19.1_TextureArrays engine and the “Pro-1.1/4.19-TextureArrays” version of the plugin. I attached a file with the errors that I’m seeing after the described changes were made. These errors occur with both recent releases of your TextureArrays UE4. Just with that information alone, it seems like the problem is with the Gumroad release that I downloaded.
I also have something else that I was having issues with and have already solved. I was playing around with the custom C++ world generators and my generator instance’s GetValuesAndMaterialsAndVoxelTypes() was receiving a null “Materials” array (only the “Values” array was not null). I followed the docs and configured my VoxelWorld’s Rendering->Voxel Material to use the provided “M_VoxelMaterial_Colors” that came with your plugin. I would have expected that to work, but only the “M_VoxelMaterial_Textures” seems to work. I’m pretty sure this is because I’m using the TextureArrays build of your plugin. It would help other people if you mentioned something about that in your documentation for the Voxel World Generator or Texture Arrays. It would be even nicer if you were able to catch this sort of misconfiguration and throw an error. I usually force users of my software to use it in the correct way and that is easily enforced at configuration time. However, that sort of error check probably should only occur in the test/build environment (the C++ preprocessor can help with that), because it might cause unwanted slowdowns for consumers.