Ice’s Falcon BMS Profile Updated for BMS 4.35
-
This post is deleted! -
I have the profile working fine and my warthog HOTAS has been programed with the new ICE key file. However, I have only used the first layer of each button for commands. I tried to understand the shift function in the Ice key file but could not figure out how to work it. I noticed that in Section 5.11 of the key file in the game there is a command for STICK: PINKY SWITCH (DX SHIFT). Is that how I implement the shift function? If so, how do I indicate which other commands that will use the shift function?
If you set a button to the STICK: PINKY SWITCH (DX SHIFT) callback then pressing this button shifts the DX values seen by BMS by a default 256. So for example this shifts the original 0-31 range to 256-287. Therefore if you assign DX callbacks in the keyfile to the 256-287 range then holding the DX shift button and pressing any of the buttons mapped to the original 0-31 range will give you the callbacks in the 256-287 range, hence a new layer.
So with the default value of g_nHotasPinkyShiftMagnitude of 256 you can shift up to 8 separate DX devices giving a possible 8 shifted layers with a maximum total of 512 DX buttons. Check out the Falcon BMS Key File Manual if you need more information.
-
Options for Next Update - Version 4.35-2
Is anyone actually using the YAME64 option on the Centre Panel Display for the moving maps?
If this is not being used I’m considering removing it for this next update.
If you’re still using it I’ll leave it in.
-
I personally prefer the integrated CPD over the YAME CPD as a it integrates with WDP and I can use my “own” MAP. ie save from WDP as white map with flightplan. BE is dynamcially read. In Yame you would have to set BE manually in Yame. Your version has automatic briefing file reading, Ymae hasn’t. Apart from CPD as long as YAME doesn’t get fixed it can’t be used for MFD extraction on most nvidia GPU.
To be honsest don’t see any advantages in using Yame CPD -
I personally prefer the integrated CPD over the YAME CPD as a it integrates with WDP and I can use my “own” MAP. ie save from WDP as white map with flight plan. BE is dynamically read. In Yame you would have to set BE manually in Yame. Your version has automatic briefing file reading, Yame hasn’t. Apart from CPD as long as YAME doesn’t get fixed it can’t be used for MFD extraction on most Nvidia GPU.
To be honest don’t see any advantages in using Yame CPDAnd Yame64 can’t put the CPD (or anything else AFAIK) up as an overlay on your main BMS 3D screen either! One question I have since I am (as of yesterday) 100% using Helios to display MFDs and gauges on my 8" Lilliputs and the CPD on my main screen, is there a way to change the refresh rate for the MFDs in Helios? Using YAME64 or RTT the MFDs are silky smooth but I detect a bit of a low frame rate/mild stutter using Helios to display them. The CPD on my main screen seems good, though the Data Tab did not have the correct flight data showing for me.
-
The CPD on my main screen seems good, though the Data Tab did not have the correct flight data showing for me.
Which flight data was incorrect? If you’ve extracted the CPD from the full profile then you may be missing some or all of the Lua code which is in the full profile and sets up the CPD pages correctly.
-
Which flight data was incorrect? If you’ve extracted the CPD from the full profile then you may be missing some or all of the Lua code which is in the full profile and sets up the CPD pages correctly.
I want to say all of it, and yes, I just copied/pasted the gauges over from the full profile so i’m sure i’m missing something. As all the data I need is on my kneeboards its not really an issue but if its an “easy” fix ill do it. Reality is once I set the CPD to 60Nm/Bullseye/Moving MAP view once in 3D (I have to Alt-Tab to use the mouse, main screens are not touch) I don’t normally touch it anyway. This is a pic of my setup -
And THANK YOU for your work on this linknet!!
-
I want to say all of it, and yes, I just copied/pasted the gauges over from the full profile so i’m sure i’m missing something. As all the data I need is on my kneeboards its not really an issue but if its an “easy” fix ill do it. Reality is once I set the CPD to 60Nm/Bullseye/Moving MAP view once in 3D (I have to Alt-Tab to use the mouse, main screens are not touch) I don’t normally touch it anyway. This is a pic of my setup -
And THANK YOU for your work on this linknet!!
As I said with the help of JoystickGremlin and VJoy you could handle button presses on a Helios profile with keyboard commands as well.
Assing a free (not used in BMS) keyboard combination in JG to a VJoy Virtual Button
Add the VJoy device is interface to the Helios Profile (if you have multiple VJoy Devices they are in order so VJoy Device#1 is first )
Assing the Vjoy Button press as input to the Helios Button you wan’t to be pushed with the keyboard. No need for alt-tab
-
I want to say all of it, and yes, I just copied/pasted the gauges over from the full profile so i’m sure i’m missing something. As all the data I need is on my kneeboards its not really an issue but if its an “easy” fix ill do it. Reality is once I set the CPD to 60Nm/Bullseye/Moving MAP view once in 3D (I have to Alt-Tab to use the mouse, main screens are not touch) I don’t normally touch it anyway. This is a pic of my setup -
And THANK YOU for your work on this linknet!!
Very nice setup, and no it’s not an easy fix.
-
Very nice setup, and no it’s not an easy fix.
:bowd:
Again, i’m perfectly happy with just the map functioning correctly! the FR issue with the MFDs may be related to the Lilliputs being 60hz while my displays are set to 120hz (or not!). For a test I set the MFDs to “hidden” in Helios and then ran RTTClient64 alongside just for the MFDs, they are smooth as silk so i’m going to use this combination as a solution until someone tells me different…
-
:bowd:
Again, i’m perfectly happy with just the map functioning correctly! the FR issue with the MFDs may be related to the Lilliputs being 60hz while my displays are set to 120hz (or not!). For a test I set the MFDs to “hidden” in Helios and then ran RTTClient64 alongside just for the MFDs, they are smooth as silk so i’m going to use this combination as a solution until someone tells me different…
Have a look on the Binding of the Data and Maps buttons you can easily switch so that your profile starts with the MAPS Panel active instead of the DATA Panel
-
is there a way to change the refresh rate for the MFDs in Helios? Using YAME64 or RTT the MFDs are silky smooth but I detect a bit of a low frame rate/mild stutter using Helios to display them.
The updating of data from sharedmemory (gauges / MFDs, etc …) is based on a fixed polling frequency that is at the core of Helios. The last time I looked into it I believe we discovered that it is 60hz. I noticed this small delay when I first implemented the Texture extraction of MFDs, DED, etc … in the Helios Falcon Interface. It’s not perfect but its workable in most cases. I do want to make it better but it has to be done without breaking the rest of Helios. YAME64 was smooth because I believe they extracted from DX9 and not from SharedMemory depending if you added the Direct3D hook dll or not. That was by far the fastest extraction method that I’ve seen besides the recent RTT implementation.
-
The Direct3d hook is not going to work as of 4.34. So with 4.34 YAME has to read from Sharedmemory as well
-
Quick (maybe) Helios question. I set the MFDs to “hidden” in my Helios profile so I could compare RTTClient64’s export to it. I’m sticking with RTT for the MFDs, should I remove the MFDs from the Helios profile or are they just being ignored using the “hidden” switch and not using CPU/GPU cycles or memory?
-
Shared memory reading is active as soon as you add the FalconInterface to Helios otherwise none of the gauges nor the CPD would be functional as they all are feed by the shared memory reader. I would have to dig into the code but i thing neither setting them to hidden nor to remove them completely from the Profile would stop reading the shared memory itself
-
Shared memory reading is active as soon as you add the FalconInterface to Helios otherwise none of the gauges nor the CPD would be functional as they all are feed by the shared memory reader. I would have to dig into the code but i thing neither setting them to hidden nor to remove them completely from the Profile would stop reading the shared memory itself
My concern is, is there a possible conflict if Helios is still pulling the MFD data while RTT is pulling/displaying it, even if Helios is not displaying it (MFDs)?
-
There is no conflict directly with having RTT and Helios polling for data in shared memory. If you hide the Helios mfds that should be enough mitigate any performance hit you might experience on the rendering side. If your not going to use the Helios ones then just remove them. It’s eady enough to add them back later if you want to switch back.
Sent from my iPhone using Tapatalk
-
There is no conflict directly with having RTT and Helios polling for data in shared memory. If you hide the Helios mfds that should be enough mitigate any performance hit you might experience on the rendering side. If your not going to use the Helios ones then just remove them. It’s eady enough to add them back later if you want to switch back.
Sent from my iPhone using Tapatalk
Thank you Wheelchock, as RTT handles the extraction much “smoother” i’m going to continue using the combination so I will remove them from Helios for now. Maybe when I find a cheap RTX 3090 the issue will not be present… ;D
-
Great, great work. Thank you so much for your effort.
-
Update 4.35-2 for BMS 4.35 U1