A few finds from messing around this season, including some random fun facts.
vex::vision::codeis largely undocumented/unexplained. I believe these work similar to Pixy2 Vision Codes- Suprisingly,
vex::pneumaticsisn’t listed anywhere on VEX help resources (they recommend usingdigital_outinstead). This offers an easier abstraction overdigital_out. vex::this_thread::sleep_for();offers an alternative API tovex::task::sleep, which better matches the standard library implementation of threads.- Headers for libv5rt can be easily accessed via the vscode extension (since
lv5rt.ais a static library). api.vexcode.cloud seems to be generated on these headers using doxygen (or something similar). These include the undocumented C API, but not the actual private API (v5_apiprivate.his omitted from the actual production distribution of the V5 SDK). - The actual entrypoint for the V5 API is actually
v5_cpp.hand notv5_vcs.h.v5_vcs.hseems to be included invex.has a relic of the older VEX coding studio program. vex::competition::bStopAllTasksBetweenModes- For some reason
vex::inertial::getTurnTypeis marked as protected, making it impossible to tell which direction the gyro of an inertial sensor reads as positive. - VEXCode Pro is written using nw.js and uses Monaco for its internal editor.
- This is documented, but not well known.
vex::triport::installedallows you to get the status and type of a triport device, similar to how smart port devices have an installed method. vex::controller::axis::positionreturns integers from [-100, 100], whilevex::controller::axis::valuereturns integers from [-127, 127]. This isn’t really listed anywhere, and could be a footgun if you use value instead of position.