 Hello, everyone, and welcome to the 5.30 to 6.00 p.m. session of the 2023 Open Simulator Community Conference. In this session, we are pleased to introduce the presentation Supercar, a versatile and low-impact land vehicle scripting system. Our speaker is Kuga Rajal. Kuga Rajal is an active content creator, and he assists with the Open Simulator core development. Let's check out the website found at conference.opensimulator.org for speaker bios, details of the sessions, and the full schedule of events. The session is being live-streamed and recorded, so if you have questions or comments during the session, send your tweets to atopensimcc with the hashtag pound OSCC23. Welcome, everyone. Let's begin the session. Hi, everybody. I'm going to present an overview of the Supercar land vehicle scripting system. And Supercar is an open-source, versatile, low-impact land vehicle scripting system that has been in development for about eight years. The system supports a wide range of creative options and has been tailored for low lag, ease of upgrades, and installation simplicity. It is compatible across all V2 VR grids and physics engines, primarily Bullet and U-Bode. The project started in 2015 during an Open Simulator project at Burn2, the Burning Man Regional and Second Life. The Burn2 team wanted to build a standalone Open Simulator version of their art festival so that it could be demoed offline from a laptop at the real-life Burning Man event. One of my tasks in that project was to import a selection of their art cards into Open Simulator, and the search for a compatible car script became central to that effort. After reviewing a number of script options, I settled on a modified version of Shin Injin's Supercar project. After the event was over, that script became the basis of a long-term project. Shin was not planning to develop the project any further after 2015. And in 2016, by permission, I forked the project and started a GitHub page where it has resided since. The scripting system has always been targeted primarily for Open Simulator while maintaining compatibility with Second Life. Also at that time, I established a roadmap and goals for the script development as follows. First I wanted to merge the best features of all the car scripts into a single script which can handle the needs of all the cars. We had a large collection initially with many different types of scripts, good and bad and with various issues, and we wanted an easier way to maintain it and fix the bugs. We needed a simple method to update the scripts across all the vehicles without having to hand-edit or transfer any of the settings. The script also needed to be sufficiently low-lagged to work with multiple cars operated in regions simultaneously and already full of scripted art and near-alvatar capacity. Finally, it needed to be easy to install and configure for people not familiar with scripting, allowing people to focus on design and creativity. Many improvements and enhancements were added over the years. Highlights include the following. The initial release of the script merged the best features of a variety of car scripts and allowed us to use a single script for all the vehicles. An optional note card configuration feature was added. If the configuration note card is present in the contents of the car, the script uses the settings in the note card and ignores settings within the script. This allows the script to work standalone, but we always recommend using the note card so that script updates such as bug fixes can be a simple drop-in replacement without having to hand-transfer or hand-edit any settings. Initially, the wheels required separate scripts to turn and stop the wheels in response to driver controls. And more recently, the script has been reworked so that no wheel scripts are required anymore, and all wheel movement is managed by the core script. One of the primary goals is to make the scripting system easy to use for non-scripters and less experienced builders. The process to set up rotating wheels, especially mesh wheels, was historically the most difficult part of the scripting system and where a lot of people really got hung up. A recent development has been to use a series of dialogues and visual feedback to complete the wheel setup without requiring any script knowledge, any script editing, math calculations, or guesswork. A temporary script runs through the dialogues, writes the configurations to the wheels' primed descriptions, and then deletes itself. The core script then reads in the configurations and manages all wheel movement. In many cases, the script count of all of the cars as a result of this change went from five scripts per car to one script per car. Low impact has always been one of the most important features. Development has been an iterative process, adding only features that are needed and thinning out features when possible to keep memory footprint low. Features needed for certain use cases were sometimes moved to separate scripts, keeping the core script as thin as possible. There were many performance optimizations along the way as well. For example, LLGetVel, where it queries the server for the velocity of the car, was actually a source of significant lag and was present in the original engine script and many others that you find around in script archives. We decided to remove it from the core script control loop and since it's only used with race car HUD, we moved that feature to the race car script since it's only needed for race car applications. Another important feature on low lag is how the script manages child prim types to minimize impact on the server. When the script initializes, it reads in the physics types of all the child prims and stores them in memory. When the driver sits to drive the car just before the car goes physical, the script changes all the child prims to physics type none. The server then only needs to make physics calculations on the root prim, reducing CPU cycles. When the driver stands, the script restores the original physics types to the child prims. A reserve prim name can override this behavior and allow the prim to remain physical for special applications that require it. Add-on scripts provide extra functionality, such as headlight switching, managing passenger sit animations. It's common to use a one-to-one correspondence between script and prim, dropping the script into the prim that's to be affected. We added the option to control some key functions across all the prims with a single script to reduce the total script count on the car, such as managing all headlights and brake lights with a single script or managing all passenger animations with one script. Server impact has been evaluated occasionally by watching script CPU and memory usage in a controlled setting. Script CPU is spiky during use and is sometimes hard to quantify. Running several instances of the script or driving several cars concurrently can be useful to get a more reproducible results for aggregate CPU usage and for simulator dilation percentage. Then A-B tests can be reproduced more consistently. The configuration note card contains all the user-defined settings for the core script and the short explanation for each. The following highlights a few of them. The core script has predefined speeds and turning radio that work well for the average size vehicle. Very large or very small vehicles, however, can benefit by using custom turning radii for a more realistic driving experience. These can be added to the configuration note card as an option. The number of gears available to the driver is also configured. While there's normally not a need to adjust speed settings for each gear, this option is also available. Different sounds can be defined in the configuration to trigger or loop with various driver controls such as forward, idle, start, stop, et cetera. Driver permissions can be set a number of different ways. It can be configured for owner only, group only, or for anyone to drive. There's also a whitelist option that allows driving for a list of avatar UUIDs. A few features have been added to the solve common problems with land vehicles. One example is that the vehicle is often left in a different location than when it started. Visitors come drive a car and then leave it somewhere else and then the owner is like, where's my car? So the script solves this with an auto park option that causes the car to park itself back to a predefined location after a set time interval. And this is triggered when the driver stands. A local chat message informs people nearby that the auto park is engaged so they have the opportunity to take control before the car relocates. The auto park is canceled if a new driver takes control before then. Another scenario we addressed is that of a bus which makes periodic stops to let people off and bring people on board. Since child frames are set to physics type none while driving, walking on and off the vehicle or finding a place to sit can be problematic. A bus mode option in the configuration file allows the driver to touch the vehicle to temporarily turn off physics and restore child prim types while remaining seated, making walking on and off the bus much easier. This can also trigger the temporary deployment of a boarding ramp while temporarily parked. Another requested feature was compatibility with AV sitter. With this compatibility mode enabled the core script does not manage any avatar animations. A number of add-on scripts are included with the scripting system. Some of these were separated out from the core script at some point and others were added to solve problems or to add creative options. Race car features which were part of the original Shin engine script have been moved to a separate script now to keep the core script as lean as possible. A speedometer hood with button controls is included with the kit and along with an associated script to manage that. And we also include an alternate version and a separate version, a separate add-on script manages the temp attached deployment and communication with that hood. There are add-on scripts to manage such things as headlights, brake lights, passenger sits, opening and closing doors, honking horns and more. In cases where we saw multiple instances of the same script being used on the same vehicle such as passenger sits and headlights, we include an alternate version that can manage that function across all the prims with a single script. Documentation that comes with the kit includes a full description of the link messages passed from the core script to the child prims. These can be used to trigger customizable actions on sit, stand, forward, reverse, stop and gear change. One creative use of this API was to assemble a series of prims to represent tank treads and then a custom script to activate a texture animation on those prims from the link messages. This creates the illusion that the vehicle movement is being caused by the tank tread motion. We set up a vehicle demo in the OSCC sandbox to demonstrate this and other link message API examples. The latest version of the script package and documentation are available at GitHub. The address shown on the screen here. You can also get a copy of this presentation from the giver boxes that have been set out either here at the presentation, keynote areas or at the sandbox or at the booth number six as well. At OSCC, car scripts are available at the presenter booth number six. And at the sandbox next to the demo vehicles. The script package is also available in world at the deep Playa grid with the address also shown there and also printed on the presentation transcript. You can test drive a wide range of vehicles at the deep Playa grid as well. I give occasional workshops in world by request and I will be in the OSCC sandbox on Sunday during lunchtime to answer any more detailed questions. If you have a vehicle that you would like to script up, bring it to the sandbox and I can help you get started. And with that, I think that finishes the presentation. If there are any questions, I'd be happy to take those. Thank you, that was a fantastic session. While we're waiting for questions, what made you get started with this? I know you explained that you took over the project and forked it, but was it the Burning Man 2 event? Is that what inspired you, the special cars? Originally it was. And then as I became more involved in Open Simulator, I realized I just really liked cars and I developed a pretty large collection of cars on my own in Open Simulator. And so I had an ongoing need to work with and improve the scripting system. I also became the Department of Mutant Vehicles lead at Burn 2, basically the, I'm in charge of the cars at the Virtual Burning Man Regional. And so I kind of use it both in my own region for the cars that I have there and for managing a large collection. I'm a custodian of about 70 different art cars that have been contributed by different members there. And so this script is useful for that as well. Oh, that's great, that's wonderful. Well, thank you for such a fantastic session. Yeah, go right ahead. And if anybody is still looking for a copy of the transcript with link information or landmarks to the demos, there's a cardboard box just in front of the podium now where you can click and get a copy into your inventory. Okay, well, I'm gonna jump into the car and the car does not move, but you'll be able to see and hear an example of some of the race car effects. Great, well, while you're doing that, I'll, there you go. There you go, all right, great. No, Tizzy, couldn't resist. Oh, that's fun. Well, thank you Cougar for an informative and interesting presentation. As a reminder to our audience, you'll wanna check out conference.opensimilar.org and see what's coming up on this conference schedule. We hope you've enjoyed today's conference and invite you to move to the Music Region at OSCC Music, where we will end the evening with three amazing artists beginning at 6 p.m. We also encourage you to look through the OSCC Expos for our sponsor and crowd funder booths and for all our speaker booths and their presentations. Thank you again to Cougar and to you, the audience.