Short answer:

Use IPv4 whenever you can, it is more effective and has less overhead.

IPv6 has only been implemented in case s/o faces a situation where IPv4 is no longer available.

Slightly longer answer:

Getting IPv6 to work is not trivial on Windows. IPv6 has a feature called “privacy extensions”, which is enabled on Windows by default (on purpose). This means it assigns TWO “externally visible” IPv6 addresses, one permanent one, and a temporary one that changes with each reboot. With “privacy extensions” enabled, ONLY the temporary one will be allowed to accept incoming connections. That means you can NOT properly use the permanent IPv6 address, which seems counter-intuitive, but this is indeed working as designed. So, for local servers/clients, if you want to use IPv6 (which, as pointed out above is completely non-sensical if IPv4 is still available), make sure to specify the temporary addresses, not the permanent ones. If you want to connect ppl from the internet, there is no NAT’ing in IPv6, only firewall configs in the router to allow data to come through. This is not port forwarding at all. However, in order to connect from the outside world to a temporary IPv6 address inside your local network, the router also needs to be configured to let pass “echo requests”, usually that means allowing all ICMP packages. And your router usually refers to the PC in the network with the permanent addresses, not the temporary ones. So that means that you probably need to manually add the IPv6 addresses for your local PCs, because your router does not even list them. Last not least, the Windows firewall also has echo requests disabled by default on IPv6, so you need to allow this locally on your Windows PCs as well. Another option to simplify all this would be to disable the “privacy extensions”, but that would pose quite some security risk (as ppl would now permanently be able to reach your PC, at least if the firewall is open. It is not “disguised” anymore like it has been the case with IPv4 NAT’ing).

All in all: IPv6 is more complex to setup than IPv4, and you HAVE to educate yourself properly in case you ever want to use IPv6. But, again, if you can use IPv4, there is no need at all to migrate to IPv6.

If you want to add your own squadron patch or pilot picture to the sim, here’s a step-by-step howto:

1) Get a nice high-res version of your logo/patch:

2) Extract the actual logo, i.e remove the background, and scale it down in such a way that the longest side is 96 pixels (max 96x96):

Note: it is important NOT to use aliasing for the edges of the logo! BMS does not support “partial transparency”, i.e. a pixel can either be solid, or transparent. No “blending” between transparency and pixel color is allowed. Usually, this is achieved by scaling with “nearest neighbor” as opposed to the usual “bicubic”. So your scaled down logo should look like this:

3) Fill up the background - or anything that should be transparent in the final logo - with “pure magenta” (R 255, G 0, B 255):

Again, it is important NOT to use aliasing for the edges:

4) Save the final result as TGA/Targa file with 16bits/pixel and w/o RLE compression, and with a “.tga” extension:

This file here is the result in my example case, just for your reference:
MyLogo.tga

5) Copy the new file into the appropriate BMS directory.

For squadron patches, this would be:
<bms>\User\Patches</bms>

For pilot pictures, this would be:
<bms>\User\Pictures</bms>

6) Fire up BMS, open the logbook and the list of available patches should pick up your new picture automatically. There is NO NEED to fiddle around with “resource tools” or other stuff!

Enjoy your new patch!

FYI, I’ve added some missing info about RakNetDefineOverrides.h at compile time to the post above, as well as UDP multicast info.

A quick follow-up:

The upcoming RTTServer/RTTClient v3.3 (which will be part of 4.35 U1) bumps the RTT_VERSION to 33U.

Before you ask, no, there will be no actual network message format changes, but that particular datum is used for other purposes as well and hence will be bumped with each major & minor version (however not micro & patch).

I’ve finished the writeup of the RTT network formats, you’ll find it in the upcoming U1 in <bms>\Tools\RTTRemote*RTTNetData.h*</bms>.

However, since the info is neither secret nor new, RTTServer is released and available to be used, I can make it available here already:

Also, for the real nerds, RTTServer v3.3 will also support UDP multicast in addition to the RakNet protocol (however only for shared mem data, not RTT):

/* Dunc, January 2021, on behalf of Benchmark Sims
 *
 *
 * Upfront note: in *addition* to the regular RTTServer/RTTClient network
 * protocol described here, *custom* remote shared men clients may also receive
 * the data by means of UDP multicast on plain sockets independent of RakNet.
 * Please see the "MULTICAST.txt" document for further information.
 *
 *
 * This document defines/describes the network message format that RTTServer is
 * using to communicate with RTTClients. You can use this information to build
 * your own RTTClient receiver applications.
 *
 * The transport layer is implemented on top of RakNet 4.081, i.e. your client
 * must use RakNet to implement the network connectivity. The official source
 * repository is located here:
 * https://github.com/facebookarchive/RakNet
 *
 * However, it is strongly advised to use the "larku" fork as the basis for your
 * implementation, as it includes the most pressing bug fixes:
 * https://github.com/larku/RakNet
 *
 *
 * The following options need to be set in "RakNetDefinesOverrides.h" to make it
 * compatible at with RTTServer at compile time:
 *
 * #define RAKNET_SUPPORT_IPV6 1
 * #define USE_SLIDING_WINDOW_CONGESTION_CONTROL 0
 *
 *
 * Connect/disconnect handling should be purely handled by RakNet means, there
 * is no further RTT specific message handling needed (i.e. you can ignore the
 * message types MSG_CONNECT and MSG_DISCONNECT in the enum below, they are only
 * used internally in the native RTTServer/RTTClient).
 *
 *
 * After the initial network connection is established, the message flow is as
 * follows:
 *
 * 1) The client sends an initial MSG_HANDSHAKE message to tell the server what
 *    data exactly it *requests*.
 * 
 * 2) The server will send back an MSG_HANDSHAKE message with the *actual* data
 *    that it will send to the client during the session.
 *
 * 3) The server will send out MSG_IMAGE (RTT) and/or MSG_DATA (SharedMem)
 *    messages to the client continuously once it detects that BMS is providing
 *    the data. This is the "main message loop" (albeit one-way only). Note that
 *    IMAGE/DATA messages are sent unreliable, but ordered. That means that
 *    while it is possible for the server to skip sending out messages (e.g. due
 *    to network congestion), it is nevertheless ensured that each message the
 *    client receives is always *newer* than the previous one.
 *
 * 4) If a client disconnects or loses connection, it has to start out at step 1
 *    again to re-initiate the message flow.
 *
 *
 * Since RakNet is used as the transport layer, all messages you receive are of
 * type "RakNet::Packet". Each RN packet holds its payload in an array of type
 * "unsigned char", called "data", which you must evaluate and handle
 * accordingly (this is not RTTServer/Client specific, but generic RakNet
 * functionality).
 *
 * In the following, I will describe the various data contents for each message
 * type. Note that I will only identify the *starting* fields in the data array,
 * you can deduce the length of the data from the data types itself.
 *
 * RakNet stores the message type in data[0]. It uses a sizable number of
 * internal message types that get evaluated by RN automatically. Other internal
 * RN message types need to be handled by *you* (e.g. connect/disconnect/already
 * connected/request accepted/denied...) in order to enable your client to track
 * the connection status to the server from a *business* point of view. Check
 * out the various RakNet examples in case you need more info on this.
 *
 * (Note: you will never see an actual IP address in our payload "data". If you
 * want to know where a packet came from, you need to evaluate the
 * "systemAddress" field in the "RakNet::Packet".)
 *
 * Last not least, it can hold custom message types, in our case MSG_HANDSHAKE,
 * MSG_DATA, MSG_IMAGE.
 *
 * 
 * MSG_HANDSHAKE messages are composed as follows:
 *
 * data[0] = MSG_HANDSHAKE
 * data[sizeof(MESSAGE_TYPE)] = <struct handshake="">
 *
 * The "struct HANDSHAKE" needs to hold the following info (check below):
 *
 * BYTE rttVersion = RTT_VERSION
 * (If there is a mismatch between the server version and the client version,
 * the server will not send out any data to the client.)
 *
 * BYTE fps = <how often="" will="" the="" image="" data="" be="" sent?="">
 * (The client does not need to specify a value here. It is the server who
 * provides this info to the client in its MSG_HANDSHAKE response. This info can
 * be used by the client program to optimize message polling and or render
 * update cycles.)
 *
 * BYTE useData[DATA_NUM] = <which sharedmem="" areas="" are="" requested="" by="" the="" client?="">
 * (The client needs to set a non-0 value to the fields in the array that
 * correspond to the data areas it wants to receive. Check the "enum SMEM_DATA"
 * below.)
 *
 * BYTE useDisp[DISP_NUM] = <which rtt="" images="" are="" requested="" by="" the="" client?="">
 * (The client needs to set a non-0 value to the fields in the array that
 * correspond to the RTT images it wants to receive. Check the "enum RTT_DISP"
 * below.)
 *
 * Note that the MSG_HANDSHAKE response message from the server might send back
 * different info than originally set by the client. This is to inform the
 * client about the actual data it will be sending. For example, if the server
 * detects a version mismatch, it will set ALL useData/useDisp fields to 0,
 * because it will not send out any data at all.
 *
 *
 * MSG_DATA messages are composed as follows:
 * 
 * data[0] = MSG_DATA
 * data[sizeof(MESSAGE_TYPE)] = <which sharedmem="" area="" are="" we="" sending?="">
 * (Check the "enum SMEM_DATA" below for possible values.)
 *
 * data[sizeof(MESSAGE_TYPE) + sizeof(SMEM_DATA)] = <the actual="" sharedmem="" data="">
 * (The actual SharedMem object names, their composition and sizes are defined
 * in the "FlightData.h" file in the BMS folder, e.g. in
 * "<bms>\Tools\SharedMem". If you use the C/C++ object names, that would be
 * FlightData, FlightData2, OSBData, IntellivibeData.)
 *
 *
 * MSG_IMAGE messages are composed as follows:
 *
 * data[0] = MSG_IMAGE
 * data[sizeof(MESSAGE_TYPE)] = <struct rtt_header="">
 * data[sizeof(MESSAGE_TYPE)+sizeof(RTT_HEADER)] = <the actual="" image="" data="">
 * 
 * The "struct RTT_HEADER" needs to hold the following info (check below):
 *
 * RCV_MODE mode = <which image="" type="" is="" this?="">
 * (Check the "enum RCV_MODE" below for possible values. The payload data after
 * RTT_HEADER will be binary data in the format specified here.)
 *
 * RTT_DISP disp = <which rtt="" image="" is="" this?="">
 * (Check the "enum RTT_DISP" below for possible values.)
 * 
 * WORD width = <the resolution="" width="" of="" the="" image="">
 * WORD height = <the resolution="" height="" of="" the="" image="">
 * 
 * DWORD size = <the size="" of="" the="" binary="" image="" data="" after="" rtt_header="" in="" bytes="">
 *
 * Note that for RCV_MODE "JPG" and "PNG", the binary data is just that, a
 * "proper" JPG or PNG image. It is up to your client to decode/render that
 * image.
 *
 * For RCV_MODE "RAW", you will receive a continuous array of individual "struct
 * COLOR_RGBA" (8 bit per color/alpha, see below) values, each image line simply
 * concatenated to the former one. So you need to chop them up according to the
 * RTT_HEADER "width" and reconstruct/render the image from the individual
 * COLOR_RGBA values (one value per pixel).
 *
 * For RCV_MODE "LZ4", you also will receive a continuous array of individual
 * "struct COLOR_RGBA" values like the "RAW" option, however, the data is
 * compressed with LZ4 and hence you need to unpack it before handling it in the
 * same way as you handled "RAW".
 *
 * 
 * ...and that's all there is to it. How you actually use the received
 * image/shared mem data is completely up to your client application and your
 * imagination.
 *
 * I hope this info is helpful and concise enough to get you going.
 *
 * Cheers,
 * Dunc
 */

#pragma once

#define RTT_VERSION 33U // v3.3

// data structures within "pragma pack" will be serialized over the wire
#pragma pack(push,1)

enum MESSAGE_TYPE : BYTE
{
	MSG_CONNECT = 134U, //RakNet ID_USER_PACKET_ENUM
	MSG_DISCONNECT,
	MSG_HANDSHAKE,
	MSG_IMAGE,
	MSG_DATA
};

enum SMEM_DATA : BYTE
{
	F4 = 0U, //FalconSharedMemoryArea (FlightData)
	BMS,     //FalconSharedMemoryArea2 (FlightData2)
	OSB,     //FalconSharedOsbMemoryArea (OSBData)
	IVIBE,   //FalconIntellivibeSharedMemoryArea (IntellivibeData)
	DATA_NUM
};

enum RTT_DISP : BYTE
{
	HUD = 0U,
	PFL,
	DED,
	RWR,
	MFDLEFT,
	MFDRIGHT,
	HMS,
	DISP_NUM
};

enum RCV_MODE : BYTE
{
	PNG = 0U,
	JPG,
	LZ4,
	RAW,
	MODE_NUM
};

struct HANDSHAKE
{
	BYTE rttVersion;
	BYTE fps;
	BYTE useData[DATA_NUM]; // 0 = false, other = true
	BYTE useDisp[DISP_NUM]; // 0 = false, other = true
};

struct RTT_HEADER
{
	RCV_MODE mode;
	RTT_DISP disp;
	WORD     width;
	WORD     height;
	DWORD    size;
};

struct COLOR_RGBA
{
	BYTE r, g, b, a;

	COLOR_RGBA(BYTE r = 0U, BYTE g = 0U, BYTE b = 0U, BYTE a = 255U) :
		r(r), g(g), b(b), a(a) {}
};

#pragma pack(pop)</the></the></the></which></which></the></struct></bms></the></which></which></which></how></struct>

Happy developing!

@I-Hawk:

@Dee-Jay:

No self-ban. Lack of unity. The team is ripping appart.

Come on man… this is too extreme.

You gents know that it is not my habit to post (or even very much participate) in the public forum discussions. But this time, I’d like to chime in for once.

The main issue that the BMS team is facing is that internal issues/problems/discrepancies are dragged out into the public forum. BMS members discussing things here will always find themselves in their very own POV echo chamber, and hence insist that they are correct in their opinions. I know I exaggerate, but bear with me.

If BMS members voice/vent their internal issues in public, each side receives support from enough ppl in such a way that they feel they “must act” to some extent. And if these urges and artificial amplifications mix with emotions, ppl become unable to see that later on, in internal discussions, the attempts to calmly analyze the facts and rationalize whatever the issue may be, they feel personally attacked or unheard or ignored. And hence tension builds up, and eventually it reliefs itself “violently”.

This is nothing new. The unfortunate thing about that is that it is not predictable whether the individuals involved in such events are exiting these situations “unhurt”. Sometimes it is not working out for everyone to “get back to normal”, sometimes things stick. The team can be as professional as it gets, but we’re all humans.

However: extrapolating things like “the team ripping apart” from - objectively locally restricted events, even multiple ones - is another artificial echo chamber amplification. If you find yourself thinking that everything falls apart because you witness a tiny portion of the team being unable to resolve their issues, then you need to be aware that you are needlessly amplifying perceptions for others who actually do not have the whole picture.

The BMS team in itself is strong. Its composition might change over time, that’s undeniable. Ppl will leave, ppl will join. But regardless what happens, the show will go on.

FYI,

I’m planning to add a writeup about the RTTServer network protocol and message formats for you gents and add it as part of the upcoming U1.

Thousands of ppl using BMS and being happy with it. A handful of ppl screaming and kicking and being annoying.

Why would I care about that tiny number of poor sods that always will make anything bad? I really could not care less about them.

I care about the thousands of ppl who like BMS and appreciate it. And I draw my energy from these guys, and the positive energy they give back to me waaay outweighs the tiny spark of negative crybaby anger the the handful of attention-getters try to ignite.

Hence: I still laugh, shrug, and let them cry. Not anyones problem until you chose to make it one.

The only thing that surprises me here is the fact that stuff like this actually gets discussed and heats up emotions.

Repeat after me:

I don’t care! :mrgreen:

/me walks away laughing, continuing the development for fun like it always has been…

Would you be surprised if it’s all written down in the README.TXT inside the RTTRemote directory?

• You need to have the latest Visual C++ 2019 x86/x64 runtimes installed:
  x64: https://aka.ms/vs/16/release/vc_redist.x64.exe
  x86: https://aka.ms/vs/16/release/vc_redist.x86.exe

Summary: it just needs the latest combined 2015/17/19 runtimes, not some older standalone stuff.

If you don’t like using the direct links mentioned above, the MS entry page for these is:
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

The answer is:

1. Of course!

2. But only after the torrent is stable enough - which usually takes a day or (tops) two after release.

So, just hang in there.

PS: torrent doesn’t suck. The policy of some ISPs regarding torrents sucks.

Ladies and Gentlemen,

on behalf of the entire BMS development team, I am happy to announce that the latest iteration of the BillionSoft Falcon 4.0 total conversion modification - Benchmark Sims 4.35 - is available for you to enjoy as of RIGHT NOW!

BMS 4.35 requires a legit installation of a Falcon 4.0 (all older and newer versions are accepted alike, i.e. Microprose, Hasbro, GOG, Steam, Retroism). The check is performed both at setup time and every time you start BMS. If no valid installation is found, BMS will exit with a corresponding error message.

For those of you who are new to Falcon and still need a legacy Falcon 4.0 license, you’re lucky, as there are various season sales going on right now (i.e. at the time of writing this post):

• Retroism
• GOG

Note that this is NOT an exhaustive list of where to buy Falcon 4.0, it’s just a list of retailers known to me (best effort) that offer sales/discounts right now, for your convenience. The list will not be updated.

This mod may not be used for any commercial purposes. Any such use may constitute a violation of the intellectual property of Billion Soft (Hong Kong) and the non-commercial Terms and Conditions under which Benchmark Sims make this mod available to you.

BMS 4.35 comes with a plethora of changes. As with each major BMS release, a full changelog would fill whole books. Instead, we’ve summarized the most important changes for you here:

NOTES:
======

- 4.35 is *not* an update to the former 4.34, but a new independent base installation
- 4.35 can co-exist with 4.34 on the same machine
— The build number string in the Falcon UI will read "4.35.0 (x64) Build 22548" for the base installation

BMS 4.35 Changelog Summary:
===========================

- DirectX 11 Upgrade
- Tactical Reference UI and Data Update
- Weather Control Improvement
- Zulu Time Integration
- Enhanced Flight Planning
- Updated 2D War
- Enhanced Fog Of War and Unit Detection (RECON/JSTAR)
- Improved Gameplay for KTO TvT Theater
- Revision of (AI) pilot names
- New Arresting System for emergency landings
- HTS and HARM improvements
- New multipage customizable kneeboards
- Full canopy control implementation
- Jet Fuel Starter 1+2 support
- Taxi-/Landing light update
- New Pilot Seat Adjustment
- New Anti-Ice Implementation
- Updated MFD fonts
- Enhanced Brakes + Hydraulic Systems
- Accurate Gear Implementation
- Better Aircraft Spawning and Despawning
- Improved Taxi, Lineup, Takeoff and Landing behavior (AI)
- ATC Overhaul (AI)
- Tanker AAR Update (AI)
- Carrier Enhancements (AI)
- RWR Realism Update
- New Pilot Death Situation
- SAM and AAA Operator Enhancement (AI)
- SAM Multi Targeting (AI)
- Enhanced Ship Self Defense Capability (AI)
- Anti Missile Intercept (AI)
- Better Aircraft Weapon Selection + Deployment (AI)
- Improved BVR Tactics (AI)
- More realistic pilot view and threat detection (AI)
- New Wind Turbine Facilities
- New Airbases
- New Features
- New Aircraft
- New Aircraft Skins
- New Ground Units
- New Naval Vessels
- Optimized LOD transition
- Improved Aircraft Destruction Model
- Moon Phases + Ephemeris
- Higher Atmosphere Upgrade
- Enhanced Smoke Duration for Destroyed Vehicles
- Updated switches on the F-18 cockpits
- Mirage 2000 cockpits improvements
- A-10 cockpit fixes
- New Sounds (internal + external)
- New HOTAS Callbacks
- RTTClient/RTTServer Update
- Hitbox Optimization
- Updated Flight Models (non F-16)
- Updated Key Files
- New Training Missions
- Documentation Update
- Enhanced Multiplayer Stability
- Hundreds of bug fixes, 3D and data improvements

Furthermore, as usual, the team has gone to great lengths to update the outstanding Falcon manuals. So once you installed 4.35, please check out the “documentation” section and the various manuals, you’ll probably find all of your questions answered there.

Please check chapter 2 “Feature Overview” of the BMS 4.35 manual from page 8 to 9 in particular:```
2. Feature Overview

2.1 F-16 System update

Many items were updated in the F-16 cockpit. The gear system has been totally rewritten with accurate
implementation of the alternate gear, down lock release, gear sequence and other system depending on gear
state. Canopy operations have been completely revised as well with proper operation of the spider and
warning lights. Anti-Ice system and Probe heat systems are now correctly implemented.
The Brake system has been reviewed as well with new implementation of the brake channels and anti-skid
systems. Supporting all these new features the FLCC has been revamped and is now a true quad redundant
channels which might fail individually and induce specific system failures.
Other details were updated as well such as Landing/taxi light implementation, seat adjust, new faults etc.

2.2 New airbase models

Some airbases were deleted, others added but the most striking factor will be the update of many airbases
from generic to realistic layout models. Most of the South Korea airbase are now looking quite close to their
real counterparts. The update is not only graphical, some airbases now feature a working arrestment system
with a cable allowing landing aircraft equipped with a hook to be stopped in case of brake failure.

2.3 Weather updates

To support the F-16 system changes the BMS weather model has been updated to implement icing, runway
conditions. Other aspects have been updated or implemented: wake turbulence, (jet wash & wingtip vortices)

2.4 Database changes

The BMS database is going though constant updates and this version is no different.
Default teams have been increased to 7 rather than the previous 2. Unfortunately, that means compatibility
with earlier versions TE’s is lost. TEs can be converted from previous versions to 4.35 with Mission
Commander.
More 3D models for buildings, vehicles & aircraft have been introduced as well as many new textures.

2.5 Direct3D 11

The graphic engine has been updated to DirectX11. There are no striking visible changes yet but this was
necessary to prepare the future.

2.6 SEAD/DEAD update

The update of SAM systems started with 4.34 has been continuing in 4.35. More SAMs have their own
dedicated Search/Fire control radar, the tactics the AI SAMs will use have changed and to support these
changes the AGM-88 has been updated as well with new sub modes and a completely rewritten HAD
mechanisation.
Some SAMs are now able to perform multi targeting and therefore might engage cruise missiles or missiles to
better defend themselves.

2.7 ZULU Time

BMS implements now ZULU time and all default times are ZULU unless LT or FT is mentioned. This change may
sound peculiar but allows correct implementation of the sunrise/sunset time, moon phases and star position
according to the chosen date of flight. Tiny details you might say but the night might not be as dark as ever
depending on the moon phases and that in turn will influence your NVG need. It was also very complicated to
plan using the sunrise or sunset during your flights, not anymore.

2.8 Tools

Tools have been updated to help manage many aspects of BMS 4.35:

• WDP: Weapon Delivery Planner: http://www.weapondeliveryplanner.nl
• MC: Mission Commander: http://www.weapondeliveryplanner.nl
• WC: Weather Commander: http://www.weapondeliveryplanner.nl
• Korea Interactive Map for navigation in BMS KTO (including all charts):
http://www.ravico.com/ST/BMS_KTO_interactive/index.html
• F4Wx – Real Weather Converter (see BMS forum for download link)
• RTT Client/Server is now the primary (and only) BMS way to extract the displays. The old system has
been removed and needs to be replaced by RTT.

2.9 Documentation

The documentation suite has been updated to reflect the BMS 4.35 changes and is completely up to date:
• TO-BMS1F-16CM-1 (aka Dash-1) is about managing the F-16 as an aircraft.
• TO-BMS1F-16CM-34-1-1 (Dash-34) is about managing the F-16 as a weapon platform.
• The BMS TRAINING manual covers the 26 BMS training missions.
• The BMS COMMS and NAV book includes elements from the old Chart Tutorial (such as how to use the
approach charts) and also covers the way users should interact with the ATC and use the radios.
• The BMS TECHNICAL manual is a detailed reference for those interested in customising or developing
their BMS experience and gathers many single documents into one big technical publication.
• The BMS Naval Ops document is dedicated to carrier-based operations with relevant aircraft types.
• The charts have been completely updated for the new airbase models.
• The key files and other Input Device files have been maintained and documented for 4.35.

Here's some **generic info** that you probably want to be aware of:

*   The base 4.35 installation will take 8.92 GB of HDD space
*   For the Falcon BMS.exe and the Editor.exe, we only ship the 64bit version, the 32bit versions have been removed due to memory requirements
*   All other tools (IVC, RTT etc.) still have 32bit versions available, e.g. for use on other PCs
*   Windows 7 SP1 is the minimum supported OS version
*   Windows 7 SP1 requires the "platform update" ([KB2670838](https://www.microsoft.com/en-us/download/details.aspx?id=36805)) to be installed

Don't want to keep you waiting any longer… here it is:

**A) The primary distribution method is by TORRENT, as always (please use THIS whenever possible):**

File: Falcon_BMS_4.35_Setup.torrent
Size: 93.5 KB
CRC-32: fd212860
MD5: c4a7d31c217cf2612943dd19c1e90874
SHA-1: 8996ad995d7e0ff89d7c68c71383aa7bddab3878
SHA-256: c031452b5aa723c2c88545ad01e4f78a635f21ad06a0c096cac625e75a2f249e

File: Falcon_BMS_4.35_Setup.zip
Size: 2.32 GB
CRC-32: 3b4bb8c9
MD5: fdbb052517ef6282ae767485753d1c8a
SHA-1: 016e742992df094f21749ae865b38a4c115d12ce
SHA-256: f0a26d69dd1e2676e6519a6e4887a90ecd7a36b1a369f5a221facda3aebac73a

**B) As a secondary method, we offer direct download links (the torrent method above will be faster and you will support the community by seeding):**

*   [MediaFire](https://www.mediafire.com/file/unjw7xj1aelvl97/Falcon_BMS_4.35_Setup.zip/file)
*   [Weapon Delivery Planner](http://www.weapondeliveryplanner.nl/files/BMS/Falcon_BMS_4.35_Setup.zip)

Please do NOT post alternate download mirrors in the forum if you want to offer a mirror. Give the torrent some time to get stable (won't take longer than a day). If you want to offer a mirror, please PM a moderator, they will take care about adding the links here.

The information in the forum, blogs, FAQs, articles etc. will be updated subsequently to reflect the new 4.35 capabilities and features.

**A big THANK YOU to everyone in the BMS development team and to the gents from BILLION SOFT who made this release possible!**

Now download and enjoy! :)