MA Menu Installer incompatibility with VRCFury main component

[fullstackdelay]

MA Menu Installer can't generate menus inside of submenus if the avatar has a VRCFury main component even if no features are in use. VRCFury has a feature to move menu items to other menus. Maybe this is related.

The menu generation works in Unity's play mode but the menu is not there if you test it in game.

I don't think this is a configuration issue on the MA Menu Installer. It was tested using several different configurations and on different gameobjects but the menus are always missing in game.

It was tested using the latest version of MA (1.7.7), VRCFury (1.435.0) and latest VRC SDK (3.3.0).

Could be the same issue as described here bdunderscore/modular-avatar#399

[bdunderscore]

This sounds like an issue with processing order - currently VRCFury and MA process in a different order depending on whether you're using play mode or doing an actual build. I might try to put in some kind of workaround for this in NDMF, but it'd be preferable to get consensus from the VRCFury maintainer on the best way to make things consistent.

[ni1chigo2115]

かなり残念なことに、VRCFuryの開発者が、依存するlibraryを増やしたくないからNDMFに参加するつもりもないし、そのうえで解決策が見つからないから問題を解決する気がないという報告をもらいました。 アップデート頻度が頻繁なのでVRCFuryに合わせる義理はないとは思いますが、こちら側で対応する必要があります。

Quite unfortunately, I received a report that the VRCFury developers are not going to participate in the NDMF because they do not want to increase the number of LIBRARIES on which they depend, and on top of that, they are not willing to solve the problem because they cannot find a solution. I don't think we have any obligation to match VRCFury because of the frequency of updates, but we need to address the issue on our side.

[SenkyDragon]

and on top of that, they are not willing to solve the problem because they cannot find a solution

To be clear, if this is a VRCFury bug, then we are more than willing to resolve the issue. However, I believe that this is more likely to be an issue with MA being unable to read menus stores as sub-assets, which is the way that VRCF packages them.

The comment about NDMF is correct however. I have reservations depending on a library that may be updated out from under us.

[bdunderscore]

MA can read menus as sub assets, but the issue is probably that we reference menus as an object reference; when Fury clones the menu as part of its processing this results in a dangling pointer, so to speak.

One option would be to use menu paths by name instead of asset references, but there are some advanced use cases for asset references that folks are using that make it impossible to deprecate asset references entirely. It would also interact poorly with any Fury features to paginate menus (ie, add a “next” item when the menu overflows).

@SenkyDragon I wonder if there’s some way to at least collaborate on a registry for asset replacements? If MA/NDMF knows that Fury replaced menu A with menu B, we could fix the references on our side.

[SenkyDragon]

I don't think it's super unreasonable for VRCF to always be at the end of the build to avoid issues like this, since most (all?) of our features are input-file agnostic. I've added a stable hook at VF.Api.VfBuildHooks in the VRCFury-Api assembly that will call you back if VRCF is about to build on an avatar in play mode. Feel free to do with that as you wish within NDMF or MA.