ProjectSettings.load_resource_pack replaces res:// completely

[mrimvo]

Godot version:
3.3 stable

OS/device including version:
Ubuntu 18.04

Issue description:
I tried to load a resource pack:

ProjectSettings.load_resource_pack("res://resource_pack.pck")

as described in the documentation

After loading the resource pack, it is not possible to access the resources of the original game. It looks like the loaded resource pack replaces res:// completely.

Steps to reproduce:

1. import my minimal reproduction project into Godot 3.3
2. hit F5 to run it
3. the console will show the contents of res://

Expected:

• Main.tscn should still be listed as part of res:// even after using load_resource_pack

Observed:

• Main.tscn is missing in res://

Minimal reproduction project:

load_resource_pack.zip

This is the Main.gd script of the minimal project:

func _ready():
	# zip or pck doesn't matter, produces the same result
	ProjectSettings.load_resource_pack("res://resource_pack.pck")
	
	# check res:// content
	var dir = Directory.new()
	dir.open("res://")
	dir.list_dir_begin(true, true)
	while true:
		var file = dir.get_next()
		if not file:
			break
		print(file)

[Calinou]

For reference, here are the contents of resource_pack.pck included in the MRP (listed with GodotPckTool):

❯ godotpcktool resource_pack.pck
Contents of 'resource_pack.pck':
res://.import/icon.png-487276ed1e3a0c39cad0279d744ee560.stex size: 3413
res://PackResource.tscn size: 56
res://default_env.tres size: 163
res://icon.png size: 3305
res://icon.png.import size: 640
res://project.binary size: 260
end of contents.

Contents of resource_pack.zip:

❯ unzip -l resource_pack.zip
Archive:  resource_pack.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
       56  00-00-1980 00:00   PackResource.tscn
      163  00-00-1980 00:00   default_env.tres
     3413  00-00-1980 00:00   .import/icon.png-487276ed1e3a0c39cad0279d744ee560.stex
      640  00-00-1980 00:00   icon.png.import
     3305  00-00-1980 00:00   icon.png
      260  00-00-1980 00:00   project.binary
---------                     -------
     7837                     6 files

[kleonc]

Related issue: #19815. According to that it's an editor-only problem which isn't really a bug. In such a case in-editor behavior needs to be documented.

[mrimvo]

I' working in the software field for a while now and not too long ago I read about an interesting view, that the classification "bug or not" more often than not is irrelevant. I felt this was quite a statement, having in mind all the office discussions over something being a bug or not.

But they continued to explain that it doesn't matter if you call it "bug" or "feature" or "change request". Fact is: there is a problem. You can estimate it's impact, required effort to solve it, etc, but classifying it as a bug or not, doesn't help with the actual problem at hand. In my opinion, the classification if something is a "bug" or not is subjective and even irrelevant. It is a problem that's for sure. The question is: is there a way to solve it, is it hard to do it, what impact does it have, how many users are affected, is there a workaround, does it need documentation, etc.

Me filing an issue does not mean I want anyone to fix it immediately, there is no reason to feel pushed (this is the only reason I can think of someone defends an issue "not really being a bug"). But I do want this problem to be documented in case someone actually got the interest and skills to fix it. Might be even my future self, who knows?

Sorry, especially to @kleonc for the tiny rant here. :) It just happens to most of the issues I keep track on here in the godotengine repository...

Back to the actual topic:

It is an editor-only problem. It's very counter intuitive for the user that the game, run from the editor, behaves differently from an exported game.

There is an obvious workaround though: You need to extract the to-be-loaded .pck or .zip into your project. However, it makes it unnecessary hard to develop and debug something like a mod-loader for a moddable game. Same problem for developers that want to provide DLCs or incremental updates and need to develop respective updating algorithms.

[kleonc]

To make things clear (yeah, maybe I wasn't clear enough in my previous comment): all I meant was that according to the linked issue/discussion "it's not really a bug" because it's caused by design. So it's not a bug in "doesn't work as designed" sense but it's rather a bug in "by design" sense. So sure, you can still call it a bug as it's indeed a kinda vague term but I think I just usually use it in "doesn't work as designed" sense, that's all. And by any means I didn't say "document it and close this issue ASAP!", just said that current behavior needs to be documented. No problem with the rant, didn't get hit hard. :) Ending this offtopic.

[mrimvo]

I understand, thank you for clarification. I think documenting about this issue would help a lot already, because in my case it lead to strange errors and it wasn't obvious at all what was going on.

Another thing which I think would help even more, if the engine would print an error in case you try to use ProjectSettings.load_resource_pack while the game was started from the editor, and clearly state that this replaces res:// and this is a different behavior from an exported game. This would be even better because

• not everyone reads the docs very carefully, or forget about these limitations later on, or work on somebody else's code and just are not aware of this issue
• the error would happen exactly where it was caused, and not in various other places down the road where it is hard to guess what went wrong

[tracefree]

I adapted the MRP above to Godot 4.x:
MRPResourcePack.zip

[JHDev2006]

can i suggest that if this doesnt get addressed in time for 4.4, we could have a note in the docs saying that this function is broken, and that a fix for it will come soon? just so that others dont potentially get screwed over by thinking this function works