So yes, as I was saying, the VRC guidelines for building worlds, explicitly states that no unique or custom c# scripts are allowed what so ever, (and, understandably so). However, I have been in a number of rooms, where there is absolutely NO WAY, that some of the stuff I have experienced, could or can be done “natively” within Unity, without additional scripting.
So, how is this explained then?
Well for one there are allowed scripts and to a degree UDON (SDK3) can allow some custom scripting.
They could also possibly be using a bit of a workaround using different solutions to accomplish the same goal.
It’s also possible that something in SDK2 can accomplish the same thing that you may not be aware about.
You also got to think outside the box on a lot of the native unity stuff.
A good example would be The Devouring, that world was made with just native unity components and SDK2.
I just feel that, there should be some small scripts, like say, a 4 line c# script that does absolutely nothing other than rotate a Cube on the Y in mid air, that the higher heads of state at VRC would inspect and say, gee, this script really does nothing but rotate a Cube in mid air, we can allow this.
That would be great, because I am currently up against just that problem. I have a ceiling fan that spins the blades on the Y using Unity’s animation, now in Unity, it looks great, but as soon as I put on my Vive, within VRCSDK and watch the fan blades, they rotate, but there is a nano second pause/glitch before the loop restarts at 0 again in the rotation. So first I said, ok, being that 0 and 360 are actually the same location, and hitting 360 and then 0 WOULD actually promote a glitch/pause like I’m experiencing, I then changed it to 0 and 359, and it didn’t fix the problem. Then I remembered about animation uses FPS, and Script uses DeltaTime. So guess what, I created a script, using DeltaTime, and now there are no glitches, using the VRCSDK, and, I cant use it because it is a custom script.
The fan animation probably just needs tweaking of the animator that’s moving the fan.
On the animation window, click the Curves tab and right-click the start/end keys, then set both tangeants to Linear. (By default it will move faster at the start, slower at the end, then smoothly in between).
You’ll also want to set the animator state (Animator tab) to have transition = 1 and transition duration = 0. That’ll snap immediately from the last frame to the first frame of the animation between updates instead of trying to set up a smooth transition.
Having it automatically detect what the script is doing sounds easy in theory but as soon as something like that’s enabled, tons of people will immediately find ways of bypassing it or tricking the automated detection.
If you have any other examples of stuff that you’ve seen that you want to know how is done though, this is a good place to ask about it. There’s an insane amount that you can do with just proper usage of Unity builtins and SDK2. (Keep in mind that everything in Standard Assets is also whitelisted)
Why dont u use Udon for the fan? You can do that very easily in Udon.
Just use Udonsharp. It let’s you use C# code with udon by compiling the code into udon code.
The rule against custom scripts applies to external scripts and tools.
Udon and by extension Udon Sharp use a set of whitelisted functions and calls. Which is allowed within the scope of the guidelines.
Scripts like dynamic bones are on a similar whitelist as well since the vrc team has found those to be safe.
However it’s still impossible to have a udon world that loads external libraries or code that doesn’t conform to the udon standard.
All u# does is compile the code in the same way udon does. Hence why that is fine. But you’re still unable to do a lot of things with u# that would be normal in c#. A good example would be using LINQ which isn’t whitelisted by udon.