[EM 1.828-2.848] Bizarre Problem with Arvoch/Evochron Series and Saitek X65f *FIXED 2.848b*

[Infinity+1]

Vice,

If I use the SST to bind that hat to WASD, then everything works fine in the game. So I suppose this just became a non issue for me.

Thanks for your help.

∞

[Vice]

Interesting, the problem for the other user was they got 3 buttons signals back, not just 1. And it was (oddly) on an axis channel rather than just another button channel. So it would appear that the same control device on the same driver produces two different false key/button input patterns, which is what suggests a possible device-side issue to me (although it might also be driver related).

It does indeed appear that all of the buttons are registering on the device, but there is some kind of cross-over/blending where the wrong button (or perhaps key) is signaled for the wrong input (left HAT), producing unwanted control function (weapon fire and/or self-destruct). The negative value might be explained by the exceeding of an integer limit, but the button/key blending could be something different. I'm curious if perhaps some kind of key scancode might also be getting returned and that's where the problem is at. I may put together a key testing program for you to try out, or I may add it to the joystick test program, then see if that produces any results from your device. Pinning down whether it is really a mismatched button signal getting returned or a key signal could help diagnose things further.

Other game's could respond differently, especially those that don't already have certain key/button controls already mapped that Evochron does. So those key/button signals would just be ignored by other games while Evochron responds to them because they are mapped and the game is watching for input from them.

Edit: Just noticed, I included a key input signal readout at the bottom left of the joystick configuration program. So if a key signal is being returned somehow, it should appear there.

[Edited on 5-31-2014 by Vice]

[Infinity+1]

Running without the SST profile, the "Keyboard Input Signal" remains '0'

Running with the SST WASD profile, the "Keyboard Input Signal" becomes '30' (edit: and the joystick button 31 remains '0')

Also, I think their might be a 4th input being triggered, because even when I let go of the left hat, I still hear "beep beep beep" coming from EM. Sometimes that beeping lasts a while, and I am not able to get to the ESC menu until it stops.



[Edited on 5-31-2014 by Infinity+1]

[Vice]

Might be something like target selection or energy bias, but it's tough to say for sure unless the additional key or button signal can also appear in the joystick config program.

Very strange issue, glad using the SST to map it generally seems to resolve it. Maybe the SST software has some kind of bypass built into it where it disables the default button return(s) in favor of whatever SST binding is set up with it.

[Infinity+1]

I'm sure that is the case (SST bypass), because with my X52, anything programed in a profile overrode what was already mapped in EM.

[Infinity+1]

Vice,

1. That beeping is either the left or right mouse button. I managed to enter the NAV menu whilst beeping, and things would get selected when my mouse would pass over them.

2. The weapons being fired by left-hat DO CYCLE if I press 'N' (edit: In other words, its the "Fire Primary Weapons" command that is being triggered, not a combination of both "Fire Particle Weapon Only" and "Fire beam Weapon Only")

3. I completely unbound "Fire Primary Weapon" so that nothing at all should cause me to shoot... left-hat still fires.

Do you have something hard-coded to fire primary weapon?

[Edited on 5-31-2014 by Infinity+1]

[Vice]

Only the bindable input. The game is simply listening for any bound key, device button, or mouse button. If one is returned, then it activates that function. So it seems some form of control input is getting crossed/blended.

Certainly possible that the additional button being registered is the left mouse button. That would explain why weapons are firing when consoles are closed and items are selected when it is open. How and why the left hat input would cause the left mouse button to activate would be the mystery. However, if you also cleared the left mouse button from the fire weapon control, then it would be even more puzzling since the game would then be ignoring that signal entirely. Might also be worth looking at other secondary control options on the other pages of the key/button configuration menu to see if there might be any additional bound inputs the left hat might be returning.

[Infinity+1]

Vice,

Just to be sure, I COMPLETELY unbound Fire Prime, Fire Beam, Fire Partical, and Eject. Also made sure Mouse 1 & 2 weren't bound to anything. Left hat still fires and starts the eject countdown.

[Vice]

Yup, that's why I can't explain it. I take it you cleared the self-destruct bindings as well?

The game is only listening for input on the 3 device signals for mouse, keyboard, and joystick/gamepad for any given control functions. If the control mapping is cleared, then it's flagged with a -1 value and the game ignores them completely. So it's like the signal input from the left HAT is somehow blending over into other control channels.

[Infinity+1]

"Eject and Self-Destruct Ship" was the only command I saw related to that countdown, and yes, I unbound that.

Are there any controls in the code that didn't make it into the GUI, thus I would be able to trigger them, but not unbind them?

[Vice]

Not that I can recall, and in particular, not for that control function itself. To produce what you describe would require something to send a signal through slot 52 of the control input system on either the joystick/gamepad input set, matching keyboard scancode, or matching mouse button. If nothing is bound, then it shouldn't even be possible to activate the self-destruct sequence because to enable it requires input from one of those sources using the mapping value assigned to it/them. I would be interested in seeing your keymap8.sw file if you'd like to e-mail it to me.

[Infinity+1]

Sure, I just rebound a bunch of stuff, do you want me to unbind again before I send the file?

[Vice]

Whatever condition it is in that produces the SD mode when you hold the left HAT should work.

[Infinity+1]

I sent it to the email mentioned earlier in this thread.

[Vice]

Thanks, everything looks properly cleared as you described. I'll try to run some tests to try and artificially provoke a response from the self-destruct input system. Although I doubt it will produce an explanation, it's worth looking into just in case.

[Infinity+1]

Good luck Vice, let me know if you need any help from me.

[Vice]

Ok, I've managed to rule two possible causes out and find one potential cause. First, if no keyboard or mouse control is mapped to that input channel, then the game will completely ignore them. So that rules out the X65 sending back some kind of key or mouse signal entirely.

The only possible way it appears this could be happening is if the Saitek driver/hardware considers -1 a valid button channel. If so, then there is a possibility that this could trick the game into thinking it's received a valid input signal from that '-1' button. Why that one button and why the driver > Windows/DirectX > game would think it's a valid button value would be a mystery. But it does provide a way to test against this idea. To do that, what we'll need to try to do is change the '-1' to something else that doesn't try to report to the game as a valid button channel via DirectX/DirectInput.

Since I don't have a X65 to test with, I'll need to rely on your results. I've sent you a copy of your config file with the required line modified with a '-2' value. If you start counting from the first '0,-1' value in that file, it's the 53rd line down from that and will read '0,-2' (below 0,3 and above 0,15). First, try it with that value in place. If the same behavior occurs, then try it with the number 40 in place, so '0,40'. See if the behavior changes at all.

If it continues, then try mapping that specific 'Eject and Self-Destruct' control to a button other than your left HAT. You can do this test in-game. Any button will work and once mapped, the value will change in the file to something like '0,20' or any value between 0 and 31. Once that's done, launch the game and see if the behavior changes. One way or another, if this is the cause, we should see a change in the behavior with a different value in place on that line.

[Infinity+1]

Value: (0,-2)
Result: Left hat still triggers fire BUT NOT EJECT

[Vice]

That's encouraging, the same value could be applied then to the weapon fire slot and likely solve it. That one is the 12th line starting from the first '0,-1' entry. It shouldn't hurt anything if you want to change the others around it to '0,-2' just to be sure.

[Infinity+1]

Vice, you're never going to believe this...

With the new -2 value in place, the left-hat button just makes that beeping sound (no fire, no eject), but now the down-hat button is performing fire+eject (no beeping)!

[Infinity+1]

I went a step back to confirm, and sure enough, with the file you sent me (-2 in the 53rd slot down) the eject just moved from left-hat to down-hat

[Vice]

It must use negative numbers as well then, odd. Lol, try value 40 in its place and see if that helps resolve it by exceeding the normal range. If we can find a value that works, then changing any 0,-1 to the new 0,X value should resolve any such unwanted signals.

[Infinity+1]

Ok, Changing them (just those 2, not all) to 0,40 moved the fire/eject over to a hat on the stick. 'Up' on the top rightmost hat is the new culprit.

That button, using the joystick exe, registers as Joystick Button #8, value of 256. The down-hat that was affected when (0,-2) was used is Joystick Button #30, value of 1073741824.

[Vice]

Interesting, -40 -100 etc might also prove effective.

[Infinity+1]

I think this HOTAS has too many buttons! -40 moved it to a new hat. There are only 8 hats, so 5 more to go.

I'll keep trying 'till I find a number that works.