Stop the Cursor Movement
-
@jc1:
I realize it supports up to 16 devices. I only need and use 3, stick, throttle and pedals. I have no problem with all other shifted or unshifted keys. The documentation says SimCursorStopMovement was developed for Cougar, but Tiffy says it shouldn’t matter if the callback is used with CH Products equipment. My experience is that SimCursorStopMovement doesn’t work with the CH Throttle or CH Stick. I hope someone with CH equipment can demonstrate that it should work.
Have you check in the setting page that the button is firing the call-back. Go to SETUP/CONTROLLERS and press the button. You should see BUTTON: 263 and the call-back name shown. If this isn’t working but other shifted button on the same controller do then I’m out of ideas.
Unfortunately I’m all TM kit so I can’t test this either.
-
@jc1:
I realize it supports up to 16 devices. I only need and use 3, stick, throttle and pedals.
Sorry that part was for Tiffy
-
Have you check in the setting page that the button is firing the call-back. Go to SETUP/CONTROLLERS and press the button. You should see BUTTON: 263 and the call-back name shown. If this isn’t working but other shifted button on the same controller do then I’m out of ideas.
Unfortunately I’m all TM kit so I can’t test this either.
At your suggestion I did check. What I found was that the callback name returned was “BMS - Full”. All my other buttons return the correct callback name. If you look at the file named “BMS - Full.key” in the Falcon BMS 4.33\Docs\Key Files & Input directory, you will see that the first callback is SimDoNothing, and its description is “BMS - Full”, exactly what’s returned when I followed your suggestion. The callback SimCursorStopMovement is described in 4.33 BMS documentation, “Callback Updates.pdf” on page 12, as designed specifically for Cougar owners. What I suspect going on is that if the device is not a Cougar, then the programming logic detects that it’s not a Cougar and will not recognize SimCursorStopMovement. At that point the programming logic will default to the callback SimDoNothing. Great for Cougar owners but not anyone else. Hopefully there’s a better explanation that would satisfy the CH owners because it appears from other threads that the drifting cursor is a real nasty problem. I can eliminate the drifting cursor by selecting “keyboard” for the X/Y axes in Setup/Controllers/Advanced and then assign the cursor callbacks (up, down, left, right) to DX buttons, but that just doesn’t have the same feel as the microstick.
As I was checking into this matter I came across another situation which may be nothing more than a typo, but may be more significant. In the BMS 4.33 documentation “BMS Keystrokes - old vs new. pdf”, there is a SimCursorStopMovement callback with the keystroke combo Shift Z. Shift Y is not listed in the “BMS Keystrokes - old vs new. pdf”. In the BMS 4.33 documentation “BMS Keystrokes - Defaults.pdf” there is a SimCursorStopMovement callback with the keystroke combo Shift Y, and that is in my keyfile as "SimCursorStopMovement -1 0 0x15 1 0 0 1 “TQS: RDR CURSOR - Toggle Stop Movement”. My DX entry was “SimCursorStopMovement 263 -1 -2 0 0x0 0” But even when I use the keyboard Shift Y, nothing happens.
-
We screwed it up. We implemented it (commands.h, commands.cpp) but forgot to expose it (findfunc.cpp). It will be fixed in next update.
-
@Switch:
We screwed it up. We implemented it (commands.h, commands.cpp) but forgot to expose it (findfunc.cpp). It will be fixed in next update.
I have the same problem with my TUSBA TQS cursor… Drifting to the left all the time… Hope to solve my problem with your next update???
-
Lol I first read the topic title like it was propaganda for a new political movement. Sorry for the offtopic.
-
I have the same problem with my TUSBA TQS cursor… Drifting to the left all the time… Hope to solve my problem with your next update???
I HAD !!! that problem with my TUSBA R2 TQS cursor. It can be corrected using the RS_HID_DEV_TOOL.
-
I HAD !!! that problem with my TUSBA R2 TQS cursor. It can be corrected using the RS_HID_DEV_TOOL.
Can you specify, prese?
-
The problem with the cursor is that the controller doesn’t return to a repeatable zero - you can sort of “help” it manually during calibration, then you can set your deadband and help it more…but it takes some fiddling.
If you really want to go full-geek, you can note that the for the Cougar the controller acts as a mouse and describes a Lissajous in output…for a converted Cougar TQS that I use with FAF Mac I developed a ControllerMate scrip that determines which quadrant the controller is in and then outputs the appropriate Arrow key command for cursor control - this kills my drift very nicely, and also is very controllable. I still had to do some deadband setting. I’m pretty sure you can/could do the same thing using Foxy (and probably to an even finer extent), but that’s only for the Cougar.
BTW - I have a TUSBA R2 and was able to get the drift out by just adjusting deadband in a combination of places - R2 setup, BMS, CCP, Windows…again fiddly trial and error, but it can be done.
-
Thank you Stevie, I have TUSBA R1 and have not installed any probram for setup the device. I use only Windows(10) control panel. I will download and try the tools from RealSimulator.
-
Moved to tech support as documentation was wrong place
-
I have TUSBA R2 and just calibrate and set a deadband in RS_HID_DEV_TOOLS software. Its pretty simple. I do not use Foxy or Target and I use no settings in Windows or BMS or CPP. Before the TUSBA, I simply set a deadzone in BMS.
-
I don’t use Foxy or Target either. I like to let BMS do the work wherever I can!
-
Better hardware is really the answer to this problem (even in the code it has a comment that says – in effect – this is a workaround for poor hardware). Cursor deadzone settings is the next best answer. The callback…well it doesn’t actually do what you need unless the physical control is precise enough that it doesn’t deliver any “flicker” in position value (…which I’ve observed from the TM gear I have which includes the limp noodle thumb cursors is rather transducer specific…some stop stably, some just look to Windows like they’re in constant motion).
-
+1.
-
This post is deleted! -
I had a same problem with my TUSBA R1 and it worked for me.
First I thought all I have to do is just hitting the callback when the cursor is drifting, but it wasn’t. I misunderstood the callback.
When your cursor starts drifting, touch and move your microstick against the drifting direction so that radar cursor holds its position.
Hit the callback while you are keeping the cursor position, release your thumb from the microstick, then cursor will not drift any more.Hope this works for anyone facing the same problem.