Do you build on Linux? I think I found a related issue, that might be it. This issue affects only linux, but mac and windows work fine. The fix on its way.
No, on Mac.
Have been trying to reproduce the error, but havenāt been able to.
The full journey was this (starting with the game, then trying to narrow it down)
- Tried to bundle our game through the editor - editor crashed once, and later failed to bundle with errors
- Tried to bundle extension-facebook through the editor - failed to bundle with errors.
- Tried to bundle extension-facebook with Bob - failed to bundle with errors.
But today it all seems fineā¦ will try again if time allows.
I found that the engine can mount data from multiple sources based on the uri
(the info is from LIVEUPDATE.md) passed to the function liveupdate.add_mount(name, uri, priority, callback)
:
-
file
- Used during development to read built files from the project folder -
archive
- Used for the base game archive (.dmanifest
,.arci
,.arcd
) -
zip
- Used to read content from regular .zip files (e.g. .obb on Android) -
http
- Used to read files over http when the engine is attached to the editor. -
mutable
- Used for live update when downloading individual files. Same formats asarchive
As I understand it right, if uri
is specified as zip:/path/to/file
, then the engine will read the file at the specified path from the file system. Thatās great! I would like to use this for html5, i.e. mount an externally loaded zip archive, but it is probably not supported? There is no file system access in html5.
I played around with the new live update features and ran into two main issues:
- Calling it when running from the editor crashes the engine, no matter what arguments I pass _crash.txt (50.0 KB)
- Calling
liveupdate.remove_mount()
doesnāt seem to update the mounts file, so in my test project it would see a mount to remove, reboot to apply changes (which Iām guessing is necessary based on the docs), see a mount to remove, reboot, etc. forever
What exactly Lua function you are calling here?
Iām not an expert on the filesystem on HTML5, but āThere is no file system access in html5ā doesnāt seem right?
We use the file system to store the āmutableā liveupdate, and save data?
I donāt know how to properly download and store a .zip file and store it, but perhaps someone else can help out with this?
Yeah, we use the IndexDB API, or more specifically IDBFS via Emscripten:
Interesting if we could add support for something like idbfs:/path/to/file
? Or maybe it is indeed possible to use zip:/path/to/file
also on HTML5 as-is if the zip file was downloaded and saved using sys.save() or io.write().
As long as the path is valid, I assume it will work. Thatās how the old āmutableā files work.
The main problem should be to download a file and store it. Isnāt that possible with the http.request() already?
Yes it is.
Sorry, I meant liveupdate.add_mount()
. Thatās what I get for writing late at night . I also forgot to mention that Linux users would appreciate the folder with the mounts file being moved into somewhere like ~/.Defold
instead of right in the home folder.
Itās currently saved in the āsaveā directory, where the other save data ends up. (in a folder which is unique to the project title). This isnāt anything new though.
Is there a better user directory than āHOMEā on Linux?
but sure, we could probably add it to a .defold/<project_id>
folder. Not sure how to migrate old save games though.
Itās recommended to use either ~/.config/
or ~/.local/share/
(the default values of XDG_CONFIG_HOME and XDG_DATA_HOME respectively). DefSave uses this code here to save in ~/.config/
:
-- For Linux we must modify the default path to make Linux users happy
local appname = "config/" .. tostring(M.appname)
return sys.get_save_file(appname, file)
Unity games also store save data in ~/.config/unity3d/<appname>
(or $XDG_CONFIG_HOME/unity3d/<appname>
if set).
At the moment, Live Update doesnāt work in the editorās build, but of course it shouldnāt crash. The fix is already in beta branch and an update should be available in 40-50 mins.
Thanks for the quick fix!
Just updated to the latest beta and there is now an error on defos. The previous build of 1.5.0 was working as expected.
SHA1: b4d6c0f12fad75d6d75d280b948322b9bc20c047
The instance had ran out of diskspace. Iāve increased it. Please try again!
It seems like we have to increase disk size now that more developers are using extensions with Cocoapod dependencies.
We have decided to add one more fix to the beta version. This fix will help prevent the occurrence of an āInternal Server Errorā when building massive extensions, such as ADS mediations, on the extender.
Added a fix the gamepads not signalling a connected state when starting a game with the gamepads connected.
Is this affecting the stable build server too? Weāre having problems building for iOS:
INFO: 'arm64-ios' could not be built. Sdk version: '3dbbf1dbebd3a8146f6a917d101882a
61f56afdcā
Problems also with extender:stage channel:stable Ā· defold/test-sdk@633ffdf Ā· GitHub