Has anyone had a chance to play around with the new VRC Virtual Skills in VEXcode V5? What’s you experience?
It seems like a really useful tool - once the bugs are out. And fun. But currently the physics are really buggy. Is there a way I can fix it on my end? I can imagine it being a super useful tool.
We’re working on improving physics, but keep in mind that the goal is not to be a “robot simulation” but rather a coding tool.
Meaning don’t expect 1-to-1 matching of the real world field, but we are doing out best to abide by the laws of physics 
If you do find reproducible issues, using the feedback tool and including diagnostic data will help us troubleshoot and continue to improve over the coming weeks.
I find it doesn’t matter what I try to code, the robot will do really unpredictable things.
I’ll make sure to use the feedback tool more. 
Given concern around tower “wobble” would be nice to simulate that to show not a big deal 
Totally love this tool you guys have developed for this season!
Tip of the hat!
Will text-based coding be coming in the near future?
Have you considered making the game in the Unreal Engine framework and wrapping the code editor around the game?
Unreal Engine is free for non-commercial purposes, unless I am mistaken.
Not to mention, the framework is C++ supported.
We use Unity for our development environment which has a lot of the same features of as Unreal.
The issue isn’t so much related “make the physics” work… it’s a few key issues that I’ll share to give you some insight:
100% pure physics would become processor intensive and would require “higher” end machines. We’ve set an internal mark to make sure our tools work reliably in school environments (low end computers, 5-7 year old computers, Chromebooks) to increase accessibility. We could make the game VERY pretty and simulate materials and real world physics, but then only about 1-2% of users could use it, and most schools don’t have those high end machines available.
“Real” physics can present a level of unreliability and punishing difficulty, so we use the magic of video games in order to simply some engagements for repeatability to increase the enjoyment and success of the user. The objective is not to “make a game simulator”, it’s to make a tool to bring the game and coding experience to more people by increasing accessibility. We fully understand that “top end” teams might not even bother, but for a lot of teams this is a great way to get planning / strategy / coding experience early in the season.
All of this is then compounded by exporting out our projects into a WebGL package, which takes your wonderfully working game and throws a lot of it out of the window. Processor and Memory limitations, browser threading limits, all of which make your gameplay scripts do completely unexpected things (and even crazier things with “real” physics after you’re getting 2 FPS…) . I would say that 40-50% of our development effort is playing the game in-browser to tweak and tune based on WebGL.
Then… you give it to users. Who do the kinds of things you didn’t test and now you have to improve your gameplay scripts to handle because the robot does crazy things now:
Soon we’ll be adding Python support to VRC Virtual Skills and will get to see what fun new “unexpected features” pop up as well 
- hope this provides some insight into the development experience.
Are you thinking about making an application instead of just browser in the future?
I’m curious, in many video games; physics, enemies or objects cheat. Where they aren’t following the same set of rules as the user, but it looks like they do. For example, an enemy might have more health or do more damage, because replicating true human actions isn’t feasible, and the user will be easily able to defeat the enemy otherwise.
I’m wondering if (or is already), the program should cheat to create a “more authentic” experience, without replicating real world physics. Such as the robot snapping to the ground and platform (instead of gravity), because there is almost no reason for it to leave the ground otherwise. I’ve noticed that the robot snaps to the goals when picking it up - which is a good thing, as it eliminates some of the randomness/absolute precision that would be require otherwise.
Sorry if I’m being tiresome, I’m really curious. 
Yes, part of the longer plan is to embed VR Skills directly within VEXcode V5 / IQ to be able to take advantage of more computing resources.
That’s what we’re doing with a lot of the video game “magic” I spoke of. It’s running an internal script to control the logic and movement rather than relying on a physics engine for a number of the game elements - such as how the rings “magically” snap into the fork arms on Moby rather than trying to have to programmatically perfectly align picking up individual rings.