Signallers

From SEOW Wiki (EN)
Jump to: navigation, search

SEOW commanders and players have long needed direct feedback from friendly units when they encounter enemies. This was the role of signaller units in WW2. Signallers would detect enemy movements/dispositions and provide timely reports to HQ. Examples of signaller units were coastwatchers (in the Pacific), field observation officers (FOO) on land, recon aircraft, masthead lookouts on capital ships, radar operators etc.

Catsy has recently developed an update of his excellent triggers mod for HSFX7. In the updated Catsy triggers mod (v1.2) there are new features that allow a trigger to:

  • be associated with an object (the signaller)
  • detect an approaching object (the enemy)
  • initiate a movement order for an object (the scrambler)
  • display an arbitrary on-screen message containing the location of the signaller at the time of detection

In general, the signaller, the enemy and the scrambler can be any kind of objects. This is a wonderful tool that is not only useful for mission builders but also perfectly useful in an SEOW context where we need to allow for unexpected events, such as signaller destruction by indirect artillery fire from 20 km away or more!

As of SEOW v7.1, we have in-built support for signaller units using Catsy's Trigger Mod v1.2 (which was released as part of HSFX v7.0.3). Here is how it works.



SEOW Signaller Requirements

You need to be using SEOW v7.1 (SEDB71, MP4public v7.1.x, SEDCS v7.1.x) and you must have Catsy's Trigger Mod v1.2 enabled in HSFX via JSGME (or be using HSFX v7.0.3 which includes the Trigger Mod natively) for the host and every pilot in your SEOW campaign. You then need to enable the "Use Catsy Triggers for Signallers" option in the DCS Territorial Control tab. This turns on SEOW support for signallers and triggering.


SEOW Signaller Concepts

SEOW allows the campaign designer to provide ANY combat object with signaller ability. There is a column called "Default_Signals" in the Object_Specifications table of the database where signaller ability can be customized for each different object type. Once a unit is commissioned into the campaign order of battle (which is stored in the ObjMissionData table in the database), each unit will be allocated its default signaller abilities as specified in Object_Specifications table according to the type of unit. Additionally, campaign admins can alter signaller abilities for each individual unit in the order of battle by editing the corresponding Signaller field in the ObjMissionData table.

Signaller ability is programmed by the contents of the Default_Signals and Signaller fields. These fields both accept character string values in two different formats: keyword and encoded mask. The campaign designer is free to choose between the two modes when specifying signaller abilities, either for object type or for individual combat units.


SEOW Signaller Keywords

  • All - a single trigger activated whenever any type of enemy unit is detected.
  • Ground - a single trigger activated whenever an enemy ground unit of any type is detected.
  • Air - a single trigger activated whenever an enemy air unit of any type is detected.
  • Sea - a single trigger activated whenever an enemy ship unit of any type is detected.
  • Coastwatch - two separate triggers activated whenever an enemy air unit OR an enemy ship unit is detected.
  • Lookout - identical to Coastwatch.
  • FOO - five separate triggers activated individually whenever an enemy armour, artillery, infantry, train or vehicle unit is detected.
  • Sentry - two separate triggers activated whenever an enemy air unit OR an enemy ground unit is detected.

SEOW signaller keywords are case insensitive, and cannot be combined. You can only use one keyword for each object type in the Object_Specifications table!


SEOW Signaller Encoded Masks

This format uses the internal code structure of the Trigger Mod. The structure has 12 possible values, so the encoded mask uses a string of exactly 12 characters to indicate which values are enabled and which are disabled. A "-" character indicates a disabled trigger mode, while an "x" or "X" characters indicates an enabled trigger mode.

The internal Trigger Mod mode order is given by the following (with the respective encoded masks written to the right):

  • All mode = 0  : "x-----------"
  • AI mode = 1  : "-x----------"
  • Humans mode = 2  : "--x---------"
  • Ground mode = 3  : "---x--------"
  • Moving_Planes mode = 4  : "----x-------"
  • Static_Planes mode = 5  : "-----x------"
  • Armour mode = 6  : "------x-----"
  • Artillery mode = 7  : "-------x----"
  • Infantry mode = 8  : "--------x---"
  • Shipping mode = 9  : "---------x--"
  • Trains mode = 10  : "----------x-"
  • Vehicles mode = 11  : "-----------x"

Campaign designers can use encoded masks to mix and match any combination of trigger mode abilities for any combat object types in the campaign. This is a little harder to read, so here are some simple examples.

  • An encoded signaller mask of "------------" denotes "no signaller" (equivalent to an empty character string "")
  • An encoded signaller mask of "-----x-x----" will yield two separate triggers for the signaller unit, activated individually on parked planes and on artillery.
  • An encoded signaller mask of "----------xx" will yield two separate triggers for the signaller unit, activated individually on trains and on vehicles.
  • An encoded signaller mask of "------x---xx" will yield three separate triggers for the signaller unit, activated individually on armour, on trains and on vehicles.
  • An encoded signaller mask of "----x----x--" will yield two separate triggers for the signaller unit, activated individually on aircraft in flight, and on ships. (equivalent to the Coastwatch and Lookout keywords)


Signaller Detection Ranges

Just as in real life, signaller performance will depend on the combat effectiveness of the signaller unit. A high combat effectiveness will mean that the signaller will see to long distance to detect approaching enemy units, and it will report the signal with high probability of success. A low combat effectiveness will mean that the detection distance will be reduced and there will be a strong chance that the signal is not reported to HQ. Observation balloons have extended detection ranges, as do ships.

If the Combat Effectiveness Model (CEM) is not enabled for the campaign, then signaller detection ranges will be constant for each individual signaller object, and will not change with morale, fatigue, CC etc. Detection will be disabled for all signallers that run out of supply.


What can be a Signaller?

Any combat object, mobile or stationary. Once an object type is given a signaller ability by editing the Default_Signals field in Object_Specifications, ALL instances of that object type in the campaign will have that ability throughout the campaign, unless their supply is exhausted or they are loaded as freight on another unit, or they are destroyed. Signal abilities can be modified on an individual unit basis by altering the Signaller field in ObjMissionData table.

Finally, a note of caution: signallers must be within Command and Control (CC) range of a command unit or location in order to operate. If signaller units are isolated from CC they will be unable to relay their signals through to friendly forces. If CC restrictions are disabled, all signallers will be able to operate independent of CC considerations.


What can be a Scrambler?

Any combat object with a planned movement order, e.g. a mobile tank, vehicle, infantry team, ship or plane. The scrambler will spawn as usual in the mission and rest at its starting waypoint until the signaller sends the signal to commence moving. If the signal never arrives, the scrambler stays still and finishes the mission in its starting location. If the signal does arrive, the scrambler will commence following its movement order as normal, but delayed by the time that the signal is activated. For example, if the signaller does not send its signal until the 20 minute mark of the mission, any associated scrambler will not start moving until the 20 minute mark.

Off map flights can be designated scramblers. In this case they will spawn into the game when the signal arrives. Human pilots cannot occupy off-map scrambler flights!


How many signals can one signaller send in a mission?

Each scrambler can only be linked to one signaller. Each signaller can be linked to many scramblers, so multiple units can start moving simultaneously based on signals from a single signaller. And each signaller can send up to 12 signals to a single scrambler (!) according to the encoding mask specified. It is recommended that designers are sparing with the number of signallers used in the campaign. By default SEOW specifies all combat ships to have signaller capability, plus all radio vehicles, seaplanes and radar stations.

A signaller will only send a signal for the first time it sees an enemy object of the appropriate type in a mission. For example, consider a signaller with only armour detection capability. The signaller has detection range of 1.5 km, and three enemy tank units are approaching from 3 different directions and distances. When the closest tank penetrates within 1.5 km, the signaller will send one signal to all associated scramblers and will also cause a message to appear on friendly pilot screens in game. As the second and third tank units draw within detection range, no more signals will be sent. Any signal is only sent once (upon the first qualifying detection event).


Mission Planner Support

The MP contains graphical support and other tools to help commanders use signallers in a very simple and realistic manner.


Signaller Unit Tooltip Icon

The following image shows the signaller icon (radio tower, highlighted in blue here) displayed inside each signaller unit's tooltip. If the signaller icon is not visible then the unit has no signaller capability.

Trigger3.jpg



Signaller Unit Abilities

The detailed detection abilities and ranges for each signaller unit can be displayed simply by clicking on the signaller icon inside the signaller unit tooltip. This causes a secondary window to appear. This window contains a list of all detection modes enabled for the signaller together with the detection ranges for each mode (see image below). Detection ranges are calculated to include Combat Effectiveness modifiers automatically.

Trigger2.jpg


Integration of Signallers into MP Tools

Like other SEOW features, commanders can use signallers very simply. When planning movements in the MP, commanders can simply select a signaller to associate with the movement orders using a simple drop-down menu available just above the Commit button. The drop-down menu shows all available signallers on the map. There is no distance limitation between signallers and scramblers. If a signaller unit is chosen during planning a movement order, then the unit being ordered to move automatically becomes a scrambler once the Commit button is pressed. This is reflected in the Scheduled Missions tool (see image below). Like other movement settings, the designated signaller can easily be altered or removed by using the Scheduled Mission Variation Tool.


Trigger1.jpg


There may be many signallers on the map at any one time, and not all of them may be associated with scramblers in any particular mission. SEOW will detect this and still generate trigger directives in the mission file, so friendly players may still see important signal messages appearing on screen throughout the mission even if no scrambler units are activated. To ensure this signal reporting activity SEOW may place a single dummy scrambler (motorbike object) on the map near the host aircraft location. If used, this dummy scrambler forms a virtual link to all unassociated signallers. If the dummy scrambler is placed SEOW will not show the dummy scrambler in post-mission statistics etc and the net increase in server load is tiny.

Example of message sent by the Signaller above:

Trigger4.jpg


Hosting Signaller Missions

In principle, there are no special requirements for running/hosting missions involving signaller units. However, some performance degradation is observed on the host and clients machines when there are large numbers of signallers defined and/or large numbers of objects present.

In SEOW testing, we ran missions with 2-6 pilots and at least 100 signaller directives. The host machine showed micro-pauses every 3 seconds, which made it almost impossible to fly and land when using the host machine. Client machines ran smoothly, so it seems the signaller overhead was large enough to cause a problem on the host machine. Missions without signallers enabled ran smoothly. Further testing showed that even client machines can see some slight rubber-banding of planes in mid-air every 3 seconds. The following recommendations are made:

  • Limit the number of active signallers in any mission. Note that SEOW allows default signaller ability to be edited for any combat object type (via Object_Specifications table). After campaign initialization admins can then edit the ObjMissionData table to add/remove signaller capability from any individual combat unit in the order of battle. Use the minimum number of trigger modes for each signaller.
  • The number of trigger directives in a mission equals the total of all enabled trigger modes for all active signallers. For example, 20 coastwatchers will yield 40 trigger directives in the mission file since each coastwatcher has 2 trigger modes: a trigger for enemy air and a trigger for enemy shipping.
  • Use a dedicated host machine for hosting signaller missions. All human pilots should have their own client machines.
  • In SEOW HQ testing we found that we used "message" triggers more often, i.e. simple reports of enemy unit proximity. These are the default methods in SEOW and do not require any commander intervention.

Note: Catsy has released an upgrade to his Trigger mod (Mod_Trigger_v1.2.1mp) that runs the mod in a separate thread on the host. In testing this seems to remove the 3 second micro-pauses on the host discussed above. This mod is only required to be run on the host (not the client machines) in SEOW coops.