SDK Scripting define
Thryrallo
In the recent Jam SDK the vrc scripting defines were removed. In response to this the devs explained the defines are planned to be removed in the future.
I would like to arguee against this decision.
This already broke multiple world creation tools like VR World Toolkit in the jam, but intruducing this change to all SDKs could result in much worse results.
As an example for one project i am working on: The UI for poiyomi shader. The shader uses a locking system to remove keywords and improve performance significantly.
This locking is foced upon avatar upload using the vrc callback, which is sourounded using the vrc define.
If the define was now removed it would mean everyone using older version is poiyomi (which there is alot) would not have locked materials. And believe me, if locking is not forced, people will not lock. This will hurt vrc performance significantly.
Most other communcity made tools also use the scripting defines, maybe for small stuff like checking which sdk is importat, or bigger stuff.
My suggestion is: Do not remove them. It is a few lines of code to keep in the sdk. Internally all of vrchat code can move to the new package manger system, but please DO NOT BREAK MOST COMMUNITY SCRIPTS.
Lots of love,
- Thry
PS: My constant appeal to the vrchat team: Please improve communication with the communcity.
Log In
Momo the Monster
I apologize both for accidentally breaking the system in the JokeJam SDK, and for commenting on the other post about the deprecation of defines before we had a strategy and timeline to communicate. Here's where we are, and where we're going:
- We are not removing the project defines from any existing projects. Deprecation is not removal, but the act of marking a method as old logic when there is a better way to do things. It is an important part of how software teams communicate upcoming changes.
- There is a better way to detect the existence of other packages, using Define Constraints (https://docs.unity3d.com/Manual/class-AssemblyDefinitionImporter.html#define-constraints).
- We will support both methods of detection for the foreseeable future.
poiyomi
My shader uses the SDK Scripting defines to lock in and this will tremendously decrease shader performance for everyone not willing to update. I don't mind if we eventually move away from the defines but we need to be in the new system for a while so people have time to update their things.
The average user is very slow to update and I don't want to see a master shader situation happen again.
Pumkin
I feel like this is a pretty misguided breaking change that will affect lots of community scripts out there.
Lots of things include their own defines even in the unity asset store to allow packages to add additional functionality from other scripts without having hard dependencies.
z3y
Please at least tell us next time, it was removed without a word
Momo the Monster
z3y: The removal was accidental, it has been restored and only Closed Beta test projects and new JokeJam projects were affected.
Thryrallo
Another comment, related to my PS. Please if you are planning moves like this in the future, communicate it to us.
Currently I have no idea what the timeframe would be that i have to plan for it to be removed. I also do not have any idea what system replaces it so i could future proof my own code.
With the info i currently have there are two options:
- Use reflectiong. Barf. Really bad.
- Make my own scripting define. Also bad. I did that in the past at one point, but it introduces additional points of failure and concusion. Pumkin acutually used my define at one point thinking it was an offical one ;D