The standard sector file and position file does not provide enough functionality so a new format has been developed, called ESE. This file includes information about controller positions, callsings and frequencies in the POSITIONS section, standard departure and arrival routing in the SIDSTARs section, additional static map elements such as FREETEXT and AIRSPACE section with the sector definition and auxiliary boundary information. This file is in addition to other resource configuration files.
This file may be edited and created with any text editor and saved as a standard text file. It must then be renamed to the file name of the sector file plus the .ese” extension. And it also must be placed in the same folder where your .sct file is as in EuroScope you can load the .sct file only and the .ese will be loaded automatically.

OFFSET

Offsets can be used in both SCT and ESE files in any place in the file. Defining an offset will change all coordinates next to this line to be shifted accordingly. Use offset back to 0, 0 to resume normal operation. That way you can use offset brackets to shift your content.

OFFSET has two forms:

OFFSET:0.01:0.02

This will move all coordinates by 0.01 degrees to the north 0.02 degrees to the east.

OFFSET:N047.25.50.442:E019.16.05.320:N047.25.51.548:E019.16.16.327

This will calculate the offset values to ensure N047.25.50.442, E019.16.05.320 is moved to N047.25.51.548, E019.16.16.327

Freetext Section

This section provides additional map drawing elements. It provides the ability to display any ASCII character on the radar video map. The freetext section must be prefixed by this line:

[FREETEXT]

Freetext definition lines have the following format:

<latitude>:<Longitude>:[<group name>:]<characters>

The separator between each element is the : character. The coordinates of latitude and longitude are prefixed by the letter of the hemisphere and then the geographical coordinate. The format for the coordinate may be either the decimal format (eg. N013.32861) or in the degrees.minutes .seconds.decimals format (eg. N013.19.43.327). You can group the free texts using the group name. If you omit the group name then a Default group will be used. The character section may use any number of ASCII characters except carriage return. A finished line may look like this:

N044.34.6.524:E026.06.27.632:LROP texts:TORA-D/26L 2490m

A finished freetext section may look like this:

[FREETEXT]
N044.34.37.952:E026.05.53.935:LROP taxiways:W
N044.34.34.336:E026.05.28.289:LROP taxiways:O
N044.34.6.524:E026.06.27.632:LROP texts:TORA-D/26L 2490m

Terminal Routing Section

This section contains the routing for the standard terminal procedures such as SID and STAR. It also contains the rules for assignment of those procedures by runways in use and the route end point/route start point. This section must start with the following line:

[SIDSSTARS]

The format of a routing line is:

<type of route (SID or STAR)>:<airport of destination/departure>:<runway related to that route>:<routing name>:<route points>

The lines priority is from top to bottom. The topmost line has most priority. The first line that completes all conditions will be chosen as the correct routing. The type of route can be SID or STAR and declares whether the next condition, airport, should be the departure or the arrival airport for that aircraft. The airport is declared as the full ICAO code for that airport. The next condition is the runway in use. Declare a new line for each runway that uses that respective routing. The name will be the name of the SID/STAR with the discrete identifier. The route will be declared by any FIX, VOR or NDB that makes part of the routing with spaces between each route element. An example of a routing, below:

[SIDSSTARS]

STAR:LROP:08R:TUSET2E:TUSET BAREM MADIT OBELA OPW
STAR:LROP:08L:TUSET2E:TUSET AMETI ABATU DILAS OTL
STAR:LROP:26L:TUSET3F:TUSET FLR AMODA LEVTA OPE
STAR:LROP:26R:TUSET3F:TUSET FLR AMODA RARIT OTR

STAR:LROP:08R:VALPA1E:VALPA FLR OBELA OPW
STAR:LROP:08L:VALPA1E:VALPA FLR DILAS OTL
STAR:LROP:26L:VALPA2F:VALPA FLR AMODA LEVTA OPE
STAR:LROP:26R:VALPA2F:VALPA FLR AMODA RARIT OTR

SID:LROP:08R:VALPA1A:OPE BSE BSW MEGIK VALPA
SID:LROP:08L:VALPA1A:OTR BSE BSW MEGIK VALPA
SID:LROP:26L:VALPA1C:OPW FLR VALPA
SID:LROP:26R:VALPA1C:OTL FLR VALPA

SID:LROP:08R:NILOV1A:STJ NILOV
SID:LROP:08L:NILOV1A:STJ NILOV
SID:LROP:26L:NILOV1C:OPW NILOV
SID:LROP:26R:NILOV1C:OTL NILOV

The Positions Section

This section contains information about all recognized controller positions. It is used to recognize what controller is what position using information from the callsign and the frequency. This is a slightly modified POF file used before in ASRC and VRC. Users may simply copy that file and modify it accordingly. The Positions section must begin with the following line:

[POSITIONS]

The format of the Position line is the following:

<name of position>:<radio callsign>:<frequency>:<identifier>:<middle letter>:<prefix>:<suffix>:<not used>:<not used>:<A code start of range>:<A code end of range>[:<VIS center1 latitude>:<VIS center1 longitude>[: ... ]]

The name of the position can be anything used to help in identifying the line inside the ESE file. Radio callsign shall be the official radiotelephony callsign that shall be used for that station. Frequency shall be in full with “.” as decimal separator. The identifier is used in many places in the software and may be as short as one character and as long as required. It is recommended to use a standard length. In ASRC/VRC and FAA systems the length of that ID is 2 characters. Prefix and suffix are the first and last parts of the callsign used to identify the position. A code ranges are used to preset the assignment A code ranges from which the system will assign the codes for a specific position. Optionally there can be some visibility centers defined for the position. One center can be defined by two parameters: latitude and longitude. There can be maximum 4 visibility centers defined (that is altogether 8 optional elements in the line)

Some examples of a finished Position section below:

[POSITIONS]
ARGES_TOP:Bucharest Radar:121.170:AST:A:LRBB:CTR:-:-:5401:5477
ARGES_MID:Bucharest Radar:124.250:ASM:1:LRBB:CTR:-:-:5401:5477
NERDI_TOP:Bucharest Radar:122.020:NIT:N:LRBB:CTR:-:-:5401:5477
NERDI_MID:Bucharest Radar:125.150:NIM:4:LRBB:CTR:-:-:5401:5477
BUCHAREST_TMA:Bucharest Approach:118.250:TMA:-:LROP:APP:-:-:5401:5477
OTOPENI_S_CTR:Otopeni Tower:120.900:TOI:S:LROP:TWR:-:-:5401:5477
LHCC:Budapest Radar:133.200:BUD:-:LHCC:CTR:-:-::
LYBA:Beograd Radar:123.770:BEG:-:LYBA:CTR:-:-::
EUE:Eurocontrol East:135.300:EE:C:EURE:FSS:EURE:FSS:0200:0277:N050.54.1.002:E019.49.42.216:N042.40.42.169:E022.28.7.307

The Airspace Section

The airspace section is the section containing information about the sectors in the delegated area and auxiliary boundary information. To understand the Airspace section one has to understand the functions of EuroScope well. It has a first section prefix with SECTORLINE which defines actual broken line that is common for only two lateral sectors. Then the sector is built by two or more of these lines and then additional boundary information is added such as COP (Coordination Points).

Please also take a look to the [[Tutorial]] section that describes some steps how to define the sectors.

The Airspace section must start with the following line:

[AIRSPACE]

The Sectorline Subsection

Each sectorline piece is usually comprised of three sections. The first line/section is prefixed with SECTORLINE then ‘:’ separator and the name of that respective sectorline.

SECTORLINE:MOPUG_LHCC

Then the declaration of that respective sectorline continues with an optional section prefixed with DISPLAY. It is used to declare when that respective border will be highlighted. More exactly, what sectors must be covered discretely by different controllers for that line to be highlighted.

DISPLAY:MGT:MGT:BUD

The prefix is DISPLAY with the ‘:’ separator. The next item is the sector you are covering. In this case, for this line to be taken in account you must be covering MGT sector. NOTE: this sector is not from the POSITIONS section but from the SECTOR section which will be described next. So it does not have to be your sole sector, and it does not refer to your callsign. The next two items are the two SECTORs that are compared to have different owners for this line to be highlighted. In this example the sectors MGT and BUD must be covered by a different controller and you must be controlling sector MGT. NOTE: the compared sectors do not have to match the sector you are covering. They usually do, but you can also display lines for nearby sector if you need them for reference.

Then the actual line must be declared using coordinates. Each coordinate point must be declared with the COORD prefix then followed by the LATITUDE and then the LONGITUDE.

COORD:N047.59.23.032:E023.30.49.151

A new COORD line will be made for each point making up the respective SECTORLINE. Make sure the end point of the SECTORLINE is common with the start point of the next SECTORLINE.

There is an easy way to create circle sectors without defining so many coordinates that form a circle on the screen. Just use the CIRCLE_SECTORLINE definition. Using that you can make a circular sector around any object (FIX, VOR, airport), or a coordinate defined in the line. In the first version it needs three parameters: sector line name, center point name, radius. In the second version it needs four parameters: sector line name, latitude, longitude, radius.

CIRCLE_SECTORLINE:LHBP_APP:LHBP:30
CIRCLE_SECTORLINE:LHBP_APP:N047.25.2.968:E019.21.31.221:30

Tips: A SECTORLINE is a border line which is common with only two lateral sectors.

SECTORLINE:BUDOP_LHCC
DISPLAY:BPT:BPT:BUD
DISPLAY:BPM:BPM:BUD
COORD:N046.37.12.101:E021.19.19.610
COORD:N047.29.04.510:E022.00.35.050
COORD:N047.57.13.950:E022.53.46.100

Translated this means: the SECTORLINE has been assigned a name of BUDOP_LHCC. It will be highlighted when condition [you are controlling BPT AND BPT and BUD sectors are controlled by different controllers] or [you are controlling BPM AND BPM and BUD sectors are controlled by different controllers]. The sector line is created by two segments, created by 3 coordinates/points.

You have the possibility to define the sectorline display away from the sectorline definition. We found that sometimes it is far easier to define this when defining the sectors. So whenever you need just add a DISPLAY_SECTORLINE entry (after the sectorline definition). Its syntax is the same as DISPLAY except that you have to define the sectorline name at the beginning.

DISPLAY_SECTORLINE:BUDOP_LHCC:BPM:BPM:BUD

The Sector Subsection

This is the subsection where you define the limits of a sector and controller assignments priorities.

SECTOR:MGT:34500:66000
OWNER:MGT:BPT:NIT:EUE
ALTOWNER:When no BPT:MGT:NIT:EUE
BORDER:MOPUG_LYBA:LOMOS_MOPUG:MOPUG_NERDI:BUDOP_MOPUG:MOPUG_LHCC

In the first line you declare the sector name and the vertical limits. Prefixed by SECTOR followed by the ‘:’ separator then the assigned Sector Name (MGT) then followed by the lower altitude limit in feet (34500) then the upper altitude limit in feet (66000).

The next line is prefixed by OWNER and defines which controller will be recognized ad controlling that respective sector and their priority. After the ‘:’ separator will follow a list of position identifiers from the Positions section. The first has most priority and the last, the least priority. For example if MGT position is identified as online by the Positions table, the MGT sector will be assigned to it. If not it will move on to the next position, verify it and if it is open the sector will be assigned to the BPT sector. This line also defines which sector you will be controlling when you are online as a specific position.

The alternate owner line (ALTOWNER) makes it possible to define an alternate setting of the sector ownership. The alternate rules can be selected at the [[Sector Ownership Setup]]. Its syntax is the same as the OWNER line with an additional name after the ALTOWNER tag.
Next follows the Border sector in which you define which borderlines make up the sector. Make sure a borderline and the next borderline have the end/start points common so it will be able to create a continuous border. Also make sure that it is a closed border, that is, that the last line ends at the start point of the first line.

The order of the sectors in the file is extremely important. EuroScope will check if an airplane is inside a sector in the order defined in the file. Therefore the first match will be used and the rest is not tested at all. You can use this behavior and create overlapping sectors. But be sure that the smaller is earlier in the list.

ACTIVE:LROP:08R

All sectors are active by default and are used in your session. However you may define sectors that are not always used but just in some runway configuration. After the ACTIVE keyword you should define the airport and runway configuration. The sector will then be used only if the specified runway at the specified airport is active for arrival or departure. An example is the Traffic Director in Hungary. He has the role to move the planes from downwind to the final and is used only on real busy events. Because of its role he controls at the arrival end of the active runway. But as the runways have two ends we defined two Traffic Director sectors, but only one of them should be used in one session.

GUEST:APP:LROP:LROP

The GUEST line is a formal way to handle exceptions to the general roles. After the keyword you should define a position a departure airport (or a * for all airports) and a destination airport (or a * for all airports). When an aircraft is flying in this sector and its current owner is the controller defined in this line and the departure and the destination airport match the flight plan then the sector owner will be the current controller. This may be a special solution to a normal situation over Slovak airspace. Normally this area is controlled by Prague, but the arrivals from Austria is passed to Budapest Radar even the route crosses this sector for a while and never enters to the sector of Budapest Radar, but goes directly to the Approach. So the Bratislava sector has a guest controller, Budapest Radar. And all arrival traffic to LHBP will accept it and EuroScope will not show the frequency of Prague indicating a necessary handoff.

DEPAPT:LHBP:LHDC:LHNY
ARRAPT:LHBP:LHDC:LHNY

The DEPAPT and the ARRAPT can be used to activate airports for departure and for arrival depending on what sectors belong to you. If there are airports defined for the sectors whenever you controlling sectors are changed the active airports data is updated. And as a side effect the your METAR list might be changed also as they depend on the active airports.

The Coordination Point Subsection

This section defines the COP (COordination Points) used for coordination with adjacent sectors and ACCs. Here you can also add LOA (Letter of Agreement) details and EuroScope will show you the appropriate action based on the LOA for each radar track.

Each line defines a different set of conditions for a LOA point to be recognized.

Syntax:

<TYPE>:<DEP|FIXBEFORE>:<DEP RWY>:<FIX>:<ARR|FIXAFTER>:<ARR RWY>:<FROM SECTOR>:<TO SECTOR>:<CLIMBLEVEL>:<DESCENDLEVEL>:<COPNAME>

• TYPE
  • COPX – The COPX points are considered for the Sector entry and exit points.
  • FIR_COPX – The FIR_COPX points also for the FIR exit points.
• DEP/FIXBEFORE
  • departure airport code
  • any point name on the route before the coordination point
  • * – any airport or point
• DEP RWY
  • departure runway
  • * – any runway
• FIX
  • the point name where this coordination point applies
  • * – any point
    Note: if ‘*’ is entered, the climb or descent altitudes for this coordination point have no effect on the aircraft profile calculation and are only used for display on the tags and aircraft lists. The point is used only in case the AC will leave FROM SECTOR and will enter to TO SECTOR in the future without additional sectors between.
• ARR/FIXAFTER
  • arrival airport code
  • any point name on the route after the coordination point fix
  • * – any airport or point
• ARR RWY
  • arrival runway
  • * – any runway
• FROM SECTOR and TO SECTOR
  • sector names – if these two sectors are owned by the same controller, this COPX line is bypassed
• CLIMBLEVEL
  • altitude to climb the aircraft to (in feet)
  • * – no climb level
• DESCENDLEVEL
  • altitude to descend the aircraft to (in feet)
  • * – no descent level
• COPNAME – name for the coordination point (usually the point name associated with it)

The COP lines have a priority from top to bottom. So the topmost line that verifies all rules will be chosen even if lower is a more suitable line which should be chosen. Therefore place the lines with most rules at the top and the lines with least rules at the bottom.

Examples:

FIR_COPX:*:*:BUDOP:LHBP:*:BPM:BUD:*:28000:BUDOP
FIR_COPX:*:*:NARKA:*:*:BPT:BUD:*:*:NARKA
FIR_COPX:*:*:NARKA:*:*:BUD:BPT:*:*:NARKA
COPX:*:*:NEPOT:*:*:BPT:NIT:*:*:NEPOT
COPX:*:*:NEPOT:*:*:NIT:BPT:*:*:NEPOT

The MSAW Subsection

This subsection defines the areas and their minimum safe altitudes for the MSAW (Minimum Safe Altitude Warning) system. When an aircraft is within one of the areas and below its minimum safe altitude, a yellow text MSAW is displayed in its tag above the callsign.

Each area must start with the following line:

MSAW:<Name>:<Altitude>

• Name – The name for the MSAW area.
• Altitude – Minimum safe altitude in feet within the area.

Then the actual area must be declared using coordinates. Each coordinate point must be declared with the COORD prefix then followed by the LATITUDE and then the LONGITUDE.

COORD:N047.59.23.032:E023.30.49.151

The COORD definition is identical to the one for SECTORLINEs.

The Radar Section

This section defines the radar coverage and radar outage areas used in Professional Mode by defining radar stations and radar holes.

The Radar section begins with the line:

[RADAR]

Then define each radar station. There are two ways to define a station. One has been available before but the other is new with EuroScope version 3.2

The New Radar Definition

RADAR2:<Name>:<Latitude>:<Longitude>:<P range>:<P altitude>:<P cone slope>:<S range>:<S altitude>:<S cone slope>:<C range>:<C altitude>:<C cone slope>

• Name – A user readable name of the station.
• Latitude and Longitude: The position of the radar station.
• P range – The primary radar range.
• P altitude – The altitude of the radar antenna in feet. It is used in a simplified formula for how to handle the curvature of the Earth(http://www.tscm.com/rdr-hori.pdf).
• P cone slope – It defines the slope of the cone of silence above the antenna in feet per nautical mile(http://www.radartutorial.eu/18.explanations/ex47.en.html). 3100 is a good value to here.
• S range – The S-mode transponder range. Our experience shows that S-mode transponder answers can be seen some 10-20% further away than primary radar positions.
• S altitude – The same as P altitude, but for the S-mode transponders.
• S cone slope – The same as P cone slope, but for the S-mode transponders.
• C range – The C-mode transponder range. Once again from real word experience we found that C-mode transponder answers can be seen nearly 200% the distance of the primary positions.
• C altitude – The same as P altitude, but for the C-mode transponders.
• C cone slope – The same as P cone slope, but for the S-mode transponders.

Some examples from Hungary:

RADAR:Püspökladány:N047.21.22.79:E021.02.39.55:140:2000:3100:180:2000:3100:250:1000:3100
RADAR:Kőris-hegy:N047.17.40.08:E017.45.13.65:140:2000:3100:180:2000:3100:250:1000:3100
RADAR:Ferihegy TAR:N047.25.36.182:E019.17.52.700:100:450:3100:120:450:3100:150:450:3100

HOLE:<P top>:<S top>:<C top>

• P top – The top of the radar hole for primary radar positions.
• S top – The top for the S-mode transponders.
• C top – The top for the C-mode transponders.

COORD:<latitude>:<longitude>
COORD:<latitude>:<longitude>

The COORD definition is identical to the one for SECTORLINEs.

The Old Radar Definition

This type of definition is treated as obsolete, but still available in v3.2.

RADAR:<Name>:<Latitude>:<Longitude>:<P range>:<P floor>:<P slope>:<S range>:<S floor>:<S slope>:<C range>:<C floor>:<C slope>

• Name – A user readable name of the station.
• Latitude and longitude – The position of the radar station.
• P range – The primary radar range.
• P floor – The minimal altitude of the radar positions. No plane below that will be seen as primary target. In this version the curvature of the earth is not used in the calculation, just the slope value. Please use the new version of the RADAR for the better simulation.
• P slope – This a linear slope that levels the visibility floor up by the distance. The value itself is the feet to be climbed in one NM. I used value 60 that levels the visibility floor from 2000ft to 11000 at 150 NM away.
• S range – The S-mode transponder range. Our experience shows that S-mode transponder answers can be seen some 10-20% further away than primary radar positions.
• S floor – The same as P floor, but for the S-mode transponders.
• S slope – The same as P slope, but for the S-mode transponders.
• C range – The C-mode transponder range. Once again from real word experience we found that C-mode transponder answers can be seen nearly 200% the distance of the primary positions.
• C floor – The same as P floor, but for the C-mode transponders.
• C slope – The same as P slope, but for the C-mode transponders.

Some examples from Hungary:

RADAR:Püspökladány:N047.21.22.79:E021.02.39.55:140:2000:60:180:2000:60:250:1000:60
RADAR:Kőris-hegy:N047.17.40.08:E017.45.13.65:140:2000:60:180:2000:60:250:1000:60
RADAR:Ferihegy TAR:N047.25.36.182:E019.17.52.700:100:1000:60:120:0:0:150:0:0

The ground taxi network

To make the ground plane movements more precise and more easy for the pseudo pilots, from v3.2 the ESE file has a complete new section. It should start with the

[GROUND]

section name.

Then define the complete TAXI network:

Runway exits

EXIT:<RWY name>:<exit name>:<direction>:<maximum speed>
COORD:<latitude>:<longitude>
...
COORD:<latitude>:<longitude>

The EXIT lines define RWY exits. When a simulated plane lands it looks for the exits along the RWY. It selects the first that is far enough to slow down and the direction is the one selected by the pseudo pilot. The plane decelerates to the given speed and follow the point of the exit route. EuroScope looks for the exit in the order they are defined in the file and selects the first one it can use. Therefore the order of the exit definitions are important. They should follow the distance order from the runway end.

• RWY name – The name of the RWY in the simulation.
• EXIT name – The name of the exit.
• Direction – It can be LEFT or RIGHT.
• Maximum speed – It defines the maximum speed of the AC during exiting the RWY.
  Note: The RWY exits should be defined with as many points as necessary for the smooth plane movements. ES simply calculates the speed, the distance, then the actual heading and moves the plane to there. Using huge turns makes the planes turning erratically, that destroys the tower view.

EXIT:31L:D:LEFT:20 COORD:N047.26.56.203:E019.13.14.197 COORD:N047.26.56.724:E019.13.12.426 COORD:N047.26.56.531:E019.13.10.935 COORD:N047.26.55.628:E019.13.08.998 COORD:N047.26.54.933:E019.13.08.118 COORD:N047.26.54.141:E019.13.07.751

Taxiways

To define the taxiways on the ground use the following lines:

TAXI:<TWY name>:<maximum speed>[:<usage flag>][:<gate name>]
COORD:<latitude>:<longitude>
...
COORD:<latitude>:<longitude>

• TWY name – The name of the taxiway. Use the following naming convention to enable the direct taxi instructions:
  • Use real name for full lenth taxiways: S, A2.
  • Use a / to define part of the taxiway: S/G42.
  • Use a - to define a taxiway connector: P1-P2.
• Maximum speed – It defines the maximum speed of the AC during taxiing on the TWY.
• Usage flag – This flag allows you to define sometimes common, sometimes separated taxi networks for different ground vehicles. A vehicle can use all the taxiways if the taxiway usage value of the vehicle with bitwise AND to this usage flag is not 0. Typically define all real taxiways with usage flag of 1. Then all ground car taxiways with 2. If there is a way that can be used both, then use the value 3 to allow it.
• Gate name – If the far end (last coordinate) is a gate or a stand, then mark it with the name. Be sure that the name starts with a letter (like G or S), to make it different from the usage flag that is a number. This end be used for other end points such as holding points, lineup or backtrack positions to have Direct Taxi capability to those positions: [[Running a simulator session / Ground Simulator Ribbon / Ground Simulator Ribbon]].

Notes: Taxiway should create a complete network. They MUST meet each other at their endpoints (the direction does not matter). If taxiways have joins, intersections, you should define the taxiways from the shortest pieces.

Same note as for the EXITs. The TWYs should be defined with as many points as necessary for the smooth plane movements.