Godot: get_path() for ImageTexture return null

[bosman697]

.get_path() for ImageTexture return ""

Godot version:

3.2.2

OS/device including version:

Windows 8 GLES2

Issue description:

Expected path to image texture

Steps to reproduce:
var mat_texture = ImageTexture.new()
mat_texture.load('res://Characters/Textures/TEXT_Face.png')
print(mat_texture)
print(mat_texture.get_path())
print(mat_texture.get_name())
print("end")

Outputs:
[ImageTexture:2613]

end

[JohanAR]

I think it's because your ImageTexture is not a resource, so it doesn't have a path. You create a new ImageTexture and load it with a copy of the actual resource, which is probably a StreamTexture.

If you replace the first two lines with this:

var mat_texture = load('res://Characters/Textures/TEXT_Face.png')

Then it will have a path, but it will also be the type that you imported the resource as, so it might not work for what you're trying to do.

[KoBeWi]

Yeah, ImageTexture.load doesn't set the path (you can use take_over_path to assign it manually). This should be easy to fix though.

[rluders]

One side note in this one. Looks like the load method was removed from Godot 4 (master) - also, it is marked as deprecated on 3.2, as you can see here: https://github.com/godotengine/godot/blob/3.2/scene/resources/texture.cpp#L236

[rluders]

I also can confirm the same issue for Image and StreamTexture

[chrishatch52]

New here, would like to tackle this if no one has claimed it yet.

[chrishatch52]

Just to make sure I am not crazy, and this is just an omission and some code needs to just be moved around a bit. I have basically done a paper stack trace, on where this should go, in comparison with StreamTexture2D and it seems the the ImageTexture is missing a bind_methods call to for load that in theory should be running to Texture2D, like it is for StreamTexture2D,

ClassDB::bind_method(D_METHOD("load", "path"), &StreamTexture2D::load);

which makes me wonder if it should be there, should it not be put in Texture2D and not StreamTexture2D since StreamTexture2D and ImageTexture both extend from Texture2D? Or was there some intended design decision where this was done this way that I am not seeing?

This would thereby enable both ImageTexture and any classes that may potentially extend off of it, and StreamTexture2D with any classes potentially off that, or really any other potential extensions off of Texture2D you could cook up, to have the same basic loading logic. I do not think these really should not be all that different considering they are just loading a given file, the kind of file does not seem as relevant at this level in the hierarchy as where it is in storage and if it exists or not?

Potential change would look something like this.

RES ResourceFormatLoaderTexture2D::load(const String &p_path, const String &p_original_path, Error *r_error, bool p_use_sub_threads, float *r_progress, bool p_no_cache) {
    Ref<Texture2D> tex;
    tex.instance();
    Error err = tex->load(p_path);
    if (r_error) {
        *r_error = err;
    }
    if (err != OK) {
        return RES();
    }

    return tex;
}

With the necessary change to the bind_method moved up to Texture2Ds version of _bind_method()

Am I crazy? Maybe, who knows. @KoBeWi @Calinou

[Calinou]

@chrishatch52 I don't know why it's done this way.

[rluders]

@chrishatch52 I guess that you are not crazy. When I was looking into the code to confirm the bug, I had the exact same feeling as you. Maybe if you bring this discussion to the Discord, someone could give us light to this one.

[KoBeWi]

Maybe if you bring this discussion to the Discord, someone could give us light to this one.

godot-devel IRC is a better place for engine discussion.

[chrishatch52]

@KoBeWi what IRC server does this channel live on? nm found it.

[chrishatch52]

Sad as it is to say, I am having a helluva time getting the workflow set up. First time using SCons.

On Windows, I have tried to install SCons, and it does not work. Installed in Python3.8 folder, using pip, Windows refuses to recognize it.

On Linux(Manjaro) have SCons, no issues compiling, but debugging it in Visual Studio Code is not working either, followed the launch.json and task.json file recommendations on the godot doc website, and it just sits there and does nothing, checked the path of the test project with the included lines from the initial bug report. and it just sits there and does nothing. Installed the C/C++ runtime stuff on VSCode, set it up exactly the way it is recommended on the doc site, and just does nothing but timeout.

Going to load my task and launch json files here to see if anyone sees something that is not right.

While I figure out what is going on, if anyone else has a fix for this, and wants to take it over, go right ahead I will not be upset or anything. Just frustrated that I can't get the damn thing up and running.

tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "type": "shell",
            "command": "scons",
            "group": "build",
            "args": [
                "platform=x11",
                "target=debug",
                "-j",
                "4"
            ],
            "problemMatcher": [
                "$msCompile"
            ],
            "presentation": {
                "reveal": "always"
            },
        }
    ]
}

launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/bin/godot.x11.tools.64",
            "args": ["--editor", "--path", "/home/chris/Documents/godot_test/project.godot"],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "build"
        }
    ]

}

[rluders]

@chrishatch52 let me try to help.

• Can you share more information about the error message?
• Are you trying to compile it from master branch? You probably should not use the master check this comment.

Also here my VSCode configuration to compile the 3.2 branch is:

tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "type": "shell",
            "command": "scons",
            "group": "build",
            "args": [
              "platform=x11",
              "target=debug",
              "-j8"
            ],
            "problemMatcher": "$msCompile"
        }
    ]
}

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/bin/godot.x11.tools.64",
            "args": [ "--editor", "--path", "path-to-your-godot-project-folder" ],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
              {
                "description": "Enable pretty-printing for gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": true
              }
            ],
            "preLaunchTask": "build"
        }
    ]
}

[chrishatch52]

No, I am trying from 3.2.2 stable, where the OP mentioned they were having a problem.

There is not a message or anything on the VSCode attempt. It just does nothing. I have the project in a separate folder, I have breakpoints set where the code is being called based on the bug report, and it times out.

I can't imagine it is a problem with my development computer being too old, because it successfully compiles the full engine in just under 30 minutes, I know that is slow, but it isn't ridiculous when you consider I am only trying to modify a few lines.

As far as on my Windows machine, neither PowerShell, or cmd prompt recognize that SCons is installed, and the directory is where it is installed is in my environment variables.

Could it be as simple as editing my version of launch.json with this

"args": [ "--editor", "--path", "path-to-your-godot-project-folder" ],

instead of this

"args": ["--editor", "--path", "/home/chris/Documents/godot_test/project.godot"],

It just doesn't make any sense, I even tried putting a break point on the main.cpp main function, as the docs suggested.

I have the C/C++ compiler on VSCode, I can run the program from the terminal in VSCode, it will compile and finish successfully, but it never actually executes the program in debug, maybe it is because I am not calling the godot editor in the launch.json and passing it just the location of the project?

I am going to try changing it from (gdb) Launch to just Launch. Maybe that is it. Seems to be another difference.

[Calinou]

@chrishatch52 The --path argument should point to a project directory, not a project.godot file. If you want to use a project.godot file, don't pass --path (but keep in mind this will always open the editor instead of running the project).

Since you need to run the project here, use --path with the absolute path to the project directory.

[chrishatch52]

is there potentially something wrong here?

c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**",
            ],
            "defines": [],
            "compilerPath": "/usr/bin/g++",
            "cStandard": "c11",
            "cppStandard": "c++14",
            "intelliSenseMode": "gcc-x64",
            "compileCommands": "/home/chris/godot/compile_commands.json"
        }
    ],
    "version": 4
}

I had to put the absolute path in the compileCommands line because it kept not finding the file, even though it is in the godot folder. I have confirmed that is where my g++ is maybe I shouldn't be using that though and that is what the issue here is, not quite sure. I haven't really used VSCode much, and as I mentioned this is my first attempt with SCons.

Sorry about all the questions, this is just really nagging at me to get working, and google has only partially been helpful.

I've got a breakpoint set on line 344 in main.cpp, it never even enters the debug context.

I'm thinking maybe I need to start fresh as there is something wrong with these files.

[chrishatch52]

Okay, I figured out the Windows SCons, so I am going to run with that as this computer is MUCH more capable than the other, plus, I can actually use Visual Studio which I am significantly more comfortable with. I would still like to fix the Linux version though, so if my c_cpp_properties file looks messed up, please let me know.

[somnathsarkar]

Hi, I'm new here and I don't know if there's been any update on this, but I noticed that in StreamTexture::load the following code is intended to set the path for the resource if none has been set:

if (get_path() == String()) {
    //temporarily set path if no path set for resource, helps find errors
    VisualServer::get_singleton()->texture_set_path(texture, p_path);
}

Which doesn't actually set the path string for the resource, however there is the StreamTexture::set_path function that does:

void StreamTexture::set_path(const String &p_path, bool p_take_over) {

    if (texture.is_valid()) {
        VisualServer::get_singleton()->texture_set_path(texture, p_path);
    }

    Resource::set_path(p_path, p_take_over);
}

Changing the block of code in StreamTexture::load to the following ensures future calls to get_path do not return null:

if (get_path() == String()) {
    //temporarily set path if no path set for resource, helps find errors
    set_path(p_path,true);
}

As mentioned by @rluders in this comment the issue is also present in Image, StreamTexture and ImageTexture. Adding the above block to the load functions of each class fixes the issue.

For now, I am setting p_take_over, mentioned by @KoBeWi in this comment, to true but I'm not sure if that is correct given the check to get_path() already present, or if that get_path() check, present in the original code, is even necessary with the proposed changes.

If the fix looks all right, I can submit a PR.