App bundles inconsistent behavior than building in editor

[Griffin]

I think I am making a mistake but if I am, it is not obvious. I am trying to test my bundler and it doesn’t work as bundle as it does in editor builds.
This is part of a massive project but for the sake of debugging, I have a debug collection with a debug script instead of the normal main collection, so none of the other files should be loaded or run. When I turn on debug, there is only one function which should run (everything else is not implemented).

This script for now reads as:

function doTest()
	label.set_text("/go#label", "stage1")
	label.set_text("/go#label", sys.load("pack/duiashfsdfrhuisdfhuio").test)
	local function fulldata()
		label.set_text("/go#label", tostring(sys.load("pack/duiashfsdfrhuisdfhuio")))
	end
	timer.delay(2, false, fulldata)
	print(sys.load("duiashfsdfrhuisdfhuio").test)
	pprint(sys.load("duiashfsdfrhuisdfhuio"))
	local function changetet()
		label.set_text("/go#label", "stage3")
		os.exit()
	end
	timer.delay(4, false, changetet)
end

The behavior acts in two different ways from the editor and the bundle.
When I build from editor: the label onscreen starts as "hardy har har" (the test value of duiashfsdfrhuisdfhuio), and after 2s the label displays the memory address, and after 4s the window does close self
When I run from bundle: the label onscreen starts as "LABEL" (the default label value) and after 2s the label does NOT display a memory address, and 4s the window does NOT close self
why are these different? For the context of the strangely named file duiashfsdfrhuisdfhuio, it is so named to make it easier to locate in my fs. It is included as a bundle resource  its data is just the one key value as said above  it is so included: 

I have made many bundles to try to resolve this:

(and as a side note, britzl, I am building specifically to only arm64 (x86 is unchecked), but all the bundle information (folder name, debug html files, etc) reflects x86_64)

[Griffin]

Images stopped rendering properly in my previous forum post after I begun to include raw html formatting in it. Apologies, I didn’t know that it was not recommended. Here are the missing images:

Additionally, I will provide a macOS bundle demonstrating the problem:
debug (kopia) 2.app.zip (7.5 MB)

[britzl]

@Griffin

sys.load("pack/duiashfsdfrhuisdfhuio")

This is for loading a previously saved (using sys.save) Lua table. Is this really such a file?

Also, sys.load() will load from a path relative to the executable. When you build and run from the editor I believe this will be from the root of the project, ie where you have game.project, bit when you bundle it will be from the location of the executable. And in the case of the location of the executable it varies depending on platform. For Windows and Linux it is typically in the same location as the game archive, but on macOS it is a location within the .app file (eg MyGame.app/Contents/MacOS/).

Also, I see that you are using Bundle Resources. This is for copying files into the application bundle, which is what you want in your case, BUT the Bundle Resources functionality expects the files to be organised per platform, see documentation for more info: Defold project settings

So in your case you want to have a folder structure which looks like pack/osx/Contents/MacOS/pack to copy the folder to the same location as the exe on macOS.

Finally I’d like to point your attention to the manual about working with files and accessing files bundled with the application, using either Custom Resources or Bundle Resources:

Working with files

[Griffin]

I want to save files into the project fs from the editor build and read them when the app is bundled, preferably as part of the bundle so that I don’t have to include some launcher and patcher for the files.
It would also be preferable if there is a method where the fs pathing is consistent across editor/bundle or macos/win/linux so that I don’t have to detect if it is a bundle and switch the addressing.

Is sys.save() and sys.load() the wrong method to achieve this goal? If so, what is a better method?

@britzl

BUT the Bundle Resources functionality expects the files to be organised per platform

Thank you for catching this! I made such a mistake. I put it in “pack/common/duiashfsdfrhuisdfhuio” now. I’m not sure why sys.save and sys.load() let me use paths in the raw project but bundles don’t.
When I am debugging the app fs on the bundle, and I click visa paketets innehåll, I can see that the files are placed by default at the root location. I could back address to this, such as …/…/…/duiashfsdfrhuisdfhuio, but this would mean that i would have to change my addressing between bundle and editor build somehow, and that it would only work on macos and not on win/linux, so it is probably not preferable. Is it possible to somehow change the organization of the fs or addressing to reference the correct location, cross-platform way?
Or should I be using custom resources instead, and I am doing it the wrong method?
Thanks!

[britzl]

@Griffin

Is sys.save() and sys.load() the wrong method to achieve this goal? If so, what is a better method?

sys.save() and sys.load() is for saving and loading a Lua table. It didn’t look like you were loading a table, but if that is indeed what you do then those functions are perfect!

@Griffin

I can see that the files are placed by default at the root location

Yes, and that is wrong since in the .app case since the root will be considered the folder where the exe is. You should do this:

@britzl

So in your case you want to have a folder structure which looks like pack/osx/Contents/MacOS/pack to copy the folder to the same location as the exe on macOS.

Did you try it?

@Griffin

Or should I be using custom resources instead

Using a custom resource will be simpler, but depending on your use case it might not be the best case.

[Griffin]

@britzl

sys.save() and sys.load() is for saving and loading a Lua table. It didn’t look like you were loading a table,

I was using table

@britzl

Yes, and that is wrong since in the .app case since the root will be considered the folder where the exe is. You should do this:

If I understand this system correctly, doing this would require me to have multiple branches of the pack for different oses but all with the exact same files, which are to be kept the same, so I do not understand why it should be necessary then.

@britzl

Using a custom resource will be simpler, but depending on your use case it might not be the best case.

I am looking into it, but I do not understand why there exists no sys.save_resource() function to sys.load_resource() like there is for sys.save() to with sys.load()

UPDATE: with custom resources I got the thing I wanted working as intended, although I haven’t tested on any platform but macOS. The caveat is that I had to switch from storing the data as lua tables to json files which I then have to encode and decode at load and save. Not a problem, though, very small cpu effect.

[britzl]

@Griffin

If I understand this system correctly, doing this would require me to have multiple branches of the pack for different oses but all with the exact same files, which are to be kept the same, so I do not understand why it should be necessary then.

The main purpose of bundle resources is for a developer to be able to add additional platform specific resources, such as icons, plist files, Android resource xmls etc. You can ofc also use it to bundle other types of files, but you then need to take care when doing file operations to load the files from the right location depending on the OS you are running on. You can check which OS the game is running on by calling sys.get_sys_info(). Also you can use sys.get_application_path() to get the path to where the exe is located. This is useful sometimes when you need to load files that are in the same location as the exe itself.

@Griffin

I am looking into it, but I do not understand why there exists no sys.save_resource() function to sys.load_resource() like there is for sys.save() to with sys.load()

The reason is that the custom resources are written into the game archive (a big binary blob) when the game is bundled. This is the read only archive, which is why there is no sys.save_resource().

@Griffin

The caveat is that I had to switch from storing the data as lua tables to json files which I then have to encode and decode at load and save. Not a problem, though, very small cpu effect.

Note that there are also sys.serialize() and sys.deserialize() to work with the binary/serialized version of Lua tables in the same way as the sys.save() and sys.load() does.