14 replies to this topic

[evilC]

Note: This post is only relevant if you wish to aim with a joystick in MWO. If you aim with a mouse, this post is useless to you.

This is still very much proof-of-concept, so don't expect a finished solution.

You will need AutoHotkey installed to use these scripts.

Technique
Read joystick input and convert it to mouse output. The game thinks you are playing with a mouse.

Challenges
In order to implement a third party absolute aim system that emulates a mouse, these are the challenges you need to overcome:

• Twist Range limits
  If you are outputting as mouse, the script will need to know how many units of mouse movement that any given mech is capable of twisting. If the torso is at max twist, and the script tries to twist it more, then MWO will ignore this impossible movement, and your script will drift out of synch (ie the middle position on your stick will no longer centre your torso)
  Also, different mechs can twist different amounts, so the script needs to be configurable.
  
• Twist Speed limits
  Mech torsos can only twist so fast. MWO will ignore any mouse input that would result in a mech twisting faster than it is capable of.
  If you issue a mouse movement of a million units left in one "tick" of the engine, but your mech is only capable of twisting as much as 1000 mouse units in that time, MWO will twist 100 units and ignore the remaining 999,000 , so your mech does not even go to 100% twist left.
  So if you are twisted full left (your stick is full left) and you release the stick, the stick will probably center itself quicker than the mech is capable of moving back to centered torso.
  For this reason, you cannot just directly map joystick movement to mouse movement - you must work out how many mouse units of movement per second each mech can handle and limit all mouse moves to that rate.
  Getting this wrong will also result in the script going out of synch.
  
• All calculations of how much the mouse needs to move needs to result in an integer.
  You cannot move 1.5 mouse units.
  In AHK (The language this script is written in), joystick input values are floating point (0-100).
  You must be careful not to try to move by a floating point value, else your script will again go out of synch.

Status
Calibration currently only works for the X axis, calibration for the Y axis would be harder.

You still need to use an image editor (eg MS Paint) to find out the Y coordinate for the "twist indicator":


There is currently no calibration routine to find the "Max Twist Rate" (in mouse units). You are on your own with this value for the moment. Trial and error will tell you the correct value - if the center point drifts out of synch, lower your MAX_TWIST_RATE value

Download:
http://evilc.com/fil...AbsoluteJoy.zip

Edited by evilC, 07 April 2016 - 10:21 AM.

[mclang]

Hello.

I finally had time to test this and it seems that I can't get it to work. I have checked that TWIST_INDICATOR_Y is right (1920x1200 monitor, thus 322 or 323) but the result I get is either 20 when I use MOUSE_STEP_SIZE of 10 and 2 if I use step size of 1. So it seems that for some reason the condition at calibrate.ahk:122 is true right away.

Could it be a problem with taking screenshot, because for me 'ShowTwistSnapshotKey' seems to display an empty window?

[evilC]

So you got the script in the other thread to work, but this calibrate one doesn't?

Start the calibrate script, then hit the FindTwistLimit hotkey, then wait for it to look left and recenter, then hit the AbortFindTwistLimit hotkey.
Finally, hit the ShowTwistSnap hotkey - you should see an image appear in a window - it should be 1px high and as wide as your game window is. The center pixel of the image should be HUD orange.

If you get no image:
Try running the script as admin (Right click > Run As Admin)
Try turning UAC off.
Try turning the Aero theme off.

The script uses my CGdipSnapshot library to grab the pixels from the screen - maybe this is not working properly on your system. You could try the sample script from that lib, to make sure it works on your system.

[mclang]

I did as you told to but the one pixel high image seems all back to me.

I tried already yesterday by running script as admin but forgot to mention it. Turning UAC off didn't help either, and I'm running Window 10 Pro, so ( I think) turning Aero completely off is not an option.

I will test your CGdipSnapshot library as soon as I have time. I think that I play some before though, so it may take time.

[mclang]

(Un)Fortunately my work project stalled a little.

I had to fix the includes to use local files because I use portable Autohotkey, but after that it seems that your CGdipSnapshot library works, at least on windows:


Next I probably should test if the example works inside game by putting some delay in the example script...

[mclang]

Bad news.

I tried the example script inside MWO and all I get, even when running as Administrator and all visual effects disabled, is a black box. So it seems that something in Windows 10 makes this fail

[evilC]

This does not hugely surprise me.
I have yet to bite the win10 bullet.

Have you tried other games? Fullscreen window mode?

Anyone else on win10 got it working?

[mclang]

Haven't tried with other games or fullscreen window mode.

What I tried though is that example works with the MWO "play" screen, so I think the fullscreen windowed mode could work.

[mclang]

Good News!

Calibration worked like a champ when I set the game in Full Window mode instead of the default Full Screen that I was using. It isn't useful for me right now though because I'm playing with arm lock disabled... Although it might be better for my performance with joystick to learn the ropes using locked arms so that the reduced movement range and speed would make the aiming somewhat easier. Your twist speed limit handles the drift really well, so I don't need the speed of arms for that.

The calibration could be a tad faster tough. Could it be done in a way that first the MOUSE_STEP_SIZE is large and when the limit is exceeded the script goes backwards with smaller steps until the right range is found?

And now, after experimenting it some more, it most often doesn't work

For some reason the calibration movement starts like it is supposed to, but then it stops and displays e.g 80 or 100... I don't know why it worked before but then just stopped

Edited by mclang, 08 April 2016 - 10:56 AM.

[evilC]

I seem to remember seeing some weirdness going on too when I was working on it last week, not sure though.
Hopefully will have some time to look at it this weekend.

Agree about the calibration, but bear in mind this is still very much proof-of-concept. There's not that much point polishing that part of it until we have all the pieces in place, as things may have to change.
I have pretty limited time, and this is all very experimental, so I think a "Make it work, then make it good" approach is best.

[mclang]

I understand, you are busy as I am too.

And because it may well be that I'm to only one interested of using this, it should be me who tries these additional things. So no pressure, I'm just throwing ideas.

I noticed something when I inspected the screenshot this script uses. Mine at least, taken in Mining Collective, had different colors at the ends of the twist indicator because of the diamond arrows. In addition, the indicator is not visible at the beginning of the twist when the diamonds are near each other. Could these be the source of weirdness?

I tested also against black scenery in the corner but I didn't manage to get valid reading anymore.

[evilC]

I did some work on this last night - I have abandoned the old calibration script, because if you have a mech with a large torso twist (eg a Catapult) then at max twist, the twist indicator is off the edge of the HUD. Also the old method would only every be any use for the X axis.

I have implemented a new system that solely uses view change detection - ie take a snapshot of the view out the cockpit, issue a twist command and observe if the view changes.
This can also be used to detect if the mech's torso is centered - if you hit "center view" and the view does not move, then the torso was centered.

I wrote a calibration routine to detect the max twist rate - it issues a big twist in one chunk (eg +50), then issues the same number of units in the other direction, but in chunks of 1 (eg 50x -1 moves). It then checks if the torso is centered, and if so it knows it can safely move that fast, so it increases the number and tries again.

With this new technique, I should hopefully be able to gain all the calibration information that we need.

[mclang]

Sounds good!

If I undestand right, this can be used to find both X and Y ranges... Does this new calibration logic work also when using free arms?

Even if it does not, this is helpfull because with this I can find multiplier with which I then can calculate also then needed range with arms lock disabled.

[evilC]

No, it would not work with arm lock off, as if you are at full twist, then move more (So just the arms move) - just the arm reticule moves across the screen, the view does not move.
However, this could possibly be done as another phase. Once you know the torso twist limit, move the torso to the limit, turn off arm lock, then start moving the mouse. Once the circle reticule stops moving, you have found the range of arm motion. This should be fairly easy to do using pixel detection: The crosshair is in the center of the screen, so keep walking along the central line until you find a pixel that is not HUD colour.

[mclang]

I quickly tried 'calibrate2' with my Firestarter.

Sadly both twist range and speed limit logic fail every time just after couple of movements... Currently I don't have the time to try again, but I will if you have ideas how to debug this.