packed_tex Load Failure Using Godot Server Executable #298
Labels
Comments
|
Looks like there is a different issue with the reproduction project after cloning new it is expecting some information from the .import folder. So has a dependency missing error even though all the files are there. I had the same error with the demo terrain project. Might have to open a separate issue for this. |
|
Having to reproduce this on Linux with a server version including Mono is going to be hard for me, I'll have to try without Mono and on Windows probably, because I think (hope) it has no relation, but can't tell when I'll have time to do such investigation. Also everytime I see a custom loader involved I am suspicious of the feature being randomly broken because it depends on On top of that, the packed texture importer suffers from API shortcomings so any change the engine has made since I wrote them could have caused breakage. It could also be that server builds do something special to textures that I'm not aware of. I suppose it works if you use any other type of export? |
|
I just removed mono from the reproduction project and it has the same problem so easier to try and debug. Yes, if you build/run the project without the server binaries it will work. When opening the project local, I do get those missing dependencies errors and have to re-setup the packed textures and activate the addon (since it disables it). Do I need to commit files in the .import folder to prevent that? If I copy over the .import files it still has the above error of not loading the packed_tex files so not sure if headless building is hitting that error, it seems to create the files in .import though I don't see it creating the .stex files for packed textures. |
|
I think the above is a red-herring though since I took the .pck file after building it with the godot editor and ran it with the server executable and it fails with the loading resource packed_tex. The same pack run with non-server godot runs fine. |
You should not need to commit anything from inside the Perhaps we can simplify the problem further by eliminating all terrain stuff. Packed texture code should be fairly independent (just some bits in What's interesting though is that importers are editor-only code. So there is actually no script code directly involved in loading the texture in an exported build. I wonder what Godot is missing there. |
I'll see if I can put something together tonight.
Try opening that sample project (https://github.com/kruffin/hterrain_server/tree/master/godot_files) and note it complains about missing files that exist. I get a similar error with demo project (https://github.com/Zylann/godot_hterrain_demo). |
|
Last time I saw something like this, it was someone with a failing hard drive, or under Windows a case-insensitive issue. I assume that is yet another cause here. Once again Godot is misreporting errors like a pro, totally saying what's actually going on... will have a look when I have time |
|
Put together that minimal addon and project here: https://github.com/kruffin/packed_tex_test It has the same error with the server binary, so has to be something with how it treats importers... |
|
So, doing --help on the three different Godot binaries resulted in some interesting options for the video driver. My guess at this point is a video driver is needed to create a stream texture so it complains about the .packed_tex resource when it can't create one. Making this up though and have no proof. It really shouldn't be trying to load the packed texture (none of the files it references are included in the pck). Slightly more interesting output with the -v parameter when running. Might have to give up on server or headless binaries and just use the --no-window command on the regular one. Probably brings it's own problems with fake frame buffers, but a different rabbit hole. |
|
Maybe something to do with this nonsense: https://github.com/godotengine/godot/blob/3.4.2-stable/drivers/dummy/texture_loader_dummy.cpp#L38 |
|
Yeah I was just pointed to the same thing. But I still have no idea what I'm supposed to modify in my plugin for the loading to work, because I did not write any kind of custom loader for this. The only guess I can make is that That also means every other addon adding extra texture formats (some of which I listed here) will likely have this problem as well. |
|
Thanks Zylann. Just want to say thank you for putting this height map plugin out there for others to use and play with. I'm going to ask on IRC and see what I can find out. I'll create an issue in the Godot project and report back the URL here. [Edit]: Opened an issue here: godotengine/godot#57067 |
Zylann
added
bug
|
Thought I should take some time to reply back here with some of the workarounds that can be done to get around this custom resource loading issue on a server executable:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When using the Godot server executable to run with a HTerrain node and the Classic4 shader it will fail trying to load the packed_tex files.
resource_format_text.cpp line 412: https://github.com/godotengine/godot/blob/3.4.2-stable/scene/resources/resource_format_text.cpp#L412
resource_loader.cpp line 206: https://github.com/godotengine/godot/blob/3.4.2-stable/core/io/resource_loader.cpp#L206
resource_loader.cpp line 270: https://github.com/godotengine/godot/blob/3.4.2-stable/core/io/resource_loader.cpp#L270
To Reproduce
Steps to reproduce the behavior:
A minimum project to reproduce is here: https://github.com/kruffin/hterrain_server
Basically, add textures to the terrain node and the packed_tex files will not be loaded by the server binary.
Expected behavior
Would be nice to know if this is the expected outcome or how to identify why it's failing to load. I did take a look a the packed texture importer (https://github.com/Zylann/godot_heightmap_plugin/blob/1.5.2/addons/zylann.hterrain/tools/packed_textures/packed_texture_importer.gd) but am wondering if custom importers are broken in Godot Server. Line 270 of resource_loader.cpp makes me think it doesn't have the custom importer, but am not sure.
Screenshots
N/A
Environment
The text was updated successfully, but these errors were encountered: