BMS MISSING SHARED MEMORY BITS

[Nigel]

Guys please list any SHMEM bits that you think are missing or are needed and I will ask the Dev's to see if we can add them. This is not a feature request thread, you can ask that on the public forum. This is specifically for cockpit builders including desktop of course. I posted this for the UHF problem, but any other missing bits are welcome.
   Also, dont confuse this with the Beta Innovations issues in a separate thread, that is specific to Beta Innovations only. That one is for his software not responding to SHMEM bits already there.

[KK]

missing or are needed and I will ask the Dev's to see if we can add them

Great idea.

What's definitely missing in the SharedMem is the current HUD brightness level.
We can fire keystrokes INC/DEC to change the brightness level but this is just fine for gamer's with keyboard.
The simpitters with analog thumb wheels on the ICP need the current level in order to properly synchronize BMS with the pit.

It would be great to have it in the form [0,1,2,3,4,5]  where  0=OFF, 5=max brigthness
or
float [0 ... 100%]  if it makes them happier.

More to come ...
Klaus

[Focaldesign]

In game time for the analogue clock (and for standalone clock for GCI/Awacs/ATC).
And in viewpoint of ATC, wind (speed & direction) & QNH would be nice too

[Nigel]

missing or are needed and I will ask the Dev's to see if we can add them

Great idea.

What's definitely missing in the SharedMem is the current HUD brightness level.
We can fire keystrokes INC/DEC to change the brightness level but this is just fine for gamer's with keyboard.
The simpitters with analog thumb wheels on the ICP need the current level in order to properly synchronize BMS with the pit.

It would be great to have it in the form [0,1,2,3,4,5]  where  0=OFF, 5=max brigthness
or
float [0 ... 100%]  if it makes them happier.

More to come ...
Klaus

Klaus,
Already in, go to Setup, Controllers, Advanced then Avionics Control and assign a pot to the HUD brightness analog controller.

In game time for the analogue clock (and for standalone clock for GCI/Awacs/ATC).
And in viewpoint of ATC, wind (speed & direction) & QNH would be nice too

I will ask.

[Red Dog]

Just an inside note:

Sometimes, the coders expect the users to use a combination of different bits to get the expected results.
Don't think about one bit only but use combination of different bits.

Or understand that what you may be requesting is actually already implemented, but though of in another way

the analog values of the hud brightness is an example, it's not required if you use the system how it was intended to be used
When you wire a pot and declare it in the UI as HUD brightness, then when you enter 3D, the HUD brightness is defacto adjusted to the pot position, so no out of sync issues. It works just like a joystick, you don't have to centre your HOTAS before entering the pit
Same for other analog controls.

Beside, also understand that adding bits often means renumbering them is there is a very high chance of loosing backward compatibility with older (or even current) shared memory applications.
It's a request that dev consider very carefully and we should thank them deeply for that

[The_target]

In game time for the analogue clock (and for standalone clock for GCI/Awacs/ATC).

I thought it was already in FlightData2.currentTime. Am I wrong ?

Liquid oxygen on the Right Aux : But it's a nice to have

[Red Dog]

I think it's indeed in Flight data 2
AltCal reading (not per se QNH, but often is)
&
CurrentTime

although it may need additional parameters (or conversion) to get exactly what you need

Guys, there is an applet called BMSFlightData in your tools folder, there you can see it all

[KK]

When you wire a pot and declare it in the UI as HUD brightness, then when you enter 3D, the HUD brightness is defacto adjusted to the pot position, so no out of sync issues. It works just like a joystick, you don't have to centre your HOTAS before entering the pit
Same for other analog controls.

Thanks a lot guys for your prompt response. I have seen that and it surely is the solution for pots that are known to the system and found by the UI. This is unfortunately *not* the case for the pots that are connected to the PHCC mainboard. The OS doesn't know them
because they are not hooked into the system with a proper device driver.
It would have been so easy to solve this problem if I had that feedback value in the shared mem..
I cannot write a device driver for those pots as I don't have that knowledge.

[Focaldesign]

I think it's indeed in Flight data 2
AltCal reading (not per se QNH, but often is)
&
CurrentTime

although it may need additional parameters (or conversion) to get exactly what you need

Guys, there is an applet called BMSFlightData in your tools folder, there you can see it all

I was thinking in line of F4Awacs or sort like programs, without having to be in 3D. But that isn't possible via sharedmem then of course, I now realise

[Nigel]

RD,
I should have consulted you on this, you have WAY more experience with this stuff and your advice will be invaluable. If you could address some of these issues and figure out the best way to proceed it would be great. I feel like the Dev guys are willing to help and between us as pitbuilders we can raise awareness and move forward.

[Red Dog]

Well, i have been on that road quite often and dev wisdom always prevails.
keep the request coming, but i feel indeed that before going back to the dev, we should make sure there is no other way to achieve what we want to do in our pit. because if there is, the dev will point us to it and tell us to use the system as it's intended.

the other aspect is the one presented by klaus.
it's a specific request based on his own interfacing decision.
the system actually provides what he wants but not in the configuration he uses, because the configuration is specific to him

In these cases, it's hit and run to get a blessing from devs. It really is going to depend on the pros and cons of adding such support. If there is the slighest chance that it may break backward compatibility with shared mem readers, the decision will probably be no, we won't do it.
let's face it you can't break a system used by many to please a single guy.
if on the other hand the dev think the costs and risks are low, they will most certainly aim to please (barring their development time and mojo) i'd say

So keep the request coming, it's good to have these questions addressed anyway - but don't anyone be offended if the answer to your request is initially a pointer to where the feature already is implemented

[Nigel]

Agree 100% Olivier. Klaus, I dont understand how PHCC works that is different from any other system. Don't you also have analog pot inputs somewhere on a PHCC card?

[Willy]

Agree 100% Olivier. Klaus, I dont understand how PHCC works that is different from any other system. Don't you also have analog pot inputs somewhere on a PHCC card?

The problem is that the PHCC hardware/software doesn't emulate a Joystick with its analog axis.  I don't think it is reasonable to get the BMS devs to make a special interface for PHCC so I don't think this request should be included. 

Instead, PHCC types need to come up with a way to make the PHCC pots look like a Joystick axis.  I'm pretty certain that is what Lightning's JoyMapper software does via PPJoy drivers. 

Here's the excerpt from Lightnings readme.md file from his GitHub Repository on JoyMapper.

JoyMapper
Desktop application for remapping analog and digital inputs from DirectInput devices, BetaInnovations non-Joystick-class HID devices, and PHCC devices using PPJoy virtual joystick drivers.

@KK, if I were you and you are not using Lightnings code, I would download the JoyMapper C# code and write your own C++ version that does the same thing.  I'll bet it wouldn't be too hard to convert that code from C# to C++.  (But I could be wrong about that.)

[KK]

I dont understand how PHCC works that is different from any other system

Nigel,
PHCC is not a solution like others where everything is presented on the silver tablet with its price tag on it.
There is nobody that you can call up for support 8 am - 5 pm.
PHCC is for freaks. It is a solution that offers total freedom to do whatever you want.
Best example for this is Henkie with his wealth of additional boards etc.

PCBs, Firmware, Protocols, etc, is all available in source code.
No hardware delivery dependency from any person. Send the files to a China etcher
and get as many boards as you like. Soldering is up to you.
And also application programming is totally up to you.
This is the good and the bad. If you can't program an interface program between your pit and the PHCC motherboard, then PHCC might not be for you.
Lightning has developed a solution based on .net/C# that can be taken.
But again you should have some skills to adapt that.

Now back to your question with the pots on PHCC.
YES, the PHCC motherboard has direct inputs for pots (3 of them fast scanning).
BUT you will see the change of the pot only in the communication protocol with the PHCC mobo.
This information is not promoted any further into the OS of your computer with the aid of a device driver.
To my knowledge nobody has done this so far.
So the solution with pots in the BMS UI for display brightness doesn't work.

I was hoping to find an open ear for putting the current value of the HUD brightness into the shared mem.
No problem with backwards compatibility. The developers have extended the shared mem so many times with
additional sections that is won't hurt at all. To me it would be the clean solution to have this extra info in there.
Of course I can program around. Sending 5 INC's to make the maximum brightness, reading my current analog value and the sending DEC's until it matches with my pot. Done. Not a problem. But its a dirty solution and I hate to make workarounds for the shortcomings of a solution if it could be done better.
 
 

 

[Red Dog]

No problem with backwards compatibility. The developers have extended the shared mem so many times with
additional sections that is won't hurt at all. To me it would be the clean solution to have this extra info in there.

First that's an easy way out when you are outside the dev team -  We all tend to believe that solutions are easy when you are not responsible for carrying them out. Being on the inside of the dev group for more than 10 years, I have been on that path myself quite often requesting things from coders.
And from that experience, I can attest that they usually are taking the right decision. ANd yes they turned my request down quite often and showed me the intended way to work the problem out. And yes sometimes, that meant doing a bit of extra work

What would happen if dev would add each time a subsection when one pitbuilder requests something specific due to his own philosophy?
In 5 years, chaos and a completely unorganized shared memory.

Thankfully the shared mem remained pretty well organized and pretty well controlled thanks to the dev's vision, and most specifically one guy's wisdom
I wish it remains so in the future.

That doesn't meant your request is going to be denied today, it means it needs to be properly evaluated as I said above.

So keep the request coming, it's good to have these questions addressed anyway - but don't anyone be offended if the answer to your request is initially a pointer to where the feature already is implemented

The argument you used could be fairly returned to you as well:
Why can't you simply add a device driver interfacing 8 pots (Leo Bodnar BU0836 comes to mind) apart from your PHCC system and connected to your computer to implement these axis like they are meant to be interfaced? (there is actually much more than the single HUD brightness, FLIR and backup reticle comes to mind as well)
It's no different than a HOTAS system, Is your HOTAS part of your PHCC system??

If there is no real benefit in implementation to be gained by going through the PHCC system, why should the dev team work more so that you can work less?
If there is an obvious benefit, then the question is different, but is there?