Main controllers have six critical scripted parts: system memory, user memory, the audio controller, the door, the fan controller, and the light controller. The first three are mandatory; the last three are not. In most newer controllers the door, fan, and light scripts are kept in one prim, but for various reasons these may be missing or located elsewhere. A lot of pain can be skipped by getting your hands on a classic DAX/2 main controller to chop up, as the DAX/2 was designed to be much more customizable than other systems.
Basics: To set up a new controller, the easiest way is to locate the user memory and audio controller from an existing system, unlink them and the root prim from the rest of the controller, and re-link them to your new casing. (Alternatively, you can relocate the prim contents; just remember to copy the prim names and descriptions too.)
Lights scripting (flicker): For adding light effects, we recommend using the _flicker-autoconf script from the NS Extra Resources kit, which contains instructions for modifying the script to be used for controllers (a single line needs to be uncommented.)
Screen setup: Holographic menus like the ones on the XSU, DAX/3, and Aegis are animated by additional specialized code in their door and lighting scripts. Reproducing this is fairly tedious work. On the XSU and DAX/3, the "project" and "stop_project" light bus messages are used as signifiers to determine when to show and hide the screen, respectively, within the Flicker script. On the Aegis, the screen is visible whenever the door is open and the system's power is on; this is done within the hinge script.
There are several different screen geometries, which determine the scale, face, rotation, and offset parameters that the controller uses when applying menu item textures to the screen prims. The default screen geometry is the DAX/2's, which is planar and intended to be displayed on cube prims that have been sliced to have half their normal size; this is desirable for making the hardware more reliable. The chosen screen geometry is determined by the model name in the _oem file. However, the _oem model name also affects battery auto-positioning, so we strongly recommend using the DAX/2's screen layout if you plan on including a screen at all.
Screen elements are recognized by their prim names. For best results, copy the screen prims from the full-sized DAX/2. This also applies to the battery capacity and usage gauges, which are manipulated by slicing on most controllers (except the Scout.)
Battery positioning: Only a limited list of model types are recognized for battery auto-positioning. If you're willing to accept DAX/2 screen geometry (or no screen at all), then the best results will be obtained by entering a custom model and manually positioning your battery. To exploit auto-positioning properly, your controller needs to have the battery socket prim and root prim (ideally copied from an official controller) in the same orientation, size, and link number as the original. Advice for accomplishing this can be found here.
Battery door (hinge) scripting: You may be able to reuse an existing hinge script. The hinge scripts from most controllers, including the Aegis and DAX/2, will recognize changes to the door size upon reset. The hinge scripts from the XSU and Hephaestus should not be used for this purpose, as they are much more extensively hardcoded to accommodate the particulars of their casings.
Basics: To set up a new controller, the easiest way is to locate the user memory and audio controller from an existing system, unlink them and the root prim from the rest of the controller, and re-link them to your new casing. (Alternatively, you can relocate the prim contents; just remember to copy the prim names and descriptions too.)
Lights scripting (flicker): For adding light effects, we recommend using the _flicker-autoconf script from the NS Extra Resources kit, which contains instructions for modifying the script to be used for controllers (a single line needs to be uncommented.)
Screen setup: Holographic menus like the ones on the XSU, DAX/3, and Aegis are animated by additional specialized code in their door and lighting scripts. Reproducing this is fairly tedious work. On the XSU and DAX/3, the "project" and "stop_project" light bus messages are used as signifiers to determine when to show and hide the screen, respectively, within the Flicker script. On the Aegis, the screen is visible whenever the door is open and the system's power is on; this is done within the hinge script.
There are several different screen geometries, which determine the scale, face, rotation, and offset parameters that the controller uses when applying menu item textures to the screen prims. The default screen geometry is the DAX/2's, which is planar and intended to be displayed on cube prims that have been sliced to have half their normal size; this is desirable for making the hardware more reliable. The chosen screen geometry is determined by the model name in the _oem file. However, the _oem model name also affects battery auto-positioning, so we strongly recommend using the DAX/2's screen layout if you plan on including a screen at all.
Screen elements are recognized by their prim names. For best results, copy the screen prims from the full-sized DAX/2. This also applies to the battery capacity and usage gauges, which are manipulated by slicing on most controllers (except the Scout.)
Battery positioning: Only a limited list of model types are recognized for battery auto-positioning. If you're willing to accept DAX/2 screen geometry (or no screen at all), then the best results will be obtained by entering a custom model and manually positioning your battery. To exploit auto-positioning properly, your controller needs to have the battery socket prim and root prim (ideally copied from an official controller) in the same orientation, size, and link number as the original. Advice for accomplishing this can be found here.
Battery door (hinge) scripting: You may be able to reuse an existing hinge script. The hinge scripts from most controllers, including the Aegis and DAX/2, will recognize changes to the door size upon reset. The hinge scripts from the XSU and Hephaestus should not be used for this purpose, as they are much more extensively hardcoded to accommodate the particulars of their casings.