Messages

Hi, I've added the option to control other ship light sequences in the code (see https://github.com/bridgecommand/bc/pull/83).

If you want to try this and have a GitHub account, you could download the automatically built (not code signed) installer from the artifacts section at https://github.com/bridgecommand/bc/actions/runs/16900762076

Alternatively, this will be in the next release.

Hi, this won't work at the moment, but is a good suggestion, and probably quite easy to add to the program.

I'll have a look next week and let you know.

Hi Pat,
I think the best way to use a 3d model as the terrain will be to use a 'dummy' height map image and settings in terrain.ini, to set the overall parameters (the image can be black, with SeaMaxDepth set to be at least as deep as your maximum depth).

You would then load the terrain model as a 'Land Object'. You will need to make sure you know where the model origin is, and set this as the land object position.

You will need to make sure the Radar, Collision and Absolute settings are all '1'.

Details of the parameters are in https://www.bridgecommand.co.uk/Doc/Current/WorldFileSpec.html

Let me know how this works!

Hello, apologies for the delay!

Is this an elevation map that you are trying to import? If so, the best way is generally to use a heightmap and texture (See https://www.bridgecommand.co.uk/Doc/WorldFileSpec.php) This should avoid problems with the texture not being loaded.

If you do want a 3d model, the 3ds format as used in Bridge Command should support textures. I'm afraid I'm not familiar enough with blender to know what set of options are needed. Quite a lot of other formats are also supported, including .obj (see the full list at https://irrlicht.sourceforge.io/?page_id=45#supportedformats), so it might be worth trying a few different options. Although a lot of the models used in Bridge Command are .x format, I don't think there's a lot of support in modern tools for exporting to this format any more.

Please let me know how you get on, and I may be able to provide more advice depending on exactly what you are trying to do.

Hello, for an existing ship, you can change or add the files BWave.wav for the wave sound, Horn.wav, Alarm.wav and Engine.wav within the own ship's folder (e.g. Models\Ownship\Protis\Engine.wav). If any of these are not present, Bridge Command will use the files in the Sounds folder in the installation directory.

If you want to change for an existing ship, you can either change the existing files, or copy the whole ship model into the local user directory (on windows this is "%appdata%\Bridge Command\5.9\Models\Ownship"), and change the files there.

Bridge Command uses Libsndfile to read the sound files, so most formats should be supported, please see http://libsndfile.github.io/libsndfile/formats.html.

However, note that all of the sound files must have the same number of channels (stereo or mono), and the same sample rate. We currently assume that the files have a .wav extension. If this is a problem, it's probably quite easy to recognise other extensions.

Hi, I don't have a copy of huckleberry's code, it might be best if you try sending a PM? If this doesn't work, let me know, but it is quite a while since I have worked on version 4.7!

Thanks, I've just added them.

Hi, the discussion above was related to an earlier version of Bridge Command that used UDP networking directly. The current version still uses UDP, but via the enet networking library, so you will need a python wrapper to this. I think pyenet may be what you need.

Depending on what you want to do, you can see the networking parts of Bridge Command in https://github.com/bridgecommand/bc/blob/main/src/NetworkPrimary.cpp, and for the map controller in https://github.com/bridgecommand/bc/blob/main/src/controller/Network.cpp.

Alternatively, it might be easier to modify OwnShip.cpp, either to do what you want directly, or to add an interface to your code.
   

Hi, if you are able to test the build from https://github.com/bridgecommand/bc/actions/runs/9454561364 that would be great (you will need a GitHub login to download the 'Artifact'. This is an automated build, and won't be code signed, but should otherwise be identical to the normal installer.

This build has some updated settings for the enet networking, which I hope will significantly help.

If this helps, I'll include this in an 'official' release shortly.

Thanks, I'll have a look, probably next week will be the earliest I can start. Does it work ok initially?

Hi, the only one I'm aware of being commercially available is from VRInsight, but is quite expensive. If you are interested in making one, any microcontroller with analog inputs and then can run CircuitPython (like the raspberry pi pico) can be used as an interface, as it supports the usb hid joystick interface.

Hello, I've added a new parameter that simply allows 'azimuth drives' to be engaged astern. This is the parameter 'AzimuthDriveAstern' in the own ship boat.ini file, and should be set as AzimuthDriveAstern=1 for your case. The change doesn't limit the range of allowed angles, but particularly if you are using a joystick input, this could easily be mapped to give you the angle range that you want.

This change isn't yet in a formal release on the website, as I'm trying to finish a few more things related to the VR implementation, but if you have a GitHub account, you should be able to download the automatically built installer (assuming you are on Windows) from https://github.com/bridgecommand/bc/actions/runs/9119286367 (look for the 'BC_windows' artefact. (Note that the automatic builds are not code signed, so you may need to click through various Windows warnings to install).

This also includes some improvements to the scenario editor for the initial course and speed of own ships.

Thanks. At the moment, to update the scenario with course or speed changes, you need to use the 'Change Leg' button for the 'Own Ship' settings, and either 'Change Leg' or 'Add Leg' button for other ships. In https://github.com/bridgecommand/bc/commit/0c2153d0a4794e1b3bbeaae038abea37e8fd5e51 I have changed this so for the 'Own Ship', the changes will take effect immediately. I have left it unchanged for 'Other Ships', because you may want to be adding a series of 'legs', and type in the values for the next leg.

I think the uninitialised value would depend on many things, as it depends on what happened to be in that memory location before. I have fixed this in https://github.com/bridgecommand/bc/commit/a536c8394efd79c1b06cfcfc23ed92c059b751de

I'm currently aiming to add a few updates to the VR interface, and will then put out an updated release.

Hi, thanks for pointing this out. I think that some of the data in the scenario editor may be uninitialised, which should be simple to fix.

If starting a new scenario, if you set the own ship speed and heading, then click 'Change leg', and save, does it work for you?

Hi, with a normal greyscale image, 0 represents -1*SeaMaxDepth, and 255 represents TerrainMaxHeight, with linear interpolation in between. This actually means that the 'half way' between max height and max depth is between 127 and 128 greyscale values.

I made a simple calculator at https://www.bridgecommand.co.uk/data/_uploaded/file/Height%20conversions_255.xlsx which might be useful.

The relatively small number of steps available in a greyscale image is why there is also the 'RGB' encoding (height in metres is set by (red * 256 + green + blue / 256) - 32768), or raw 32 bit floating point format available, which both allow a much finer elevation step.