Why Gemfury?
Push, build, and install
RubyGems
npm packages
Python packages
Maven artifacts
PHP packages
Go Modules
Debian packages
RPM packages
NuGet packages
marcdupain
marcdupain / bridgecommand deb
Repository URL to install this package:
|
Version:
5.8.9 ▾
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<!-- ======================================================= --><!-- Created by AbiWord, a free, Open Source wordprocessor. --><!-- For more information visit http://www.abisource.com. --><!-- ======================================================= -->
<meta http-equiv="content-type" content="text/html;charset=UTF-8">
<title>World file specification.html</title>
</head>
<body style="color: rgb(0, 0, 0); background-color: rgb(221, 221, 221);" alink="#000099" link="#000099" vlink="#990099">
<div style="text-align: center;">
<h1>Bridge Command 5 related files specification</h1>
<h2>World file</h2>
</div>
<p>Please refer to the <a href="IniFileFormat.html">Initialisation file format (.ini) specification</a> in conjunction with this document.</p>
<h3>Introduction:</h3>
<p>The world model defines the environment of a scenario, and uses a heightmap to set the terrain and bathymetry. In addition, a texture file
is used to set the terrain colouring, and configuration files control how the environment is loaded, and other features such as buoys, landmarks
and lights etc. A 'map' image is also used to display as a 2d view in the scenario editor and map controller.
</p>
<p>
A primary terrain must be defined, and any number of additional areas may be defined. The intention is for the primary terrain to cover the
entire area defined, and for secondary terrains to be used to give higher resolution models of some areas if required. To allow the secondary
terrain to be seen, the primary terrain must be below the height of the secondary in this area. The programme will prioritise the shallowest
terrain when taking depth soundings, and to decide if the ship is aground.
</p>
<p>
For small details such as harbours and marinas, 3d models can be loaded into the world model. See the detail below in the landobject.ini
for how land objects can be set to appear in the radar, and act as physical models that the own ship can interact with.
</p>
<p>
A variety of formats can be used for the height maps. The simplest is a greyscale png image, with black representing the deepest point, and
white representing the highest point. A standard greyscale png can represent 255 shades from black to white, so if you need finer elevation
steps (for example if you have high mountains within the world area), another format may be better. These are:
<ul>
<li>RGB encoded png, which uses the red, green and blue channels to encode the height directly.</li>
<li>A binary height matrix, either signed 16 bit integers, or 32 bit floating point, giving the height in metres.</li>
</ul>
</p>
<p>
The world model is made up of files in a common folder. The folder name is used when loading the world model, and is found under <i>World</i>
in the <i>Bridge Command</i> root folder. For example, if <i>Bridge Command</i> is installed in <i>C:\Program files (x86)\Bridge Command 5.x</i>, the
files making up a world model called <i>Atlantis</i> would be in <i>C:\Program files (x86)\Bridge Command 5.x\World\Atlantis</i>. To allow users to
edit or add world models without changing the overall installation, Bridge Command will look first in the user directory for a world model, and
will use this in preference to the global model. The user directory can be found using the button on the Bridge Command launcher.
</p>
<p>
The terrain is loaded from two files, a height map and a texture. The shape of the terrain is generated from a height map, in which the
colour of each pixel in the image is translated into a height value for that terrain location. The height map should be a greyscale PNG image,
and black is low and white is high, or for better height resolution, you can use the RGB format where the height in metres is encoded as
(red value * 256 + green value + blue value/ 256) - 32768.
</p>
<p>
It is recommended to use .png format for the heightmap images, as .bmp files may give inaccurate heights in some cases (depending on the exact
type of .bmp images used).
</p>
<p>
Alternatively, a raw binary format is allowed. Bridge Command will load files with the standard 3dem header and binary format (.hdr and .bin). Also, height
maps with the extension .f32 will be interpreted as a list of heights in metres as 32 bit floating point numbers. The benefit of both the RGB encoding and
the binary format is a higher vertical resolution of height map, which may be helpful if your area includes deep sea and high mountains.
</p>
<p>
The terrain generated from the height map is coloured with a texture image, and then the additional features are loaded into the world as
configured in the .ini files.</p>
<h3><span style="font-weight: bold;" lang="en-GB">The files:</span></h3>
<p>The constituent files are listed below, with their purpose. Each is dealt with in detail below</p>
<h4>Configuration:</h4>
<p>
<ul>
<!--TODO: Check case of these file names-->
<li>terrain.ini: Specifies terrain areas, and what image files to build them from.</li>
<li>buoy.ini: Specifies buoys and other floating, fixed objects in the world.</li>
<li>landobject.ini: Specifies fixed, land based objects in the world.</li>
<li>light.ini: Specifies navigation lights in world (floating or land based)</li>
<li>tide.ini: Defines the tides</li>
<li>tidalstream.ini: Defines the tidal stream (optional)</li>
<!--<li>RadarReflector.ini: Defines location of fixed radar reflecting objects (Optional)</li>-->
<!--<li>Description.ini: A brief description of the world model (Optional)</li>-->
<!--<li>Thumb.bmp: A thumbnail image (Optional)</li>-->
</ul>
</p>
<h4>Height maps:</h4>
<p>
The filenames for the height map and texture files are as specified in <i>terrain.ini</i>. The heightmap should be in .png or raw binary
format (3dem format with a .bin and .hdr file, or 32 bit floating point file with extension .f32), and the texture and map image should generally
be square and power of two (2^n) sizes (512, 1024, ...).
The heightmap does not have to be square, but internally Bridge Command uses square terrain models with 2^n + 1 in size (513, 1025, 2049, ...).
Therefore it is less efficient to define a heightmap slightly larger than one of than this size, as it will be padded to fit the next largest square.
</p>
<p>
</p>
<h4>File details:</h4>
<h5>terrain.ini</h5>
<p>Example</p>
<pre>
Number=2
MapImage="map.bmp"
HeightMap(1)="height.png"
Texture(1)="texture.bmp"
TerrainLong(1)=-10
TerrainLat(1)=50
TerrainLongExtent(1)=0.05010
TerrainLatExtent(1)=0.04008
TerrainMaxHeight(1)=100
SeaMaxDepth(1)=44.07
HeightMap(2)="detail.png"
Texture(2)="detailTexture.png"
TerrainLong(2)=-9.992284795
TerrainLat(2)=50.006875322
TerrainLongExtent(2)=0.006250292
TerrainLatExtent(2)=0.005000234
TerrainMaxHeight(2)=100
SeaMaxDepth(2)=44.07
</pre>
<p>
<ul>
<li>Number: The number of height maps used (normally 1)</li>
<li>MapImage: File name of image used in 2d views (scenario editor, map controller)</li>
<li>For each terrain area, at least 1 required, where # is the number of the terrain (1, 2, ...)
<ul>
<li>HeightMap(#): Height map file name (.png, .hdr or .f32)</li>
<li>Texture(#): Texture file name</li>
<li>TerrainLong(#): Longitude of the south west corner of the terrain area (Decimal degrees, East positive)</li>
<li>TerrainLat(#): Latitude of the south west corner of the terrain area (Decimal degrees, North positive)</li>
<li>TerrainLongExtent(#): Extent of the terrain in decimal degrees (East-West)</li>
<li>TerrainLatExtent(#): Extent of the terrain in decimal degrees (North-South)</li>
<li>TerrainMaxHeight(#): The height in metres represented by a pure white pixel on the heightmap image (ignored for RGB encoded or binary heightmap)</li>
<li>SeaMaxDepth(#): The depth in metres represented by a pure black pixel on the heightmap image (ignored for RGB encoded or binary heightmap)</li>
<li>(Optional) UsesRGB(#): This should be set to 1 if the heightmap is encoded in the RGB format where the height in metres is set by (red * 256 + green + blue / 256) - 32768. Set to 0 otherwise</li>
</ul>
</li>
</ul>
<p>If the .f32 format is used, two additional parameters, TerrainHeightMapRows and TerrainHeightMapColumns are needed to specify the shape of the binary matrix.</p>
<p>Note that if you are using a 3dem .bin and .hdr file, set the HeightMap name as the .hdr file. In this case, the entries
TerrainLong, TerrainLat, TerrainLongExtent and TerrainLatExtent are not required, as they are included in the .hdr file
from 3dem.
</p>
<h5>buoy.ini</h5>
<p>Contains 1 general variable, and a set of 3 to 6 variables for each buoy defined. The global variable is Number, which is the number of
buoys to be defined in the file. This can be zero, in which case no buoys are defined, and nothing further is required in this file. The three
required variables for each buoy are Type(#), Long(#) and Lat(#). Type(#) takes the buoy type, as a text string. This must correspond to an
available buoy model as defined in the <i>Models\Buoy</i> folder under the Bridge Command root directory.
Long(#) and Lat(#) take respectively the buoy's Longitude and Latitude in standard decimal degrees. Note that only the buoy model and its
location is specified here - if the buoy has a light attached, it must be specified in <i>light.ini</i>, as specified below.
The first optional variable is RCS(#), which sets the buoy's radar cross section in metres squared. If not set, a default value will be used.
The second optional variable is Grounded(#). If set to 1, this means that the 'buoy' will not respond to wave or tide, for example
for a post. The third optional variable is HeightCorrection, which adjusts the vertical position of the buoy, and is set in metres, with a positive
value moving the 'buoy' higher. Again this is useful for adjusting the height of a post.</p>
<p>Note that a folder <i>Models/Buoy</i> can be created in the world model folder to hold buoys required for this world model. </p>
<h5>Example buoy.ini, setting up three buoys:</h5>
<pre>Number=3<br><br>Type(1)="Port"<br>Long(1)=-4.135<br>Lat(1)=52.407<br><br>Type(2)="RY"<br>Long(2)=-4.299<br>Lat(2)=55.004<br>RCS(2)=3.5<br><br>Type(3)="Mooring"<br>Long(3)=-4.505<br>Lat(3)=52.702</pre>
<h5>landobject.ini</h5>
<p>The analog of <i>buoy.ini</i>, but for fixed objects, either on land or ground based object at sea
(breakwaters etc). Contains 1 general variable, and a set of 5 to 6
variables for each land object defined. </p>
<p><i>Number</i> sets the number of objects to be defined.This can be zero, in which
case no land objects are defined, and nothing further is required in
this file.</p>
<ul>
<li><i>Type(#)</i> is defined in the same way as for buoys, except that the available land objects are located in the <i>LandObject</i> folder under <i>Models</i> in the Bridge Command root folder.</li>
<li><i>Long(#)</i> is defined in the same way as for buoys.</li>
<li><i>Lat(#)</i> is defined in the same way as for buoys.</li>
<li><i>Rotation(#)</i> allows for the model to be rotated about its vertical axis. Specified in degrees. An anticlockwise rotation, as viewed from the top, is positive.</li>
<li><i>HeightCorrection(#)</i> allows for the model to be moved up or down. so it sits properly on the land. A positive value moves the object upwards, and is in metres.</li>
<li>Optional setting <i>Absolute(#)</i>. If this set to 1, then the object will be loaded at a height relative to chart datum, not relative to the local ground level.</li>
<li>Optional setting <i>Collision(#)</i>. If this is set to 1, then collision modelling with the own ship will be enabled for this object.</li>
<li>Optional setting <i>Radar(#)</i>. If this is set to 1, then the object will be included in the radar scan.</li>
</ul>
<p>Note that a folder <i>Models/LandObject</i> can be created in the world model folder to hold land objects required for this world model. </p>
<h5>Example landobject.ini</h5>
<pre>
Number=5
Type(1)="lighthouse"
Lat(1)=33.30200
Long(1)=-118.31758
Rotation(1)=0
HeightCorrection(1)=64.62
Absolute(1)=1
Type(2)="lighthouse"
Lat(2)=33.40618
Long(2)=-118.36655
HeightCorrection(2)=21.64
Rotation(2)=0
Absolute(2)=1
Type(3)="lighthouse"
Lat(3)=33.46322
Long(3)=-118.49170
HeightCorrection(3)=22.86
Rotation(3)=0
Absolute(3)=1
Type(4)="lighthouse"
Lat(4)=33.47873
Long(4)=-118.60573
HeightCorrection(4)=23.16
Rotation(4)=0
Absolute(4)=1
Type(5)="lighthouse"
Lat(5)=33.42338
Long(5)=-118.51390
HeightCorrection(5)=121.92
Rotation(5)=0
Absolute(5)=1
</pre>
<h5>light.ini</h5>
<p>This
specifies navigation lights in the environment. These can either be
floating, maintaining its height above the water level - the location
of these are defined by selecting the buoy number (as in buoy.ini) to
which the light should be attached, or fixed. Fixed lights can be set
to be either above the surrounding land height, or at an absolute
height (Above the programme datum - equivalent to Chart datum). The
position of fixed lights are defined by their latitude and longitude.
There is one general variable, <i>Number</i> which as usual sets the
number of lights to be defined. This can be zero, in which case no lights
are defined, and nothing further is required in this file. The variable
names for each light are:</p>
<p>
<ul>
<li>One of:
<ul>
<li>Long(#) and</li>
<li>Lat(#)</li>
</ul>
</li>
<li>or
<ul>
<li>Buoy(#)</li>
</ul>
</li>
<li>Height(#)</li>
<li>Red(#)</li>
<li>Green(#)</li>
<li>Blue(#)</li>
<li>Range(#)</li>
<li>Sequence(#)</li>
<li>(optional) PhaseStart(#)</li>
<li>StartAngle(#)</li>
<li>EndAngle(#)</li>
</ul>
</p>
<p>
<i>Long(#)</i> and <i>Lat(#)</i> set the light's position in the usual way. <i>Height(#)</i>
sets the height in metres above the water for a 'floating' light or
above the ground for a fixed one. If Absolute(#)=1 is set, then the
height will be above chart datum.
</p>
<p>
<i>Red(#)</i>, <i>Green(#)</i> and <i>Blue(#)</i>
together set the colour of the light, in terms of an RGB colour code,
where each takes a value between 0 and 255, with 0 showing none of that
colour and 255 being fully bright in that colour. (Tip - use a
painting/photo editing programme such as MS Paint to find the RGB
values, using the 'Define custom colors' dialog box, accessed in MS
Paint by double clicking on the colour selector at the bottom). <i>Range(#)</i> sets the range of the light in nautical miles, within which the light can be seen.
</p>
<p>
<i>Sequence(#)</i>
is set as a text sequence of 'L' and 'D's. The case is not significant.
Each character represents a quater of a second of the sequence, and 'L'
represents the light being on, and 'D' is off. When the end of the
sequence is reached, the sequence restarts. So for example, <i>Sequence(#)="LLLDDDDDD"</i>
represents 0.75 seconds where the light is on, followed by 1.5 seconds
where it is off, then restarting with 0.75s of light and so on. So for
a fixed (constant) light, <i>Sequence(#)="L"</i> is all that is required, and to get a light occulting with 1s of light and 1s of darkness, <i>Sequence(#)="LLLLDDDD"</i> would work. The optional variable PhaseStart(#) sets which 'step' the light starts on, and should be given as an integer between 1 and the length of the sequence. For example, if you want two lights synchronised, you can give them the same sequence and set both to have a PhaseStart(#) of 1.
</p>
<p>
To allow for sector lights, a light start and end angle are defined by <i>StartAngle(#)</i> and <i>EndAngle(#).</i> The light is visible between the <i>StartAngle(#)</i> bearing and <i>EndAngle(#)</i>, going clockwise. Therefore, <i>StartAngle(#)=0</i> and <i>EndAngle(#)=90</i> would show a light shining between North and East, as seen on a chart or from above the light. For an all round light, <i>StartAngle(#)=0</i> and <i>EndAngle(#)=360</i> should be used. The <i>EndAngle(#)</i> value must be greater than the <i>StartAngle(#)</i>.
Therefore, angles can be defined in the range 0-720, so a light shining
northwards and visible 20 degrees on either side would be defined by a <i>StartAngle(#)</i> of 340 and an <i>EndAngle(#)</i> of 380.
</p>
<!--<p>
The last variable is <i>Floating(#)</i>,
which should be set to 1 if the light should maintain its height above
the water (if it is a buoy's light for example), and to 0 if it should
be at the defined hight relative to the land at its position.
</p>-->
<h5>Example light.ini</h5>
<pre>Number=2<br><br>Buoy(1)=2<br>Height(1)=8<br>Red(1)=0<br>Green(1)=255<br>Blue(1)=0<br>Range(1)=20<br>Sequence(1)="lldddd"<br>StartAngle(1)=45<br>EndAngle(1)=315<br><br>Long(2)=50.2<br>Lat(2)=-34.6<br>Height(2)=3<br>Red(2)=255<br>Green(2)=0<br>Blue(2)=0<br>Range(2)=20<br>Sequence(2)="lllldd"<br>StartAngle(2)=0<br>EndAngle(2)=360</pre>
<h5>tide.ini</h5>
<p>
Bridge Command defines the tide in terms of it's harmonic constituents, which each have an amplitude, speed and offset. This means that any tide of any complexity can be modelled. Currently there is only one set of tidal characteristics, which apply across all of the environment model. The amplitude is set in metres, and is half the range of the component. The speed is set in degrees/hour, where one full period is 360 degrees. So for example, the main component of a tide, which has approximately two highs and two lows in a 25 hour period would have a speed of around 28.8 degrees/hour. The offset is how much the tidal component is shifted in degrees, relative to a component that had a peak at 0000 on the morning of the 1st January 1970 (used as Bridge Command's time reference point).
</p>
<p>
Harmonic 0 sets the constant part of the tide, and all other components set the time-varying parts, which have a mean height of zero.
</p>
<p>
There is one general variable, and there are 3 variables for each harmonic. The global
variable is <i>Harmonics</i>, which defines the number of harmonic components modelled. Then for # = 0 to <i>Harmonics</i>, more three more variables must be set, which are:
<ul>
<li>Amplitude(#): The amplitude of the component (metres)</li>
<li>Offset(#): The offset in degrees (see above for discussion): Not required for harmonic 0</li>
<li>Speed(#): The component's speed in degrees/hour (see above for discussion): Not required for harmonic 0</li>
</ul>
</p>
<h5>Example tide.ini:</h5>
<p>
<pre>
Harmonics=4
Amplitude(0)=3.40480
Amplitude(1)=1.68500
Offset(1)=319.23
Speed(1)=28.984104
Amplitude(2)=0.60460
Offset(2)=206.87
Speed(2)=30.000000
Amplitude(3)=0.31850
Offset(3)=408.04
Speed(3)=28.439730
Amplitude(4)=0.17370
Offset(4)=411.51
Speed(4)=30.082137
</pre>
</p>
<h5>tidalstream.ini</h5>
<p>This is an optional file, and defines the tidal stream by specifying the speed and direction at one or more positions, at each hour before and after high tide.
</p>
<p>There are three general variables, <i>number</i> to set the number of locations where the tidal stream will be defined, then <i>MeanRangeSprings</i> and <i>MeanRangeNeaps</i> specifying the mean tidal range at springs and neaps. These are used to calculate how to interpolate between the neaps and springs speeds.</p>
<p>For each location where the tidal stream is specified, the speed and direction must be given for each hour from 6 hours before high tide to 6 hours after high tide.
For each hour, the direction of tidal flow is defined with <i>Direction</i> (the direction the tide is flowing to), and the speed (in knots) is defined for springs with <i>SpeedS</i> and neaps with <i>SpeedN</i>.
</p>
<h5>Example tidalstream.ini:</h5>
<p>
<pre>
Number=2
MeanRangeSprings=5
MeanRangeNeaps=2
Long(1)=-9.9688
Lat(1)=50.0091
SpeedN(1,-6)=0.1
SpeedN(1,-5)=0.5
SpeedN(1,-4)=1
SpeedN(1,-3)=1.5
SpeedN(1,-2)=1
SpeedN(1,-1)=0.15
SpeedN(1,0)=0.1
SpeedN(1,1)=0.2
SpeedN(1,2)=1.2
SpeedN(1,3)=1.5
SpeedN(1,4)=1
SpeedN(1,5)=0.6
SpeedN(1,6)=0.2
SpeedS(1,-6)=0.2
SpeedS(1,-5)=1.1
SpeedS(1,-4)=2.0
SpeedS(1,-3)=2.8
SpeedS(1,-2)=2
SpeedS(1,-1)=0.35
SpeedS(1,0)=0.12
SpeedS(1,1)=0.43
SpeedS(1,2)=3.0
SpeedS(1,3)=4.0
SpeedS(1,4)=2.8
SpeedS(1,5)=2
SpeedS(1,6)=0.5
Direction(1,-6)=300
Direction(1,-5)=330
Direction(1,-4)=340
Direction(1,-3)=350
Direction(1,-2)=340
Direction(1,-1)=330
Direction(1,0)=260
Direction(1,1)=190
Direction(1,2)=180
Direction(1,3)=170
Direction(1,4)=180
Direction(1,5)=190
Direction(1,6)=260
Long(2)=-9.9701
Lat(2)=50.0113
SpeedN(2,-6)=0.1
SpeedN(2,-5)=0.5
SpeedN(2,-4)=1
SpeedN(2,-3)=1.5
SpeedN(2,-2)=1
SpeedN(2,-1)=0.15
SpeedN(2,0)=0.1
SpeedN(2,1)=0.2
SpeedN(2,2)=1.2
SpeedN(2,3)=1.5
SpeedN(2,4)=1
SpeedN(2,5)=0.6
SpeedN(2,6)=0.2
SpeedS(2,-6)=0.2
SpeedS(2,-5)=1.1
SpeedS(2,-4)=2.0
SpeedS(2,-3)=2.8
SpeedS(2,-2)=2
SpeedS(2,-1)=0.35
SpeedS(2,0)=0.12
SpeedS(2,1)=0.43
SpeedS(2,2)=3.0
SpeedS(2,3)=4.0
SpeedS(2,4)=2.8
SpeedS(2,5)=2
SpeedS(2,6)=0.5
Direction(2,-6)=300
Direction(2,-5)=330
Direction(2,-4)=340
Direction(2,-3)=350
Direction(2,-2)=340
Direction(2,-1)=330
Direction(2,0)=260
Direction(2,1)=190
Direction(2,2)=180
Direction(2,3)=170
Direction(2,4)=180
Direction(2,5)=190
Direction(2,6)=260
</pre>
</p>
<!--
<h5>RadarReflector.ini</h5>
<p>This is an optional file, which specifies fixed radar reflectors in the
environment. For example, if you have a lighthouse in the sea, if you do not
add a radar reflector at its location, it will not appear on the radar picture.
It is also used to add RACONs to buoys.
</p>
<p>
There is one general
variable, and there are two or three variables for each radar reflector defined. The global
variable is <i>Number</i>,
which as usual sets the number of radar reflectors to be defined. This can be
zero, in which case no radar reflectors are defined, and nothing further is
required in this file. The variable names for each reflector are:</p>
<p>
<ul>
<li>Height(#): The height of the radar reflector in metres above sea level</li>
<li>One of:
<ul>
<li>Long(#) and</li>
<li>Lat(#)</li>
</ul>
</li>
<li>or
<ul>
<li>Buoy(#)</li>
</ul>
</li>
<li>(Optional) RCS(#)</li>
<li>(Optional) RACON(#)</li>
</ul>
</p>
<p>
<i>Long(#)</i> and <i>Lat(#)</i> set the reflector's position in the usual way. Instead of Long(#)
and Lat(#), Buoy(#) may be defined, which links the reflector to the buoy chosen. So setting Buoy(#)=4 would place the radar reflector on buoy 4, as defined in Buoy.ini. In general, this option will be used with the RACON option, to add a RACON to a buoy. If the RACON option is specified, this should be one or two letters, giving the RACON code, which will be shown in morse code on the radar display. RCS is an optional variable, which sets the reflector's effective radar cross section in metres squared. If not set, a default value of 5 will be used.
</p>
<h5>Example RadarReflector.ini</h5>
<pre>Number=2<br><br>Buoy(1)=2<br>Height(1)=3<br>RACON(1)="B"<br><br>Long(2)=50.2<br>Lat(2)=-34.6<br>Height(2)=5<br>RCS(2)=2</pre>
<h5>Description.ini</h5>
<p>This is optional, and is the simplest file, just a plain text file of up to 12 lines in which you can describe the world area. This is displayed when the user is selecting which world model to load. This file is not strictly required, but useful if you want to put in some information for the user. Each line should be a maximum of 57 characters for all of the content to be visible.
</p>
<h5>Thumb.bmp</h5>
<p>
This is optional, and is a thumbnail image that will be displayed to the user when selecting the world model.
</p>
-->
<h3>Conclusion</h3>
If you have any questions, please ask the author - <a href="mail.php" onmouseover="this.href='mai' + 'lto:' + 'help' + '@' + 'bridgecommand.co.uk'">send
me an email</a>, or ask on the <a href="https://www.bridgecommand.co.uk/forum">Forum</a></p>
</body>
</html>