So i was working on a Node inherited class trying to change it to fit a new requirement
I ended up not changing anything inside the class and coming up with a better solution

but immediately after doing so other scenes that used the class started throwing errors reading
_parse_ext_resource: <scene.tscn:line of ExtResouce() call> - Parse Error: [ext_resource] referenced non-existent resource at: <script.gd for the class in question>
<C++ Source> scene/resources/resource_format_text.cpp:163 @ _parse_ext_resource()

the thing is. the reference for the ext resource of the script is identical to the one in the scene i added the class into just at that time
and that scene works flawlessly

after trying to understand what was happening i tried to just simply copy the script in the file system and change its name by adding one character. then removing the class_name assignment on the old script and moving it to the new one whilst also modifying the reference inside the .tscn files to the new system path. again by simply adding the character to the resource path

and viola it worked. but i don't want to have to change the script name in the file system and change references
especially if this is going to randomly happen again

just to clarify i didn't move any files across the file system
the path in the working scene was identical to the path in the broken scenes
the class script had not been modified and did not have any errors

can someone please explain what is happening or find a way to fix godot's file path reference for those scenes
thanks in advance

  • godot 4.2.2 -
  • xyz and LunarShadow replied to this.
  • LunarShadow for anyone else coming across this the solution in my case was not to solve it.
    i found a piece of code that for some reason triggers the parsing error when enabled and just used a different method to do the same thing
    (the script parses with the misbehaving code on other scenes and on the bugged scenes when copied to a under a different path)

    xyz xyz unfortunately not.
    I don't know how I would go about reproducing it aswell. since like I said I didn't even end up changing the script for the class
    or the bugged scenes for that matter

    i was able to copy the projects files but its so dense that its nearly impossible to remove anything without the bug disappearing
    which is a new observation I made. commenting out all the script's content stops the error messages

    which prompted me to start trial and error my way through the script

    commenting out these lines

    SaveManager.On_Loading_Done.connect(on_post_load.bind(data))
    
    func on_post_load(_data : Dictionary) -> void:
    	SaveManager.On_Loading_Done.disconnect(on_post_load)

    which are part of this code block

    func on_save() -> Dictionary:
    	var data : Dictionary = {}
    	
    	#data["nav_col_layers"] = nav_col_layers
    	
    	return data
    
    func on_load(data : Dictionary) -> void:
    	if data.is_empty():
    		return
    	
    	#nav_col_layers.assign(data.get("nav_col_layers", []))
    	
    	SaveManager.On_Loading_Done.connect(on_post_load.bind(data))
    
    func on_post_load(_data : Dictionary) -> void:
    	SaveManager.On_Loading_Done.disconnect(on_post_load)
    	#update_col_layers(true)

    (normally non of the code is commented)

    the errors disappear but i don't understand why.
    the exact same script is copied under a different name and it works completely fine
    (I.E. no parsing error that would cause the class name to not be available)

    for context SaveManager is a autoload script and the code in question does not run when the errors appear
    (checked with a print statement before)

    I can't see any way to make an MRP without removing bits of code at a time.
    yeah, no. I really tried multiple times. I can't see a way to make an MRP. hope the extra info helps. and thanks for responding

    • xyz replied to this.

      xyz that's honestly fair. i appreciate you trying to help
      i thought maybe someone would know what's causing it.
      thanks regardless

      • xyz replied to this.

        LunarShadow It's likely caused by an inappropriate setup in your project. If you're alluding it's an engine bug or problematic behavior that could be improved, nothing much can be done regarding it unless it's unambiguously reproducible.

          xyz sure, don't see how that would make sense but I have my workaround regardless. thanks

          LunarShadow for anyone else coming across this the solution in my case was not to solve it.
          i found a piece of code that for some reason triggers the parsing error when enabled and just used a different method to do the same thing
          (the script parses with the misbehaving code on other scenes and on the bugged scenes when copied to a under a different path)

          • xyz replied to this.

            LunarShadow Maybe it's just me but from your descriptions it's utterly unclear what was the actual problem here as well as what was the "workaround".

              xyz I'll try to explain it more clearly.
              the problem is pretty much the error. which if i read it correctly states that the given scenes cannot find the resource (which is a gdscript)
              in the path defined by the scene.tscn file. and that it is unable to parse the scene

              that is to say. my problem is not being able to use those scenes since they complain about the resource

              but it confuses me because
              A) the same script whilst showing the bug on the 3 culprit scenes is also placed inside a fourth scene with a nearly identical setup, the only difference i could pin point is that the working scene had the script in question added after i tried to modify the script
              B) simply copying the script with a change to the path and manually changing the scene reference resolves the parse error
              C) the script has no errors which would results in the class name not being available in the project
              D) also since there are no errors in the script it doesn't make sense why the section of code i outlined in my response is failing
              given that the same piece of code works as intended in another script
              E) the scenes started throwing the parse error after trying to modify the script, but when i saved and launched the project no actual changes to the script had taken place.

              the work around is to disable the code i outlined and using a different approach to do the same thing.
              which in my case was to call the function in a deffered call instead of waiting for the signal of the autoload script
              and for extra clarification that same signal is used in the same manner across the entire project

              • xyz replied to this.

                LunarShadow Hard to conclude anything without seeing what's inside the offending tscn file as well as full contents of the scripts involved.

                  xyz yeah, but i wouldn't offload my entire project onto someone to sift through. which is why i tried to break it down but that didn't work out
                  it did help to try and break it down since i found a workaround. that works for me. i'll just cross my fingers it doesn't happen again

                  • xyz replied to this.

                    xyz that's like the first thing i always do with weird bugs
                    like CS 101 turn it off and on again lol.
                    i even tried to remove the scripts from the 3 scenes
                    reload the entire editor
                    run the project
                    make the changes back
                    reload again
                    and when i run the issue persists

                    • xyz replied to this.

                      xyz i wish i could. i want to know a proper solution to this so i can use it next time it happens

                      • xyz replied to this.

                        LunarShadow Btw you can't just call things "workarounds" if you don't know what exactly you're working around. Hm, this sounds like something one may find written inside a fortune cookie.