Is anyone here using Remote Config with Gameanalytics?
There is an issue getting the information immediately after initialization - the gameanalytics.isRemoteConfigsReady() returns false. If it’s called a second or so later, it usually returns true.
The official API says this:
I’ve sent an email to the Gameanalytics support asking if there is a way to see when the remote config vars are delivered. In the meantime, does the Defold forum have any insight?
Update:
You should make an issue on their github for the Defold version for this.
Should be fixed now:
That’s great, thanks so much for adding this! Will the callback always fire? Even if the device is offline?
Yes @totebo it will fire in every case the remote configs are updated even if there are no configs for the game or being offline. It will cache remote configs from previous time getting them from the server. So if the user is offline it will use the cached configs instead until getting new ones from the server next it is online for a session started.
Super. Thanks!
After integrating the callback, the game now sometimes crashes when regaining focus on iOS. Defold’s own console sometimes has time to fire an error (these two errors happened separately):
ERROR:SCRIPT: Unbalanced Lua stack, expected (0), actual (1)
ERROR:SCRIPT: Unbalanced Lua stack, expected (4), actual (3)
The crash only happens when gameanalytics.setRemoteConfigsListener() is used, and it happens even if the Lua listener method contains no code. When setRemoteConfigsListener() is not used, this message is printed to the console, but it doesn’t crash:
WARNING:GameAnalytics: Received remote configs update but no listener was set!
I can’t see a clear error in the MacOS console, but in case it’s useful, here are the death throes of the crash and subsequent auto-restart: crash.txt (104.4 KB)
I haven’t been able to replicate the crash on Android.
Also posted here: https://github.com/GameAnalytics/GA-SDK-DEFOLD/issues/30
Any idea what could cause this?
Ok sorry for the late reply. I have been away on holiday. I will look into fixing this.
So it is not always it happens? I tried to reproduce the error but I am not able to. I put the app to the background and then into focus again and it runs fine with no errors.
No, it happens maybe one time in five when the app loses focus and then regains it.
On iOS the quickest way to replicate it is to swipe up from the bottom to make the game start shrinking, then go back to it and so on.
I created an empty project to try to replicate it, but wasn’t able to. The issue may be in my implementation.
I set the callback in a Lua module that I require from the loading screen. The loading screen then gets removed.
Question to the floor: Would the lua module also be cleared then, because the reference to the module is lost? And the callback becomes unavailable?
It is still loaded and referenced in the global package table.
No, BUT I think I have found something that’s related to the crash.
I’m using manual session handling, with this code:
local function window_listener( self, event, data )
if event == window.WINDOW_EVENT_FOCUS_LOST then
if gameanalytics then
gameanalytics.endSession()
end
elseif event == window.WINDOW_EVENT_FOCUS_GAINED then
if gameanalytics then
gameanalytics.startSession()
end
end
end
window.set_listener( window_listener )
When I disable this code, I’m no longer able to reproduce the crash.
I’ve changed the callback to this and haven’t seen the crash (yet):
local function window_listener( self, event, data )
if event == window.WINDOW_EVENT_ICONFIED then
if gameanalytics then
gameanalytics.endSession()
end
elseif event == window.WINDOW_EVENT_DEICONIFIED then
if gameanalytics then
gameanalytics.startSession()
end
end
end
I’m guessing the remote config callback and session handling is somehow related?
The SDK should automatically end sessions when it goes to background and start a new one when it goes into focus again.
Even when using manual session handling?
No sorry, I mean there is no need to use manual session handling to just start and end sessions manually if it is simply for going to background and back in focus. If you are trying to do something more complex then fine. Just wanted to mention that.
You are welcome to post the simple test project where it is reproducible in and then I can try to test that.