Topics created by Focaldesign

Latest BMS & Balkans version in use.
We were returning from a SEAD flight (multiplayer), low on fuel I diverted to Rivolto. When changing frequencies I correctly received QNH & active runway (06), but no lights turned on. When calling an autonomous approach, no lights either. Tried calling emergency landing (aft-fuel low warning), still no lights.
Set EHSI to CRS 060 and tried aligning at low level. Got a glimpse of difference in greyscale visual, hoping it was the runway and not the parallel taxiway. Still almost no visibility at 50ft AGL. Landed safe and sound but with sweaty palms and back!

Any idea what can be causing this odd behavior?

At 50’AGL

Split second before touchdown

Hi all,

Been setting first steps into Helios but encountered an issue.
In Belgium and France we use an Azerty instead of Qwerty keyboard. If I start from ice’s helios keyfile it seems I get issues in helios. For example a callback mapped to ctrl alt - would trigger cctrl alt = because the = is on azerty where - is on a qwerty.
Other then swapping to a qwerty keyboard and windows setting, any workarounds known?

Tested vanilla KTO & Balkans 3.5 with modified Janhas acdata.
In both I tested blck52 & any country MLU. Verified with shared memory (as read by Yame; Yame tested with tape VVI gauge, needle VVI gauge & CP60 data gauge to eliminate texture issue on YAMEs side).

Baseline: in both theaters, I first try the block52 with tape VVI gauge and compare the value in 3D in BMS to shared memory and extracted gauges. They correspond ok. That should make me believe the shared memory and original BMS 3D VVI textures are ok, and YAME is reading it out and visualizing it correctly too.

Comparison: When I switch to an F-16 with needle VVI (e.g. BAF MLU) the shared memory and the extracted gauges still are in sync. However in BMS 3D, once moving above 3 to 4k ft/min (or below -3/-4), the needle shows a too high (low) value (e.g. +4k ft/min in memory shows needle at +5k).
You can also tell by when moving to the max the gauge can offset (+/-6), the needle is past the 6 marker in 3D. The needle is actually correct (6 is 90°), but the texture shows the 6 a bit shallower then full 90°.

I believe the used VVI gauge texture is a bit wrong as it comes to the indicated white markings.
I have cut out the texture from the dds, and placed a picture of a real one I took above it with the same 0 point and matching the up/down labels on the top/bottom left. You see the further you go up or down the scale, the more the real start to diverge from the BMS version. I think the used picture was slightly badly squeezed/transformed during implementation.

Not a biggy, but I thought I’d let you know.

…should…and hope so…because I’m building my pit without an O2 gauge…OBOGS style!

@hoover:

Thanks for the cornfield bomber link. While reading the article I just found out that the air force magazine is now free to download, nice perk! 😄

More info here:

http://www.airforcemag.com/Pages/HomePage.aspx

While I guess they’re not the most “objective” publication around, it’s nice to be able to download entire magazines in PDF format to your reading device of choice.

All the best, Uwe

Not only that but they implicitly acknowledge the existence of time travel technology !

http://secure.afa.org/joinafa/AFMag2017/AFMag0217/AF_Feb2017.html

@-Ice:

Curious as to why you are doing this? Voice comms no good?

I’ve tried VAC and alike but never got it to work optimal for me. As we use human ATC/GCI often, and we try to use the same phraseology when practising single player, they can’t be matched with VAC profiles easily.
I need some comms from time to time and in my semi pit the keyboard is not handy at all. So it’s much easier for me to be able to access BMS comms menus via my ICP in front of me then.

not running at at the moment but IIRC also based on shared mem so those values. I recall seeing small discrepancies in the time I used MFDE.

@Reaper58th:

Has to do with the custom airbases in Balkans. Nothing you can do against it AFAIK 😞

good to know.
Hope it gets fixed in the future somewhere. Our sqn would love to permanently move from Kunsan to Aviano, but this is not optimal for human ATC.

BMS 4.33 U1.

When pushing the MAL & IND LST button in 3D pit, I want to read the light bits to have all extractions light up.
If I just look at the lighbits of all separate items, they light up of course, but only the ones implemented in BMS. That means some of the caution panel don’t light up, and for MLU eyebrows some indicators also stay out.

However, in “Flight Data.h” version 117 we base ourselves on

enum LightBits { AllLampBitsOn = 0xBFFFFFEF }; enum LightBits2 { AllLampBits2On = 0xFFFFF03F, AllLampBits2OnExceptCarapace = AllLampBits2On ^ HandOff ^ Launch ^ PriMode ^ Naval ^ Unk ^ TgtSep ^ AuxSrch ^ AuxAct ^ AuxLow ^ AuxPwr }; enum LightBits3 { AllLampBits3On = 0x1147EFFF, AllLampBits3OnExceptCarapace = AllLampBits3On ^ SysTest }; enum HsiBits { AllLampHsiBitsOn = 0xE000 };

EDIT:
After a lot of more testing in several types and several situations I can reproduce the issue in 2 distinct situations.

Regardless what F-16 type:
During ramp start all works normal.
From the moment I put CMDS (or EWS in certain types) out of OFF and into stby/man/semi/auto/byp the light bits change when pressing mal & ind and does not correspond with the sharedmem allightson hex codes as states in flight data.h file.
When choosing commit taxi directly, the same issue exists.
Whenever I’m weight off wheels, the issue is gone again and no matter if I started from ramp, taxi, runway, airborne; and no matter the position of the CMDS mode switch, all works correctly.

In BAF MLU with Carapace the issue is exactly the same as described above plus additional occurrence when EW (CMDS) is still off but Carapace RWR is powered on.

Can someone confirm this is correct behavior or a bug? I know the gauge isn’t working in BMS 3D pit, but it is giving a pretty correct value in shared memory so potentially useful for gauge extraction. But then I’d like to know if the behavior is as real life.

Based on the third item for that list it would more be weight off wheels?
In my test starting from ramp it has been in off from setting it so when still cold until airborne and flame out, so shouldnt be fired

@Red:

I see the no data at ramp with the shared mem EHSI

but power distribution in BMS is not always like the real docs. There are still lots of room for improvement in there

With Lightnings MFDE I indeed so NO DATA at a certain point. That’s what got me thinking about when I should & shouldn’t appear, and then I noticed I couldn’t get it in BMS (or I’m not testing right).
Can anyone enlighten me on what HSI_OFF exactly flags in sharedmem? And if my logic is correct on the 3 situations mapped to BMS sharedmem?
The 2nd question I also can’t immediately explain, but I’m far from an avionics specialist so wonder what the reason can be.

Thanks Focaldesign,
I will try this 😄

@Frederf:

When the DTC is loaded by the DTE, is the file (and they call them files) loaded straight into the ARC-186, failing if it isn’t on? I doubt it. I bet there is some MMC or UFC memory where that radio channel data is loaded which doesn’t require the box in the avionics bay to be on at all. There is some mention of a “UFC battery” as well.

There is no backup control to the VHF radio system and it is controlled strictly through the UFC system so obviously as far as DTC loading is concerned it is going to the UFC system.

The UFC battery is for the scratchpad memory of the DEEU/EXDEEU. It makes the volatile memory (kinda like the RAM in your computer) non-volatile while the battery is connected. That holds all of the information like steerpoints, radio channels, ILS freqs, TCN freqs, etc. between flights.

@Frederf:

My guess is that the data plugged into the avionics bay box is strictly frequencies (no channels) and that it is the control head (UFC/MMC in F-16) that has understanding of channel preset-frequency table. So the jet is loaded with ch1 = XXX.XX Mhz, ch2 = YYY.YY Mhz, and so on. When it comes times to tune the radio the electronic tickle down the cable into the avionics bay is just “tune XXX.XX Mhz.”

Yes the radios only need to be told what to tune to. The channel number is irrelevant to the radio itself. The MMC isn’t really getting involved in radio tuning. That would be the UFC alone for VHF or the UFC or the UHF radio head for UHF comms.

Although this is an aside the DEEU is in the cockpit right behind the ejection seat so for UHF comms all of the controlling happens right there in the cockpit and not in an avionics bay. 🙂

@Frederf:

I’m also guessing that the VHF radio would still be tuned to the last frequency set on the last flight similar to how when you CNI BUP you can still key VHF because it’s tuned but you have no control over future frequency changes. Unless UFC initializes the VHF to some frequency every time it’s powered on (and why ch13 of all things?) or perhaps the VHF memory is volatile and it isn’t tuned at all at initialization.

The UFC would be the controller of the VHF and tell it what to tune to. Yet another case of something I don’t have an exact answer for as no one ever tries to turn on the aircraft except for the UFC and then tries to transmit on VHF to see what happens.

@Frederf:

Yes, airborne with MAIN PWR switch in the off position some stuff keeps working. On ground this switch position additionally disables the standby generator and disconnects the battery from the battery bus which airborne doesn’t do. And so despite selecting MAIN PWR off after the crash the airborne state prevented the battery bus from being disconnected and therefore the COM1 radio continued to function.

that could Indeed be it. If airborne State is determined by weight on wheels, And I landed without wheels,
It makes sense.

…curiouser and curiouser…I can’t help thinking that it has something to do with the wind, that your ground tracks are actually correct, and this is a trick of geometry somehow - I believe your instruments and your flying. I’m stumped.

Compared to stock block 52, on MLU MISC the A/P switches are switched in place (ROLL - PITCH) which is correct.
Pitch switch also acts correct (up ALT hold, center OFF, down ATT hold).
Roll switch however acts like the block 52 counterpart so does not what the labels on the MISC panel suggest, which is very confusing.

MLU MISC label - BLOCK52 label - BMS functionality
–--------------------------------------------------------------
HDG SEL - HDG SEL - HDG SEL
OFF - ATT HOLD - ATT HOLD
ATTT HOLD - STRG SEL - STRG SEL

@Focaldesign:

Anyone an idea on what is the cause?

Base of clouds in weather settings.

Ok, new question that could take advantage of this bug…

Some Vipers, like the BAF MLU have another position at the external lighting master switch besides off & on, namely covert. Based on the -1 found online, it disactivates all normal wing/tail/fuselage lights and activates IR-only lights, located only on top. That way, pilots with NVG can see the IR lights blinking, people on the ground cannot.
This could be done by implementing the IR pointer dots in a smaller size on the respective locations and have them activated when switch goes to covert in the pit. That would be awesome 🙂

Hi guys,

Never had this in previous 4.33 mission debriefs but yesterday night 2 MP flights resulted in scrambled text afterwards in the debrief.
Any clue?