@AR_Parker said in New Clean installation crashing in splash screen:

try turning off the intro movie in the launcher. that solved it for me.

Thanks, I remember I used to do that on old versions, it finally got it to start.

So this is what I had to do to get it working in W7:

-Find xinput1_3.dll, copy it, rename to xinput1_4.dll and paste it back
-Update windows to get the “Could not create SSL/TLS secure channel” thing going
-“nomovie” and “window” mode on the launcher

So the sim starts, now I have to set it up, specially curious to check if the new display extractor works for me, but that is a different history.

On my part this thread can be label as SOLVED and closed

Thanks a lot!

Hi there,

I run a pretty complex setup with many (many!) devices to run a full cockpit and I am in the process to adapt it from the 4.34 to 4.37.

Up to version 4.34 I have relayed on editing the DeviceSorting.txt and it has been a rock solid solution for a decade or so, never had an issue with USB devices and that´s a lot to say in a setup like mine.

After moving to 4.37 editing the file does not work for me anymore since the program keep on overwriting it and change the order of the devices, even if I try to set it to read only.

I did some searching in the forum and read some advices about not to rely on editing these files anymore and use instead the launcher. I am confuse about these advice. I don´t see how to alter and save the device order from the launcher. Also, if the launcher is free to alter the order of the DeviceSorting.txt file, doesn´t it challenges the whole point of why this file was introduced years ago?

I hope someone can help me to understand how things work now, I´m looking forward to enjoy the 4.37 in my cockpit, thanks!

Thanks a lot for your answer,

Yeah, it is W7, I thought i read in the manual that the unsupported limit was in WindowsXP and Vista, but fair enough, I understand that W7 has to fall sooner or later…

I know, I know… why in earth would someone still use W7? Well, I fly BMS in this setup:

…it is very fine tuned with the million screens and all and it would be a real pain in the ass to switch to W10 so I have stretched W7 as long as I could. I use this computer only for this cockpit an nothing else anyway and I have another new fancy one for my VR setup. But oh well, I guess the day has arrived…

@airtex2019 said in New Clean installation crashing in splash screen:

@Tulkas

[28/09/2024 17:13:43] [EXCEPTION] The request was aborted: Could not create SSL/TLS secure channel.::

This is Windows 7?

[28/09/2024 17:13:42] [INFO] :: FalconBMS Launcher v2.4.1.12

It also appears, you’re missing the latest BMS update. But probably the Updater.exe won’t run, for the same reason… (idk I don’t think anyone has tested it on Win7, and it’s certainly not supported).

Anyway, I don’t think that has anything to do with the issue because I have not even have the chance to use my keyfile since the sim crash on the splash screen.

The splash screen is the point of time when the game engine is initially loading stuff, including your key file. That’s why splash screens exist.

I did some experimentation. I use AIC (Aircore & Interface Controler) that has a output named “Gear Solenoid” which I assume reads the status of the shared memory bit “SolenoidStatus”. I just connected a multimeter to the output to check what was it doing on every situation:

It turns out that the AIC “Gear Solenoid” bit is basically a MAIN GEAR WOW SENSOR.

So the solenoid is powered all the time except when the three wheels are on the ground. That means I have to break the circuit when the gear is up, to unpower the solenoid, and then close the circuit with the permission button so I power the solenoid and I can lower the gear

@Boxer said in Shared Memort bit "gear solenoid":

@Tulkas – you gotta read the whole flightData.h

Look for MLGWOW and NLGWOW in LightBits3 - those are the weight on wheels predicates. There is only one for both mains, that’s deliberate.

I did, I did. I’m aware of the two WOW bits, but still not sure if they give me all I need. Would they just send info of weight on/off the wheels with gear down, what does that bit do with gear up? Still sending weight off? I need a bit to account for three situations:

-Gear up, solenoid is unpowered, lever locked
-Gear down, airborne, solenoid is powered, lever unlocked
-Gear down, on the ground, solenoid unpowered, lever locked

So, would the MLGWOW send the correct signal to the solenoid or is it just a weight on/off? I thought the “solenoidStatus” maybe is a more complete bit with all the logics already on it.

The DN LOCK REL is mechanical in my box so it does not need interaction with BMS. The same for the consent button, it will just connect electrically to the solenoid

@MaxWaldorf

That I know and it is fine, the consent button does not need to come from BMS because, well, if you are pushing the physical button that’s sending it’s own signal.

What I need from BMS is a signal that there is WOW, so the solenoid is unpowered and the gear level is locked in position, but also a signal that the gear is down and the plane is airborne (no WOW), so the solenoid is powered and the lever unlocked.

I suspect that “SolenoidStatus” may do that, but I need to know before I wire my LG box.

Thanks! That helped me to find it.

But I don’t know if I can get more information, would the solenoid be powered when the gear is down so permission button is no needed to retract?

Does exist a description of the information given by the different bits in the shared memory? I took a look on the technical manual but I could not find much.

I am building a landing gear box and I need to know what bit to use. “Gear solenoid” sound like the best candidate, but we have also “MLGWOW”.

Thanks!

Thanks @airtex2019 and @Revientor, that line edit did the trick.

It’s good that BMS has moved to 128 inputs per device to adapt to all the new gadgets that are available today, but I’m very happy we still have full flexibility to choose, it saves me a lot of tedious work. That flexibility and freedom is why BMS is still the best sim for cockpit builders well ahead of any other!

Well, this is now sorted out together with the setup of the shift layer. I was a bit confused in the beginning because the lines regarding the HOTAS lines have moved out to a separated file from the .KEY file. But the lines look the same, so I just pasted in my .KEY file and for the time being is working. I will study later the reason to have separated files.

Only two issues remaining to get 4.37 working nicely in my cockpit.

One more question/issue though.

Traying to assign all my DX inputs it looks to me that in this version of BMS the devices can have 128 inputs instead of the old 32, messing all my assignations. The PDF technical manual still mentions 32 inputs per DX device.

Is this so? Some options/file editing to limit it back to 32?

@oakdesign said in DeviceSorting.txt in 4.37:

@Tulkas
If you use the launcher things are much more dynamic. The Launcher writes all device related files every time you start BMS by clicking Launch, such as Key, devicesorting, axismapping. As it’s dynamic and allows to swap in and out devices without the need of manually changing any configuration, devicesorting therefore doesn’t have that neccessity as without the Launcher any more.
In addidtion Launcher saves all DX bindings per device in its own device xml files in User/confg/ folder

you can still use your old approack and still use the Launcher if you check the checkbox “no setup override” on the Launcher Main page, in that case if you click on Launch to start BMs no Device related files will get overwritten at all

Thanks a lot, that did it!

Hi there,

I run a pretty complex setup with many (many!) devices to run a full cockpit and I am in the process to adapt it from the 4.34 to 4.37.

Up to version 4.34 I have relayed on editing the DeviceSorting.txt and it has been a rock solid solution for a decade or so, never had an issue with USB devices and that´s a lot to say in a setup like mine.

After moving to 4.37 editing the file does not work for me anymore since the program keep on overwriting it and change the order of the devices, even if I try to set it to read only.

I did some searching in the forum and read some advices about not to rely on editing these files anymore and use instead the launcher. I am confuse about these advice. I don´t see how to alter and save the device order from the launcher. Also, if the launcher is free to alter the order of the DeviceSorting.txt file, doesn´t it challenges the whole point of why this file was introduced years ago?

I hope someone can help me to understand how things work now, I´m looking forward to enjoy the 4.37 in my cockpit, thanks!

@Icarus said in RTTR - rotation:

@Tulkas If its same screen then why is one flipped?

Because of the position of the controller board for the screen. It is really cramped on the back of an F16 front panel, and more than a decade ago we had less of a variety of small screens to make our MFDs. So we made do with what we found and ingenuity to put everything together. Turning the left one upside down is how I got it to fit. They were too big so a part had to go inside the center pedestal

There is a lot packed behind that panel!