417 replies to this topic

[HackNFly]

I've only used AutoHotKey once in the past, so I'm not sure what its capable of. However I would prefer to create a solution that didn't rely on it. Between installing LibUSB, the SB drivers and running my program, I'd hate to throw something else in the mix. Also, the new release won't require calibration anymore. I've come up with a way around that, just calibrate once and be done with it, or just accept my default calibration levels and no need to calibrate at all.

Also, i have the mouse fully working. I'm just doing some additional testing before throwing out another release. I played around with a few of the methods you guys were mentioning. Here's my opinion.

(Edit: I'm making these measurements with arm lock off, to simulate maximum possible range necessary)
Calibrate left to right swing. While initially a good idea, there's just too much range to make it practical. Even with incorporating exponential control, you get jitter in the center of the screen. On one of the trial mechs, it took something like 2000 px movement to go from full left to full right swing. Even with the new improved resolution of 1024 levels, you're still relying on very precise movements to go a few pixels. There may be a smarter way to go about it, and I'm open to suggestions, but thats my current take on that one.

My current approach. I think I have the default set to 1200 px movement. Which leaves < 5 pixel of jitter in the center, but this is associated with the pots in my device. If I move the joystick a little bit up, the jitter stops. This provides pretty precise control in the immediate area of the screen. Then, when you move the stick to the bottom/top 5% of its range, it continues outputting +/- 50 pixels per polling interval. This extreme range is also linear, so if you're at 96% of your range, you output 10 pixels per polling interval, and 50 pixels at 100% range. This seems to work really well for a game like MWO, which lets you reset your center.

I'm trying to figure out a way to incorporate the free look, as that seems to be the way better players make kills. Or at least my perception of it, since it lets you move so much faster, and target with your arms. I'm thinking maybe somehow incorporating the left thumbstick. Maybe when its off center trigger the ctrl key to be pressed and switch mouse control over to thumbstick.

I'll try to put out a release tonight or tomorrow night. I'm just trying to incorporate the changes necessary so that you no longer have to calibrate.

Edited by HackNFly, 23 September 2013 - 07:43 AM.

[Golden Gun]

I agree, if we can keep all the changes to the programs we already need, it would keep down the confusion and installation headaches.

I know making a GUI for the Stellbattalion-64 loader is kinda crazy at this point. But I was wondering if we could make blocks of code so someone would have an easier way of cut and pasting each part of what they want to do.

I know that most of the coding can be in any order, I thought we could make a step by step/make your own profile guide with a fill-in-the-blank settings for each part.

I'll put together a proof-of-concept to the best of my ability and post it in a bit.

[HackNFly]

A full GUI was always the plan, I just lost interest in the project due to a number of reasons.

1. Resolution, I found the original 255 levels of resolution unusable
2. Lack of return to center on right stick.
3. Lack of HOTAS controls.
4. Lack of interest in MWO

Helping me discover that resolution bug temporarily reinvigorated me to continue devlopment, and making the right stick work as a mouse makes the whole SB controller make a lot more sense. The lack of buttons is still quite an annoyance, but the lights on the joystick are cool.

I'm estimating it would take 20 - 30 hrs to create a decent releasable GUI. I just don't think I have the time right now. We'll see.

As far as your suggestion, I did my best describing how the configuration files work
https://code.google....i/Configuration

The majority of the code is either.
Assign buttons/lights to keyboard keys
Assign SB controller axes to vJoy axes
(emulate mouse) -- new

The rest of it is specific to the profile, i.e. von Pilsner's toggle switch craziness.

[HackNFly]

For those of you following along and would like to beta test the next release for me:
https://code.google....te.zip&can=2&q=

Release Candidate for new 2.1 release

Assuming you've installed the program before:
Steps:
1st please type "Set Up Usb Game Controllers" in windows start bar to bring up usb game controllers.
Click on "vJoy device"
Click Properties.
Go to Settings tab, click "Reset to Default" button. This will allow you to use new calibration free system.

Unzip program and run "runSteelBatallion64" like normal.
Open up program and open file "MWO-mouse.cs"
Right stick controls mouse when "Buffer Material" switch is flipped up.
Not all controls have been mapped for this test, so lots of possibilities still open.


Lots of great new things:
-Fixed bug -> upgraded resolution from 256 to 1024 levels on all important axis, pedals, sticks, and thumbstick
-added important debugging capbality for scripting.
-NO MORE CALIBRATION necessary. Keeping track of calibration within file for now. Will separate into separate calibration file later on.

[Golden Gun]

Down loading now.

Will post the testing from several different mechs ASAP!

Oh, and yes! That read through/guide was the foundation of several of my own tweaks and fixes, but things that we have discoursed, even only briefly are not listed there. That was the basis for my thought on the "build your own adventure" style of stick programming...

[Golden Gun]

I did a test run through with eight different mechs in the Testing Grounds using Caustic Valley. First thing that I noticed was that if you go to any extreme, the joy stick does not center properly. I have to use the mouse to recenter the cross hairs.

Once the joy stick is off center, it is very hard to use it as I'm guessing there is still an exponential being used on the outer most ranges of the stick and that cross hair goes FLYING!

This does not happen if I stop short of going past the torso twist limit or height. I've taken specs for each mech because there were different ranges for each mech. I hope this information helps.

As a bit of a guide, the information is presented in two ways:

#x means after going to the far extreme in that direction, I centered the joystick and the arm reticule (circle) was # times the distance away from the center of the torso reticule (cross hairs). The distance of measurement is from the center of the cross hairs to the outer most tip of the cross hairs. This measurement is used when there is no specific reference available.

Example: 4x high means that the circle was four segments above the center of the cross hairs after the joystick was put back to center.

# deg. means that the circle is a certain amount of degrees out from the cross hairs after centering the joystick. this measurement is used when the game gives a specific left or right amount.

Example: 60 deg. left means that the circle was, well, sixty degrees to the left of the cross hairs after centering the joystick.

??? means that I was unable to get a measurement. the only time this happened the circle was actually so low after re-centering the joystick it was behind the map screen...

ARMS means that this mech has arms that swing out further than the torso twists

1 means Twist Speed unlocked on this mech and twists 20% faster than normal

2 means Twist X unlocked on this mech and has an additional 10% more twist radious

3 means Arm Reflex unlocked on this mech and they move 15% faster than normal


MECH__________Additional Specs______Left / Right difference______Up / Down difference

JR7-D(F)________2, 3_________________80 deg / 80 deg__________5.5x high / 5x low

CPLT-C1(F)_____1, 2, 3________________80 deg / 80 deg__________8x high / 9.5 low

HBK-4G(F)______1, 2, 3, ARMS__________2x / 2x____________ _____9x high / 8x low

AS7-D(F)________2, ARMS_____________2x / 1.5x________________5x high / 5.5x low

CPLT-K2________3___________________75 deg / 70 deg__________14x high / ??? low

CPLT-A1________NONE_______________80 deg / 80 deg___________9x high / 9x low

Firebrand_______1___________________60 deg / 65 deg___________9x high / 8x low

JR7-D(s)________2, 3_________________80 deg / 80 deg___________7.5x high / 6x low


I also checked it with different user.cfg files active. The latest one put out, an older one I built, and nothing at all. I came up with the same numbers for all three so that isn't a factor.

[Foust]

This is the "edge behavior" that Loc Nar was referring to earlier, and will happen with any joystick that is configured with mouse emulation. Your research here confirms what Loc Nar and I have been working through.

The data that you gathered also shows another challenge in building a absolute position stick. Not all mechs share the same torso speed or travel distance, nor arm travel and speed. If you dial in your stick to perfectly match a dragon for example, it will be way off on a stalker.

From my experiments I believe that the issue is in how MWO interacts with the mouse as opposed to how your operating system interacts with it. If I run the TARGET script for my T16000 in 1:1 mouse emulation, it behaves how you would expect it to behave. Center the stick, center of the screen. Full right deflection, far right side of the screen. Center the stick again, back to the center of the screen. In MWO, I have to switch to a drastically scaled down axis assignment, as well as turn the mouse sensitivity down in game to manage the range of motion such that I dont over shoot the maximum torso/arm travel at full stick deflection.

I said it in one of the other threads, It is a hard like for a absolute device in a relative world.

[HackNFly]

Actually, what you're observing is the intended behavior. I described it 4 posts up. If you were using something like the T-16000, I could actually make it work. But the SB controller even at 1024 levels of resolution gets jittery if you make it go from arm-lock to arm-lock.

As far as how the mouse works, it works similar to how most games work. They capture the mouse and then measure differences in mouse position. Its not actually absolute positions. I played around with the current scheme and prefered it over one that goes from lock to lock. If you want it the other way, simply comment out this section :

private int getDeltaS(int axisVal, int desiredVal, int currentVal,int pixelExtra)
{
int delta = desiredVal - currentVal;
//int temp  = (int) (expo(axisVal)*pixels);
//debugString += "axisVal" + axisVal.ToString() + " " + expo(axisVal).ToString() + " temp " + temp.ToString() + " "
//+ "desiredVal:" + desiredVal.ToString() + " currentVal : " + currentVal.ToString() + "\n";
[size=4]double tempD = (double)axisVal/(double)maxAxisValue;[/size]
 
/*
 
if(tempD > (1 - sideZone))//sidezone is a percentage, i.e. 0.05 for 5 percent
{
tempD = (tempD - (1- sideZone));
tempD = tempD/sideZone * pixelExtra;//defined at top
return (int)tempD;
}
if(tempD < sideZone)
{
tempD = (sideZone - tempD)/sideZone * pixelExtra;
return (int)(-1*tempD);
}
*/
return delta;
}

And you modify the total movement here:

int numPixelX = 600;//number of pixels to move in X direction
int numPixelY = 300;//number of pixels to move in X direction

[Golden Gun]

Can the current joystick-to-mouse setup you have be edited? Basically make a profile for each Mech?

If we don't have to calibrate for each profile, it would be a simple matter of swapping out profiles in between matches. The only headache would be figuring out each set of ranges for each mech...

The second way of doing seems simpler and easier to edit, but if the functionality diminishes, it may not be worth it.

[HackNFly]

Yes, I just posted above how to edit it. Just edit the .cs file. Or maybe I don't understand your question.

You still have the problem of resolution. Try the changes above to see. To change the amount of rotation, change the

int numPixelX = 600;//number of pixels to move in X direction
int numPixelY = 300;//number of pixels to move in X direction

Edited by HackNFly, 24 September 2013 - 06:43 PM.

[Golden Gun]

Okay, I misread. I thought you were saying that to use these two lines I first had to REM out the above section but that there were some inherent issues using it this way.

Foot all swelled up from today's testing But I'll get on this tomorrow and post any findings. BTW, outside the issue I mentioned before, the controls were really nice! thanks again for all the effort you are putting into this, it is definitely appreciated!

[Foust]

HackNFly, on 24 September 2013 - 05:05 PM, said:

As far as how the mouse works, it works similar to how most games work. They capture the mouse and then measure differences in mouse position. Its not actually absolute positions.

Agreed, most games act exactly like this one, relative input. I am quite interested in your modifications here, but my code-fu is weak and I dont own a SB controller.

Sorry if I derailed this thread at all, just wanted to contribute my findings.

Carry on.

[HackNFly]

A T-16000M could work just like a mouse, I have one downstairs, it has HUGE resolution. Resolution is the issue here.

You want to have a wide range of movement, but you want to be able to move up and down a few pixels at a time. Exponential works well for motions in the center, but lets say you want to twist your mech to the side to shoot at something. You would then be moving the stick away from the center towards the area where resolution is poor (because of expo).

If instead you use the extremes of the joystick range to "recenter" the joystick with respect to the cockpit, then you have good resolution from arm lock to arm lock. To recenter the stick / torso you just move the stick all the way to the other side until you're facing center and then bring the stick back to center.

But then again, I don't have that much experience with the game. So I'll help modify the code as needed. I do suggest giving my scheme a try. Try both ways, see what you like better.

Golden Gun, on 24 September 2013 - 07:05 PM, said:

Okay, I misread. I thought you were saying that to use these two lines I first had to REM out the above section but that there were some inherent issues using it this way.

Foot all swelled up from today's testing But I'll get on this tomorrow and post any findings. BTW, outside the issue I mentioned before, the controls were really nice! thanks again for all the effort you are putting into this, it is definitely appreciated!

Also, just for clarification, in most C-languages
//
and
/*
*/
are used for commenting. REM is something I remember from MS batch scripting.

[Golden Gun]

Yeah, I use "REM" since the total sum of my programming is Apple-IIe BASIC and making batch files for DOS.

I have some numbers for everyone too. the Y axis is almost static for each Mech I tested. It is the torso twist and arm movement that has such a difference. Sorry it took so long getting back to you.

- For all Mechs, "int numPixelY" should be set to 800 from 300.

- For Mechs with a torso twist of 100 degrees / No arms (Firebrand, etc. WITHOUT Twist X activated) "int numPixelx" should be set to 1550 from 600.

- For Mechs with a torso twist of 110 degrees / No arms ( Jenner, Catapult etc. WITHOUT Twist X activated) "int numPixelx" should be set to 1700 from 600.

- For Mechs with a torso twist of 110 degrees / No arms ( Jenner, Catapult etc. WITH Twist X activated) "int numPixelx" should be set to 1850 from 600.

- For Mechs with a torso twist of 125 degrees / ARMS!!! ( Hunchback, etc. WITH Twist X activated) "int numPixelx" should be set to 2650 from 600.


I still need to do more testing, but this should give you some numbers to calculate things out. I noticed that there is an additional 10 degrees twist when Twist X is activated giving a total of 120 degrees twist. Take that and plug it into the the above info and you get a difference of 150 for every 10 degrees of twist.

There are still some bugs that need to be worked out.

- You need to make sure the joystick is centered when you activate it. "Activate" meaning flipping up the Buffer Switch. Since there is no spring, you need to do this manually.

- If you jamb your joystick all around super fast, it will get a bit off center.

- The change in fields of vision when using zoom does not translate well and will throw off center.

- Moving the joystick while shut down will throw off center.

- Still very sensitive in certain ranges where almost dead (center) in others


I hope this information help everyone who is trying to get these up and running.


PS- CONGRATZ LOC NAR on making it to the finals at the MWO Launch event! I didn't even know you were going. I was accepted and everything but my knee surgery totally knackered it up.

[Loc Nar]

Quote

If you jamb your joystick all around super fast, it will get a bit off center.

Hmm, I find this only happens to mine if the mouse accel or smoothing values are not actually zero, which btw playing with armlock on does exactly this -adds 'x' amount of accel and smoothing to simulate the additional mass being slung around. On one hand neato, on the other hand it kills control schemes that are based on absolute mouse emulation. For this type of control scheme to actually work, it's critical those values are zero and remain such.

I keep the 'c' center button nearby but on a shift layer to keep from spamming it. I rarely use it anymore since it's pretty second nature to use opposing torso and leg inputs to get it in line as well (which is also also how it most often gets out of whack), but it's a handy option to have.

Quote

PS- CONGRATZ LOC NAR on making it to the finals at the MWO Launch event

Heh... not sure why they didn't update the list yet, but I opted out of the competition although I attended the event (you local?). I was told I could not use any of my own peripherals and I'm not a kbm player. Like at all. I was going to use a lefty joystick for a throttle/mouse scheme, seeing as a $12,000/$6000 prize fight is not the time to L2P! ...ironically there was a throttle/mouse player on the winning team so go figure

[HackNFly]

Golden Gun, on 30 September 2013 - 02:24 PM, said:

- You need to make sure the joystick is centered when you activate it. "Activate" meaning flipping up the Buffer Switch. Since there is no spring, you need to do this manually.

- If you jamb your joystick all around super fast, it will get a bit off center.

- The change in fields of vision when using zoom does not translate well and will throw off center.

- Moving the joystick while shut down will throw off center.

- Still very sensitive in certain ranges where almost dead (center) in others

I'm not surprised that the joystick feels so dead in the center. Expo is great for being able to move a few pixels at a time, but the way you're setting up the mouse emulation to go from arm lock to arm lock, you may way to try without it.

change the following lines:

desiredX = (int)(expo(aimingX)*numPixelX);//numPixels stores resolution, i.e. how much we move mouse
desiredY = (int)(expo(aimingY)*numPixelY);
rAxis = (int)(expo(rAxis)*maxAxisValue);

to:

desiredX = (int)(aimingX*numPixelX);//numPixels stores resolution, i.e. how much we move mouse
desiredY = (int)(aimingY*numPixelY);
rAxis = (int)(rAxis*maxAxisValue);

that will give you linear range throughout, but you will feel the lack of resolution, especially with numPixelX set to 2560.

Its about 90 degress of throw, so you're moving roughly 30 pixels per degree of the joystick (2560/90). It's going to make it nearly impossible to aim. Please give my hybrid approach a try. It doesn't take that long to get use to, and it lets you actually aim, while being able to move lock to lock and maximizes the resolution of the stick. Plus with a game like MWO which has a recenter button, you're good to go.

As far as moving the joystick around really fast, its possible that the refresh rate on the joystick isn't fast enough to keep up with your motions. At least thats my guess.

[Sephlock]

i wish i hadn't lost mine in the move .

[Critty Cat]

This is everything I have been looking for. Thank you so much for all the hard work getting this beast of a controller to work with this game. I dusted off the old SB controller and played MW:O all day with it... Brought back a lot of SB memories.

Quick question: Is it possible to map the left joystick's mini-joystick to freelook the cockpit? Also, I'm not too sure how to use firing group 3+ using the new mouse map controls. Thanks for the help!

Edited by Critty Cat, 17 October 2013 - 01:50 PM.

[Golden Gun]

Hey Critty Cat. I've gotten around using the other firing groups by binding them to the toggle switches. WG6 I have as a constant on/off for TAG (I use it a lot) and several other switches to bind my "Main Weapon" and "Sub Weapon" to different WGs.

If you look at the bottom of the BvP-MWO.cs (config) file you'll see several lines under "Toggle Tricks!!!" that give a good example on how to do this.

As for the mapping of the look function, I don't think you can since it is currently mapped as a button press&mouse execution. This means it will only work with the main input device. I hope they DO make it a separate input for just this reason though!

[CMDR Refflex]

Hi just a little off subject are u golden gun from line of contact? If so do ppl still play loc on network Kai? Would love to get set up if ppl still play there