Right now every single QR code that has been seen while the tracker is enabled is retained between launches of an app, meaning if you even glance at a code that may be sitting on the side somewhere it could end up doing weird stuff during an app that handles codes.
Example scenario
I have a code that aligns the player rig, rather than aligning an object. I launch my app, look at the code, things align and all is well.
Then I close the app, flip the code over, relaunch the app. Those objects are still where they were last seen. Hell, I can close out the MR Portal and try again and they're in the same place. Going off what I've been told the only way to actually reset things is to replug the USB cable to restart the QR tracking driver.
For the majority of applications, I really can't see this being useful. If I have an app that ignores the actual code content and spawns something whenever it sees a QR code there would be absolute chaos. But also testing an app is a lot harder too as I will always immediately have everything spawned.
By the looks of it LastDetectedQPCTicks is just a unix timestamp so that could be an option - just add a checkbox to QRCodesManager that filters out codes that were seen before QRCodesManager initialised. I've just tested that out with my own QRCode handler and it seems to work well. You store a timestamp on Awake() or Start() from System.Diagnostics.Stopwatch.GetTimestamp() and compare any codes that pass through an event with that and only queue the event the LastDetectedQPCTicks is higher than the stored timestamp
Tagging relevant folk: @Yoyozilla @chgatla-microsoft
@BenWoodford, That is the right way to filter out the QR codes that are older. There are other scenarios where the QR codes needs to be reported. For example: you relaunch your app and you would want to know where was the QR code last time ( QR code could already have been removed or occuluded or in different room where you started the app and walked down here). The events in the QRtracker "updated:" is the one that should be used if you are truly only interested in QR codes you see "Now". The API is pretty general so the scnario you describe can be accomplished many ways, as you are already doing using timestamp. ( or using updated event).
Good to know I got the approach right!
This may be more something for the MRTK implementation rather than the “low-level” example we have right now perhaps.
@BenWoodford Do you feel this issue is resolved now? If so, I'll go ahead and close this issue
@BenWoodford Do you feel this issue is resolved now? If so, I'll go ahead and close this issue
I think it’s worth keeping open for when we actually make an MRTK implementation of it with all the bells and whistles, as it’ll be more relevant then
Closing issues older than 180 days. If this is still an issue, please reactivate with recent information.
Most helpful comment
I think it’s worth keeping open for when we actually make an MRTK implementation of it with all the bells and whistles, as it’ll be more relevant then