DMX Functionality (Artemis DMX Tools):
Mission Tracking (Artemis Mission Browser):
Advenced Mission Scripting
Artemis Bridge Tools currently assumes Artemis SBS is in one of the following locations:
If it is, installation will complete normally.
If your installation directory is not one of the above (e.g., you have some other Steam directory), Artemis Bridge Tools can still be installed, but the installer will warn that Artemis was not found, and Artemis Bridge Tools won't be fully enabled for use until you install the mod to one or more Artemis directories, which you can do as follows:
If asked "Do you want to allow this app to make changes to your PC?" then click Yes.
Note: if you later want to completely uninstall Artemis Bridge Tools, you should do so from the Control Panel ("Uninstall a program"). Currently uninstalling fails if attempted from the System "Apps & features" page, but works fine from Control Panel.
Mission Browsing:
DMX Basics:
Fancy DMX Effects:
DMX Device Types:
Advanced Mission Scripting:
If you later need to edit the DMXcommands.xml file manually or with any other program, you will need to use a file in the "%LocalAppData%\ArtemisBridgeTools\" directory (where the filename is listed in the ActiveProfileFileName.txt file there), NOT the one in your Artemis\dat directory. If you uninstall Artemis Bridge Tools, your active DMXcommands profile will be put back into your Artemis\dat directory.
Artemis Bridge Tools versions prior to version 3.18 required you to represent such a device as if it were multiple devices, each with 4 or fewer channels. As of version 3.18, this workaround is no longer needed, and it can be configured as a single device.
Let's take an example of an 8-channel device such as this light. The manual page lists the 8 channels as:
The first three channels are special, and usually all you want to do is treat it as a simple full color light. So in this case, you'd want to set CH1=0 (No macro function), CH2=0 (All color), CH3=0 (no speed). These are referred to in Artemis DMX Editor as "Other" channels, as opposed to (master) Intensity/Brightness, Red, Green, Blue, or White channels.
So to configure this light:
At this point, you can now add commands for any other cue, set the device to your RGBW light, and observe the effects.
You can either manually trigger individual cues to observe the effects, or use one or more console simulators that simulate what cues are triggered in response to various game controls.
To use the console simulator(s):
To manually test individual cues:
The log file can be found in "%LocalAppData%\ArtemisBridgeTools\ArtemisLog.txt" and one easy way to find it is:
Events are logged using the format illustrated below where the first column is number of seconds since start, second column is the cue name, and 1 means set, and 0 means cleared, e.g.:
117.640 ENERGY_20
= 1
139.906 ENERGY_20 = 0
You can view DMX cues in real time over a socket, so that you can consume them programmatically, such as from a Python script, or display them on your screen. For example, to display them on your screen, you might connect to Artemis SBS using a command such as "telnet localhost" (the telnet client comes with Windows but is an optional component and must first be enabled using "Turn Windows features on or off" via the Windows control panel).
To view the events in real time, you will need to connect to that port after starting Artemis. Only one connection to that port at a time is supported.
Events are logged using the format illustrated below where the first column is number of seconds since start, second column is the cue name, and 1 means set, and 0 means cleared, e.g.:
117.640 ENERGY_20
= 1
139.906 ENERGY_20 = 0
You can also use a socket from your own program (e.g., a Python script) to trigger custom DMX cues. The syntax is "dmxset cuename[=value]", where cuename is the name of one of the custom cues (CUSTOM_{EVENT,STATE}_{1-4}), and value is 0 or 1. If value is not present, it defaults to 1. Some examples are:
dmxset CUSTOM_STATE_1 = 1
dmxset CUSTOM_STATE_1=0
dmxset CUSTOM_EVENT_1
Event cues need not be cleared, they will be triggered each time the value is set to 1.
Note that only DMX cues that are used in one's command profile will be logged. To enable logging of specific cues that are not otherwise used by other DMX devices, you can add DMX commands with no devices associated for those cues.
New versions of Artemis often change the format of messages sent between the server and clients such that they are no longer compatible. Since Artemis Bridge Tools watches these messages, it needs to understand the format in order to support new DMX cues. Artemis Bridge Tools detects the version of Artemis and by default only enables non-native DMX cues if it recognizes the version. This means that when a new version of Artemis comes out, any non-native cues won't work by default, even if the message formats haven't changed. You can manually override this, and tell Artemis Bridge Tools to try to parse the messages anyway, in the hopes they haven't changed. If this works, great! If not, it will cause Artemis to crash pretty quickly once a mission is started, and you can go back and undo it and just wait for the next version of Artemis Bridge Tools to come out (usually within a week of a new release of Artemis). To change the maximum Artemis version supported:
That's it! You can now run Artemis normally and the non-native cues will be enabled.
Artemis SBS itself is limited in the ability to create a gradual transition into a continuous effect, but Artemis Bridge Tools makes this much easier by allowing any continuous effect to have a set of 0 or more "entrance" timeblocks that play only once at the beginning of the effect, and a set of 0 or more "exit" timeblocks that play at the end of the effect. There may be multiple entrance and exit timeblocks if desired, but any entrance timeblocks must occur at the beginning of the command, and any exit timeblocks must occur at the end of the command. For example:
<event type="NORMAL_CONDITION_1" continuous="yes">
<timeblock mseconds="1500"
phase="entrance">
<!-- Various setvalues go here that
only happen once when a game is started... -->
</timeblock>
<timeblock mseconds="1000">
<!-- Various setvalues go here for
the normal effect after any entrance timeblocks complete -->
</timeblock>
<timeblock mseconds="1500"
phase="exit">
<!-- Various setvalues go here that
only happen once when a game is ended... -->
</timeblock>
In the example above, when a game is started, any entrance timeblocks play first, then the normal timeblocks play in a continuous loop until the game ends, at which point the exit timeblocks play. This illustrates that entrance/exit timeblocks on a continuous command obviate the need to have separate event cues (such as GAME_OVER, which didn't work anyway) that occur when some state cue is set or cleared. So many event cues, such as PLAYER_SHIELDS_{RAISED,LOWERED}, become redundant in this mechanism, meaning you can either use them normally OR just use entrance/exit timeblocks on the associated state cue.
Let's look at two common cases of desired effects:
1) an effect that
gradually moves in across a series of lights, and
2)
an effect that gradually changes all lights in a set together
Say you have a set of lights that are all white under NORMAL_CONDITION_1 or all purple under WITHIN_NEBULA. When you raise shields, you want them to transition to blue in series, one every 500 ms, and then use a continuous blue effect for all those lights with PLAYER_SHIELDS_UP. Without Artemis Bridge Tools, this is problematic since all the lights will go blue at the same time because PLAYER_SHIELDS_UP masks the existing condition (NORMAL_CONDITION_1 or WITHIN_NEBULA) immediately upon raising shields so there's no way for PLAYER_SHIELDS_RAISED to let any lights use the pre-existing condition. To do so gradually and allow the existing effect to remain on some lights as you override them sequentially, you would need to delay the PLAYER_SHIELDS_UP effect to begin at the end of the PLAYER_SHIELDS_RAISED.
To solve this, you can use an entrance timeblock with a duration of 1500ms (assuming your PLAYER_SHIELDS_RAISED duration is 1500ms) to delay the normal effect until then. You can either use PLAYER_SHIELDS_RAISED normally and use an empty (no devices/setvalues) entrance timeblock in your PLAYER_SHIELDS_UP, or you can simply omit PLAYER_SHIELDS_RAISED and just put your shields-up effect in the entrance timeblock of PLAYER_SHIELDS_UP.
This scenario is easy to accomplish with Artemis DMX Editor, as follows:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
Say you have a light (or set of lights) that are all white under NORMAL_CONDITION_1 or all purple under WITHIN_NEBULA. When you raise shields, you want it to (say) slowly transition (or fade) to blue. Without Artemis Bridge Tools, this is problematic since the PLAYER_SHIELDS_RAISED and PLAYER_SHIELDS_ON cues will take effect and override the base condition immediately, and transition from whatever the start color is for the first timeblock.
Instead, we want to cause the PLAYER_SHIELDS_RAISED effect (or the entrance timeblock of PLAYER_SHIELDS_ON) to slowly transition from transparent to opaque, so that it will fade from white to blue, or from purple to blue, depending on the previous color. This is easy to accomplish with Artemis DMX Editor, as follows:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
Let's now look at a more complex example. Say you have a set of front shield lights that form a front shield strength gauge when shields are up. When you raise shields, you want the lights to gradually brighten from the previous color to whatever colors the gauge would normally show. When the shield strength level changes due to damage or repair, you want the lights to gradually transition to their new color. This is easy to accomplish with Artemis DMX Editor, as follows:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
If you have an effect you want to occur only while two states are both true, or only when one is true and the other is false, you can now do this. For example, say you want one effect to play during forward impulse, and another one to play during reverse impulse, and neither to play when one is at a full stop. The stock Artemis SBS cannot do this, since HELM_IN_REVERSE plays even when at a full stop. Instead, you want to create one (say) IMPULSE_20 effect when REVERSE_IMPULSE is true, for the forward impulse effect, and another IMPULSE_20 effect when REVERSE_IMPULSE is false, for the reverse impulse effect. (See the New DMX Cues table for further discussion of the difference between the native HELM_IN_REVERSE cue and the new REVERSE_IMPULSE cue.) Artemis Bridge Tools allows a command to optionally have an "if" condition to test before making the command become active. Currently the only condition supported is a simple check whether another State cue is true or false, which looks like this in your command profile:
<event type="IMPULSE_20" continuous="yes"
if="REVERSE_IMPULSE">
<!--reverse impulse-->
...
</event>
<event type="IMPULSE_20" continuous="yes"
if="!REVERSE_IMPULSE">
<!--forward impulse-->
...
</event>
You can configure this in Artemis DMX Editor as follows:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
Artemis DMX Editor supports easily creating a number of different chase effects, from a single moving light to a growing/shrinking line.
First, make sure you've configured your light strip:
You're now ready to create a chase effect:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
A "gauge" is when you have a set of lights that together indicate the value of something via how many lights are on, similar to the number of "bars" of signal strength on a cell phone. While you can create such effects manually, it often involves significant work and experimentation. Artemis DMX Editor currently allows you to easily create gauges for the following values by bulk-adding all the appropriate commands for you:
To easily add a gauge for one of the above values:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
A ship's Accent Color can be changed inside the game by clicking the Customize button on the server or on the Helm client, and then changing the color slider. Now we'll see how to set a light's color to match that color. Say you have previously created a light named L1, and you want this bridge light to always be the ship's accent color so it's visible even before the game begins, to provide ambient lighting. So in this example, we'll need to use ALWAYS_ON, since if you use NORMAL_CONDITION_1 it will only be visible when a simulation is in progress.
You can do this as follows:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
Within the Test dialog, you can change the Accent Color via a slider at the bottom, to observe the effects.
The following Color Names can be used to map to relevant Weapons console values:
In addition, the following Engineering values can be mapped to named colors, using the same names used in mission scripts, as shown in the following table.
Engineering Values
| System | System Heat Color Name | System Energy Color Name | System Coolant Color Name |
| Beams | systemCurHeatBeam | systemCurEnergyBeam | systemCurCoolantBeam |
| Torpedoes | systemCurHeatTorpedo | systemCurEnergyTorpedo | systemCurCoolantTorpedo |
| Weapons | systemCurHeatTactical | systemCurEnergyTactical | systemCurCoolantTactical |
| Maneuver | systemCurHeatTurning | systemCurEnergyTurning | systemCurCoolantTurning |
| Impulse | systemCurHeatImpulse | systemCurEnergyImpulse | systemCurCoolantImpulse |
| Warp | systemCurHeatWarp | systemCurEnergyWarp | systemCurCoolantWarp |
| Front Shield | systemCurHeatFrontShield | systemCurEnergyFrontShield | systemCurCoolantFrontShield |
| Read Shield | systemCurHeatBackShield | systemCurEnergyBackShield | systemCurCoolantBackShield |
Now we'll see how to set a light's color to match a named color from one of the above tables. Say you have previously created a light named L1, and you want this bridge light to be set to a color based on the beams heat level, where you want (say) green to be 0% heat, and red to be 100% heat. So in this example, we'll need to use "systemCurHeatBeam" as the color name, and associate it with a (say) NORMAL_CONDITION_1 cue so that it is active whenever the simulation is in progress.
You can do this as follows:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
Within the Test dialog, you can change the game values by clicking on the Engineering button and changing the relevant values, to observe the effects.
Often you want the color or brightness of a light to indicate the value of some important quantity. While you can create such effects manually, it often involves significant work and experimentation. Artemis DMX Editor currently allows you to easily create stacked effects for the following values by bulk-adding all the appropriate commands for you:
To easily add a stacked effect for one of the above values:
That's it! You can now use the Test feature of Artemis DMX Editor to observe the effects, or just exit and run Artemis SBS normally.
Currently any sound file (.mp3, .wav, .wma, .au, .mid, and possibly more) file can be triggered in response to a DMX cue (endless looping effects are not yet supported, however).
Let's say you have a sound file named Data_Hail.wav (a sound clip of Data saying "Captain, we are being hailed!") that you want to be played whenever an incoming transmission is received from an enemy, which the new DMX cues table tells us is the INCOMING_COMMUNICATION_PRI0 cue. This can be done as follows.
First we add an audio device as follows:
Next we need to associate a DMX value with the sound file, as follows:
Finally, we need to associate the sound with a DMX cue as follows:
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
The above steps will have created a command in your DMX commands file looking something like this:
<event
type="INCOMING_COMMUNICATION_PRI0">
<timeblock mseconds="1500">
<setvalue
index="16" value="3" change="0"></setvalue>
<!-- play Data_Hail on Audio -->
</timeblock>
</event>
In the above example, the audio device was created to use DMX address 17 (i.e., index 16), with the value 3 to indicate the sound file we selected. The change attribute should be 0 for sound effects, and the timeblock duration will affect the duration of the audio effect. The effect will be started when the timeblock begins, and will play until either the sound clip finishes, or another value is set on the audio channel, or the last timeblock of the command ends, whichever comes first.
A video file in AVI format can be triggered in response to a DMX cue (you can convert an mp4 file to an avi file for free at http://video.online-convert.com/convert-to-avi). The video can be played (in full screen mode) on any monitor attached to the machine running the main screen.
Let's say you have a video named IncomingTransmission.avi that you want to be played whenever an incoming transmission is received from an enemy, which the new DMX cues table tells us is the INCOMING_COMMUNICATION_PRI0 cue. This can be done as follows.
First we add a video device as follows:
Next we need to associate a DMX value with the video file, as follows:
Finally, we need to associate the video with a DMX cue as follows:
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
The above steps will have created a command in your DMX commands file looking something like this:
<event
type="INCOMING_COMMUNICATION_PRI0">
<timeblock mseconds="1500">
<setvalue
index="16" value="3" change="0"></setvalue>
</timeblock>
</event>
In the above example, the video device was created to use DMX address 17 (i.e., index 16), with the value 3 to indicate the video we selected. The change attribute should be 0 for video effects, and the timeblock duration will affect the duration of the video effect. The effect will be started when the timeblock begins, and will play until either the video finishes, or another value is set on the video channel, or the last timeblock of the command ends, whichever comes first.
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
To instead add only a single light, instead of all of them, do the following for step 5 above instead:
Note that this support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for such LED lights will also be removed.
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
Note that Enttec Pro support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for Enttec Pro controllers will also be removed.
If you have problem getting your Enttec Pro controller to be detected, or to work correctly, the "ftduutil.exe" utility in your Artemis Bridge Tools directory (e.g., "%ProgramFiles(x86)%\Artemis Bridge Tools\ftdiutil.exe") can be run from a command-line and may provide helpful diagnosis information.
Note that Art-Net* support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for Art-Net controllers will also be removed.
*Art-Net™ Designed by and Copyright Artistic License Holdings Ltd
The instructions below assume that you have previously installed the udmx.dll and libusb0.dll drivers that came with your controller, and that you have verified that your controller is working outside of Artemis (e.g., by using a utility that comes with your controller).
Artemis Bridge Tools will look for udmx.dll in the following locations and if not found, you'll get an "Error: can't load UDMX.dll" message when trying to use the uDMX controller:
To use the controller with Artemis:
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
Note that uDMX support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for uDMX controllers will also be removed.
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
Note that Velleman DMX support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for Velleman DMX controllers will also be removed.
To use Philips Hue lights, you will be configuring each Hue light by id. The id is always a number (e.g., "1", "2", "3", etc.), not the name (like "Living Room"), but you will be able to see the names as well during configuration.
From this point on, the DMX channels selected will control the Hue lights, whenever they are used from Artemis or Artemis DMX Editor. Note: Hue lights by nature transition between colors gradually, not instantaneously. As such, they work best with effects with change="0".
If you encounter problems, here are some troubleshooting steps to check:
Note that Philips Hue support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for Philips Hue lights will also be removed.
There are two kinds of LIFX light bulbs, ones that say "Designed for ALLSEEN" on the box and ones that don't (currently the white bulbs say "Designed for ALLSEEN" and the color ones don't, but this will change in the future as color ones will say that too). Artemis Bridge Tools supports both kinds.
To use a bulb that does NOT say "Designed for ALLSEEN" on the box:
To use a bulb that DOES say "Designed for ALLSEEN" on the box:
From this point on, the DMX channels selected will control the LIFX lights, whenever they are used from Artemis or Artemis DMX Editor.
Note that LIFX support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for LIFX lights will also be removed.
To use LimitlessLED lights, you will be configuring each light group as if it were a 3-channel DMX light. The group is always a number in the range 1-4. For best performance, you should obtain the IP address of your LimitlessLED bridge beforehand (e.g., look it up on your WiFi router, where in the list of attached devices the bridge will typically show up with a MAC address starting with AC:CF:23).
From this point on, the DMX channels selected will control the LimitlessLED lights, whenever they are used from Artemis or Artemis DMX Editor. Note: LimitlessLED lights used with LimitlessLED/Mi-Light bridges older than v6 require 100ms delay between being turned on and setting the color, and if you want to control multiple light groups they require 100ms delay when sending a command to a different group. Artemis Bridge Tools automatically handles this, but it means your lights can only change simultaneously when they are in the same group or on different bridges. This restriction does not apply to v6 bridges.
If you encounter problems, here are some troubleshooting steps to check:
Note that LimitlessLED support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for LimitlessLED lights will also be removed.
To use Nanoleaf Aurora lights, first configure the device for use with Artemis:
First, configure the device for use with Artemis:
From this point on, the DMX channel selected will control the WeMo switch, whenever it is used from Artemis or Artemis DMX Editor.
Now you can configure DMX commands to affect the WeMo switch. For example, say you want the switch turn on while a simulation is in progress, and turn back off at the end of the simulation:
That's it! You can now play Artemis and observe the effects, or use the Test Active feature of Artemis DMX Editor to test it.
Note that WeMo switch support is provided by Artemis Bridge Tools, so if you uninstall Artemis Bridge Tools, support for WeMo switches will also be removed.
Artemis SBS uses a standard API for talking to FTDI chips, which API is exposed by the ftd2xx.dll that comes with Artemis SBS.
Artemis Bridge Tools has five components, three for DMX purposes, and two for mission logging purposes:
To support the additional DMX cues, the custom ftd2xx.dll inspects Artemis protocol packets flowing between Artemis SBS and Winsock, so anything that is normally sent or received in an Artemis protocol message could be used to support new DMX cues.
To support mission logging, the custom ftd2xx.dll also detects starting a mission and starts ArtemisMissionLogger.exe which runs only while a mission is in progress. ArtemisMissionLogger.exe connects as another main screen console in order to get the ending stats or detect that the server has crashed.
To support advanced mission scripting, the custom ftd2xx.dll also inspects messages written to the mission log, to detect commands that should trigger additional behavior.
Upon installation, Artemis Bridge Tools backs up the stock ftd2xx.dll as "ftd2xx-orig.dll" so it can be automatically restored if Artemis Bridge Tools is uninstalled. The current DMXcommands.xml is also backed up as "DMXcommands-orig.xml", since it is replaced by a custom DMXcommands.xml file that tells Artemis SBS to put each DMX cue on a separate channel for use by Artemis Bridge Tools itself (this is required for the logging feature, for instance).
The %LocalAppData%\ArtemisBridgeTools\ directory contains the files used by the Artemis Bridge Tools components:
The following output Device Types are supported:
The same Virtual Input Device (i.e., DMX channels as used by Artemis) can be used by multiple associated output devices, if you want to mirror the same DMX commands to multiple devices (such as a DMX device and a log). However the combination of Device Type and Param should be unique for each device entry.
If you later replace a 3-channel light with a 4-channel light, or vice versa, Artemis DMX Editor can convert your DMXcommands profile for you. To do this, first create a new DMX device profile, then edit your command profile and switch the DMX device profile to the newly created one. At the prompt, select "Attempt to convert the Artemis DMX command profile from the old devices to the new devices".
The following DMX cues are added to the list of ones supported natively by Artemis SBS. See the DMX cues wiki page for more details on how DMX cues work.
See the fighter cockpit page for which cues (native and non-native) work in a fighter cockpit using Artemis Bridge Tools.
| Category | Event Tag | Type | Notes |
| General | MAIN_SCREEN_AFT_VIEW | State | Set when rear view is on main screen |
| MAIN_SCREEN_FORE_VIEW | State | Set when front view is on main screen | |
| MAIN_SCREEN_PORT_VIEW | State | Set when left view is on main screen | |
| MAIN_SCREEN_STARBOARD_VIEW | State | Set when right view is on main screen | |
| Helm | WARP_1 | State | |
| WARP_2 | State | ||
| WARP_3 | State | ||
| WARP_4 | State | ||
| IMPULSE_1 | State | Set when impulse >= 1, cleared on full stop (not simply when throttle is at 0) | |
| IMPULSE_20 | State | Set when impulse >= 20, cleared when < 20. Normally this should be placed after IMPULSE_1 when both affect the same channels. | |
| IMPULSE_40 | State | Set when impulse >= 40, cleared when < 40. Normally this should be placed after IMPULSE_20 when both affect the same channels. | |
| IMPULSE_60 | State | Set when impulse >= 60, cleared when < 60. Normally this should be placed after IMPULSE_40 when both affect the same channels. | |
| IMPULSE_80 | State | Set when impulse >= 80, cleared when < 80. Normally this should be placed after IMPULSE_60 when both affect the same channels. | |
| IMPULSE_100 | State | Set when impulse reaches 100, cleared when < 100. Normally this should be placed after IMPULSE_80 when both affect the same channels. | |
| REVERSE_IMPULSE | State | Set whenever ship is moving in reverse. This differs from HELM_IN_REVERSE in two ways. First, if you use a joystick throttle to move in reverse rather than selecting the Reverse setting, HELM_IN_REVERSE will not be set whereas REVERSE_IMPULSE will be set (it will also be set if HELM_IN_REVERSE is set and the ship is actually moving in reverse). Second, HELM_IN_REVERSE remains set even if the ship is stopped, whereas REVERSE_IMPULSE does not. | |
| JUMP_IN_PROGRESS | State | Set when jump countdown is initiated (same as when JUMP_INITIATED event is fired) and cleared when jump is executed (same as JUMP_EXECUTED event) or fizzled (JUMP_FIZZLED event) | |
| JUMP_DRIVE_EXISTS | State | Set when in a ship with a jump drive | |
| Weapons | AUTO_BEAMS_ON | State | Set when Auto Beams enabled |
| BEAM_FIRED | Event | Triggered when any beam is fired | |
| BEAM1_FIRED | Event | Triggered when beam #1 fired | |
| BEAM2_FIRED | Event | Triggered when beam #2 fired | |
| BEAM3_FIRED | Event | Triggered when beam #3 fired (such as on a Battleship with 4 beams) | |
| BEAM4_FIRED | Event | Triggered when beam #4 fired (such as on a Battleship with 4 beams) | |
| BEAM5_FIRED | Event | Triggered when beam #5 fired. No stock ships have more than 4 beams, but some mods have additional ship types that may. | |
| BEAM6_FIRED | Event | Triggered when beam #6 fired. | |
| BEAM7_FIRED | Event | Triggered when beam #7 fired. No stock ships have more than 4 beams, but some mods have additional ship types that may. | |
| BEAM8_FIRED | Event | Triggered when beam #8 fired. | |
| BEAM9_FIRED | Event | Triggered when beam #9 fired. | |
| BEAM10_FIRED | Event | Triggered when beam #10 fired. | |
| BEAMS_EXIST | State | Set when on a ship that has beams (e.g., not set on a Missile Cruiser) | |
| TUBE1_EMPTY | State | ||
| TUBE1_EXISTS | State | ||
| TUBE1_LOADING_HOMING | State | ||
| TUBE1_LOADING_NUKE | State | ||
| TUBE1_LOADING_MINE | State | ||
| TUBE1_LOADING_EMP | State | ||
| TUBE1_LOADING_PSHOCK | State | ||
| TUBE1_LOADING_BEACON | State | ||
| TUBE1_LOADING_PROBE | State | ||
| TUBE1_LOADING_TAG | State | ||
| TUBE1_READY_TO_FIRE_HOMING | State | ||
| TUBE1_READY_TO_FIRE_NUKE | State | ||
| TUBE1_READY_TO_FIRE_MINE | State | ||
| TUBE1_READY_TO_FIRE_EMP | State | ||
| TUBE1_READY_TO_FIRE_PSHOCK | State | ||
| TUBE1_READY_TO_FIRE_BEACON | State | ||
| TUBE1_READY_TO_FIRE_PROBE | State | ||
| TUBE1_READY_TO_FIRE_TAG | State | ||
| TUBE1_UNLOADING_HOMING | State | ||
| TUBE1_UNLOADING_NUKE | State | ||
| TUBE1_UNLOADING_MINE | State | ||
| TUBE1_UNLOADING_EMP | State | ||
| TUBE1_UNLOADING_PSHOCK | State | ||
| TUBE1_UNLOADING_BEACON | State | ||
| TUBE1_UNLOADING_PROBE | State | ||
| TUBE1_UNLOADING_TAG | State | ||
| TUBE1_FIRED_HOMING | Event | ||
| TUBE1_FIRED_NUKE | Event | ||
| TUBE1_FIRED_MINE | Event | ||
| TUBE1_FIRED_EMP | Event | ||
| TUBE1_FIRED_PSHOCK | Event | ||
| TUBE1_FIRED_BEACON | Event | ||
| TUBE1_FIRED_PROBE | Event | ||
| TUBE1_FIRED_TAG | Event | ||
| TUBE2_EMPTY | State | ||
| TUBE2_EXISTS | State | ||
| TUBE2_LOADING_HOMING | State | ||
| TUBE2_LOADING_NUKE | State | ||
| TUBE2_LOADING_MINE | State | ||
| TUBE2_LOADING_EMP | State | ||
| TUBE2_LOADING_PSHOCK | State | ||
| TUBE2_LOADING_BEACON | State | ||
| TUBE2_LOADING_PROBE | State | ||
| TUBE2_LOADING_TAG | State | ||
| TUBE2_READY_TO_FIRE_HOMING | State | ||
| TUBE2_READY_TO_FIRE_NUKE | State | ||
| TUBE2_READY_TO_FIRE_MINE | State | ||
| TUBE2_READY_TO_FIRE_EMP | State | ||
| TUBE2_READY_TO_FIRE_PSHOCK | State | ||
| TUBE2_READY_TO_FIRE_BEACON | State | ||
| TUBE2_READY_TO_FIRE_PROBE | State | ||
| TUBE2_READY_TO_FIRE_TAG | State | ||
| TUBE2_UNLOADING_HOMING | State | ||
| TUBE2_UNLOADING_NUKE | State | ||
| TUBE2_UNLOADING_MINE | State | ||
| TUBE2_UNLOADING_EMP | State | ||
| TUBE2_UNLOADING_PSHOCK | State | ||
| TUBE2_UNLOADING_BEACON | State | ||
| TUBE2_UNLOADING_PROBE | State | ||
| TUBE2_UNLOADING_TAG | State | ||
| TUBE2_FIRED_HOMING | Event | ||
| TUBE2_FIRED_NUKE | Event | ||
| TUBE2_FIRED_MINE | Event | ||
| TUBE2_FIRED_EMP | Event | ||
| TUBE2_FIRED_PSHOCK | Event | ||
| TUBE2_FIRED_BEACON | Event | ||
| TUBE2_FIRED_PROBE | Event | ||
| TUBE2_FIRED_TAG | Event | ||
| TUBE3_EMPTY | State | ||
| TUBE3_EXISTS | State | ||
| TUBE3_LOADING_HOMING | State | ||
| TUBE3_LOADING_NUKE | State | ||
| TUBE3_LOADING_MINE | State | ||
| TUBE3_LOADING_EMP | State | ||
| TUBE3_LOADING_PSHOCK | State | ||
| TUBE3_LOADING_BEACON | State | ||
| TUBE3_LOADING_PROBE | State | ||
| TUBE3_LOADING_TAG | State | ||
| TUBE3_READY_TO_FIRE_HOMING | State | ||
| TUBE3_READY_TO_FIRE_NUKE | State | ||
| TUBE3_READY_TO_FIRE_MINE | State | ||
| TUBE3_READY_TO_FIRE_EMP | State | ||
| TUBE3_READY_TO_FIRE_PSHOCK | State | ||
| TUBE3_READY_TO_FIRE_BEACON | State | ||
| TUBE3_READY_TO_FIRE_PROBE | State | ||
| TUBE3_READY_TO_FIRE_TAG | State | ||
| TUBE3_UNLOADING_HOMING | State | ||
| TUBE3_UNLOADING_NUKE | State | ||
| TUBE3_UNLOADING_MINE | State | ||
| TUBE3_UNLOADING_EMP | State | ||
| TUBE3_UNLOADING_PSHOCK | State | ||
| TUBE3_UNLOADING_BEACON | State | ||
| TUBE3_UNLOADING_PROBE | State | ||
| TUBE3_UNLOADING_TAG | State | ||
| TUBE3_FIRED_HOMING | Event | ||
| TUBE3_FIRED_NUKE | Event | ||
| TUBE3_FIRED_MINE | Event | ||
| TUBE3_FIRED_EMP | Event | ||
| TUBE3_FIRED_PSHOCK | Event | ||
| TUBE3_FIRED_BEACON | Event | ||
| TUBE3_FIRED_PROBE | Event | ||
| TUBE3_FIRED_TAG | Event | ||
| TUBE4_EMPTY | State | ||
| TUBE4_EXISTS | State | ||
| TUBE4_LOADING_HOMING | State | ||
| TUBE4_LOADING_NUKE | State | ||
| TUBE4_LOADING_MINE | State | ||
| TUBE4_LOADING_EMP | State | ||
| TUBE4_LOADING_PSHOCK | State | ||
| TUBE4_LOADING_BEACON | State | ||
| TUBE4_LOADING_PROBE | State | ||
| TUBE4_LOADING_TAG | State | ||
| TUBE4_READY_TO_FIRE_HOMING | State | ||
| TUBE4_READY_TO_FIRE_NUKE | State | ||
| TUBE4_READY_TO_FIRE_MINE | State | ||
| TUBE4_READY_TO_FIRE_EMP | State | ||
| TUBE4_READY_TO_FIRE_PSHOCK | State | ||
| TUBE4_READY_TO_FIRE_BEACON | State | ||
| TUBE4_READY_TO_FIRE_PROBE | State | ||
| TUBE4_READY_TO_FIRE_TAG | State | ||
| TUBE4_UNLOADING_HOMING | State | ||
| TUBE4_UNLOADING_NUKE | State | ||
| TUBE4_UNLOADING_MINE | State | ||
| TUBE4_UNLOADING_EMP | State | ||
| TUBE4_UNLOADING_PSHOCK | State | ||
| TUBE4_UNLOADING_BEACON | State | ||
| TUBE4_UNLOADING_PROBE | State | ||
| TUBE4_UNLOADING_TAG | State | ||
| TUBE4_FIRED_HOMING | Event | ||
| TUBE4_FIRED_NUKE | Event | ||
| TUBE4_FIRED_MINE | Event | ||
| TUBE4_FIRED_EMP | Event | ||
| TUBE4_FIRED_PSHOCK | Event | ||
| TUBE4_FIRED_BEACON | Event | ||
| TUBE4_FIRED_PROBE | Event | ||
| TUBE4_FIRED_TAG | Event | ||
| TUBE5_EMPTY | State | While no stock ship types have more than 4 tubes, some mods have additional ship types that may have up to 6 tubes. | |
| TUBE5_EXISTS | State | ||
| TUBE5_LOADING_HOMING | State | ||
| TUBE5_LOADING_NUKE | State | ||
| TUBE5_LOADING_MINE | State | ||
| TUBE5_LOADING_EMP | State | ||
| TUBE5_LOADING_PSHOCK | State | ||
| TUBE5_LOADING_BEACON | State | ||
| TUBE5_LOADING_PROBE | State | ||
| TUBE5_LOADING_TAG | State | ||
| TUBE5_READY_TO_FIRE_HOMING | State | ||
| TUBE5_READY_TO_FIRE_NUKE | State | ||
| TUBE5_READY_TO_FIRE_MINE | State | ||
| TUBE5_READY_TO_FIRE_EMP | State | ||
| TUBE5_READY_TO_FIRE_PSHOCK | State | ||
| TUBE5_READY_TO_FIRE_BEACON | State | ||
| TUBE5_READY_TO_FIRE_PROBE | State | ||
| TUBE5_READY_TO_FIRE_TAG | State | ||
| TUBE5_UNLOADING_HOMING | State | ||
| TUBE5_UNLOADING_NUKE | State | ||
| TUBE5_UNLOADING_MINE | State | ||
| TUBE5_UNLOADING_EMP | State | ||
| TUBE5_UNLOADING_PSHOCK | State | ||
| TUBE5_UNLOADING_BEACON | State | ||
| TUBE5_UNLOADING_PROBE | State | ||
| TUBE5_UNLOADING_TAG | State | ||
| TUBE5_FIRED_HOMING | Event | ||
| TUBE5_FIRED_NUKE | Event | ||
| TUBE5_FIRED_MINE | Event | ||
| TUBE5_FIRED_EMP | Event | ||
| TUBE5_FIRED_PSHOCK | Event | ||
| TUBE5_FIRED_BEACON | Event | ||
| TUBE5_FIRED_PROBE | Event | ||
| TUBE5_FIRED_TAG | Event | ||
| TUBE6_EMPTY | State | ||
| TUBE6_EXISTS | State | ||
| TUBE6_LOADING_HOMING | State | ||
| TUBE6_LOADING_NUKE | State | ||
| TUBE6_LOADING_MINE | State | ||
| TUBE6_LOADING_EMP | State | ||
| TUBE6_LOADING_PSHOCK | State | ||
| TUBE6_LOADING_BEACON | State | ||
| TUBE6_LOADING_PROBE | State | ||
| TUBE6_LOADING_TAG | State | ||
| TUBE6_READY_TO_FIRE_HOMING | State | ||
| TUBE6_READY_TO_FIRE_NUKE | State | ||
| TUBE6_READY_TO_FIRE_MINE | State | ||
| TUBE6_READY_TO_FIRE_EMP | State | ||
| TUBE6_READY_TO_FIRE_PSHOCK | State | ||
| TUBE6_READY_TO_FIRE_BEACON | State | ||
| TUBE6_READY_TO_FIRE_PROBE | State | ||
| TUBE6_READY_TO_FIRE_TAG | State | ||
| TUBE6_UNLOADING_HOMING | State | ||
| TUBE6_UNLOADING_NUKE | State | ||
| TUBE6_UNLOADING_MINE | State | ||
| TUBE6_UNLOADING_EMP | State | ||
| TUBE6_UNLOADING_PSHOCK | State | ||
| TUBE6_UNLOADING_BEACON | State | ||
| TUBE6_UNLOADING_PROBE | State | ||
| TUBE6_UNLOADING_TAG | State | ||
| TUBE6_FIRED_HOMING | Event | ||
| TUBE6_FIRED_NUKE | Event | ||
| TUBE6_FIRED_MINE | Event | ||
| TUBE6_FIRED_EMP | Event | ||
| TUBE6_FIRED_PSHOCK | Event | ||
| TUBE6_FIRED_BEACON | Event | ||
| TUBE6_FIRED_PROBE | Event | ||
| TUBE6_FIRED_TAG | Event | ||
| WEAPONS_TARGET_SELECTED | State | Set whenever weapons (on a capital ship, not a fighter) has a target selected | |
| Engineering | SYSTEM_OVERHEATING | State | Set if any system is overheating (>80% heat) |
| BEAMS_OVERHEATING | State | Set if beams are overheating | |
| TORPEDOES_OVERHEATING | State | Set if torpedoes are overheating | |
| SENSORS_OVERHEATING | State | Set if sensors are overheating | |
| MANEUVERING_OVERHEATING | State | Set if maneuvering is overheating | |
| IMPULSE_OVERHEATING | State | Set if impulse is overheating | |
| WARP_OVERHEATING | State | Set if warp is overheating | |
| FRONT_SHIELDS_OVERHEATING | State | Set if front shields are overheating | |
| REAR_SHIELDS_OVERHEATING | State | Set if rear shields are overheating | |
| Science | SCAN_INITIATED | Event | |
| SCAN_IN_PROGRESS | State | ||
| SCAN_COMPLETE | Event | ||
| SCIENCE_TARGET_SELECTED | State | Set whenever science has a target selected | |
| Comms | INCOMING_COMMUNICATION_ALERT | Event | high priority alert (new in Artemis v2.5.107) |
| INCOMING_COMMUNICATION_SIDE | Event | message to all players on a side (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_STATUS | Event | status report, usu. from a base (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_PLAYER | Event | message from a player ship (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_STATION | Event | message from a base (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_ENEMY | Event | transmission from enemy (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_FRIEND | Event | message from an NPC ship (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_OTHER | Event | message in none of the other categories, typically from a mission script or GM console (new in Artemis v2.5.107) | |
| INCOMING_COMMUNICATION_PRI0 | Event | transmission from enemy (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI1 | Event | (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI2 | Event | (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI3 | Event | base destroyed (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI4 | Event | base under attack, refusal from neutral ships, docking complete (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI5 | Event | base accepting build orders or docking request (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI6 | Event | friendly ship accepting orders, status response from base, notice of ordnance built, message from GM (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI7 | Event | mission available from ship or base, mission transfer complete (only signaled if running an Artemis version prior to v2.5.107) | |
| INCOMING_COMMUNICATION_PRI8 | Event | outgoing message such as a request to surrender, message between player ships (only signaled if running an Artemis version prior to v2.5.107) | |
| Fighter | ALL_FIGHTERS_DOCKED | State | Set when all remaining fighters are docked. Clear when at least one fighter is still alive outside the capital ship. Only triggered on server and fighter clients. So to trigger on main screen of a ship other than Artemis, also select Fighter on the main screen client. |
| ANY_FIGHTER_READY | State | Set when any fighter is ready to launch. | |
| FIGHTER_BAY_EXISTS | State | Set when in a ship with a fighter bay. Starting in Artemis 2.6, all player ships have a fighter bay even if it is just for a single shuttle. | |
| FIGHTER_BAY1_EXISTS | State | Set when in a ship with a fighter bay that includes space for 2 or more single-seat ships. (Bays are numbered 0 to 5.) | |
| FIGHTER_BAY2_EXISTS | State | Set when in a ship with a fighter bay that includes space for 3 or more single-seat ships. | |
| FIGHTER_BAY3_EXISTS | State | Set when in a ship with a fighter bay that includes space for 4 or more single-seat ships. | |
| FIGHTER_BAY4_EXISTS | State | Set when in a ship with a fighter bay that includes space for 5 or more single-seat ships. | |
| FIGHTER_BAY5_EXISTS | State | Set when in a ship with a fighter bay that includes space for 6 or more single-seat ships. | |
| FIGHTER_BAY0_REFITTING_BOMBER | State | Set when bay 0 is busy refitting a bomber. | |
| FIGHTER_BAY0_REFITTING_FIGHTER | State | Set when bay 0 is busy refitting a fighter. | |
| FIGHTER_BAY0_REFITTING_SHUTTLE | State | Set when bay 0 is busy refitting a shuttle. | |
| FIGHTER_BAY0_READY_BOMBER | State | Set when bay 0 has a bomber ready to launch. | |
| FIGHTER_BAY0_READY_FIGHTER | State | Set when bay 0 has a fighter ready to launch. | |
| FIGHTER_BAY0_READY_SHUTTLE | State | Set when bay 0 has a shuttle ready to launch. | |
| FIGHTER_BAY1_REFITTING_BOMBER | State | Set when bay 1 is busy refitting a bomber. | |
| FIGHTER_BAY1_REFITTING_FIGHTER | State | Set when bay 1 is busy refitting a fighter. | |
| FIGHTER_BAY1_REFITTING_SHUTTLE | State | Set when bay 1 is busy refitting a shuttle. | |
| FIGHTER_BAY1_READY_BOMBER | State | Set when bay 1 has a bomber ready to launch. | |
| FIGHTER_BAY1_READY_FIGHTER | State | Set when bay 1 has a fighter ready to launch. | |
| FIGHTER_BAY1_READY_SHUTTLE | State | Set when bay 1 has a shuttle ready to launch. | |
| FIGHTER_BAY2_REFITTING_BOMBER | State | Set when bay 2 is busy refitting a bomber. | |
| FIGHTER_BAY2_REFITTING_FIGHTER | State | Set when bay 2 is busy refitting a fighter. | |
| FIGHTER_BAY2_REFITTING_SHUTTLE | State | Set when bay 2 is busy refitting a shuttle. | |
| FIGHTER_BAY2_READY_BOMBER | State | Set when bay 2 has a bomber ready to launch. | |
| FIGHTER_BAY2_READY_FIGHTER | State | Set when bay 2 has a fighter ready to launch. | |
| FIGHTER_BAY2_READY_SHUTTLE | State | Set when bay 2 has a shuttle ready to launch. | |
| FIGHTER_BAY3_REFITTING_BOMBER | State | Set when bay 3 is busy refitting a bomber. | |
| FIGHTER_BAY3_REFITTING_FIGHTER | State | Set when bay 3 is busy refitting a fighter. | |
| FIGHTER_BAY3_REFITTING_SHUTTLE | State | Set when bay 3 is busy refitting a shuttle. | |
| FIGHTER_BAY3_READY_BOMBER | State | Set when bay 3 has a bomber ready to launch. | |
| FIGHTER_BAY3_READY_FIGHTER | State | Set when bay 3 has a fighter ready to launch. | |
| FIGHTER_BAY3_READY_SHUTTLE | State | Set when bay 3 has a shuttle ready to launch. | |
| FIGHTER_BAY4_REFITTING_BOMBER | State | Set when bay 4 is busy refitting a bomber. | |
| FIGHTER_BAY4_REFITTING_FIGHTER | State | Set when bay 4 is busy refitting a fighter. | |
| FIGHTER_BAY4_REFITTING_SHUTTLE | State | Set when bay 4 is busy refitting a shuttle. | |
| FIGHTER_BAY4_READY_BOMBER | State | Set when bay 4 has a bomber ready to launch. | |
| FIGHTER_BAY4_READY_FIGHTER | State | Set when bay 4 has a fighter ready to launch. | |
| FIGHTER_BAY4_READY_SHUTTLE | State | Set when bay 4 has a shuttle ready to launch. | |
| FIGHTER_BAY5_REFITTING_BOMBER | State | Set when bay 5 is busy refitting a bomber. | |
| FIGHTER_BAY5_REFITTING_FIGHTER | State | Set when bay 5 is busy refitting a fighter. | |
| FIGHTER_BAY5_REFITTING_SHUTTLE | State | Set when bay 5 is busy refitting a shuttle. | |
| FIGHTER_BAY5_READY_BOMBER | State | Set when bay 5 has a bomber ready to launch. | |
| FIGHTER_BAY5_READY_FIGHTER | State | Set when bay 5 has a fighter ready to launch. | |
| FIGHTER_BAY5_READY_SHUTTLE | State | Set when bay 5 has a shuttle ready to launch. | |
| FIGHTER_DOCKED | Event | Only triggered on server and fighter clients. So to trigger on main screen of a ship other than Artemis, also select Fighter on the main screen client. | |
| FIGHTER_LAUNCHED | Event | Only triggered on server and fighter clients. So to trigger on main screen of a ship other than Artemis, also select Fighter on the main screen client. | |
| Captain | CAPTAIN_TARGET_SELECTED | State | Set whenever the captain has a target selected |
| Damage | FRONT_SHIELD_20 | State | Set when front shields >= 20% and shields are up, cleared when < 20% or shields are down. Normally this should be placed after PLAYER_SHIELDS_UP when both affect the same channels. |
| FRONT_SHIELD_40 | State | Set when front shields >= 40% and shields are up, cleared when < 40% or shields are down. Normally this should be placed after FRONT_SHIELD_20 when both affect the same channels. | |
| FRONT_SHIELD_60 | State | Set when front shields >= 60% and shields are up, cleared when < 60% or shields are down. Normally this should be placed after FRONT_SHIELD_40 when both affect the same channels. | |
| FRONT_SHIELD_80 | State | Set when front shields >= 80% and shields are up, cleared when < 80% or shields are down. Normally this should be placed after FRONT_SHIELD_60 when both affect the same channels. | |
| FRONT_SHIELD_100 | State | Set when front shields at %100 and shields are up, cleared when < 100% or shields are down. Normally this should be placed after FRONT_SHIELD_80 when both affect the same channels. | |
| REAR_SHIELD_20 | State | Set when rear shields >= 20% and shields are up, cleared when < 20% or shields are down. Normally this should be placed after PLAYER_SHIELDS_UP when both affect the same channels. | |
| REAR_SHIELD_40 | State | Set when rear shields >= 40% and shields are up, cleared when < 40%. or shields are down Normally this should be placed after REAR_SHIELD_20 when both affect the same channels. | |
| REAR_SHIELD_60 | State | Set when rear shields >= 60% and shields are up, cleared when < 60% or shields are down. Normally this should be placed after REAR_SHIELD_40 when both affect the same channels. | |
| REAR_SHIELD_80 | State | Set when rear shields >= 80% and shields are up, cleared when < 80% or shields are down. Normally this should be placed after REAR_SHIELD_60 when both affect the same channels. | |
| REAR_SHIELD_100 | State | Set when rear shields at %100 and shields are up, cleared when < 100% or shields are down. Normally this should be placed after REAR_SHIELD_80 when both affect the same channels. | |
| HULL_INTEGRITY_40 | State | Set when hull integrity >= 40% (ship is destroyed at about 30%). This state is the opposite of SHIP_DAMAGE_60, except that it is more reliable, such as being affected by damage from all sources including overheating. The HULL_INTEGRITY_* cues are typically used instead of using the SHIP_DAMAGE_* cues. | |
| HULL_INTEGRITY_60 | State | Set when hull integrity >= 60%. This state is the opposite of SHIP_DAMAGE_40, except that it is more reliable, such as being affected by damage from all sources including overheating. Normally this should be placed after HULL_INTEGRITY_40 when both affect the same channels. | |
| HULL_INTEGRITY_80 | State | Set when hull integrity >= 80%. This state is the opposite of SHIP_DAMAGE_20, except that it is more reliable, such as being affected by damage from all sources including overheating. Normally this should be placed after HULL_INTEGRITY_60 when both affect the same channels. | |
| HULL_INTEGRITY_100 | State | Set when hull integrity at 100% (undamaged). Normally this should be placed after HULL_INTEGRITY_80 when both affect the same channels. | |
| Game | ALWAYS_ON | State | This state is always on. It is most useful to place before NORMAL_CONDITION_1 to have effects (such as ambient lighting) that are present when a simulation is not in progress and are overridden by NORMAL_CONDITION_1 when a simulation is in progress. Any device commands set by this cue will also remain in effect after Artemis exits. All others will be cleared. |
| GAME_PAUSED | State | Set if game is paused | |
| Custom | CUSTOM_EVENT_1 | Event | Set by dmxset command in mission script or tracing socket |
| CUSTOM_EVENT_2 | Event | Set by dmxset command in mission script or tracing socket | |
| CUSTOM_EVENT_3 | Event | Set by dmxset command in mission script or tracing socket | |
| CUSTOM_EVENT_4 | Event | Set by dmxset command in mission script or tracing socket | |
| CUSTOM_STATE_1 | State | Set and cleared by dmxset command in mission script or tracing socket | |
| CUSTOM_STATE_2 | State | Set and cleared by dmxset command in mission script or tracing socket | |
| CUSTOM_STATE_3 | State | Set and cleared by dmxset command in mission script or tracing socket | |
| CUSTOM_STATE_4 | State | Set and cleared by dmxset command in mission script or tracing socket |
The following are potential future features, in no particular order. Feel free to suggest others, or ask for prioritizing one.
Send bug reports and feature requests to dthaler@microsoft.com