DMX Functionality (Cosmos DMX Tools):
Cosmos Bridge Tools currently assumes Artemis Cosmos 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), Cosmos Bridge Tools can still be installed, but the installer will warn that Cosmos was not found, and Cosmos Bridge Tools won't be fully enabled for use until you install the mod to one or more Cosmos 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 Cosmos 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.
Fancy DMX Effects:
DMX Device Types:
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%\CosmosBridgeTools\" directory (where the filename is
listed in the ActiveProfileFileName.txt file there). You can open
this directory in File Explorer by doing File→Open
File Location from within Cosmos DMX Editor.
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 Cosmos 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%\CosmosBridgeTools\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 Cosmos 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
) 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.
How to create a gradual transition into a continuous effectArtemis Cosmos itself is limited in the ability to create a gradual transition into a continuous effect, but Cosmos 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 Cosmos 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 Cosmos DMX Editor, as follows:
That's it! You can now use the Test feature of Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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 Cosmos 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 Cosmos DMX Editor, as follows:
That's it! You can now use the Test feature of Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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 Cosmos DMX Editor, as follows:
That's it! You can now use the Test feature of Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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, or only when a state is true and some other game property is above or below a given threshold, you can now do this.
Example 1: 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 Cosmos 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.) Cosmos 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 Cosmos DMX Editor as follows:
That's it! You can now use the Test feature of Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos normally.
Example 2: Say you want your IMPULSE_20 effect to only play when engineering has power to the system, and not when power is dropped to 0. Cosmos Bridge Tools supports conditions based on various named property (the same set of properties it supports for named colors) using a "<" or ">" operator and an integer percentage threshold, so your command profile would look like this:
<event type="IMPULSE_20"
continuous="yes" if="systemCurEnergyImpulse
> 0%">
...
</event>
You can configure this in Cosmos DMX Editor as follows:
That's it! You can now use the Test feature of Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos normally.
Cosmos 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 Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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. Cosmos DMX Editor currently allows you to easily create gauges for any named property or any of 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 Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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 Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos normally.
Within the Test dialog, you can change the Accent Color via a slider at the bottom, to observe the effects.
Any named property supported by Cosmos Bridge Tools can be used as a custom Color Name.
Now we'll see how to set a light's color to match a named color. 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 the property "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 Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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. Cosmos 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 Cosmos DMX Editor to observe the effects, or just exit and run Artemis Cosmos 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 for Cosmos versions prior to 2.5.107, or INCOMING_COMMUNICATION_ENEMY for v2.5.107 and later. 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 Cosmos and observe the effects, or use the Test Active feature of Cosmos 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 Cosmos 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.
Cosmos Bridge Tools supports two types of keyboards: Razer Chroma keyboards, and keyboards that support the HID LampArray standard (and as of April 10, 2021, the only in market device to support the standard is the Razer Turret for Xbox One).
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 Cosmos Bridge Tools, so if you uninstall Cosmos Bridge Tools, support for such LED lights will also be removed.
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 Cosmos Bridge Tools, so if you uninstall Cosmos 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 Cosmos DMX Editor to test it.
Note that Enttec Pro support is provided by Cosmos Bridge Tools, so if you uninstall Cosmos 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 Cosmos Bridge Tools directory (e.g., "%ProgramFiles(x86)%\Cosmos 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 Cosmos Bridge Tools, so if you uninstall Cosmos 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).
Cosmos 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 Cosmos DMX Editor to test it.
Note that uDMX support is provided by Cosmos Bridge Tools, so if you uninstall Cosmos Bridge Tools, support for uDMX 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 Cosmos 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 Cosmos Bridge Tools, so if you uninstall Cosmos 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). Cosmos Bridge Tools supports both kinds.
Note that LIFX support is provided by Cosmos Bridge Tools, so if you uninstall Cosmos 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 Cosmos 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. Cosmos 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 or MagicLight bulbs.
If you encounter problems, here are some troubleshooting steps to check:
Note that LimitlessLED support is provided by Cosmos Bridge Tools, so if you uninstall Cosmos 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 Cosmos 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 Cosmos and observe the effects, or use the Test Active feature of Cosmos DMX Editor to test it.
Note that WeMo switch support is provided by Cosmos Bridge Tools, so if you uninstall Cosmos Bridge Tools, support for WeMo switches will also be removed.
To use Govee lights, use the Govee Home phone app to enable LAN Control as follows:
Next, configure the device for use with Artemis Cosmos:
Artemis Cosmos uses a standard API for talking to FTDI chips, which API is exposed by the ftd2xx.dll that comes with Artemis Cosmos.
Cosmos Bridge Tools has two components:
The %LocalAppData%\CosmosBridgeTools\ directory contains the files used by the Cosmos Bridge Tools components:
The following output Device Types are supported:
The same Virtual Input Device (i.e., DMX channels as used by Cosmos) 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, Cosmos 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 Cosmos DMX command profile from the old devices to the new devices".
The following DMX cues are supported.
| Category | Event Tag | Type | Notes |
| General |
NORMAL_CONDITION_1 |
State |
Only partly working, this is currently always set, not just when in a simulation. |
| ENERGY_20 |
State |
Set when energy goes < 200, cleared when energy >= 200. Normally this should be placed after ENERGY_40 when both affect the same channels. |
|
| ENERGY_40 |
State |
Set when energy goes < 400, cleared when energy >= 400. Normally this should be placed after ENERGY_60 when both affect the same channels. | |
| ENERGY_60 |
State |
Set when energy goes < 600, cleared when energy >= 600. Normally this should be placed after ENERGY_80 when both affect the same channels. | |
| ENERGY_80 |
State |
Set when energy goes < 800, cleared when energy >= 800. Normally this should be placed after ENERGY_100 when both affect the same channels. | |
| ENERGY_100 |
State |
Set when energy goes < 1000, cleared when energy >= 1000. |
|
| ENERGY_LOW |
State |
Set when energy goes < 300, cleared when energy goes >= 300. |
|
| PLAYER_SHIELDS_ON |
State |
||
| PLAYER_SHIELDS_RAISED |
Event |
Use an effect that lasts
mseconds="1500" for the same duration as audio effect. Normally
this should be placed after PLAYER_SHIELDS_ON when both affect the same
channels, since both will be triggered at the same time. |
|
| PLAYER_SHIELDS_LOWERED |
Event |
Use an effect that lasts mseconds="1500" for the same duration as audio effect. |
|
| Helm | WARP_1 | State | Set when at warp 1 |
| WARP_2 | State | Set when at warp 2 |
|
| WARP_3 | State | Set when at warp 3 |
|
| WARP_4 | State | Set when at warp 4 |
|
| 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_DRIVE_EXISTS | State | Set when in a ship with a jump drive | |
| START_DOCKING |
Event |
||
| TRACTORED_FOR_DOCKED |
State |
||
| COMPLETELY_DOCKED |
State |
||
| Weapons | BEAMS_EXIST | State | Set when on a ship that has beams (e.g., not set on a Missile Cruiser) |
| HAVE_SPARE_HOMINGS | State | Set whenever the ship has at least 1 spare homing missile on board | |
| HAVE_SPARE_NUKES | State | Set whenever the ship has at least 1 spare nuke on board | |
| HAVE_SPARE_MINES | State | Set whenever the ship has at least 1 spare mine on board | |
| HAVE_SPARE_EMPS | State | Set whenever the ship has at least 1 spare EMP on board | |
| 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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_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_TAG | Event | ||
| WEAPONS_TARGET_SELECTED | State | Set whenever weapons (on a capital ship, not a fighter) has a target selected | |
| Science |
SCAN_INITIATED |
Event |
|
| SCAN_IN_PROGRESS | State | ||
| SCAN_COMPLETE |
Event |
||
| SCIENCE_TARGET_SELECTED | State | Set whenever science has a target selected | |
| Comms |
RED_ALERT |
State |
Set when red alert is active |
| Fighter | FIGHTER_BAY_EXISTS | State | Set when in a ship with a fighter bay. |
| 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. | |
| Damage | SOMETHING_HITS_PLAYER | Event | Ship recently took damage. |
| PLAYER_TAKES_INTERNAL_DAMAGE |
Event |
Ship recently took hull damage. |
|
| PLAYER_TAKES_SHIELD_DAMAGE |
Event |
Ship recently took shield 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. |
|
| SHIP_DAMAGE_20 |
State |
Set whenever >=20% of system nodes are damaged. |
|
| SHIP_DAMAGE_40 |
State | Set whenever >=40% of system
nodes are damaged. Normally this should be placed after SHIP_DAMAGE_20
when both affect the same channels. |
|
| SHIP_DAMAGE_60 |
State | Set whenever >=60% of system
nodes are damaged. Normally this should be placed after SHIP_DAMAGE_40
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 Cosmos exits. All others will be cleared. |
| NORMAL_CONDITION_1 |
State |
Set if simulation is in progress
(whether paused or not) |
|
| GAME_PAUSED | State | Set if game is paused | |
| GAME_OVER | Event |
Triggered at the end of the game. |
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 dthaler1968@gmail.com