Back to HomeThe Modular Vehicle Platform (MVP) is a standard for LSL scripts used by the NTBI Group to create vehicles under various brands. The below reference guides explain how the MVP scripts are designed and how third-party scripts can control and interact with them.
MVP is currently only used for land vehicles, but other vehicle types may be added in the future.
The MVP scripts are currently closed-source and limited to vehicles released by the NTBI Group only; they are not available for sale to other vehicle builders.
This documentation presumes you are familiar with editing objects, notecards, and basic LSL.
¶ Structure
MVP vehicles are defined by a build, a config, and parts.
¶ Build
An MVP build constitutes the following information loaded from the "MVP:Build" notecard:
- Camera parameters (position, rotation, behavior)
- Dynamics parameters (acceleration, braking, handling, transmission)
- Other miscellaneous parameters
To reduce development time, encourage modding, and simplify cross-model updates, MVP limits the use of hard-coded variables wherever possible. Instead, the Build Loader script loads these build parameter values directly into LSL's persistent llLinksetData* functions, where they can be read or modified by any other script.
The "MVP:Build" notecard can contain parameters for the following special types of build parameters:
¶ Camera
The Camera build parameters define cameras that can be used by the driver and passengers while seated. The Seat scripts control the seated avatars' cameras based on these values.
Camera build parameters are defined as build notecard parameters in the following format:
Camera:
name=json
| Parameter | Value |
|---|---|
name |
MUST be the name of the camera. |
json |
MUST be a JSON object with the following elements:
|
¶ ConfigApplier
The ConfigApplier build parameters instruct the Config Applier script how to interpret and apply visual config parameters.
ConfigApplier build parameters are defined as build notecard parameters in the following format:
ConfigApplier:
config_param=operations
| Parameter | Value |
|---|---|
config_param |
MUST be the config parameter that triggers this ConfigApplier. When this config parameter's value is modified, the new value is loaded into the accumulator register and the Config Applier script runs the operations in operations. |
operations |
MUST be a semicolon (";") delineated list with one or more operations to perform, as well as any operation parameters, if any. The Config Applier script processes this list from left to right. |
The following operations are supported:
| Operation | Additional Parameter(s) | Description |
|---|---|---|
b |
build_parameter |
Loads the value of a build parameter into the accumulator. |
c |
config_parameter |
Loads the value of a config parameter into the accumulator. |
r |
register_name |
Loads the value from a register into the accumulator. |
w |
register_name |
Writes the value from the accumulator into a named register. If the register does not exist, it is defined automatically. |
! |
n/a | accumulator = !accumulator; |
& |
i |
accumulator = accumulator & i; |
- |
n/a | accumulator = -accumulator; |
+ |
i |
accumulator += i; |
&& |
register_name |
Loads value of register_name as register_value, then:accumulator = accumulator && register_value; |
|| |
register_name |
Loads value of register_name as register_value, then:accumulator = accumulator || register_value; |
==s |
s |
accumulator = accumulator == s; |
alpha |
prim;face;max |
Sets the alpha (0.0-1.0) of the numbered face (-1 for ALL_SIDES) on the closest prim to root named prim. The rendered alpha is scaled by max (so that max of 1.0 results in a range of 0.0-1.0, 0.75 results in a range of 0.0-0.75, etc.). |
map |
prim;face;x;y;diff |
Uses the value in the accumulator as the index to show on a spritemap with diff diffuse texture UUID, x horizontal frames, and y vertical frames on the numbered face (-1 for ALL_SIDES) on the closest prim to root named prim. Frames are ordered left to right, then up to down (same as llSetTextureAnim), starting at 0. |
For example:
ConfigApplier:antennas=&;1;alpha;Antennas;0;1.0;c;antennas;&;2;!;!;alpha;Antennas;1;1.0
decodes as follows:
- ConfigApplier:antennas= - Run this operation when the "antennas" config parameter is modified. Loads the value of the "antennas" config parameter into the accumulator. (For the purpose of this example, assume "antennas" is a bitfield where 0x1 and 0x2 represent two different antenna options.)
- &;1; - Runs a bitwise AND between the accumulator and 1. Results in 1 if 0x1 is present in the "antennas" config parameter, or 0 if not.
- alpha;Antennas;0;1.0; - Sets the alpha of face 0 on the closest prim named "Antennas" to root in a range from 0.0 to 1.0 based on the value in the accumulator. Since the accumulator is either 0 or 1, this means that face 0 of "Antennas" is shown if 0x1 is present in the "antennas" config parameter, or hidden otherwise.
- c;antennas; - Resets the accumulator to the value of the "antennas" config parameter to start over.
- &;2; - Runs a bitwise AND between the accumulator and 2. Results in 2 if 0x2 is present in the "antennas" config parameter, or 0 if not.
- !;!; - Runs NOT twice on accumulator, which normalizes the value to a boolean. This converts the 2 or 0 from the last step into a 1 or 0.
- alpha;Antennas;1;1.0 - Sets the alpha of face 1 on the closest prim named "Antennas" to either 0.0 or 1.0 based on the value in the accumulator. Since the accumulator is either 0 or 1, this means that face 1 of "Antennas" is shown if 0x2 is present in the "antennas" config parameter, or hidden otherwise. Note that there is no closing semicolon since this is a semicolon delineated list.
¶ Exhaust
The Exhaust build parameters provide the Engine script with a list of positions for exhausts.
The Engine script checks for child prims named "Exhaust" and adds them to a list of eligible exhaust emitter prims. (There should be enough "Exhaust" prims in the linkset to handle the maximum possible number of exhausts using the available configurations.) Then, the Engine script sets the exhaust prims' particle settings to show different levels of exhaust depending on the engine power.
Exhaust build parameters are defined as build notecard parameters in the following format:
Exhaust:
name=json
| Parameter | Value |
|---|---|
name |
MUST be the name of the exhaust point. |
json |
MUST be a JSON object with the following elements:
|
¶ Theme
The Theme build parameters provide the Config Applier with a list of one or more default themes.
Theme build parameters are defined as build notecard parameters in the following format:
Theme:
name=json
| Parameter | Value |
|---|---|
name |
MUST be the name of the theme. |
json |
MUST be a JSON array of JSON objects, each with the following elements:
|
¶ ThemeApplier
The ThemeApplier build parameters instruct the Config Applier script how to interpret and apply config parameters that match the specified name.
ThemeApplier build parameters are defined as build notecard parameters in the following format:
ThemeApplier:
zone=json
| Parameter | Value |
|---|---|
zone |
MUST be the config parameter that triggers this ThemeApplier. When this config parameter's value is modified, the Config Applier parses it and applies the texture data in the config value. |
json |
MUST be a JSON array of JSON objects, each with the following elements:
|
¶ Config
An MVP config is the data that defines its exterior and interior themes, equipment options, access control settings, and whatever other options the builder wants to incorporate into the vehicle. These values are also stored in llLinksetData*, but the MVP scripts do not generally write them. In NTBI vehicles, the NorCloud script automatically synchronizes the configuration - default or modified - with NBS's NorCloud server, which also allows the vehicle to use the NorCloud Setup web configuration interface.
¶ Parts
MVP parts are child prims that have defined part data encoded into the prim's name and description. Parts are segregated by type, which can be any of the following:
- Door and Subdoor: prims treated as doors by the Doors script
- Stores hinge axis, door behavior, sounds
- Seat: prims treated as seats by the Seat scripts
- Stores position, associated door, available cameras)
- Wheel: prims treated as rolling wheels by the Environment script (for road contact detection) and the Drivetrain script (for steering and suspension movement)
- Stores position, rotation range, suspension range