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).