I'll give that a try tonight. I've posted the issue on esim's forum, (but I'm not holding my breath.)

I tried running the Actkey for KEYON and key down with a defercall and was able to generate discrete mouse movements, but it still does the same thing, (just slower.)

Do you know the full syntax for all mouse related functions?
Do you know if TARGET can generate USB code for mouse events?

No joy on the affinity/priority fix. I also tried another PC with different OS/video/mouse drive in an attempt to determine if it is specific to my computer. No luck.

Somehow I didn't think that was gonna do it for ya, I was grasping with that. I ran into a similar problem working on one of my configurations, but it involved what appears to have been repetitive executions of REXEC overloading it and locking up TARGET. I fixed it in a similar manner to what I did to alter your code, but given you were just EXECing axis statements, I would have been surprised if that was the problem.

Still considering other ideas, but don't have anything worth mentioning yet.

I'm trying to get someone over at the esim forum with a warthog to reproduce the issue to verify it's not just my stick, (don't really think it is.)

Do you know of any more modifiers for the mouse emulation?

Do you know of any utilities that could capture the USB reports being send by the WARTHOG to see what's being generated? I don't think that the Device Analyzer is displaying all the data.

My thinking at this point is that the WARTHOG is sending multiple movement reports that most environments filter out, but that the 3D view are buffering.

Well, it's not your stick, but it's not (entirely) TARGET either.

That code works perfectly in A10C and BF3.

Using rFactor, however, I get the behavior you describe.

I understand what's going on...and I'm sure there's a way to fix it...but the current version of TARGET doesn't have commands to do what you want.

Is there a reason you can't use the slew control? It would be a LOT easier to make that work the way you want than figuring out how to do it with the hat.

You mean the slew control from the throttle? I not using it, (it's still in the box.) I have a modified gamepad attached to my desk for axillary input with my left hand. I can live without the mouse HAT, that not the point, I WANT it!

Seriously, I really appreciate all the effort you've put into this.

Do you understand why some interfaces "see" these erroneous commands and others don't, I'm curious?

The following is not known fact, just a hypothesis I figure is at least 95% likely to be accurate...

They're not seeing erroneous commands, it's the way the different titles are tracking. You can refer to axes in either "relative" or "absolute" mode. TARGET is functioning in "absolute" mode. You'll notice in windows when you launch the TARGET script and then bump your hat-mouse, the mouse "jumps" to the center of the screen. Then as you move it around, TARGET is keeping track of where the mouse should be based on your commands and positioning it accordingly.

This is fine for some titles...and even rfactor when you're not actually in the driving interface.

When you play SBPE, or drive in rfactor, it's accessing the mouse in "relative" mode. It's watching the _changes_ in the mouse location rather than the actual current position...and only updates its view while the mouse position is changing. The game will always be "chasing" the mouse.

That's why I was suggesting the slew control. It's easy to put that in relative mode, but I'm not sure if/how to do it using the method we're describing here.

Put another way....see what happens when you start the script and move the mouse ~ 2 inches away from the center in some direction using your hat-mouse.

Then move the mouse somewhere else on the screen using the real mouse.

Now use your hat-mouse again - notice the mouse "snaps" back to the last place you moved it to with TARGET rather than moving from the current spot....

Good news...got it working.

Just looking to see if I can/need to clean it up a bit.

This might be close...might be perfect...if there's a problem let me know. There's a few things that could be tweaked yet.

include "target.tmh"

int MouseU, MouseD, MouseL, MouseR, MouseUO, MouseDO, MouseLO, MouseRO, flag1;
//program startup
int main()
{
if(Init(&EventHandle)) return 1; // declare the event handler, return on error

flag1=1;

MouseU = REXEC(0,10,"TrimDXAxis(MOUSE_Y_AXIS, -2);");
MouseD = REXEC(0,10,"TrimDXAxis(MOUSE_Y_AXIS, 2);");
MouseL = REXEC(1,10,"TrimDXAxis(MOUSE_X_AXIS, -2);");
MouseR = REXEC(1,10,"TrimDXAxis(MOUSE_X_AXIS, 2);");

MouseUO = CHAIN(EXEC("ActKey(MouseU);"),EXEC("TrimDXAxis(MOUSE_Y_AXIS,SET(0));"));
MouseDO = CHAIN(EXEC("ActKey(MouseD);"),EXEC("TrimDXAxis(MOUSE_Y_AXIS,SET(0));"));
MouseLO = CHAIN(EXEC("ActKey(MouseL);"),EXEC("TrimDXAxis(MOUSE_X_AXIS,SET(0));"));
MouseRO = CHAIN(EXEC("ActKey(MouseR);"),EXEC("TrimDXAxis(MOUSE_X_AXIS,SET(0));"));


MapKey(&Joystick, H1U, EXEC("if(flag1) ActKey(KEYON+MouseU); else ActKey(KEYON+DXHATUP);")); // starts it moving
MapKeyR(&Joystick,H1U, EXEC("if(flag1) ActKey(PULSE+KEYON+MouseUO); else ActKey(DXHATUP);")); // stops moving

MapKey(&Joystick, H1D, EXEC("if(flag1) ActKey(KEYON+MouseD); else ActKey(KEYON+DXHATDOWN);")); // starts it moving
MapKeyR(&Joystick,H1D, EXEC("if(flag1) ActKey(PULSE+KEYON+MouseDO); else ActKey(DXHATDOWN);")); // stops moving

MapKey(&Joystick, H1L, EXEC("if(flag1) ActKey(KEYON+MouseL); else ActKey(KEYON+DXHATLEFT);")); // starts it moving
MapKeyR(&Joystick,H1L, EXEC("if(flag1) ActKey(PULSE+KEYON+MouseLO);else ActKey(DXHATLEFT);")); // stops moving

MapKey(&Joystick, H1R, EXEC("if(flag1) ActKey(KEYON+MouseR); else ActKey(KEYON+DXHATRIGHT);")); // starts it moving
MapKeyR(&Joystick,H1R, EXEC("if(flag1) ActKey(PULSE+KEYON+MouseRO); else ActKey(DXHATRIGHT);")); // stops moving


MapKey(&Joystick, S3, EXEC("flag1=!flag1;"));

}

//event handler
int EventHandle(int type, alias o, int x)
{
DefaultMapping(&o, x);

//add event handling code here
}