ACS Custom HUD API Kit
  • Build your own Driver HUD, choosing which existing ACS functions to trigger
  • Route your own custom commands for your own custom scripts through the HUD connection without needing extra listens


  • Place ACS HUD Root script from the kit into your HUD object root, this will connect the HUD to the vehicle
  • Send a command from the existing command list below to the root as a link message on channel 100
  • Optionally create your own command(s) which will be passed from the HUD to vehicle and through the vehicle linkset for your own script to intercept

You can make your own custom ACS Driver HUD by using an ACS HUD Root script in your HUD root, and sending it commands via link messages. You can add your own functions as well if you have a little knowledge of scripting. The script creates a connection between the vehicle owner and the vehicle, or between the vehicle and guest driver if they are seated.

Make a custom HUD specifically for your vehicle with only the command buttons you need, or just make a really nice one that will work with any ACS vehicle and distribute it however you wish. You are free to share the HUD Root scripts with anyone, so it is no problem enlisting somebody to help you build a custom HUD.

You will need to provide your own HUD and script it to send commands to the ACS HUD Root script. There are numerous ways to go about this. Rez one of the ACS Driver HUDs on the ground and see how they are set up. You are free to raid them for parts, such as for the speedometers or the Fuel System fuel gauge.

Included in the API box are the old ACS 3.1 and 4.0 HUD button textures which you can use in designing your own HUD if you wish, but likely you will want to make your own textures.

The reason you cannot just say the commands in open chat directly to the vehicle is because of the connection the HUD Root script makes with the vehicle. The vehicle only opens a listen when prompted by the HUD, therefore your parked vehicle is not running a bunch of open listens and creating lag. The HUD system is designed like the menu system, the owner can always control it even from remote, but a guest driver can also connect a HUD if seated on the unlocked vehicle.

If you do build your own HUD, you may wish to make sure it is transferable, so that drivers of unlocked vehicles can receive a HUD if it is served from inside the vehicle.


A HUD Root script must be placed into the root of your driver HUD. When you touch the vehicle while wearing the HUD, the HUD will connect to that vehicle. The HUD will disconnect if you touch another ACS vehicle or unseat yourself from the vehicle. When active, you simply need to send commands to the HUD root and the script will relay them to the vehicle. The HUD Root Script will relay the vehicle name/connection status and gear value through the HUD linkset, and you can use those messages to trigger events.

There are two versions, one that must be clicked to be turned on before it can be connected to a vehicle, and one that is always on. Just use ONE of these in the HUD root, not both

ACSv6.0 HUD Root Script - requires the HUD user to click on it to turn it on. This HUD script handles the touch if the owner touches the root, but it sends out link messages "on" and "off" on link channel 400 that can be intercepted by other root scripts to open/close custom menus, rotate the HUD, etc. Additionally, a "closed" message is sent on channel 400 when the HUD is turned off, or the owner dismounts a vehicle. This "closed" message can be used to close up any open custom menus you may have, or other purposes.

ACSv6.0 HUD Root Script B - This HUD script does not require the root prim be touched to "turn on" and activate it. It remains connected to the vehicle until you connect to another vehicle, dismount a vehicle, or take off the HUD.


The script will optionally display a floating text message over a non-root prim in the linkset named Status, and will also display the current gear number in floating text over a link named Gears. (Capitalization must match)

This status message of the vehicle name or "Touch vehicle to connect" message is also sent to the linkset on link channel 200. The current gear value is sent on channel 210. You do not need to use the floating text prim names, you can intercept the messages on 200 or 210 and do what you like with them, or ignore them alltogether.

The default "Touch vehicle to connect" message is taken from the HUD object description. If you leave the object description blank (a couple spaces or so), it will stay "Touch vehicle to connect", otherwise it will be whatever you put in the HUD object description of the HUD root prim.


To send commands to the vehicle, you will need to send a link message to the root prim on channel 100 with the command name as the message, for example:


For example you wish to trigger the vehicle horn sound, you would send the message "Horn" on channel 100 (capitalization matters for these messages):


If the vehicle is connected to the HUD, the vehicle horn sound will be triggered.

You can place the command in a touch event on a HUD button. To relay the name of the link as the command for example, name the button prim with the command and send the button name in the touch command:

touch_start(integer total_number)

Some example scripts are included in the wiki


Commands to send to the root prim to relay to a connected vehicle as link messages on link channel 100:
(Capitalization must match)


  • "Lights" turns on/off light
  • "Key" turns on/off engine
  • "Locking" locks/unlocks vehicle
  • "Horn" triggers horn sound
  • "Flight" turn on/off flight mode
  • "Turbo" turn on/off turbo
  • "NOS" triggers nitrous boost
  • "Shift DOWN" shifts gear down
  • "Shift UP" shifts gear up


  • "Position" triggers the vehicle > Position menu
  • "Park-" scrolls through the list of Park Animations and activates them if more than one park is installed
  • "Park+" scrolls through the list of Park Animations and activates them if more than one park is installed
  • "Passenger Menu" triggers the Passenger Prim menu if a Passenger Prim is installed
  • "Passenger Sit" turns on/off any Passenger Prim
  • "Eject" ejects any seated passenger
  • "Alarm", turns on/off the alarm
  • "Alarm Test" test sequence of the alarm system
  • "Hide" toggles the Hide/Show function
  • "StartParked" turns on/off the Start Parked feature
  • "Camera", triggers the camera menu
  • "Cam A", activates camera preset 1
  • "Cam B", activates camera preset 2
  • "Cam C", activates camera preset 3
  • "Menu" triggers the main menu
  • "Record" - records the current vehicle position
  • "Return" - returns the vehicle to the recorded position
  • "Align" - race align, aligns the vehicle to the closest 90 degree direction
  • "NOS/Recvr" toggles the NOS/Recvr setting
  • "Recover" - performs a vehicle recover lift
  • "Rev" - triggers the "Rev" sound
  • "Burnout" - activates burnout routine
  • "Transmission" toggles the Transmission style in engines that have the automatic transmission feature
  • "Shift Style" toggles the gear shifting keys
  • "Controls" - activates the > Controls menu
  • "Part+" - changes sculpt-changer prims to the next stored map setup.
  • "Part-" - changes sculpt-changer prims to the previous stored map setup.

Messages to adjust current seated position:

  • "Reset Rot"
  • "Tilt Down"
  • "Lean Left"
  • "Down XL"
  • "Up XL"
  • "Pos 2 All"
  • "Reset Pos"
  • "Tilt Up"
  • "Lean Right"
  • "Back XL"
  • "Forward XL"
  • "Reset All"
  • "Left XL"
  • "Left"
  • "Turn Left"
  • "Down"
  • "Up"
  • "Right XL"
  • "Right"
  • "Turn Right"
  • "Backward"
  • "Forward"


  • "Flasher", on/off lights
  • "Flash & Siren" on/off lights & siren

The "Touch to connect" and vehicle name text appears on floating text over a prim in the linkset named "Status"
The current gear value will appear in floating text over a prim named "Gears"
In the stock ACS Driver HUD those prims are invisible. Rez one on the ground to see.


  • The HUD Root script can optionally trigger three custom sounds if you add specially named sound files to the HUD root:
  • click - if present, this sound will trigger when a command is sent to the HUD root
  • root - if present, this sound will trigger when the owner clicks directly on the HUD root (like when turning the HUD on/off)
  • connect - if present, this sound will trigger when the owner HUD connects to the vehicle


Place this one in a prim in the HUD linkset. When you touch that prim it will send the "Key" (ignition) command to the HUD Root script. If the vehicle is connected, it will relay the signal to the vehicle:

    touch_start(integer total_number)


Use the HUD connection system to pass your own commands to the vehicle to control your own added custom scripts

If you route a custom command through the Root HUD script on channel 100, it will be transmitted to the vehicle and sent through the vehicle linkset on link channel 500. This allows you to add functions that use the listen connection already established between the HUD and the vehicle, without needing to open or leave open more listens.

If you have a custom non-ACS script in the vehicle that needs a trigger command, have that script monitor for a link message on channel 500 inside the vehicle and for your custom command. This way you can add extra HUD functions without having to create new open listens on the vehicle.

If you sent the "custom command" message in your HUD to the HUD Root on link channel 100, in your custom script inside the vehicle, your link message section might look like:

link_message(integer sender_num, integer num, string str, key id)
          if (num == 500 && message == "custom command")
                              llOwnerSay("Custom command received by script!");

Use custom scripts with listens talked to from added HUD buttons:
This is a less recommended method as the vehicle keeps more open listens.

If you wish to trigger a non ACS script that is in your vehicle that listens directly, you can add a prim or function to communicate directly with your own script by simple sending a command on whatever channel the non-ACS script is listening on.
For example, if you have a particle script that is triggered by saying on on channel 55 in chat:
/55 on

You could set up your button touch event to be:


Many script set up with a listen will filter so they ONLY listen to the object owner. You will want to change your listen in the script to listen for the owner's objects, as they come from the object UUID, not the owner's as when the owner speaks directly in chat.

Usually a listen command in a script that filters by owner looks like this:

listen_id = llListen(55, "", llGetOwner(), "");

This filter prevents other people from triggering your script when they are trying to trigger their own.
With this filter, the script listening on channel 55 will not hear your HUD the same as if you say a message on channel 55, so you must change your custom script's listen to listen to anything, then later match the incoming message to the object owner:

listen_id = llListen(55, "", "", "");

Then filter your listen answers by object owner key like this:

listen(integer channel, string name, key id, string message)
             if (llGetOwnerKey(id)==llGetOwner())

Now only messages sent from an object owned by the owner (in this case the HUD) will be processed.