Here is an update for the Tactical Reference with pictures for all fuel tanks:
Version
4.37.3
The ZIP archive contains:
- TacRefDB.xml (…\Data\TerrData)
- TGA image files (…\Data\Art\TacRData)
Fuel tanks are beautiful!
Here is an update for the Tactical Reference with pictures for all fuel tanks:
Version
4.37.3
The ZIP archive contains:
Fuel tanks are beautiful!
Effective Bug Reporting
An effective bug report communicates well with the BMS developers and avoids confusion or miscommunication.
Before you add a new bug report, please use the search function to check if the same bug has been reported or not. A good bug report should be clear and concise without any missing key points. Any lack of clarity leads to misunderstanding and slows down the development process as well. The most important point that you should keep in mind is not to use a commanding tone or harsh words in the report. This breaks the morale and creates an unhealthy work relationship. Use a suggestive tone. The import information that a bug report must communicate is:
Version and Build number
Detailed Description
Pictures
Example files*
Crash logs*
Dump Files (*.dmp)
Reproducibility Procedure
Expected Behavior
.cam, .tac, .twx, .ini, .vhs (ACMI), … if applicable depending on type of bug
The report should clearly answer how the test was performed and where the defect occurred exactly. The reader should easily reproduce the bug and find where the bug is. Hence it is best to split multiple issues into separate bugs. This ensures that each bug can be handled individually.
Always use KTO as your standard Theater of Operations and the current Vanilla installation without any further modifications!
If you discover a bug in another theater, please reproduce it in KTO as well. This can already exclude some sources of error.
It is very important to layout exactly what you did, in a step-by-step manner if necessary. Try to include all the information that you think would be helpful, but don’t be overly verbose. Now try to explain what happened the best you can. If you received an error message, it is always important to include the full, specific message. If you’re having trouble explaining it, pictures can be better than 1000 words. Use the attachment option whenever reasonable. Finally, try to explain what you expected to happen. This helps everyone understand what you were thinking and will often lead to improvements.
You can easily just copy and paste from this template:Version
4.34.0 (x64)
Build
19631
Detailed Description
…
Pictures
…
Example files
…
Crash logs
…
Reproducibility Procedure
1.
2.
3.
4.
5.
6.
7.
8.
9.
Expected Behavior
…
Your effort towards writing a good bug report will not only save the resources of our team, but also create a good relationship between you and the developers.
If you already solved the problem on your own, please report back.
Makes sense?
Thank you all!
Cheers,
Nick
AI ATC Vectoring
Version
4.37.3 (x64)
Build
1329
Detailed Description
During multiple Campaign flights we observed that ATC is vectoring the flights correctly, but does not leave enough space within and between flights. This is why we had to abort our approach, although we followed the ATC instructions very carefully. Sometimes on the glideslope we had no view on an aircraft directly in front of us (they came in below and from an unexpected angle) and during touch down we found ourselves in the blast of two big F-15 engines. That happened so often, that I now created a reproducible case.
Pictures
Here I had to abort my approach, because GATOR4 flight was to close:
GATOR4-3 and 4-4 did the same:
Otherwise I had find myself here, like during this Campaign flight:
Example files
4373-BUG-AI ATC Vectoring.zip
Crash logs
none
Reproducibility Procedure
Expected Behavior
ATC should vector the aircraft with enough spacing between eachother.
AI TASMO Capability
Version
4.37.3 (x64)
Build
1329
Detailed Description
The Kh-22 (AS-4 “Kitchen”) is a Russian built long-range anti-ship missile with a range of about 320 nm. This large missiles is used on the Тu-22 and Tu-95 strategic bombers. However, in BMS, only the TU-22 can be selected from these two for TASMO missions. Then the AS-4 is used as the standard weapon for such task. Here, the AI bombers are not able to deploy this weapon at long range and they are shot down by the ship’s defenses beforehand.
Pictures
Example files
4373-BUG-AI TASMO Capability
Crash logs
none
Reproducibility Procedure
Expected Behavior
The bombers should be able to fire the long-range anti-ship missiles from a safe distance without too much risk of being shot down themselves.
Possible Root Cause
The Kh-22 (AS-4 “Kitchen”) in BMS reads SimWeapon Data “38) G-M82” - which probably does not correspond to an anti-ship missile.
Changing this to that of the Kh-35 (AS-20 “Kayak”) (Range = 160 nm) to “211) AS20” the weapon deployment works as expected.
BMS 4.34 - Multiplayer Setup
This is an recommendation by the BMS Dev Team, how to configure the server and the clients and what should be considered in order to get the best possible multiplayer experience.
This thread is not meant to discuss how to solve every individual installation. 1.1 General
Always read the available manuals. You can find the documention in your BMS installation folder under “…\Docs”.
The preferred client connection type for Multiplayer in 4.34 is peer-to-peer (P2P) networking. There is no need to force Client-Server-Computing (CS) anymore. However, the new multiplayer code is able to handle both P2P and CS connections at the same time. As you can see from the chart, a CS client also gets its updates from the other P2P clients - only the routing is different.
The number of event packets that a single client sends or receives are equal in both cases (P2P and CS). Only the way a data packet takes, is sometimes directly, sometimes with an intermediate step via the server.
Due to the different routing, the transmission time from one client to another is potentially longer for CS, hence higher latency.
Summary: P2P or CS makes no difference to the amount or type of data that a single client sends or receives. Only the way of the data (and possibly the associated bandwidth request to the server and the time that data packets need from A to B) may vary.
1.2 Installation
We recommend a clean installation (“VANILLA”) without any 3rd party modifications (theaters, aircraft, graphics, features, etc.) for server and clients. If you have successfully completed several multiplayer sessions, you can start to install step by step mods that are especially released for 4.34 and gradually checking that the multiplayer experience is not compromised. Yes, even if it does not appear at first, for example, even altered graphics can lead to problems in your Multiplayer environment.
1.2.1 Backup
You can easily make a backup of your existing 4.34 installation:
If you want to use your previous installation again, just rename …\Falcon BMS 4.34\… to …\Falcon BMS 4.34 (VANILLA)\… and …\Falcon BMS 4.34 (Backup)\… to …\Falcon BMS 4.34\…
Next time you have again to rename …\Falcon BMS 4.34\… to …\Falcon BMS 4.34 (Backup)\… and …\Falcon BMS 4.34 (VANILLA)\… to …\Falcon BMS 4.34\…
There is no possibility on the server side to check whether the installation of a client complies 100% with the recommendations. Here you just have to trust the people you want to fly with.
2.1 Server
The server delivers and receives data to and from all clients. The correct setup of the host is therefore very important and its possibilities also limit the maximum number of clients. If you don’t have a proper PC and internet connection for the server, you certainly will get issues in multiplayer.
If possible the server should always be dedicated for hosting. Stop all programs and update routines in the background that could potentially affect performance or bandwidth.
2.1.1 Server falcon bms.cfg
Make sure that the parameters listed below are set as follows. All information in gray refers only to a dedicated server that does not participate in the mission.
If you host a mission as a pilot yourself, then only pay attention to the parameters in black letters.
set g_bHiResTextures 0
set g_bUseAnalogIdleCutoff 0
set g_bReducePSFires 0
set g_bEnvironmentMapping 0
set g_bPixelLighting 0
set g_bVertexLighting 0
set g_bHdrLighting 0
set g_bHdrLightingStar 0
set g_bUseHeatHazeShader 0
set g_bUseMotionBlurShader 0
set g_bShowFarRain 0
set g_bShowRainDrops 0
set g_bShowRainRings 0
set g_bShadowMapping 0
set g_bCockpitShadows 0
set g_bFocusShadows 0
set g_bShadowOnSmoke 0
set g_bWaterNormalMapping 0
set g_bWaterEnvironmentMapping 0
set g_bEnvMapRenderClouds 0
set g_bEnvMapRenderFocusObject 0
set g_bHiResTextures 0
set g_bRequireSameAcdataMP 1
set g_bRequireSameTileSetMP 1
set g_nMPStartRestricted 0
set g_bServerHostAll 1
set g_nForceMinClientBwSetting 2048
set g_nRemoteControlSurfacesInterval 200
set g_bEnforceBandwidthLimits 0
2.1.1 Additional Server falcon bms.cfg settings These additional parameters can be added to the server’s config file if really needed.
g_bHostAllowsDubiousConnections 1 (Default)
Does allow dubious connections where port forwarding (2934-2935) is not properly set. However, in rare cases, ports may be forwarded correctly, but different port numbers are routed and shown in the Lobby. Nevertheless those clients are allowed to connect.
g_bHostDisableP2pForDubiousConnections 0 (Default)
If activated, dubious connections will automatically be forced to CS although they would work as P2P. This can be set to “1” in case it is figured that a specific connection is causing issues and/or in case you’re hosting an “open session” with plenty of ppl you don’t really know, and want to avoid the need for “network debugging”. In those cases, “dubious” connections will automatically be forced to CS (even those who usually would work fine with P2P).
Summary: The defaults are fine and preferred. There is no need to prematurely adjust these settings, unless you have specific connection issues that can’t be solved otherwise.
2.1.2 Bandwith Settings
Use a speedtest page like SPEEDTEST.NET and make sure your upload/download settings are 70% of your currently available bandwith.
(Example: 420670 * 70 / 100 = 294000 Download … 80940 * 70 / 100 = 56000 Upload)
Remember that your connection can be different every time.
If you checked everything (firewall, ports, updates, background processes, etc.) and you are still having problems (pause, lags, hickups, times 2x, 4x, …) during a multiplayer session, try to get closer to the 90% mark. In this case please do several (minimum 4-6) speedtests in a row and take the lowest value of all. Then set the upload and download bandwidth in BMS initially to 75% (instead 70%), if that is not enough go for 80%, etc. - if you still notice no improvement even at 90%, then your internet connection or that of the server is just not enough. The only thing you can do after all is to reduce the number of clients.
2.1.3 Maximum Clients
Your “Upload Bandwidth” value divided by 2048 should give you the maximum number of clients your server is able to host.
(Example: 56000 / 2048 - 1 = 26)
2.1.4 Server 3D
The Host always needs to commit to the 3D world first. If you are hosting the flight make sure you are in the flight that has the earliest take-off time.
If you want to setup a Dedicated Server, it is best to create a separate flight for the server to use as its seat. Frag any flight (e.g. C-17 at Fukuoka) and put it cold on the ground on a very remote airbase outside the combat zone. Enter it before other flights commit.
3.1 Client
The client also delivers and receives data to and from the server and all clients. The correct setup of the client is therefore also very important.
3.1.1 Client falcon bms.cfg
No special parameter settings are recommended here.
3.1.2 Bandwith Settings
Use a speedtest page like SPEEDTEST.NET and make sure your upload/download settings are 70% of your currently available bandwith.
(Example: 48940 * 70 / 100 = 33000 Download … 5030 * 70 / 100 = 3500 Upload)
Even if your Internet Service Provider has granted you a fixed bandwidth, remember that the actual bandwith can fluctuate. It is recommended to measure a couple of times throughout the day, and pick the “lowest” numbers as your baseline. Better safe than sorry, right!?
If you checked everything (firewall, ports, updates, background processes, etc.) and you are still having problems (pause, lags, hickups, times 2x, 4x, …) during a multiplayer session, try to get closer to the 90% mark. In this case please do several (minimum 4-6) speedtests in a row and take the lowest value of all. Then set the upload and download bandwidth in BMS initially to 75% (instead 70%), if that is not enough go for 80%, etc. - if you still notice no improvement even at 90%, then your internet connection or that of the server is just not enough. The only thing you can do after all is to reduce the number of clients.
3.1.3 Port Forwarding
Besides a stable (and fast) internet connection you will most likely need to open ports to allow BMS to work through it. Please refer to your router, firewall or internet service provider documentation on how to open up or forward ports.
3.1.4 Client shown as P2P
It is very important that every client can see and is shown for everybody as “P2P” in the BMS Comms “Lobby” - otherwise it can limit your multiplayer experience. If you see someone as CS it means, that he will only get data from the server. He should check his port forwarding, restart BMS and reconnect.
But if after checking all settings (firewall, port forwarding etc.) someone can connect only as CS, this can still be handled by the network code.
We hope this post, in addition to the information in the manuals, can help you to configure your multiplayer environment properly.
@spotdott said in AI TASMO Capability:
@Nick-Taylor the weapons our grandparents came up with are the stuff of nightmares
You are right … sad but true.
Compared to Falcon Allied Force (/meruns), the BMS engine is (currently) not capable of simulating very long-range missiles. Here is an example:
In Allied Force the AI can shoot an AIM-154 Phoenix from far far away out of the aggregated area (2D). The missile then is continuously calculated and suddenly pops up in the deaggrigated world (3D). The F-16 pilot has only a few seconds to react as soon as the active <M> appears on the RWR. Up to this point, except for the jammer symbol on the FCR, he had no indication of what was coming.
In BMS the range is much shorter, because of the different approach.
Download .tac .acmi .png for AF and BMS
BMS Mission Planning
AF Mission Planning
BMS Radar 160 nm
AF Radar 160 nm
BMS Radar 80 nm (radar contact)
AF Radar 80 nm (active M)
BMS Radar 40 nm (active M)
AF Radar 40 nm (Target already destroyed)
BMS ACMI (Missile launch at 56 nm)
AF ACMI (Missile launch >88 nm)
That would be a gamechanger if we had something similar in BMS.
@tiag said in [4.37.3] AI ATC Vectoring:
@Nick-Taylor on the picture you posted I see the CAS speed of the F-15 in front of you with 180-200ish knots. The F-16s behind you have 200CAS. Why are you flying at 317 knots before entering final?
Already saw the other flight at base leg and did an abort at this point in time. Then I observed the F-15s.
@Mav-jp said in [4.37.3] AI ATC Vectoring:
Increasing the distances would make the airbases not working at all between take off and landings.
Mmmmh, do understand what you mean and the issue behind it. Military aircraft have the mentioned approach minimums in real life. What about the following ideas to avoid this and still be able to have realistic spacing between aircraft?
Just looking for a solution, if possible and interest.
@Mav-jp Hey Mav, you can see the AI behaviour in both of your ACMI files:
combat AP.zip.acmi
At 5:00 you can see that Gator42 and Gator43 are coming very close to each other (2.483 ft instead of a minimum of 6.000 ft for VFR approach) .
At 5:44 you can see that Gator43 aborts the landing approach when the distance to Gator42 has dropped below 1.500 feet.
pLAYER.zip.acmi
Here the situation is even worse. At 12:00 you can see that Lynx51 and Lynx52 are coming much too close to each other (406 ft
At 12:35 you can see that Lynx52 aborts landing when the distance has dropped to 122 feet.
The expected behavior would be, that under VFR conditions the distance of >=6000 feet between aircraft is maintained (IFR >=3 nm). The distance between individual flights should be IFR >=5 nm (IFR >=10 nm).
Makes sense?
Greetings from Buchenau,
Nick
@Mav-jp said in [4.37.3] AI ATC Vectoring:
i have flown your mission twice
Thank you for digging into this. I’m packing for a week-long Falcon 4 LAN event right now.
For the younger folks here: This is an event where you connect PCs with Category 4 cables and when you sit up in your chair, you can see real people holding beer bottles and smiling in your face. Yes, more than 50 human beings.
Here I can take a look at your ACMIs and report back to you as soon as possible.
Hey Radium,
Hope everything is fine on your end. Nice to see that you’re still so much dedicated to your hobby.
I do understand that you can’t make every possible squadron … and what about VF-14 Tophatters?
Just kidding,
Nick
@Mav-jp said in AI TASMO Capability:
The Op issue is data , so is your example
Yes, could change the data of aircraft, radar, missile, seeker, aero, etc. so that the MiG-31 deaggregates much earlier (see pic) and locks the F-16 from far away . Nevertheless, the AI does not shoot the AA-9 from e.g. 150 nm. I guess it decides not to shoot because it could be a “lose” target tracking.
Any idea?
@Mav-jp said in AI TASMO Capability:
Please stop comparing arcade game data with BMS. Aim120 ranges and flight modeling in AF were totally fantaisist.
For your information AF did not have a different code than original F4 here.
The agged units firing on deagged or deagged firing on agged feature has been remove deliberately in BMS because it was super bugged and lead to very wrong results and a LOT of missiles lost for nothing
…
What button did I press with you?
Why do you forbid me to compare simulations?
Why are others allowed to do that here with other simulations e.g. DCS?
What if other simulations like FF, AF, DCS, etc. have good and stable features that BMS does not?
Why was this feature part of an AF patch if Lead Pursuit did not make a code change to the original F4?
Would you agree that something can be called a “Fix” by really diving into and actually fixing it OR by just removing the feature itself?
I made the requested test against F-14 and MiG-31 in the current version:
Do you agree with me that it is not quite “as real as it gets” when a MiG-31 does not fire its AA-9 Amos until 50 nm, even though they have a range of over 180 nm?
No offense here in any case, just asking questions.
AI ATC Vectoring
Version
4.37.3 (x64)
Build
1329
Detailed Description
During multiple Campaign flights we observed that ATC is vectoring the flights correctly, but does not leave enough space within and between flights. This is why we had to abort our approach, although we followed the ATC instructions very carefully. Sometimes on the glideslope we had no view on an aircraft directly in front of us (they came in below and from an unexpected angle) and during touch down we found ourselves in the blast of two big F-15 engines. That happened so often, that I now created a reproducible case.
Pictures
Here I had to abort my approach, because GATOR4 flight was to close:
GATOR4-3 and 4-4 did the same:
Otherwise I had find myself here, like during this Campaign flight:
Example files
4373-BUG-AI ATC Vectoring.zip
Crash logs
none
Reproducibility Procedure
Expected Behavior
ATC should vector the aircraft with enough spacing between eachother.