App Review final submit blocked by hidden fblogin-web-1 validation label
Meta App Review final submission for our app is blocked by a hidden/internal validation label. All visible App Review sections are complete/green, but final Submit returns: Some sections are incomplete question labels are invalid: fblogin-web-1 App: Hermes Bot App ID: 2389952421516474 Business ID: 1114463873276065 Submission ID: 2407995389712177 Expected behavior: - The submission should submit successfully because every visible required section is complete, or - The UI should render the missing question/field that maps to fblogin-web-1 so it can be completed. Actual behavior: - The final submit confirmation modal accepts the acknowledgement checkbox. - After clicking the modal Submit button, the page returns the fblogin-web-1 validation error. - No visible App Review section, Website platform testing instructions, Facebook Login for Business settings field, Facebook Login for Business configuration field, or Instagram setup field is visibly marked incomplete. Troubleshooting already completed: - Verified App Review checklist sections are complete/green: Verification, App settings, Allowed usage, Data handling, Reviewer instructions. - Accepted the Instagram tester app invite for Hermes Bot-IG under the wheelsfeelsusa Instagram account. - Checked/filled Website platform testing instructions. - Checked Facebook Login for Business settings. - Set and saved owned-site values: Valid OAuth Redirect URI https://wheelsfeels.com/, allowed domain wheelsfeels.com, deauthorize callback URL https://wheelsfeels.com/privacypolicy, data deletion request URL https://wheelsfeels.com/privacypolicy. - Created/reviewed Facebook Login for Business configuration for the support workflow. - Corrected configuration assets from Pages + Pixels to Pages + Instagram accounts. - Checked Instagram business login/API setup and generated/validated tester authorization where visible. - Retried final submission after each plausible fix. The same hidden fblogin-web-1 blocker persists. Requested help: Please advise the exact product/settings page and field that maps to fblogin-web-1, or escalate/fix the hidden validation state so the missing field is surfaced or the submission can proceed.
Questions regarding Shared Spatial Anchors Limits and large-scale deployments
Hi, we're an organization investigating whether using Meta's Colocation / Shared Spatial Anchors SDK will be feasible for large-scale VR/MR projects. I have found limited information in the documentation regarding this topic, mostly mentioning 'two or more' players are supported. We are building a prototype app that is planned to need to scale up to approximately 200 people in quite a large space. We'd like to know if there are any strict hardware limits to: A) the amount of headsets that can share spatial anchor data with one another (in our case, it's fine if one headset shares the spatial anchors and the others 'listen' to these anchors. e.g. how many concurrent users can accurately receive spatial anchors from a single headset? B) the maximum amount of physical space that the headsets' pointcloud can accurately track. e.g. an area of 200m2Questions Regarding Shared Spatial Anchors Limits and Large-Scale Deployments
Hello, We are evaluating the feasibility of using Meta's Colocation / Shared Spatial Anchors SDK for a large-scale VR/MR project and would appreciate some clarification regarding its scalability. While reviewing the available documentation, we found limited information about supported participant counts, with most examples referring only to "two or more" users. Our current prototype is intended to scale to approximately 200 concurrent users operating within a relatively large shared physical environment. To assess whether Shared Spatial Anchors are suitable for this use case, we would like to better understand any practical or hard limitations of the system. Specifically, we are interested in the following: A. Concurrent headset support * Are there any documented or recommended limits on the number of headsets that can share the same spatial anchor data? * In our scenario, a single headset (or a small number of headsets) could act as the source of the spatial anchors, while all other headsets only receive and localize against those anchors. * Is there a maximum number of concurrent devices that can reliably receive and use spatial anchor data from a single source? B. Physical environment size * Are there any limitations regarding the size of the tracked environment when using Shared Spatial Anchors? * For example, can the system reliably support a shared space of approximately 200 m², or are there recommended maximum dimensions/areas for accurate localization and alignment? * If limits exist, are they determined by the anchor system itself, point-cloud tracking capabilities, network considerations, or another factor? Additionally, if there are any best-practice guidelines, performance benchmarks, or case studies involving deployments with dozens or hundreds of simultaneous users, we would be very interested in reviewing them.Problem with SharedSpace and Colocation
I'm currently working on a mixed reality project, the idea is to allow two players who are physically in the same real world space to place objects around the room. Right now I'm working on the multiplayer part of the project. I used a custom script instead of the Building Blocks to connect both users using Photon Fusion and create a room with a code. The problem is that, during testing, the players do not see objects in the same positions. The objects move correctly, but they appear in different locations for each user. To fix this, I started looking into Space Sharing and Colocation so I can ensure both users share the same room alignment and anchors. I started implementing it, but I ran into another problem: I don't seem to be able to test it properly, is the only way to test this with two physical devices? Currently, I'm trying to test using one device and the Unity Editor with XR Simulator. When testing, I can see all the debug logs on the device build. When using the XR Simulator, it does not finish the process of creating the anchor IDs, and if it is running as the client, it never finishes retrieving the anchors either, in both cases, it only shows: "Starts the process..." (<- my debug log) For the Building Blocks, I'm using Passthrough, Shared Spatial Anchor Core, NetworkManager, Platform Init, and Effect Mesh to verify whether both users are sharing the same room.
ERROR_CLOUD_MESH_UPLOAD_FAILED(-400039)
Unity colocation build with MRUK, getting this error in Logcat and "host can't share the room with group xx-xx.." on immersive debugger... User ID and User profile active in dashboard, device has spatial permission enabled, project uploaded to alpha channel, my own user invited as tester, Keystore signed, tried with 4 different WIFI, no LLM has a clue... was working before upload alpha, What else should I check?
Is there a way to make the player not see their own avatar
Hello, I am building a Unity Project with Meta All-In-One SDK and I'm using the Networked Avatar Building Block on top of Matchmaking and Hand Tracking and Passthrough to create an experience where users can see other avatars with their hand movements with Passthrough in the real world , this creates an effect where you can see people walking around, talking and interacting with things in a room that they are not physically in with passthrough. My issue with this is the fact that the player (host) can see other players' Avatar and other players can see the host's avatar but when the host themselves also look down they also see their own avatar arms connected to their hands and body. I do not really want this Is there way for the player to just see their normal hand prefabs/meshes from their perspective while other connected players see the full avatar and vice versa?
Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.
Unity Multiplay End of Life
If you are using, or were planning to use Multiplay for your game server to connect players together, be aware that they announced this morning they were going to stop the service in 3 months. Their migration plan is nowhere to be seen. If you're looking for simple, quick and cheap options, I recommend looking there: https://edgegap.com/blog/easily-migrate-from-unity-s-multiplay-to-edgegap-s-game-server-hosting Full disclose, I work there and we're all ready to support you for free to migrate to make sure your game is not impacted. You will end up paying less per month anyway, so this should end up being a positive thing after all.
