Elimination of Mouse-Auto-Center while driving

[madrussian 347]

Attention – Please Read

Just so interested people are not scared off by the long post here, please be advised:  I think I've figured out a way to defeat the dreaded mouse-auto-center.  Now if I've got your attention... READ ON!

(Or if this topic does not interest you, I understand completely... Everyone is different... To each his own! )

Introduction

Many of us have been quite annoyed by the mouse-auto-center "feature" experienced when driving by keyboard/mouse since the release of ArmA.

For any of you out there who exclusively use the joystick to drive in ArmA or are otherwise unfamiliar with the mouse-auto-center issue, here's a quick step by step:

1. You start driving in ArmA using the mouse/keyboard.

2. You steer either left or right.

> Now everything seems fine at this point as you are moving the mouse but suddenly... <

3. As soon as stop moving the mouse, your wheels return to center automatically, even though you wish to continue steering in that direction!

As many many ArmA players feel, this makes driving far less precise and it's just darn-right annoying.  The worst part is it is hardcoded and there is no toggle or config entry to deal with it.

Now, there was a bug-tracker issue submitted requesting a simple toggle for mouse-auto-center, and it quickly became one of the most voted for ArmA issues in the bugtracking system (top ten IIRC).  Alas, it was never resolved and has kept driving in ArmA difficult for so many of us since ArmA was release.  (btw- It was never a problem with OFP 1.96)

Fast Forward to Present Day

I think I finally figured out how to overcome the dreaded mouse-auto-center!!!

Now, I probably shouldn't be getting people's hopes up just yet, because I have yet to test out my idea, but I'm stuck here at work thinking about it, and needed to let the world know.

A little history on my idea before I go and spill the beans.  A few months ago, Kegetys came out with his revolutionary ArmALib program which allows amazing things in ArmA, including communication with external database, the communication with the Windows clipboard, and many other revolutionary things.  Most importantly with regard to the topic at hand, ArmALib provides keyboard and mouse commands.

So my idea at the time was to use ArmALib to produce a series of rapid, miniscule manipulations of the mouse input while driving with the keyboard/mouse, thereby interrupting and preventing the hard-coded mouse-auto-center from ever occurring in the first place!  When the idea hit me I was about fall over and pass out from the excitement!

Unfortunately, after delving into ArmALib, the best I could discern was that ArmALib was only capable of trapping the mouse status, not manipulating it.  Holy crap, talk about talking the wind out of my sails.

All that was a few months ago.

Finally, a Solution?

So now picture this.  Here I am sitting here in my cube today, turning the problem over and over in my head.  And then it dawned on me.

So what if ArmALib couldn’t manipulate the mouse?  Why not use an external program to simply provide this minor manipulation for us?!?  A quick google search on "automatic mouse control program" turned up dozens of programs that appear up to the task.   (Many of them are macro related).  Better yet, many of us (including your truly) know how to crank out a quick purpose built Java program in no time.  I'm guessing mouse-tweaking this is about as simple as it gets.

Now I know some of you are thinking, "Great, but I don't want my mouse being constantly moving around like that."  Now I've got the same concern, but there are a few things to consider here.  First off, how much manipulation is required to prevent the mouse-auto-center in the first place?  Based on a bit of in-game experimentation, it sure doesn't seem like much at all.  So with the miniscule amount we are talking about here, perhaps it would be altogether unnoticeable (except of course for the desired elimination of the mouse-auto-center, that is. )

So some experimentation with one or more of the actual external program(s) is required to really know how well this will all work.  If the initial experiments go well, it would be time to go beyond the original idea and put a robust system together that is capable of determining when the player is driving and when he is not.

The Robust System

What follows is a quick rundown of what I envision for the robust version of the Mouse-Auto-Center Removal System (MACRS).  There are two components, one internal, and one external (internal and external to ArmA, that is)

1. Driver Detection Component (internal to ArmA)

Internal script or config based system that detects when a vehicle is boarded by the player driver.  Upon detection this component utilizes ArmALib based capability to send a signal to the external component to begin mouse-auto-center interruption.  This component also detects when the player exits the driver position, and at this time send a signal to the external component to switch off the interruption.

2. Auto-Center Interruption Component (external to ArmA)

External purpose-built mouse-auto-center interruption program with two states:  "Off" and "Interrupt".  This program receives the binary command via ArmALib and blocks the mouse-auto-center when necessary.  It is out knight in shining armor, it is our shield!  When it is not blocking, it’s waiting silently for the command.  Think of it like the nuclear “footballâ€.  (ok, bad example probably  Maybe a better one is a emitter that block IEDs from going off.)

Indeed, these two components exhibit a classic Master/Slave relationship.

(Note - Perhaps the vehicles which require mouse-auto-center interruption could be selectable by the user.  Example-  I mostly drive land based vehicles with the mouse/keys, but always fly helos and airplanes with a joystick.  Other people undoubtedly do things differently.)

An Action Plan

Now unfortunately, I don't have a lot of free time to spend on coding for ArmA right now.  (RL's a bitch sometimes, no?)  But I will do my best to pursue the idea, reporting back here periodically.  The main thing I want to get across however is, I just want mouse-auto-center dead.  I fully encourage any of you who feel the same way to go ahead, run some experiments with mouse-manipulation programs, etc, etc, etc.  I will collaborate with anyone who is willing and provide whatever time I can.  I do not desire any credit what-so-ever for the idea here.

Like I said I just want to eliminate mouse-auto-center while driving in ArmA and I know a lot of other people feel the same way.

In summary, I'm quite interested to hear any and all feedback from you guys on this idea… I'm all ears!

Special note for BIS

BIS if you made it to the end and are still with me, please look on this post and topic as a testement to the lengths people will go to get rid of the unwanted and disruptive mouse-auto-center.  We really do hate it that bad!

Alternately you can look at it in terms of how much we love your game!  I.e Putting forth this kind of effort to make it perfect.

Please give us a toggle in ArmA2.  Pretty please?

[Kirby 2]

It was a left over feature from the Xbox OFP:Elite, for controlers (IE You hold the stick left to go left, resulting in a constant LEFT input untill you release it).

Unfortunatly the auto-center system is useless and annoying on PC.

Hope your idea works!

[Average Joe 0]

Hear Hear!

[layne_suhr 0]

Thank You!!!

[madrussian 347]

Thanks for the replies.

Quick update... The good news is I was able to write a quick VB program to oscillate the mouse by a set amount in the X and Y direction by a selected amount on a set interval for a specified time period.  Upon alt-tabbing to ArmA the mouse continued to oscillate in the ArmA menus!!!  That part worked like a charm!

Now the bad news. Once I fired up the editor, created a unit (infantry for starters) and got in game, there was no detectable effect on the aim.  I could hit Escape and see the mouse humming away on the menus any time, but it just doesn't seem to affect the in-game, even after adjusting the magnitude of the oscillation effect.  I even tried just having the mouse automatically drag to the right instead of back and forth and again, no effect in game.

Now I did notice some interesting behavior when alt-tabbing out to Windows (from being in-game in ArmA).  Apparently, the mouse always starts out exactly in the upper-left-hand corner of the screen upon alt-tabbing out.  Then the VB program kicks back in and goes crazy with the mouse again.  Not quite sure what all this means, but I suspect that ArmA is somehow controlling the mouse at a lower level than my VB program is (when in-game but for whatever reason we still have control when on the ArmA menus).

So at this point I'm thinking maybe we need to gain control of the mouse at a lower level (perhaps the driver level?)... or maybe something else entirely.  Anyone have any ideas here?  I am not ready to give up on this just yet.

edit:

(One more quick thought...  Anyone ever plugged in two mice into the same computer at one time?  IIRC, last time I tried this, they both worked.  So maybe that's what's really on order here...  An program that actually emulates a second mouse and provides the necessary oscillation.  This idea may be a bit trickier, but I'm sure it's doable.  Still looking for easier ideas though. )

[madine75 0]

Thanks for the replies.

Quick update... The good news is I was able to write a quick VB program to oscillate the mouse by a set amount in the X and Y direction by a selected amount on a set interval for a specified time period.  Upon alt-tabbing to ArmA the mouse continued to oscillate in the ArmA menus!!!  That part worked like a charm!

Now the bad news. Once I fired up the editor, created a unit (infantry for starters) and got in game, there was no detectable effect on the aim.  I could hit Escape and see the mouse humming away on the menus any time, but it just doesn't seem to affect the in-game, even after adjusting the magnitude of the oscillation effect.  I even tried just having the mouse automatically drag to the right instead of back and forth and again, no effect in game.

Now I did notice some interesting behavior when alt-tabbing out to Windows (from being in-game in ArmA).  Apparently, the mouse always starts out exactly in the upper-left-hand corner of the screen upon alt-tabbing out.  Then the VB program kicks back in and goes crazy with the mouse again.  Not quite sure what all this means, but I suspect that ArmA is somehow controlling the mouse at a lower level than my VB program is (when in-game but for whatever reason we still have control when on the ArmA menus).

So at this point I'm thinking maybe we need to gain control of the mouse at a lower level (perhaps the driver level?)... or maybe something else entirely.  Anyone have any ideas here?  I am not ready to give up on this just yet.

I'd hazard a guess and say that your VB app is grabbing the general Windows mouse - whilst Arma is grabbing the mouse via DirectInput, at least while the menus are not open.

[alef 0]

Download and try GlovePIE and PPJoy.

Create a virtual joystick with PPJoy1 with more buttons as your real one, so that ArmA will choose that one.

Then look at GlovePIE documentation to create a VB like program to route mouse/joystick/keyboard to the ppjoy1 or mouse at different levels. As an example, this is my actual script (still WIP):

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

// POV digital3+ = down, up

ppjoy1.digital3=joystick1.button2

ppjoy1.digital4=joystick1.button3

ppjoy1.digital5=joystick1.button4

ppjoy1.digital6=joystick1.button5

// Joy buttons

ppjoy1.digital1=joystick1.button1

ppjoy1.digital7=joystick1.button6

ppjoy1.digital8=joystick1.button7

ppjoy1.digital13=joystick1.button1

// Tab,ShiftTab for targets

if joystick1.button8 then {

Key.Shift=true

Key.Tab=true

Key.Tab=false

Key.Shift=false

wait 100ms

} else if joystick1.button9 then {

Key.Tab=true

Key.Tab=false

wait 100ms

}

// Keep zoomed out/in

var.b10 = Joystick1.button10

var.b11 = Joystick1.button11

//zoom=+,-,n

if var.b10 then {

if var.zoom != "-" then var.zoom = "-" else var.zoom ="n"

wait 100ms

}

if var.b11 then {

if var.zoom != "+" then var.zoom = "+" else var.zoom ="n"

wait 100ms

}

if var.zoom == "-" then {

Key.NumpadMinus=true

} else if var.zoom == "+" then {

Key.NumpadPlus=true

} else if var.zoom == "n" then {

Key.NumpadMinus=false

Key.NumpadPlus=false

var.zoom = ""

}

// axes

ppjoy1.analog0=joystick1.x

//+mouse.x

//debug=ppjoy1.analog0

ppjoy1.analog2=joystick1.z

// y dead 0.03 -0.18

var.y=joystick1.y

if var.y < -0.18 then {

var.ey=EnsureMapRange(var.y,-1,-0.18,-1,-0.01)

ppjoy1.Analog1=var.ey

//ppjoy1.analog1=var.y

} else if var.y > 0.03 then {

var.ey=EnsureMapRange(var.y,0.03,1,0.01,1)

ppjoy1.Analog1=var.ey

} else {

ppjoy1.analog1=0

}

//ppjoy1.Analog1=var.y

//debug=var.y

//debug=var.y+" "+ppjoy1.analog1

// rudder

ppjoy1.analog3=joystick2.x

ppjoy1.analog4=joystick2.y

ppjoy1.analog5=EnsureMapRange(joystick2.roll, -1, 1, -3, 3)

// FreeTrack

faketrackir.pitch=realtrackir.pitch

if key.shift then {

// var.irx=EnsureMapRange(realtrackir.yaw, -90, 90, -0.5, 0.5)

faketrackir.x=var.irx

} else {

faketrackir.yaw=realtrackir.yaw

faketrackir.x=0

}

if key.Ctrl then {

var.irz=EnsureMapRange(realtrackir.pitch, -5, 5, -1, 1)

faketrackir.z=var.irz

} else {

faketrackir.z=0

}

As you see, GlovePIE let you control the TrackIR protocol too.

Sometimes gives me an error that 0.18 is not a float (??) at auto-startup. Don't know if this has to do with internationalization (mine should be 0,18) but a program restart usually help.

Try to find a solution with GlovePIE should be easier.

[sparks50 0]

Good luck with it. I do not know of one single person who likes this autocenter thing, BI would do good by removing it or making it selectable.

[nuxil 2]

The mouse autocenter sucks BIG time.

hope someone finds way to remove it.. or bis make a patch to make it selecteble

[madrussian 347]

Here's a preview... a longer update tomorrow:

// Eliminate ArmA Mouse Auto-Center While Driving by MadRussian

// Version 0.9

// RIP - Eliminated on October 19, 2008

// Long live OFP style mouse driving!!!

//

// Many thanks to alef for pointing me in the right direction.

// Ironic that he laid out the roadmap over 2 months before I saw the light!

Ladies and gentlemen...   It's dead!  

I just drove around Rahmadi for over ten minutes and without any bitching from my mouse.  Yep, ten minutes on an empty island with nothing but me and my Humvee.  And let me tell you, it was everything I thought it could be.

Couple of minor kinks to work out and we're there... So tired after all this problem solving.  My brain feels like goo.  Barring any unforseen consequences, I'll fill you guys in on all the gory details tomorrow.  But for now, time to hit the hay, as they say.  

[.kju 3245]

looking forward to it!

[4 IN 1 0]

let me tell you m8

if you make it come true, we are going sent a truck load of beer to your home

edit: how about removing the OFP driving wheel auto center as well?

[kremator 1065]

Excellent news. Can't wait to see it!

[TAO] Kremator

[ck-claw 1]

Excellent news.  Can't wait to see it!

[TAO] Kremator

Indeed!

Gonna make a lot of ppl happy!

[madrussian 347]

Alright, back up and at it.  Thanks for the support, beer, etc!

Very close now... everything is working, just need to figure out how to toggle it from a keystroke.  (There needs to be a way to turn it on and off as you will see.)

edit: how about removing the OFP driving wheel auto center as well?

I think I know what you mean.  In OFP, iirc you would move the dot around the screen and the vehicle would go toward the dot.  I wouldn't necessarily call that an auto-center, but I agree it wasn't the most optimal system.  For all it's flaws though, it got the job done and was head over heals over the way vanilla ArmA has it.

The way I've got it working now, the steering wheel just basically maps to the X-axis of the mouse, with no auto-center (or dot-following for that matter).  So imo it's actually even better than OFP was!

@All, this is my first addon (if you want to call it that... more like a fix really)... What's the best (and easiest) place to upload something?

[MehMan 0]

Hmm, what if you use the vehicle command in a script?

[ck-claw 1]

What's the best (and easiest) place to upload something?

Inform Armaholic/arma.info and im sure they'll host it for you!  

Click Here for Armaholic link to host an addon!

[madrussian 347]

Thanks for the info cr-claw! Is that normally the way it works though? Seems like most of the time people go upload the file somewhere and then Armaholic, etc, swing by, go grab your file and host it for you? (And drop you a comment in your thread to let you know?) Maybe I am naive on this.

Hmm, what if you use the vehicle command in a script?

I agree most people who will use this addon would probably always want the auto-center eliminated while in certain vehicles (such as all ground vehicles).

However, while the script is running, the joystick gets overridden by the mouse.  Indeed, we probably don't want to override the joystick all the time for any number of reasons.  For instance, some may prefer to drive even ground vehicles with the mouse sometimes and then with the joystick at other times.  So for right now toggle by keystroke will have to do.

Another consideration is that right now the addon exists completely outside ArmA.  While it wouldn't be terribly difficult to monitor which type of vehicle the player is in inside ArmA and automatically toggle the mouse-auto-center state accordingly and transmit the toggle state to my outside script, that's probably a bit beyond the scope of this initial version anyway.

I do envision such a robust system fully configurable by the user.  But first things first.

Quick update:

Got the key trapping sorted.  A bit more to do on the transitions between on and off (so your wheels don't go crazy when you toggle).  I'm also in the middle of writing the readme.  Hopefully not too terribly long to go now to get this puppy unleashed.

[kuIoodporny 45]

if I'm not misunderstood... I hope that BattleEye won't complain about it

[madrussian 347]

if I'm not misunderstood... I hope that BattleEye won't complain about it

I have no idea about that... but I certainly hope not.

Got the readme done.  Looking into the transitions between on and off now (mentioned previously).

Not long now...

[madrussian 347]

Thanks for all the support guys!

Version 1.0 released here.

[W0lle 1052]

Closing since this has been released now.