Ice’s Falcon BMS Profile Updated for BMS 4.35
-
Hi Oak,
Is there any way to run and old version of Helios, which currently has my personalised profile on it, along side, in parallel, with the new version of Helios and you 4.35 profile?
Why do I ask? I would like to transition from mine (old) version and profile to your (new 4.35) version which is a fantastic leap forward.
Why Transition? I have my profile, using MFDE, running across 5 touch screens, so its not a simple matter as it would be if it was just 1 touch screen and to be honest I could not fly very effectively without HELIOS.
Anyway - is there any way to run both at least in the short term?
Ironman.
Fisrt again credits for the profile don’t go to me it’s the work of @linknet
Technically you could have both a 1.4 and 1.6 version running in parallel but not by using the installer. If you install 1.6 you overwrite your old 1.4 installation.
I personally have both 1.4 and 1.6 but I build Helios from the source code so I don’t use the “normal” user version. If you know how to handle git checkout, and Building an application from source in case of Helios with VisualStudio it would be achivable -
Apologies - linknet.
And thankyou both for your responses
-
It has been a long time since I played BMS and I no longer can use Target so how I would like to be able to implement the shift function when using Ice’s key profile and this Helios profile. Any thoughts?
-
The shift function has in the first place nothing to do with Helios at all and the ICE key file.
The question is which tool do you use to set your DX Bindings for the HOTAS?
In BMS UI you can’t directly set the shift layer you would have to add your shift layer bindings in the keyfile manually
Tools that kan be used to make the DX shift layers are eihter the Excel keyfile editor. Or the easiset and most user friendly way is to use the alternate Launcher for all of your HOATS bindings -
oakdesign: I know that the shift function has nothing to do with Helios, I just didn’t want to screw things up. Therefore, I will try the Alternative Launcher and your 2. If using Alternative Launcher and/or needing to change keyfile bindings method.
-
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?
-
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?