I have released a very simple app for both iOS and android devices to render and control the ICP/DED and MFDs from BMS to both the Google Play Store and the App Store.

Find all general info here: https://kungfoo.github.io/falcon-bms-control/

Find the apps here:

Google Play Store: https://play.google.com/store/apps/details?id=ch.mollusca.falconbmscontrol
Apple App Store: https://apps.apple.com/tt/app/falcon-bms-control/id1542670299
If you do not have access to the Play Store, you can download an apk from here: https://github.com/kungfoo/falcon-bms-control/releases

A windows release of the client app is available on the releases page: https://github.com/kungfoo/falcon-bms-control/releases. Simply extract the zip and run the exe, no complex install needed.

If you find any issues, feel free to report them here or file them as github issues.

Source code:
If you want to dig in and submit a pull-request, I’d be more than happy to review it. Find the source code of falcon-bms-control here: https://github.com/kungfoo/falcon-bms-control

Ever wanted to invoke a callback like SimDropFlare or SimLaserArmToggle from a device on your network?
Are you building your cockpit button boxes with a Raspberry PI?
Building the next BMS button box app for tablets?

Now you can just send any callback name to your host over UDP and it will invoke it in BMS, reading the current key file and also watching the key file for changes.

echo 'SimStepMasterArm' | nc -u 192.168.1.212 9027

You can find it here:
https://github.com/kungfoo/falcon-bms-callbacker

Releases are here:
https://github.com/kungfoo/falcon-bms-callbacker/releases

Just download, unzip and run. I might add some authentication in the form of a shared secret later so random dudes on your network cannot simply SimEject you from your plane.

I have created a new release of the client app 1.4.0 that contains the changes to enable multiple different screen layouts.

Please find the files on the respective app stores and here:

https://github.com/kungfoo/falcon-bms-control/releases

You can now use multiple devices, for example two to have both MFDs on separate displays or use one really large device and have all the devices on one screen.

Currently supported layouts are:

• default layout (two screens: ICP/DED and two MFDs)
• one screen per device (portrait ICP/DED and both MFDs on their own screen)
• all devices on one screen (landscape ICP/DED and both MFD on one screen)

I will also create a new layout that is ‘cockpit’ like, so it’ll be [Left MFD / portrait ICP / Right MFD] for use with large landscape touch screens.

I am also thinking about adding functionality for ‘server defined layouts’ which would enable users to create their own on the machine running the server and then use those layouts on connected devices. This will come in a later release.

Apple being Apple the review is of course taking longer, once again.

@Fluke hey there!

To answer your questions briefly:
a) yes, should be possible in a next release: I want users to be able to define a custom layout on the server and upon restart the server-defined layout should be available in the app. I’ll try and make it restart-free later.
b) yes, landscape ICP has been added as a component and can again be supported as an exclusive device on a single screen with a custom screen layout.
c) this one might take a bit longer, I’ve added support for some switches on a branch an while back, but I was always unhappy with the fact that they’ll ‘desync’ from the state in the sim, which means it is very easy for the state on the screen not to reflect the state in BMS (for example after restarting a mission) since there’s no way to access the current state of quite a few buttons.

I hope that makes you eager to try the new release once it’s out (i’ll update the post here).

<p>I have published a new version of the server executable that is more resilient to dropped enet packets on sending RTT streams to clients.<br />If you have a really long network blip (over 6s at 30fps), it will still assume your client died and stop sending data to it.<br /><br /><a href=“https://github.com/kungfoo/falcon-bms-control/releases/tag/server-0.5” target=“_blank”>https://github.com/kungfoo/falcon-bms-control/releases/tag/server-0.5</a><br /><br />You can continue to use the 1.3.0 clients. </p>

The new version 1.2.0 is out: https://kungfoo.github.io/falcon-bms-control/ and https://github.com/kungfoo/falcon-bms-control/releases/

Android devices should get the update automatically (if installed from the Play Store), otherwise feel free to download the *.apk from the releases page.

Apple being Apple is taking a bit longer to review the new release, but it won’t be long I guess.

@CriticalMass @white_fang I see this would have to be a config option. I dislike the trick as well and people with large touch devices certainly don’t benefit from it. People with smaller devices do.

Look, i tried compiling and reviewed the code of the komercu app before i decided to write my own. it compiled after some tricks, but I could never get rid of the lag on the displays and especially not on the buttons.

I then decided to write my own app and made especially sure the buttons never lag, regardless of what’s going on with the texture streams. And then I figured out a way to get the streams zo actually run at 30-60fps over a good network. This took quite a while and before I had cracked that nut I did not want to add any more features. Once i had all that figured out, i added the rwr and now will likely be adding more buttons/switches and maybe very light support for custom layouts, once I figure out an economic way to define them.

Long story short: if the komercu app works for you and you don’t want any changes made to it: use it. It’s pretty cool in it’s own way and I don’t feel like I have to replace it completely.

I may add an option to toggle ‘expanded MFD mode’, I’ll see what I can do. But it definitely needs to be a user configurable option. And one of the design goals was: minimal configuration needed (but possible where necessary).

z just to let everyone know what’s going on: I’m currently away from my bms machine and home sailing the world. sadly the publisher of the iOS app has decided due to company politics to remove the app from the iOS app store a few weeks back. I’m talking to them and there is a good chance that they will publish it again, making it once more available in all the platforms. I’m sure the bms team understands why/how company politics sometimes get into the way and how working around that can be a hassle.

as of now the app works on Android, windows and Linux, so if you absolutely must run it and have an iOS device, find a cheap Android tablet. it’ll probably take me 2-3 falcon weeks to sort this out with the publisher…

@hoover I have been off-grid and mostly offline for a solid 1.5y, but now am online more or less again. I’ll continue to work on the app in the near future. I want to add a feature to support creating custom layouts and remembering them in the app settings. Once that is in place, I can see support for gauges being possible.

Apple has now accepted the 1.4.0 release for iOS as well!

@Nielzs sounds good. The place where you run it from should not affect its ability to load the active keyfile. It might just have needed a restart. It currently does not reload the keyfile on change, which i want to change in an upcoming release.

@Dracfalcon Nope, I am currently working on upgrading all the server libraries and then also the client base libs.

And I’m wondering, why the extraction display on the tablet is laggy af in 4.37, because it sure hasn’t been that way and my PC sure is fast enough to handle it easily…

Does anyone here have the app running on an iOS device with iOS 18.3.X installed? Is auto-discovery working for you? I cannot get it to work with the current dev version and I think Apple broke UDP broadcast (again)…

@Grimberno I will see to it that I can address quite a few of these things today.

• fix the hornet extraction code
• release a new version of the server with the changes for 4.37.6+ (no more busy waiting)
• release new clients with newest base libraries/engine and the new layouts

Let’s see how far I can get.

I feel like the MFDs stopping code has to be the server side sending thread either crashing or giving up on the client due to too many missed packets. I’d wager it’s the second one, since (i hope) a crash of the thread would show up in the logfiles. Maybe you can send me the log file of when the stop happens with the newest server version, since I added some more logging to when it gives up on a client that seems unreachable.

@airtex2019 what are these changes to rtt export and what do i need to do to profit from them?

@MCDeedle so that happens all the time in portrait mode on your device or just some of the times?

@Grimberno I’ll try to reproduce this, it is possible that the F18-E uses a different layout of the textures in shared memory.

@Fluke hey there!

To answer your questions briefly:
a) yes, should be possible in a next release: I want users to be able to define a custom layout on the server and upon restart the server-defined layout should be available in the app. I’ll try and make it restart-free later.
b) yes, landscape ICP has been added as a component and can again be supported as an exclusive device on a single screen with a custom screen layout.
c) this one might take a bit longer, I’ve added support for some switches on a branch an while back, but I was always unhappy with the fact that they’ll ‘desync’ from the state in the sim, which means it is very easy for the state on the screen not to reflect the state in BMS (for example after restarting a mission) since there’s no way to access the current state of quite a few buttons.

I hope that makes you eager to try the new release once it’s out (i’ll update the post here).

@Skorp There should not be 3 to 4s of delay, if that is the case, I suppose something is up with the machine sending the UDP datagrams or the network. There is a slight delay between keypresses, to make sure that BMS actually has the focus and registers the keypresses: https://github.com/kungfoo/falcon-bms-callbacker/blob/master/src/callback_sender.rs#L52C1-L52C70

I thought about making this configurable, but it’s only 30ms, so should not really be perceived as actual lag.
Then there is some delay added between modifiers and key press, but that also is only 50ms.

Of course it all adds up, but nowhere enough to explain 3s delay.

About your other question: I don’t really know what an mbm program is, but I’m pretty sure if they can make it send keystrokes, they can also make it send UDP datagrams. Maybe talk to the owners of the software, knowing that sooner or later BMS might/will get something similar to this built-in.

@MCDeedle if you could take a screenshot, I’d be most curious to see it.