The line below works on project play but not when project is compiled, how can I solve this please?

if dir.open(path) == OK:

where path is : "res://world"

well... I got this function!!

var path = "res://world/"
var levels = []
var dir = Directory.new()

#var files = []
dir.open(path)
dir.list_dir_begin()
while true:
	var file_name = dir.get_next()
	if file_name == "":
		break
	elif not file_name.begins_with("."):
		levels.append(file_name)
		get_node("PanelContainer").get_node("LabelOutput").set_text(file_name)

In the dev I got this result: Dir1 Dir2 properly!

in the compiled EXE [project I got this: project.bynary

WHY??

ok I see that the problem is that I cannot read into that dir... only that one and it is the same as many others, why?

The res:// project folder and all its assets are packed into the .pck file when you export, which is probably why it is not working. Based on this Q&A answer, it may be that the .pck file does not have directories and that is why its not working.

@TwistedTwigleg said: The res:// project folder and all its assets are packed into the .pck file when you export, which is probably why it is not working. Based on this Q&A answer, it may be that the .pck file does not have directories and that is why its not working.

no I didn't export as a PCK but EXE file and also code above can read some dirs , instead changing to other dirs it is not able to read them! I looks like a bug

basically:

var path = "res://weapons/"

built project EXE can read this

var path = "res://world/"

built project EXE cannot read this! Why?

one more thing... in the compiled project , just listing the directories, only some of them appears into the itemlist! Other directories don't exist for the program... it happens only in the built project... a BUG??

It might be a bug. You could always try opening an issue on GitHub and see what the developers say there. :+1:

@TwistedTwigleg said: It might be a bug. You could always try opening an issue on GitHub and see what the developers say there. :+1:

no please?? No seriously... how long does this may take? Do you know we are a company and we are developing few games some of them using Godot?

So that mean to wait until the developers release another version and we are f... up for now! Testers are waiting for our demos and we are planning campaigns for our games... oh fudge!

(TwistedTwigleg edit: Censored swear word)

Open an issue, if it is identified as a real issue but low priority you can always ask on the developer IRC if there's someone interested in taking the bug fixing up as a bounty. I.E. if someone is willing to fix it for $. Where there is a will there is a way.

But even if this is a bug and it is identified as such, someone might be able to recommend a workaround. It's always worth reporting it if you think you've found a bug.

@Megalomaniak said: Open an issue, if it is identified as a real issue but low priority you can always ask on the developer IRC if there's someone interested in taking the bug fixing up as a bounty. I.E. if someone is willing to fix it for $. Where there is a will there is a way.

But even if this is a bug and it is identified as such, someone might be able to recommend a workaround. It's always worth reporting it if you think you've found a bug.

thanks I did it Magalomaniac :) wow... However, because the problem is about reading subdirs in a dir from the compiled project, and because just giving a string variable with a certain path the project is running, I think to develop a small function that saves the dir list in a text file or a dictionary and then give filling an array after reading that file.

I know it is not so elegant but it should work properly just bypassing the problem

8 months later

I know I'm late to the party, but I had the same issue. I was trying to import a .prn file that worked fine within godot but not in the export process. Was resolved by putting in ".prn" in the Filters to Export Non-Resource Files in the Resource tab option when exporting. Hope this helps somebody.

a year later