Release EDRefCard - makes a printable reference card of your controller bindings

Status
Thread Closed: Not open for further replies.

Fnord Velkor

Fnord Velkor
Arrowroot 66 said:
It looks like it's caused by the Omni throttle. The pic of the left hand unit in your link doesn't show it, so EDRefCard seems to be assuming you have the normal base but since your A1 and A3 4-ways have the Up/Down/Left/Right all rotated by 90° you must have fooled it somehow. :)
....
Click to expand...

EDRefCard does not have the omni-throttle listed - reason being of course is that the omni is (was?) exactly like the normal stick electronically and functionally - so no need for a LH or RH omni-throttle. (You do know you can get an omni-adaptor to fit to a pre-existing stick.)

So no I didn't fool it, it (EDRefCard) just works that way.

After @Helmut Grokenberger 's post I see that an explanation for device ID difference is offered. I have never updated my firmware so that probably covers it.

So, if indeed the omni-throttles now have a different ID then perhaps EDRefCard can be adjusted / modified to recognise this - although I have never seen a graphic of the button / axes layout of an omni so maybe the graphic wouldn't change.
 

Brammmers

Brammmers
Darth Wonko said:
Unfortunately, I'm not a Python guy, so I'm not going to be much help. If, in the future, you do run into hosting issues, I can put it on one of my servers.
Click to expand...
I'm not a Python guy either, but it's not an overly difficult language. I'd be willing to give this a go (I've looked at the source and can see where some of the newer Ody bindings need to go which aren't scanned for).

I'd be willing to give it a crack. Team effort?

J
 

Brammmers

Brammmers
Just a quick update, nearly got it running in a WSL2 virtual Ubuntu machine. Hopefully I'll have it alive sometime tomorrow- at least locally as a testbed.

J
 

Brammmers

Brammmers
Cracked it!

Caveats:
1) It's running inside a WSL2 instance of Ubuntu on my WIn10 PC
2) Some things have been made to work "quickly" - i.e. chmodded 757 instead of doing it the right way - but it "works"

It was funny, the biggest issue is a change in how the error logging was working, which caused the script to crash on the newer Python. Fixed that then it became much easier to track the other blockers down.

I've managed to add some of the later Oddy controls (such as previous/next DSS signal - default bindings of Q&E).

I there's work to be done on the keyboard shortcuts piece - it doesn't render quite right, which is likely just a setting tweak needed for the newer libraries on Ubuntu 22.04 / Python 3.10.

Sample for my X56:
kb-test.png x56-test.png
 

Shneffley Stargazer

S
This is fantastic but for some reason when saving my keybindings it says my controllers don't exist. lzbjhx

They are Dual (left) and (right) VKB Gladiator EVO OTA I've seen lots of VKB EVO in there i guess is it the OTA ? possibly that causes it to be seen as not seen before but it's the same as the standard ones really.

It's only a basic keybinding enough to get the ship moving but i'll be building on it over time.
 

Brammmers

Brammmers
Shneffley Stargazer said:
This is fantastic but for some reason when saving my keybindings it says my controllers don't exist. lzbjhx

They are Dual (left) and (right) VKB Gladiator EVO OTA I've seen lots of VKB EVO in there i guess is it the OTA ? possibly that causes it to be seen as not seen before but it's the same as the standard ones really.

It's only a basic keybinding enough to get the ship moving but i'll be building on it over time.
Click to expand...
Likewise, the NXT and EVO differences seem to be in the gimble, so the actual stick is the same. The OTA piece looks to be electrically insert - it's just mechanical to change the physical angle of the grip. If I have your binds file I can give it a test here.

J
 

Helmut Grokenberger

Helmut Grokenberger
More accurately, the base is different between the old NXT and the new EVO line. It's not just the gimbal, one of the encoder wheels is also replaced with a self-centering three-position switch. I don't know what that means on the logical output side of things, or if it's just the physical actuation that changed. I only have two EVO sticks, I never had the old NXT. The USB IDs between the old NXT and the new EVO seem to be the same, as bind files of EVO sticks uploaded to EDRefCard are recognized as NXT sticks.

Having said that, the OmniThrottle is indeed just a mechanical adapter. I bought my OT preassembled, but you can buy the OT adapter seperately, and it's just the angled extension with a wiring harness. In terms of buttons and functions, there is no difference. However, as I already mentioned in an earlier post, there are different firmwares for the sticks and the OmniThrottles, giving them different device IDs. My OT came with the old "normal" stick firmware, but it seems newer ones might be shipped with the recent firmware with different IDs for sticks and OT. From what I could gather those IDs are:

EVO right stick: 231D 0200
EVO right OT: 231D 3200*
EVO left stick: 231D 0201
EVO left OT: 231D 3201

* this is my logical deduction. The other three IDs I have actually seen on my devices, my right stick has the above ID, on my left OT the ID changed from 0201 to 3201 when I updated the firmware.
 

Helmut Grokenberger

Helmut Grokenberger
Here is my current binds file. It's a bit convoluted because it contains keybinds for every control because of Voice Attack, and I was a bit inconsequential assigning primary and secondary binds :). The EVOs appear as Device="231D0201" (right stick) and Device="231D3201" (left OT) in the binds file, so it's litterally the USB device ID (tangent: I remember my old X52 Pro had a human readable ID, something like "SaitekX52Pro" or so).

I renamed it from .binds to .txt to be able to upload it.
 

Attachments

  • VKB NXT EVO + Omni Throttle.4.0.txt
    65.5 KB · Views: 112

Imagix

I
Hey, I was starting to look at the source to figure out how one could add support for the VKB STECS to EDRefCard. Is there a standard/quick way for drawing the call-out boxes, perhaps in InkScape? Even as a small step, it would be nice to be able to draw out all of the call-out boxes even if I have no images to point them to (yet).
 

Brammmers

Brammmers
All it needs (AFAIK right now) is an input template (svg I think), and a list of controls and the rectangle coords for the name boxes for each one.

Pretty sure I can do the rest from there.
 

Imagix

I
Brammmers said:
All it needs (AFAIK right now) is an input template (svg I think), and a list of controls and the rectangle coords for the name boxes for each one.

Pretty sure I can do the rest from there.
Click to expand...
Might be slightly more complicated. There needs to be two "controllers" in order to support the STECS. Too many buttons. Which means you'll get entries such as "<Binding Device="231D012D" DeviceIndex="0" Key="Joy_RXAxis" />" when talking about the settings. The Binding Device will be the same, but the DeviceIndex will be 0 or 1 (possibly 2 if one is using the STECS Max).
 

Brammmers

Brammmers
That's ok... Code handles devices 0/1 already by the looks of it.

Will need to see a sample binds file too to check out and test with.

J
 

Brammmers

Brammmers
The format for the templates - jpg. See "www/res/" folder for examples. Will also need to know which button maps to where; example: https://edrefcard.info/device/SaitekX56 and a sample bindings file that has things bound to each device (0/1/2).

Armed with those things, we could have a go at getting it to work.

I'm half tempted to try and port the code across to PHP rather than python, as that makes hosting easier/more secure and gets rid of the CGI implementation. But that'll take me a while in my spare time.

J
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom