_tau_ VRCOSC (https://github.com/VolcanicArts/VRCOSC/releases/tag/2024.220.1) media component (VRCOSC-Media-2023.629.0.unitypackage

) doesn't handle this change gracefully, I didn't dig through the code but I suspect it's not because they don't check for true/false and instead it's because of unsaved unsynced media control parameters the avatar package it provides are now broadcasted on avatar load.

Currently on live using VRCOSC and the media package, your playback will continue when you reload the avatar but on beta media playback will stop whenever the avatar reloads. I assume this is because the play parameter is not saved. In essence the avatar now broadcasts play to be false on avatar load which causes the media playback to stop. Previously the avatar would instead receive that play is still true from the OSC program and show that by play being active in the menu.

_tau_ I would consider this a breaking change.

My Media controller for VRCOSC, for example, uses an unsynced parameter to controller whether media on Windows is playing or not. The code is not detecting if the parameter is being enabled, the parameter is driving and being driven by the play/pause state of media on Windows. Since the parameter's value on the avatar now sends out the default value of false, it pauses media, breaking functionality.

My Media controller does handle avatar changes, as when an avatar change occurs it sends out the current state of Windows media to update the avatar. But because the avatar change now causes all the avatar parameters to be sent out, it changes the media state before the avatar can be updated.

Given that we've now got OSCQuery which lets us query the value of parameters when we need it (which we can do manually after the avatar change event comes in), OSC should only send out parameters if the value has changed like it currently does on live. Or, the avatar change event should send out a bundle containing all the avatar parameter addresses instead so that receiving them is "optional".

SlateTheFennec and d v l:

This change was originally intended to solve this previous report: https://feedback.vrchat.com/bug-reports/p/oscquery-broadcasts-wrong-parameter-values

If I'm understanding correctly, the problem you're facing is that ALL default values are getting broadcast, while the poster of that other issue was struggling with parameters that initialize to non-standard default values (i.e. true for booleans).

While I agree with _tau_ that the current behavior is reasonable, it was a broader change than was strictly required to solve the original issue.

Would it solve both of your issues if bool parameters that default to false were NOT broadcasted on avatar switch (but those that default to true still were?) If so, I think that could be a viable change for now.

Truce As far as I understood that problem, that was purely for OSCQuery, not for OSC. As in, when someone queried the endpoint for the parameter it wouldn't return the correct initial value until after the parameter had changed at least once. The change that's been made here has changed the behaviour for OSC.

My proposed solution of making the avatar change event a bundle that gets sent out would solve this if you still intend on keeping this behaviour different from what's currently on live.

When you change to an avatar you're not changing the parameters, you're initialising them. Having it be a bundle instead of sending out every parameter individually is equivalent to saying "this avatar has been initialised with these parameters", rather than "the user has changed avatar and all these parameters have changed". I think that the former makes more sense than the latter, the latter of which is what's currently happening on the open-beta.

As for your proposal of only broadcasting non-default values (bools default to false so true, ints to 0 so >0 etc), That wouldn't solve the problem at hand, given that any of my modules might have selections driven by or that drive parameters that need to carry over to the avatar that someone has changed to. This problem would also be solved by my proposal of sending the avatar change as a bundle with all the parameters.

The other problem that I've noticed is that because OSC is implemented with UDP and not TCP, some parameters can theoretically arrive the avatar change event, meaning any app that is listening for the avatar change event to then get the current state of an avatar would have desync from the client. This would also be solved by sending the avatar change event as a bundle with all the avatar's parameters and their initialised values.

As a side note, the paragraph above is technically already solved given that an app can listen for the avatar change event and then query all the parameters over OSCQuery, but this is where https://feedback.vrchat.com/bug-reports/p/oscquery-broadcasts-wrong-parameter-values comes into play, since the parameters that are broadcasted don't have their initialised values broadcasted correctly.

The way I'm seeing this, only the reported bug in that link needs to be fixed and the parameter values for the initial state of the avatar don't need to be sent over OSC. If you still want to send the initial state over OSC, consider changing it to a bundle as per the reasoning in my 3rd paragraph. Leaving the change as it currently is will break a lot of existing apps that rely on the fact that the initial state of the parameters aren't sent along with the avatar change event, and that if they need them they can get them using OSCQuery.