Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOS .app not using project folder #11450

Closed
cbscribe opened this issue Sep 20, 2017 · 18 comments
Closed

MacOS .app not using project folder #11450

cbscribe opened this issue Sep 20, 2017 · 18 comments

Comments

@cbscribe
Copy link
Contributor

Operating system or device, Godot version, GPU Model and driver (if graphics related):
MacOS, 3.0master

Issue description:
res:// file location does not use project folder, but rather reads/saves in <appdir>/Contents/Resources for all projects.

Steps to reproduce:
Build per directions at http://docs.godotengine.org/en/latest/development/compiling/compiling_for_osx.html

Resulting binary exhibits no problems.

Create MacOS .app file per directions using either osx_template.app/ or osx_tools.app/. Open new project and save a scene. Saved file will be found in <appdir>/Contents/Resources.

The following messages are logged in the console:

2017-09-20 14:33:24.758 Godot[55475:14347368] There was an error parsing the Info.plist for the bundle at URL <0x7ffd2540eef0>: NSCocoaErrorDomain - 3840
Couldn't open /Users/chris/godot/bin/Godot3.app/Contents/MacOS/Godot.pck
Couldn't open Godot.pck

Going back through @Calinou 's daily builds, I find the issue started after the 2017-09-07 build.

@akien-mga
Copy link
Member

CC @BastiaanOlij

@Calinou
Copy link
Member

Calinou commented Sep 20, 2017

I can reproduce this on macOS, this makes it impossible to run the demos as well (since their scene files can't be found).

@BastiaanOlij
Copy link
Contributor

BastiaanOlij commented Sep 21, 2017

I'll have a look when I'm home, I had this all working beautifully when I checked in all the changes :(
Mind you, I did use my own template so possibly the issue lies with the template that is created from source, it is very strange it has issues parsing the Info.plist file as well...

Looking at your log it is designed to check the folder location where the executable is first (i.e. contents/MacOS/godot.pck), that was already the order and I've left it as is. But on the second try it does is opening godot.pck in the working folder.

This is where the old code that I have left untouched is a little flakey.
https://github.com/godotengine/godot/blob/master/platform/osx/godot_main_osx.mm#L47

Contains the code that will change the working directory to the resource folder but it ONLY does this if it detects that you are running the app bundle which it will ONLY do if you start the app through finder or when entering the full path to the executable in a terminal.

If you've compiled a debug version of the executable you'll see in the code slightly below I've added that it outputs what the current working directory is to help debug these issues. It would be worth trying this out to see if it makes the folder correct.

Note also this remark here:
https://github.com/godotengine/godot/blob/master/core/project_settings.cpp#L360
when get_resource_dir has been called. I think it may make sense enhancing the code above that attempts to open the pck file to also check the folder returned here for a pck file.

I've already implemented get_resource_dir to return the resource folder if applicable. Seems a more stable solution then relying on the working folder:
https://github.com/godotengine/godot/blob/master/platform/osx/os_osx.mm#L1736

@BastiaanOlij
Copy link
Contributor

Looks like the Info.plist file in the template folder is fine, could be a rights issue on this file though. The working folder is changed to the resource folder only if this file can be successfully opened. Seeing the error that it can't parse this file, possible the issue lies there?

@akien-mga akien-mga added this to the 3.0 milestone Sep 21, 2017
@BastiaanOlij
Copy link
Contributor

Just tried this and still seems to work fine on my end, need more info to reproduce..

@cbscribe
Copy link
Contributor Author

Did you try this with one of the builds from https://bintray.com/calinou/godot/editor/ ?

MacOS version? I'm running 10.12.6

@BastiaanOlij
Copy link
Contributor

No, all testing is done with fresh builds from master so it could be a deployment issue on how things are build. Thats why I suggested using the debug build instead of the release build so you can see what the working folder is in the logs.

I suspect this is either an issue in the rights on the info.plist file or an issue in writing out this file in the exporter.

Could you upload a DMG created by the export into this issue? (see if you can drop the file into a post). I can have a closer look if the data exported matches what it should be.

@BastiaanOlij
Copy link
Contributor

@marcelofg55 , could you have a though about this as well? Do you recognise the issue @cbscribe is having?

Also I'd like peoples opinion on my suggestion to add get_resource_dir to the places Godot checks to open pck files? I would even go as far as to removing the working directory code change.

@cbscribe
Copy link
Contributor Author

It doesn't seem to want to let me drop the DMG - could be my internet connection, it keeps timing out. But here is a DMG that doesn't work:
https://bintray.com/calinou/godot/download_file?file_path=Godot-macOS-x86_64-2017-09-13.b9fddc5.dmg

I will try building a debug build this evening.

@BastiaanOlij
Copy link
Contributor

This bundle is a tools bundle, it has the plist file (still the godot 2.x one) from:
https://github.com/godotengine/godot/tree/master/misc/dist/osx_tools.app/Contents

That doesn't have the place holders required to export a runtime. You need to base the export on this one:
https://github.com/godotengine/godot/tree/master/misc/dist/osx_template.app/Contents

The app bundle also doesn't have a pck file so it looks like that DMG is simply designed to be a the tools build.

@cbscribe
Copy link
Contributor Author

Yeah, I tried using both osx_tools.app and osx_template.app with the same results. Here's the console output when launching the debug build from the .app file:

Couldn't open /Users/chris/tmp/godot/bin/Godot.app/Contents/MacOS/Godot.pck
Couldn't open Godot.pck
Successfully loaded /Users/chris/tmp/godot/bin/Godot.app/Contents/Resources/project.godot or project.binary
OpenGL ES 3.0 Renderer: Intel(R) Iris(TM) Graphics 6100
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ERROR: bind_methodfi: Class AudioStreamPlayer2D already has a method get_position
   At: core/class_db.cpp:1182.
SVG_GENERATION TIME: 0.295472

After choosing a project from the Project Manager (project opens but no project files are found, because it's looking in Resources):

OPENING: /Users/chris/Documents/godot3_projects/temp (::Users::chris::Documents::godot3_projects::temp)
arguments
0: /Users/chris/tmp/godot/bin/Godot.app/Contents/MacOS/Godot
1: --path
2: /Users/chris/Documents/godot3_projects/temp
3: --editor
Current path: /Users/chris/tmp/godot/bin/Godot.app/Contents/Resources
Couldn't open /Users/chris/tmp/godot/bin/Godot.app/Contents/MacOS/Godot.pck
Couldn't open Godot.pck
Successfully loaded /Users/chris/tmp/godot/bin/Godot.app/Contents/Resources/project.godot or project.binary
OpenGL ES 3.0 Renderer: Intel(R) Iris(TM) Graphics 6100
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144

By comparison, here's the output when just running the binary (no .app) and opening the same project. Project files are all visible:

tomservo:bin chris$ ./godot.osx.tools.64
arguments
0: ./godot.osx.tools.64
Current path: /Users/chris/tmp/godot/bin
Couldn't open /Users/chris/tmp/godot/bin/godot.osx.tools.pck
Couldn't open godot.osx.tools.pck
Couldn't load/find /Users/chris/tmp/godot/bin/project.godot or project.binary
Couldn't load/find /Users/chris/tmp/godot/project.godot or project.binary
Couldn't load/find /Users/chris/tmp/project.godot or project.binary
Couldn't load/find /Users/chris/project.godot or project.binary
Couldn't load/find /Users/project.godot or project.binary
Couldn't load/find //project.godot or project.binary
OpenGL ES 3.0 Renderer: Intel(R) Iris(TM) Graphics 6100
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ERROR: bind_methodfi: Class AudioStreamPlayer2D already has a method get_position
   At: core/class_db.cpp:1182.
WARNING: not found: gdnative/singletons
SVG_GENERATION TIME: 0.299165
OPENING: /Users/chris/Documents/godot3_projects/temp (::Users::chris::Documents::godot3_projects::temp)
arguments
0: /Users/chris/tmp/godot/bin/godot.osx.tools.64
1: --path
2: /Users/chris/Documents/godot3_projects/temp
3: --editor
Current path: /Users/chris/tmp/godot/bin
Couldn't open /Users/chris/tmp/godot/bin/godot.osx.tools.pck
Couldn't open godot.osx.tools.pck
OpenGL ES 3.0 Renderer: Intel(R) Iris(TM) Graphics 6100
GLES3: max ubo light: 409
GLES3: max ubo reflections: 455, ubo size: 144
ERROR: bind_methodfi: Class AudioStreamPlayer2D already has a method get_position
   At: core/class_db.cpp:1182.
SVG_GENERATION TIME: 0.280695
ERROR: connect: Signal 'id_pressed' is already connected to given method '_popup_callback' in that object.
   At: core/object.cpp:1338.
ERROR: connect: Signal 'id_pressed' is already connected to given method '_popup_callback' in that object.
   At: core/object.cpp:1338.
try to see fs update2
ERROR: _render_target_allocate: Condition ' status != 0x8CD5 ' is true.
   At: drivers/gles3/rasterizer_storage_gles3.cpp:6261.

@BastiaanOlij
Copy link
Contributor

Hmm, I'm starting to wonder if we're looking at different scenarios here. You are talking about exporting your project from the export menu and Godot making a new app bundle right?

Or are we talking about building the tools bundle for releasing the Godot editor?

Your first log unfortunately still doesn't show us the current folder but I'm guessing you're missing the first few entries because we can't see the arguments settings either. It can't open the godot.pck but it then does find a project.godot file in the resources folder, which makes no sense as there shouldn't be any there. It is getting stuck there, because after it finds this file, and can't do anything with it, it stops trying anything else.

Now here I have definitely introduced a bug. Because I have implemented get_resource_dir it won't try anything else after this when that is returned. It doesn't attempt to load the path pointed at after selecting the project. So that is indeed broken when Godot is running from an app bundle.

Now I'm starting to see why making the resource folder the current folder was the way this was implemented instead of using get_resource_dir. I'll undo that change.

@cbscribe
Copy link
Contributor Author

No, I'm definitely talking about the editor. Sorry if it was unclear.

I'll be happy to test the fix, let me know how I can help.

@BastiaanOlij
Copy link
Contributor

@cbscribe cool, I also know what I did 'wrong' now, or at least didn't realise was a consequence. 11482 should fix the problem for now, I haven't tested it yet cause I'm at work at the moment but its a simple enough change, it just disables some logic.

@BastiaanOlij
Copy link
Contributor

Owh and someone should redo that Info.plist for the tools build so it's actually identifying the bundle as Godot 3 instead of 2.2 :)

@cbscribe
Copy link
Contributor Author

It works! Commenting out the code in #11482 results in the expected behavior.

@BastiaanOlij
Copy link
Contributor

Cool! Glad we found that :)

Hopefully I'll catch the guys on IRC this weekend and I'll either end up removing that all together, or changing the way the loader goes through the different options of what to load :)

@akien-mga
Copy link
Member

Fixed by #11482.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants