AJust looking at my old crappy code:
There's surely no reason to use "out" for oldGroupToNewGroup? Dictionaries are pass-by-reference so it would behave the same without "out".
There's surely no reason to use "out" for oldGroupToNewGroup? Dictionaries are pass-by-reference so it would behave the same without "out".
Mi believe so?
Myeah, that makes sense. if you were passing a dictionary item it'd be different
Mgrr. newtonsoft json dependency conflicts strike again. localisation package depends on unity's version, but we have a separate hard dependency from our NuGet registry for Google API Core
Mworked around it 
https://github.com/icosa-mirror/com.unity.localization/commits/nodeps thanks needle.tools team 
https://github.com/icosa-mirror/com.unity.localization/commits/nodeps thanks needle.tools team A@mikeage Some workflow advice if I may. I've got two feature branches, one of which is less likely to be ready soon than the other. (Let's say feature A is "soon" and feature B is "not soon")
I need feature A in the B branch. If I keep merging A into B, will there be any weird issues when B eventually is ready to merge? I wondering if the squash merge for A will confuse git about which commits have already been merged into B.
I need feature A in the B branch. If I keep merging A into B, will there be any weird issues when B eventually is ready to merge? I wondering if the squash merge for A will confuse git about which commits have already been merged into B.
AOr is git smart enough to keep track of individual commits even after a squash?
MGit is smart enough to handle this case, whether the commits from A appear in B because of a merge to main and then to B, merge to B directly, or squashes.
AGood. I shall keep merging then
AThanks!
Mnp. Can't wait to see what A and B actually are 
AA is "Transform panel" (axis locking, align, distribute) and B is the generative 3d models
A@mikesky Want me to merge main into xr_vr? I accidentally did the work trying to update my feature branch so it seems a shame to waste it. Only point is that it's not been tested very well.
MPlease! unityYAMLmerge seem to handle the layers conflict fine, but the API code uses the removed Valve version of newtonsoft and our version doesn't seem to have it's utility namespace
Ajust done a PR!
Afor main - to solve the merge
Moh, that'll do it 
nice!
nice!ANow - i've got a weird bug in xr_v2 now. You can't open the popup that has the button to open the Labs panel
AMaybe other popups too
AInvestigating
Muh, I didn't notice that when working last night
AMight just be me.
AI regret not being more disciplined with the API enhancement PR. That should have been two PRs really. It's a pain to merge that back to my feature branch (not a problem with XR_V2)
MMerged
A@mikesky I think the issue is with the commit that changed one or more of these:
Mare you using monoscopic?
ASo 1d6efd0f057c0427b0bbe1ae6c845a00ed429060
Ano
Mhmm
Mwhat headset
M(did I forget to add quest to the controller options)
Aquest via link
MI'll take a look!
AI was wondering if turning on the new(ish) Incremental Garbage Collector might be a good idea. Anyone got much experience of using it?
M(there's a new incremental garbage collector?)
AWell - 3 years old new: https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html
A2019.4
Mwhich OpenXR runtime, Oculus or Steam?
Aoculus i think. i rarely change it
Amust be - otherwise steamvr would open
Myeah, okay i'll charge my Q1 up, Rosie's in London with the Q2 
Ai'm off to the beach now it's cooled down but i'm back later
Moh also, have you got the
OCULUS_SUPPORTEDsure thing! The beach is a bit far for me haha
MFound it, this is certainly an odd one esp as other buttons work but not that one, and the accounts one too
esp as other buttons work but not that one, and the accounts one tooMThere's a bug in the new input system. 
MWasPressedThisFrame only fires when the button or axis is greater than 0.5, despite me changing the default to 0.15. this is a bit of a blocker for lazy input/pressure strokes, as it only works for values above 0.5 now
AIs the bug in C# or in compiled code?
Ai.e. can we just fork it for now?
MI'm not sure yet, this code is confusing as heck 
Will take a look after lunch and fork if needed, we're already running on a forked localization package
Will take a look after lunch and fork if needed, we're already running on a forked localization package