Creator Companion

Reduce Redundancies in VPM Repositories
As it stands right now a repository listing for VPM contains the entire contents of all package.json files of all versions of all packages listed. This adds a lot of redundant information, most of which isn't even needed until the package itself is being downloaded, at which point the package.json file can be used to obtain that information instead. This introduces potential issues when information in the repository and package.json differ. Be it due to error by the repository maintainer or malicous action. Thus I suggest changing the repository listing from "packages": { <package-name>: { "versions": { <version-number>: { <contents of package.json> }, ... } }, ... } to "packages": { <package-name>: { "displayName": <user readable name>, "description": <description>, <any other informative fields that won't change between versions>, "versions": { <version-number>: { "url": <git-compatible url to fetch the package itself>, <other version specific information that should be available before installation of the package>, "dependencies": { <vpm-package-name>: <minimum required version>, ... } }, ... } }, ... } Differences of note is that non-version specific information (such as the package's display name) was hoisted to the scope of the package's entry, as opposed to being repeated for each version, and that most information (that is presumably not useful until the package itself is to be installed) was stripped from the version specific information. The biggest change is that dependencies to other vpm packages are now referred to by version as opposed to a git compatible url. This is mostly because packages from a repository generally shouldn't depend on packages outside of repositories. And if a package is within a repository, it is best referred by its identifier and version, as opposed to the git-compatible url to install it. Ideally dependencies of dependencies wouldn't need to be listed in a repository listing, but that's besides the point of this post. Thank you or your time.
1
·

tracked

Differences between ClientSim and VRChat (Multiple UdonBehaviour in one GameObject)(SendCustomNetworkEvent)
Attach three UdonBehaviour to one GameObject. <Scripts>(It was difficult to read the description here, so I am attaching it as an image.) First, interact the GameObject. <Result> [Behavior on ClientSim]->Only TestA works. [Behavior on VRChat]->TestB and TestC also work by SendCustomNetworkEvent of TestA.(Gif video) If the behavior on VRChat is normal, please modify the behavior on ClientSim to do the same. I think it would simplify some systems if a single SendCustomNetworkEvent could call functions contained in multiple UdonBehaviour. ■■■■■■■■■■■■■■■■■■ タイトル: ClientSimとVRChatの差異について(1つのGameObjectに複数のUdonBehaviour)(SendCustomNetworkEvent) 1つのGameObjectに、3つのUdonBehaviourをアタッチします。 Udonの内容は、ここに書くと読みにくかったので画像として添付します。 まず、GameObjectをインタラクトします。 (結果) [ClientSim上での動作]→TestAのみ動作します。 [VRChat上での動作]→TestAのSendCustomNetworkEventにより、TestBおよびTestCも動作します。(添付のGifアニメ) VRChat上での動作が正常であるならば、ClientSim上でも同様の動作を行うよう修正してください。 1度のSendCustomNetworkEventにより、複数のUdonBehaviourに含まれた関数を呼べるのであれば、いくつかのシステムが単純になると思います。 以上です。
0
Load More