I’ve switched from a CH Fighterstick to the Warthog and I’m trying to port over a function I had in the CH.
I want to toggle between standard DX buttons and mouse movement for HAT1 using 4 buttons, (which also need to send keystrokes or macros.) 3 of the buttons use the standard DX mapping, 1 button uses the mouse config.
The scripting manual has simple code to map the mouse to the hat, but apparently I can’t EXEC the AXIS command, so I can toggle the mouse on and off with a variable. It compiles, but nothing happens when the HAT is moved.

Is there another command that sends mouse data?
Is there another way to conditionally execute AXIS()


I’ve looked at the layer function, but don’t think that I can use 4 buttons to toggle the 2 states.

I think I can help ya here, but I'm not sure _precisely_ what you want.

Care to share the code you have (even if via PM) and I'll take a look?

Thanks for the help.

I'm not at home at the moment, but I can give you some of the code I'm having issues with.

If I could get this to work:

MapKey(&Joystick, H1U, EXEC("AXIS(MOUSE_Y_AXIS, -80, 20);"));

Then I could execute it in an if/else statement, test a flag that is toggled on and off by 4 buttons.

It compiles, but doesn't produce output.

As it says in the book, 'AXIS' inside EXEC is forbidden.

What you'll need to do is a little more complex.

Immediately above "int main", add a line:

int MouseU, MouseD, MouseL, MouseR;

Then inside main, add 4 lines:

MouseU = AXIS(MOUSE_Y_AXIS, -80, 20);
MouseD = AXIS(MOUSE_Y_AXIS, 80, 20);
(add appropriate for L & R on MOUSE_X_AXIS as well)

Then for your mapping,

MapKey(&Joystick, H1U, EXEC("ActKey(KEYON+MouseU);")); // starts it moving
MapKeyR(&Joystick,H1U, EXEC("ActKey(MouseU);")); // stops moving


And that should get you in business.

I apologize for taking so long to get back to you with my thanks for your assistance.

“As it says in the book, 'AXIS' inside EXEC is forbidden.”

Yes it does. Argh! I even remember skimming through that paragraph when I was looking for something else, (although I wouldn’t have known how to work around it, without you help.) I’d love to find a programming reference with a table for all the functions, so I wouldn’t have to jump back and forth looking for syntax, usage, etc.

The code you provided works great, (in Windows), exactly what I was trying to accomplish. I do, however, have a problem with the mouse feature in the game itself.

I’m trying to use it in SteelBeasts PE for the unbuttoned driver’s position. The simulation doesn’t support anything except the mouse for panning the driver’s view. It doesn’t require fine control or range of motion, but it’s nice to be able to turn your head a little when dashing between cover.

In game, when I enable the mouse, the view is uncontrollable. I've played with the AXIS parameters to try to reduce sensitivity, but it doesn’t work as expected.

It doesn’t seem to be just the game, the CH handles this function without issue. The WARTHOG mouse works in game in the map view as you would expect; there is something about the external views that different.

When using the mouse function on the WARTHOG, the view will swerve rapidly in one direction. Sometime, even after changing direction on the HAT, the view will persist in the old direction every time the HAT is pressed, (regardless of direction.) There seems to be a buffer that it getting overloaded with inputs even when large delays are added to the axis definitions.

I tried to include the PULSE modifier to the ActKey(KEYON+Mouse?) command to try and restrict the amount of input sent to the game. I'm not sure that it’s supported or if it has any effect. Since the amount of view movement required by the drivers position, even if I have to repeating press the HAT, it would still be usefully.

Is there a way to “clear” the mouse status to remove any pending movement commands?

Is there a way to force individual mouse movement commands?

Thanks for any assistance you provide. Below is some of the sample code I’ve been trying for your reference: The S3 button simulates the crew position button to toggle the HAT state.


include "target.tmh"

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

flag1=1;

MouseU = AXIS(MOUSE_Y_AXIS, -20, 50);
MouseD = AXIS(MOUSE_Y_AXIS, 20, 50);

MouseL = AXIS(MOUSE_X_AXIS, -20, 50);
MouseR = AXIS(MOUSE_X_AXIS, 20, 50);


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

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

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

MapKey(&Joystick, H1R, EXEC("if(flag1) ActKey(PULSE+KEYON+MouseR); else ActKey(KEYON+DXHATRIGHT);")); // starts it moving
MapKeyR(&Joystick,H1R, EXEC("if(flag1) ActKey(MouseR); 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
}

Will try to give it a look in a little while.

I wouldn't advise using PULSE for something like that though. Probably doesn't matter in this case, though.

It worked as desired in A10C. :\ A bit jerky with the 20,50 #s. 20,5 was smooth but a bit fast. 10,5 or 5,5 oughta work well...

I'm working on something an extra couple of logic layers deep to test your theory of stuffing some sort of buffer for axis commands, but I doubt that's it.

(FWIW, before you or anyone questions, I am 100% positive I was using the mouse mapped commands for view panning and not the default dxhat panning)

Give this a try. It has logic that should guarantee there's no "buildup" of mouse axis commands, and the panning in A10C is almost identical using the hat-as-mouse-axis and the normal view panning with A10C parsing the DXHAT as a pan.


include "target.tmh"

int MouseU, MouseD, MouseL, MouseR, MouseUoff, MouseDoff, MouseLoff, MouseRoff, flag1, flag2, flag3, flag4, flag5;
//program startup
int main()
{
if(Init(&EventHandle)) return 1; // declare the event handler, return on error

flag1=1;
flag2=0;
flag3=0;
flag4=0;
flag5=0;

MouseU = CHAIN(EXEC("flag2=1;"),AXIS(MOUSE_Y_AXIS, -5, 5));
MouseD = CHAIN(EXEC("flag3=1;"),AXIS(MOUSE_Y_AXIS, 5, 5));
MouseL = CHAIN(EXEC("flag4=1;"),AXIS(MOUSE_X_AXIS, -5, 5));
MouseR = CHAIN(EXEC("flag5=1;"),AXIS(MOUSE_X_AXIS, 5, 5));

MouseUoff = EXEC("flag2=0; ActKey(MouseU); ActKey(MouseUoff);");
MouseDoff = EXEC("flag3=0; ActKey(MouseD); ActKey(MouseDoff);");
MouseLoff = EXEC("flag4=0; ActKey(MouseL); ActKey(MouseLoff);");
MouseRoff = EXEC("flag5=0; ActKey(MouseR); ActKey(MouseRoff);");

MapKey(&Joystick, H1U, EXEC("if((1==flag1) & (0==flag2)) ActKey(KEYON+MouseU); else ActKey(KEYON+DXHATUP);")); // starts it moving
MapKeyR(&Joystick,H1U, EXEC("if(flag1) ActKey(KEYON+MouseUoff); else ActKey(DXHATUP);")); // stops moving

MapKey(&Joystick, H1D, EXEC("if((1==flag1) & (0==flag3)) ActKey(KEYON+MouseD); else ActKey(KEYON+DXHATDOWN);")); // starts it moving
MapKeyR(&Joystick,H1D, EXEC("if(flag1) ActKey(KEYON+MouseDoff); else ActKey(DXHATDOWN);")); // stops moving

MapKey(&Joystick, H1L, EXEC("if((1==flag1) & (0==flag4)) ActKey(KEYON+MouseL); else ActKey(KEYON+DXHATLEFT);")); // starts it moving
MapKeyR(&Joystick,H1L, EXEC("if(flag1) ActKey(KEYON+MouseLoff); else ActKey(DXHATLEFT);")); // stops moving

MapKey(&Joystick, H1R, EXEC("if((1==flag1) & (0==flag5)) ActKey(KEYON+MouseR); else ActKey(KEYON+DXHATRIGHT);")); // starts it moving
MapKeyR(&Joystick,H1R, EXEC("if(flag1) ActKey(KEYON+MouseRoff); 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
}

Teej, I was working on this when I noticed your update.

I created these to videos to illustrate the difference between the two joysticks

The first one is the CH stick. The video starts in the map view to show the sensitivity and control of the mouse. The movement is fairly choppy, but that’s mostly because of laziness. Since a great of fidelity isn’t need in the driver’s view, I never changed the resolution from my initial settings. I have no problem drawing a box.

In the driver's unbuttoned position I am able to control the view. After panning back and forth, I draw a square and then follow the barrel.

http://youtu.be/KJCUoi09eKE

With the WARTHOG, I set the sensitivity down to 5,5 so I would have some control of the mouse in the external view. It can draw a rectangle in the map view easily, although more slowly.

In the external view, it’s a different story. All I’m trying to do is move the view slightly off-center. The view skews right to the limits of travel immediately. When I try to return to the center, it resists and then move in a completely different direction, left. Finally after forcing it away from the corner, it finally moves back to the center and beyond. Even if I stop pressing it one direction and try to change direction, when I enter input, it continues moving in the old direction.

http://youtu.be/NDNwLEb7J4c

The third video shows the new code. It seems to be identical to the first at 5,5. I change it to 5,50 to illustrate what seems to be the cause. I tried to move 10 increments at a time. Once I change direction with the HAT, the view continues to move ~10 more times in the same direction. Eventually, the buffer of wrong directional data is exhausted, and the mouse will start moving in the correct direction. After I change direction, it continued moving an equal number of times. Where is the other movement data coming from?

http://youtu.be/85DZMhPl3-E

I really appreciate all the effort you put into this. I’m going to try posting in the Esim forum to see if someone can identify the cause, (I wouldn’t expect a resolution.) But it would be nice to know why this happens.

Thanks,

I never doubted you had problems with the way it's working. I'm just a bit stumped as to why when it works fine in the Windows UI and fine in A10C.

I would suggest playing a bit with the processor priority / affinity of the steel beasts executable and TARGET service to see if it helps.

Ideally everything should work with all showing as "normal" and on "all processors".

If steel beasts seems to primarily use less cores than you have, I'd try to force it onto an appropriate number of cores and force TARGET (TmService.exe in the task list - not the script editor) to other cores. If that doesn't do it (or SB uses all the cores you have, try setting tmservice.exe to "above normal" (don't go any higher than that).

Just a thought. (shrug).

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
}