And since someone brought up a release topic... where are we on 1.1? We have the logo, we have the A
And since someone brought up a release topic... where are we on 1.1? We have the logo, we have the API fix... docs / trailer? Anything else?
Ai'll finish the layers fix
Aalthough - jeez that shows how little testing it's had!
MReview promo
MFrom what I can see of the metrics (and they're limited), I think it's more about users than usage
MI.e., relatively few people are on the beta channel
MIs that what I meant by trailer? Or something else?
AToo bad there isn't a way to just toggle between them in the (in game) interface, or tell the other one to load on next restart
MThe polite pop up asking for feedback 
Mah, yes!
MAre we doing this on all platforms or Quest only?
MI’ve been working on finishing Pico to hit a few deadlines so not made as much progress on these tasks as I’d like
MAll platforms wouldn’t hurt tbh, but mainly quest
Mngl, I find the notion of "a lot of work... pico" humorous.
APico's important. That's going to be a huge market
AChina would probably end up restricting meta outright, if they haven't already
MWe still need xr_v2 to be validated for that to go through, however 
MI think we’re close on all fronts. Just needs a good push by the whole team to get everything over the line
AEverything's coming in heavy from all sides right now. Major life transition point for me, in all sectors
AAnother layers issue. If you toss the panel, there's no way to get it back. So
- Yet another button to show/hide layers?
- Make it non-tossable? (a lovely phrase...)
Moption 2 sounds good 
AI was actually leaning towards 1. Otherwise it's another panel you can't hide. We've got space on the tools panel for another button
MI was thinking 2 might be less work, but go ahead with 1 if you're up to it! If we've got room, then that's neater.
MWe're probably reaching the point where we're gonna have to think UI layouts soon 
AI was thinking 2 might be less work,Yeah - that's why i was leaning towards 1 as well - but it's not the best way so i'll do it proper.
MAre you adding this to the PR or will you be opening a separate one?
Anot sure. was gonna fix it first and then decide
Ai tried on friday but ran out of time. it's too dull to tackle on a monday morning
Awhat's easiest?
Mthe rest is good so I could just merge it now 
Ashall we do the "easy solution" for now?
Ait's a single checkbox
MYep, let's do it, it's better than the current situation right now
Aok, will push a change to current pr
ADone.
Aok. found a bug in the release version that's not in OG Tilt Brush. Groups that contain both imported models and brush strokes separate into separate groups when saved...
AIt predates the layers version which had the most changes to save/load code
Atrying to think what other features touched that part of the codebase...
Muhoh
Mi'd try and grab 0.3, 0.4 etc and work out if we introduced it somewhere there
Aah. merging brush strokes might be it
Mah, possibly
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