(not sure this is a bug, maybe it’s an expected issue but the behavior remains weird, so… you tell me)
In another post, I realized different camera behaviors depending on the context:
1/ Defold + “local” html5 version
2/ “live” html5 bundles
I thought I fixed the issue, but in the end, some unexpected behavior remains, so…
After a deeper investigation, I realized something super weird.
The game object ids are not the same in both contexts
The camera id in Defold and “local” html5 version: => “/camera_001” ok
But in “live” html5 bundle: => “XXXXXX (unknown)” wtf
I suppose that in 99% of situations it’s ok, but in my code I check if the “expected” camera_id is contained in the game object_id (for some reason)…
… and now I understand why it didn’t work.
In html5 bundles, the string is not contained because the game object id has a different format.
But only in html5 bundles.
So I’m wondering… Is this a known issue? Is this even an issue?
(in my case it is, but from Defold perspective maybe not)
Is it possible to get the correct object_id in “live” html5 builds?
@Mathias_Westerdahl Sorry I’m a bit lost with the terminology (because I didn’t know exactly how it worked, so I used the terms as they come to my mind). What I called “live” html5 bundle is, well… when you create the bundle, upload it tp a server and test it online, via an url etc. (or offline with wamp etc. I suppose it works - hmm maybe I should try this ).
@britzl That was the issue indeed!
Good to know this is something “known”, it helped me fix the issue.
It’s an honor to be part of Defold documentation
@selimanac
Yeah, I ended up directly using the hashed stuff this time (and it fixed the issue). I initially thought that my “string.find etc.” trick was clever but in the end, it wasn’t… at all
+I didn’t think it would be a problem to share a 1 single-line screenshot, but ok noted! I won’t next time.