Godot version:
3.0.6
OS/device including version:
Windows 10
Issue description:
Image.Load won't accepted res:// path's in exported projects, but works fine in editor. I was told image.load() wasn't meant for res:// paths (which doesn't make logical sense), so I'm assuming this method is broken or doesn't explicitly state its correct usage in the method name.
Steps to reproduce:
var image = new Image();
image.Load($"res://pathtoasset");
var imageTexture = new ImageTexture();
imageTexture.CreateFromImage(image, (int) Texture.FlagsEnum.Mipmaps);
Minimal reproduction project:
Will create one after ludum dare 42
@exts shouldn't you be using an absolute path, not a resource path?
@FeralBytes yes, the above is a placeholder. the original code was something along the lines with:
var img = new Image();
img.Load($"{assetPath}/{food.Value}");
where $"{assetPath}/{food.Value}" looked something like: res://Assets/Art/Food/Meats/Chicken.png
Workaround was just calling it like so:
var imageTexture = (Texture) GD.Load($"{assetPath}/{food.Value}");
imageTexture.Flags = (int) Texture.FlagsEnum.Mipmaps;
which worked fine, i still don't see why image.load() doesn't work though with res:// paths,
@exts just to make sure we are on the same page. I am saying the path should not be res://Assets/Art/Food/Meats/Chicken.png but rather it should be an absolute path like /home/user/.godot/myGame/Downloaded/Assets/Art/Food/meats/Chicken.png. The path could be to any wheres but since you are using things outside of the executable then your path should not be res:// If the path is interal to the executable then the path should work fine, but you will have to handle 2 conditions when running in the editor use the standard res://Assets/Art/Food/Meats/Chicken.png but once exported to executable if you path is dynamically generated realize that the code will be only seeing res://Assets/Art/Food/Meats/Chicken.png.import.
that makes absolutely no sense lol why would you use absolute paths with an api library that targets multiple os's?
If I pass "res://" to any load method it should grab my local resources from the project root. Else the method needs to be renamed to something else
Your part about that making no sense is you mis understanding what I meant. as I state if you read the entire post, if the path is a resource within your project then res:// is fine but outside of your project you will need to use absolute paths. It seemed to me from what you wrote that you were actually trying to load an external file.
I think you need to read Data Paths.
Yes exactly it will grab your local resources from the project root. So lets do this as a test you try and load an asset using the path you provided res://Assets/Art/Food/Meats/Chicken.png, not dynamic and tell me if it works.
For reference the method is Image.load()
Your part about that making no sense is you mis understanding what I meant. as I state if you read the entire post, if the path is a resource within your project then res:// is fine but outside of your project you will need to use absolute paths. It seemed to me from what you wrote that you were actually trying to load an external file.
Not the case. I was only loading resources from within the project assets that were exported which have .stex files. Using Image.Load() does not load those assets, only can I load those assets using GD.Load()
Here you can see the code here https://github.com/exts/godotsharp-shortserve/blob/master/App/Food/FoodLoader.cs#L81 this is the updated code.
The original method was:
private static void CreateTextures(string type, Godot.Dictionary<string, string> foods, ICollection<FoodItem> foodItemTexturess, string assetPath)
{
foreach(var food in foods)
{
var image = new Image();
image.Load($"{assetPath}/{food.Value}");
var imageTexture = new ImageTexture();
imageTexture.CreateFromImage(image, (int) Texture.FlagsEnum.Mipmaps);
foodItemTexturess.Add(new FoodItem(food.Key, type, imageTexture));
}
}
It seemed to me from what you wrote that you were actually trying to load an external file.
You can try compiling that code and tell me why it shouldn't work with the original method because I'm not looking for an external file.
To clarify a bit, Image.Load() seems to expect a path to a physical file: it works when the file is present while you're running the project from the editor, but once you're into exported virtual filesystem .pck territory, Image.Load doesn't get redirected to the imported .stex files (the .png doesn't exist in the .pck at that point).
In contrast to that, GD.Load() explicitly tries to load a Resource and as such probably respects the virtual filesystem (ie it loads the .stex when you tell it to load the corresponding .png).
Absolute or relative paths are irrelevant to the problem.
Use GD.Load and import the file as an image. Should probably unbind that
and other functions, as it confuses users.
On Mon, Aug 13, 2018, 18:32 PetePete1984 notifications@github.com wrote:
To clarify a bit, Image.Load() seems to expect a path to a physical file:
it works when the file is present while you're running the project from the
editor, but once you're into exported virtual filesystem .pck territory,
Image.Load doesn't get redirected to the imported .stex files (the .png
doesn't exist in the .pck at that point).
In contrast to that, GD.Load() explicitly tries to load a Resource and as
such probably respects the virtual filesystem (ie it loads the .stex when
you tell it to load the corresponding .png).
Absolute or relative paths are irrelevant to the problem.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/20972#issuecomment-412672151,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2zzlEcLrqfJ6cks1rCyNSdR-4Nxrks5uQfB-gaJpZM4V6j6p
.
@reduz yeah that was the solution to fix my problem. Almost didn't make the ldjam when I ran into the issue 😄. Definitely confused me when I found out.
Update: Seems to also be the case for ImageTexture.load()
Yes, those functions should be removed, they are confusing and error prone
On Mon, Aug 13, 2018, 21:11 PetePete1984 notifications@github.com wrote:
Update: Seems to also be the case for ImageTexture.load()
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/20972#issuecomment-412708370,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z25Ic5sG0siJCuLDWseDS91l1h8Zoks5uQhWWgaJpZM4V6j6p
.
Please don't remove Image.load, or you will piss off everyone loading non-resource images dynamically in their games and tools :/
or better yet just have proper support for res:// and user:// in exported games because currently it doesn't seem to work @Zylann
@exts does this work? Because it's the same deal^^
var f = File.new()
f.open("res://something.x", File.READ)
If Image.load is a confusion, renaming it Image.load_from_file would make more sense. And yeah, it should support the same kind of paths File accepts.
@Zylann yes that definitely works https://github.com/exts/godotsharp-shooter/blob/master/Application/Core/Formations.cs#L90 and to not cause confusion the res path is on this line https://github.com/exts/godotsharp-shooter/blob/master/Application/Core/Formations.cs#L28
I've done it in a tutorial game a while back. Can test it via https://g4mr.itch.io/godotsharp-shooter
Please don't remove Image.load, or you will piss off everyone loading non-resource images dynamically in their games and tools :/
@Zylann yep, I really depend on this as it's one of the core features currently used in my game.
As I understand, loading a texture by path will return imported one (StreamTexture). What if it can be made that if the loader doesn't find imported texture by path, it should fallback to loading other compatible resource types? In this case it would be Image.
var img = load("my_image.png") # returns `StreamTexture` if found, else it's an `Image`
Can anyone still reproduce this bug in Godot 3.2.1 or any later release (e.g. 3.2.2-rc1)?
If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.
@KoBeWi let me try reproducing it today.
Looks like this is intended then.
@KoBeWi it seems like this is only a limitation when you try to image.load in exported games, which doesn't work, and should likely just be documented there (there's a warning for it in 3.2+).
The "opposite" use case is here though: #39396 (the warning should be moved to documentation IMO).
Tagging as documentation then.
Looks like this is intended then.
I wouldn't say this is intended, but that's just a limitation that you have to be aware of. You could optionally try to include all image files while exporting, I would be actually interested if this works:

But instead, if you need to load an image specifically, you just need to reimport the texture as an Image resource:

If you want to distribute some images along with exported project you can also try globalizing the res:// path before doing so, so that the engine won't look into the virtual filesystem, but instead search for OS filesystem.
static func image_load(filepath):
var image = Image.new()
image.load(ProjectSettings.globalize_path(filepath))
return image
Most helpful comment
Please don't remove Image.load, or you will piss off everyone loading non-resource images dynamically in their games and tools :/