Falcon 4.36.0 Documentation: Bug Reports
-
BMS KTO AIP
Page 5, TACANs Table 1.2.1.1 South Korea
Original: Sokscho
Corrected: SokchoBMS KTO AIP
Page 10, ATIS VHF Frequency Table 1.2.4.1 South Korea
Original: Choongwon 135.6
Corrected: Delete Choongwon entry (replaced by Jungwon) -
@Fletch said in Falcon 4.36 Documentation: Bug Reports:
BMS KTO AIP
Page 5, TACANs Table 1.2.1.1 South Korea
Original: Sokscho
Corrected: SokchoBMS KTO AIP
Page 10, ATIS VHF Frequency Table 1.2.4.1 South Korea
Original: Choongwon 135.6
Corrected: Delete Choongwon entry (replaced by Jungwon)Thanks for reporting. Fixed
-
Will there be an area to download the updated documents once they are “finished”?
-
@Icer Sure. Docs folder in BMS
-
Document: BMS-User-Manual.pdf
Page 9-196
Currently: “The SETUP section is documented in Chapter 4 of this manual”
Suggestion: “The SETUP section is documented in section 3.4 of this manual” -
This took me a few reads to figure out the correct order of the color values.
BMS Technical Manual 4.35.1 Change 1
Page 231
BMS Technical Manual 4.36.0 Change 2.00
Page 238- I would like to suggest this sentence be deleted:
“A color code consists of four different values, in order: Alpha,Blue, Green and Red -> 0xAABBGGRR”.
Instead, just detail the order in which the colors should be coded, e.g. In BMS, the color hex-values are ordered as follows: 0xALPHA-RED-GREEN-BLUE, e.g. 0xFFFFFF00. The first two digits are ‘alpha’, where FF is ‘fully solid’ and 00 is ‘fully transparent’. . .
- The list of example colors contain four errors. Here are how the colors are listed in the Manual.
These are what the hex values should be.
Red = 0xFFFF0000
Blue = 0xFF0000FF
Yellow = 0xFFFFFF00 -
BMS-Technical-Manual, Chapter 14.6.1, page 14-238
A color code consists of four different values, in order: Alpha, Blue, Green and Red -> 0xAABBGGRR
So the order for RGBA is reversed in BMS.(As you have already found out while changing your radio color…)
-
Document “BMS-Training”
Ver.: BMS 4.36
Date: 05 APR 2022Page 19
Is: “If you see a wingman comm menu greyed out, you’re not on the correct frequency to communicate with them.”
Proposed: “If you see a wingman comm menu entries not highlighted, you’re not on the correct frequency to communicate with them.”
Reason: Implementation changePage 34
Is: “According to the position of the ALT switch on the HUD panel it can display
Barometric or Radar or can switch from one to another at 1500feet.”
Proposed: “According to the position of the ALT switch on the HUD panel it can display Barometric or Radar or can switch from one to another at 1500 feet.”
Reason: Missing space before unit.Page 35
Is: (bullet) MUAN VORTAC: 065X
Proposed: (bullet) Muan Intl Airport TACAN: 065X
Reason: In 4.36 MUAN became an airport.Page 35
Is: (bullet) MOKPO VORTAC: 049X
Proposed: to make changes for page 44 or else remove this bullet at all
Reason: originally MOKPO VORTAC is not used in further description, save for one place where it is mentioned as an example of “newly implemented VORTAC”.Page 37
Is: “Note that in our flight plan the ruler was set to calculate distance from Steerpoint 6 to Muan VORTAC (TACAN channel 65X).”
Proposed: “For instance, if you enabled Ruler and placed one of its triangles on Steerpoint 6 and the other on Muan Intl Airport (the closest airport NE of Steerpoint 6, TACAN channel 65X), it would show distance of 12.4 NM.”
Reason: Original sentence suggested that that distance from STPT 6 to Muan were previously used for something. However, it seems that this is only an example of using ruler to measure distance. The proposed text makes it clear(er). Additionally updated Muan name from VORTAC to airport.Page: 44
Is:
"Passing Steerpoint 5 the aircraft, still on Autopilot, steers towards Steerpoint 6. It is now time to switch from INS navigation to TACAN navigation. As we planned before the flight, we know that we are flying close to newly implemented VORTAC stations. We decided to call them VORTAC to differentiate them from the airbase collocated TACAN stations, but basically they behave in the same way as TACANs in BMS.Muan and Mokpo are 2 VORTAC stations with a limited range of 40 Nm. Let’s fly direct to Muan. Select the T-ILS page and enter Muan channel: 065X in the scratchpad. Check that the INSTR MODE is set to TCN and look at your HSI. The OFF flag is not displayed, indicating that Muan is in range. The bearing pointer is approximately 257° and distance shows 23(.4) Nm."
Proposed:
"Passing Steerpoint 5 the aircraft, still on Autopilot, steers towards Steerpoint 6. It is now time to switch from INS navigation to TACAN navigation. As we planned before the flight, we know that we are flying close to Muan Intl Airport and MOKPO VORTAC station. VORTAC stations are radionavigational aids that in BMS behave in the same way as airbase-collocated TACAN stations. Note that radionavigational aids have limited range - you must be close enough and with line-of-sight to properly receive their signal. You can check range of each station in AIP.Let’s fly direct to Muan. Select the T-ILS page and enter Muan channel: 065X in the scratchpad. Check that the INSTR MODE is set to TCN and look at your HSI. The OFF flag is not displayed, indicating that Muan is in range. The bearing pointer is approximately 257° and distance shows 23(.4) Nm.
The next time you fly this mission, you can choose to include MOKPO VORTAC in your trip. Just enter its channel: 049X and follow the same procedure as you used for navigating to Muan."
Reason: Adjusted description to the fact that in 4.36 Muan is an airport. Added encouragement to use MOKPO VORTAC for navigation as it seemed to have been missing in previous mission description.
Page 44
Is: “At 4Nm from the station the bearing pointer will start drifting to the side.”
Proposed: “At 4 Nm from the station the bearing pointer will start drifting to the side.”
Reason: Missing spaceDocument “KTO AIP”
Ver.: BMS 4.36
Date: 14 APR 2022Page 7
Proposed change: Muan should be removed from South Korea’s VORTACs table (1.2.2.1) as it is an airport in 4.36.Document “TO BMS 1F-16CM-34-1-1”
Change 4.36.0References are broken. Multiple “Error! Reference source not found” across the document.
There is duplication and seemingly wrong order in descriptions of AGR and backup bombing sensors. I propose the following steps to remove duplication and achieve more logical flow of content.
Move text from 2.4.6.7 BACKUP BOMBING SENSOR (p.80, possibly with fixes described below) and screens from 4.2.19 BACKUP BOMBING SENSOR (p.211)
to 2.4.7.1.6 BACKUP BOMBING SENSOR (BBS) (OSB 6).
Then remove 2.4.6.7 and 4.2.19 or put there reference to 2.4.7.1.6.Move contents from entire 2.4.6 AIR TO GROUND RANGING (p.77) without 2.4.6.7 (which will be moved to general GM MFD symbology section as per previous proposal)
to 2.4.7.6 AIR-TO-GROUND RANGING (AGR) (p.90).Page 78
Is: “The symbol on the HMCS is initially moved on the ground point with head movement Once the symbol is ground stabilized, it may be slewed.”
Proposed: “The symbol on the HMCS is initially moved on the ground point with head movement. Once the symbol is ground stabilized, it may be slewed.”
Reason: Missing dot.Page 79
Is: “The diamond changes to a square located at the last valid range for about 0.5 sec. When valid range can no longer be determined and then will be pegged at the top right corner of the MFD.”
Proposed: “When valid range can no longer be determined, the diamond changes to a square located at the last valid range for about 0.5 sec., after which it is pegged at the top right corner of the MFD.”
Reason: Attempted to make the sentence more clear. Original sentence probably had autocorrection error after “sec.”.Page 80 (section 2.4.6.7) and page 211 (section 4.2.19) - contain duplicated paragraph
Is: “The backup bombing sensor rotary at OSB 6 on the FCR MFD page shows which sensor is being used to determine the height above target HAT. The rotary defaults to BARO at FCC/MMC power-up. With BARO displayed, SALT is used to determine HAT RALT is also included in the rotary. If RALT is selected, the CARA will be used to determine HAT. Since the CARA measurement will be height above the release point rather than HAT, use of RALT as a backup sensor should only be used over flat terrain. The backup sensor can be accessed also from any OFF MFD page”Proposed: “The backup bombing sensor rotary at OSB 6 on the FCR MFD page shows which sensor is being used to determine the height above target (HAT). The rotary defaults to BARO at FCC/MMC power-up. With BARO displayed, SALT (System Altitude) is used to determine HAT. The other option is RALT. When RALT is displayed, the CARA (Combined Altitude Radar Altimeter) will be used to determine HAT. Since the CARA measurement will be height above the release point rather than HAT, use of RALT as a backup sensor should only be used over flat terrain. The backup sensor can be accessed also from any OFF MFD page.”
Reason: A couple of missing punctuation and readability fixes.
Page 85
Section 2.4.7.1.6
Is: “The Backup Bombing Sensor (BBS) is not currently implemented in BMS.”
Proposed: replace this text with paragraph as proposed above.Page 83
Is: “An automatic range scale option is available in the following modes: GM, EXP, DBS1, DBS2, FTT, SEA, GMTI and GMTT.”
Page 84
Is: “In the normal GM, SEA and GMTI displays, four expansion cues (tick marks) are provided on the X-Y cursors to define the area that would be displayed upon selection of the EXP FOV.”
Question: could not find what is GMTI mode. Is it something implemented? If it is not, then I propose to remove it. If it is, then some description (at least abbreviation expansion) should be added.Page 17, 86
Duplicated name in reference to “SPI MANAGEMENT” chapter: SPI MANAGEMENT SPI MANAGEMENT
Proposed: remove duplicated chapter nameChapter 4 - in my opinion there are excessive newlines or vertical space between paragraphs is set to too much. However this might have been author’s intent.
-
@Fox_15 Thanks for reporting! Very nice.
I will go through them.One note: Muan is now an airport with a VORTAC. So no change needed in AIP.
Cheers
Micro -
not sure if it’s a bug but I can now hit a target very easily in DTOS mode simple because of the TGP application. Is that the real case or is it exaggerated?
-
-
I have a question regarding the new parking charts.
Say that we are looking at a parking chart for 06R. It shows spots where spawn happens. But when landing I am sometimes not sure where to go - do the parking charts give hints on where you are supposed to go after landing on 06R or its cardinal opposite ?
So how is this documentation: The documentation talks about parking spots for takeoff, but does not mention if they are relevant for landing. Up till now you could park anywhere after landing, but the parking charts could suggest that there are some places better suited, based on which runway you land on
Thx
-
I guess this thread shows why there are no RTFM posts on this forum.
-
@jayb said in Falcon 4.36 Documentation: Bug Reports:
I have a question regarding the new parking charts.
Say that we are looking at a parking chart for 06R. It shows spots where spawn happens. But when landing I am sometimes not sure where to go - do the parking charts give hints on where you are supposed to go after landing on 06R or its cardinal opposite ?
So how is this documentation: The documentation talks about parking spots for takeoff, but does not mention if they are relevant for landing. Up till now you could park anywhere after landing, but the parking charts could suggest that there are some places better suited, based on which runway you land on
Thx
You are right about this. “Taxi back” procedures are explained pretty weak. Right now, ATC cant handle “taxi back” procedure and route you to a shelter/parking spot.
BUT, improvements for that are already cooking. -
@Micro_440th thank you that sounds great. So for now “park anywhere” still applies
-
Document: BMS Comms& Nav Book
Page: 33
Original Sentence: “The wingman menu (“z” for US layout or “w” for most other layouts)”
Corrected Sentence: "The wingman menu (“w” for US layout or “z” for most other layouts) -
Document: BMS User Manual
Page: 196
9.10 Setup
Original Sentence: The SETUP section is documented in Chapter 4 of this manual.
Corrected Sentence: The SETUP section is documented in Chapter 3.4 of this manual. -
Document: BMS COMMS & NAV Book, BMS 4.36, 30 Mar 2022
Page: 60Original sentence: “In this example, the DED CRS was set to 355° which is the magnetic heading for ILS RWY 36 Gunsan.”
Corrected sentence: “In this example, the DED CRS was set to 356° which is the magnetic heading for ILS RWY 36 Gunsan.”
The magnetic heading noted throughout the verbiage and images in the example provided in section 3.1.2 does not match the heading shown on the KTO charts located at C:…\Docs\03 KTO Charts\01 South Korea\Gunsan.
GC
-
Document: BMS COMMS & NAV Book, BMS 4.36, 30 Mar 2022
Page: 61, last paragraph, last sentenceOriginal sentence: “The EHSI does not label ILS but uses PLS instead for Precision Landing System.”
Corrected sentence: “The EHSI does not label ILS but uses PLS instead for Precision Landing System.”
Change formatting of last line in paragraph to left justified.
GC
-
BMS KTO AIP
ver. 4.36
14 MAR 2022Compared changelog, AIP and 2D and in some cases the names were not updated, so here’s the list:
1.2.4.1 (ATIS South Korea)
Choongwon (old name) should be deleted, because Jungwon (new name) is already in the table.1.2.4.4 (ATIS North Korea)
Wonsan (old name) should be changed to Kalma (new name).
Uoiju should be Uiju (according to stations+ILS.dat, but in game it is pronounced and spelled as Uiji)2.2.3
RK-111: Kunsan (old name) should be changed to Gunsan (new name)
RK-14: Kwangju (old name) should be changed to Gwangju (new name)2.3.1 (MOAs South Korea)
MOA 5: Choongwon (old name) should be renamed to Jungwon (new name)
MOA11: RKTI should be changed to RKTY (correct Yecheon’s ICAO code)
MOA6, MOA7, MOA30, MOA31, MOA32, MOA33: Kangnung (old name) should be changed to Gangneung (new name)
MOA17, MOA18, MOA19: Kunsan should be changed to Gunsan (new name)
MOA15, MOA20, MOA21, MOA22, MOA23, MOA24, MOA25, MOA26: Kwangju (old name) should be changed to Gwangju (new name)
MOA14: Taegu (old name) should be changed to Daegu (new name)
MOA27, MOA28, MOA29: Sachon should be changed to Sacheon (new name)
MOA13 EAST, MOA13 WEST: directions from Pusan but there is no such airbase3.1.4 (North Korea airbases)
KP-0021 Sunch’on (old name) should be changed to ZKSC Sunchon (new name)
Uiju ILS (Rwy) is: 110.4 (05), 110.0(23) should be should be: 110.0 (05), 110.4(23). Checked in stations+ILS.dat and confirmed in 3D.4.36 changelog
Is: Pyongtaek AB => Pyongtaek AAF (RKSG)
Should be: Pyongtaek AB => Pyeongtaek AAF (RKSG)
Reason: current implementation based on Stations+ILS.dat and 2D -
Would it be possible to run the pdf manuals or documentation through the Microsoft Word grammar and spellcheckers (assuming Word is the creating source, as it seems to be), to correct, probably 95% of those errors in the manuals? It still needs to be verified for accuracy, of course, but I’ve done that on my manuals (open the pdf’s in Word as a docx file, let it find all of the errors, then re-save back as a pdf. (It took about an hour per 100 pages for me, to verify each of the changes and corrections. Be aware that it’s NOT perfect!)
There is a lot of missing punctuation in the manuals that the grammar checker finds and fixes. These simple, auto-grammar (and spelling) corrections clarify the ideas, thoughts, directions and concepts much better than the original text in many cases. A properly placed comma or semicolon can make a world of difference in the meaning of the text!
Go U1!