417 replies to this topic

[HackNFly]

evilC, on 19 September 2013 - 03:37 AM, said:

The value AHK reports is floating point not an integer right?
ie not whole numbers between 0 and 255, but instead a number like 50.123456789

That is NOT "255 positions". It is still probably 32,000 positions, just they are spread over a decimal scale.

Actually he had a point. The joystick has a resolution of 1024 levels. Only 255 levels were being reported. The lower 2 bits were being truncated. This was being scaled i.e. reportedValue / 255 * 32768, now it'll be something along the lines of reportedValue / 1024 * 32768 depending on the axis. Also, AHK isn' necessary, since the program has a built in keyboard emulator.

[Golden Gun]

So the new settings will multiply the resolution by 4 right? That would be really cool! I'm hoping the higher resolution will make it possible to smoothly run the control scheme I've been attempting!

This news is getting better and better! Totally making up for not being able to go to the Event this weekend! If this can get perfected, I have four sets of SB sticks that I'm hoping to setup at the local gaming cafe. Imagine a local lance of Joystick players using gear that'll let them play on the same level as Mouse and keyboard players.

One word. AWESOME!!!!

Edited by Golden Gun, 19 September 2013 - 02:08 PM.

[Thunder Lips Express]

hey it looks like you guys have put a lot of work into this.
but i'm dumb when it comes to computers and i love my sb controller, is there a very easy way/very basic installation of this or am i forever doomed?
like an exe i download and install and then i just plug in the controller and shoot?
i can pay

Edited by Ecliptor, 19 September 2013 - 02:07 PM.

[Golden Gun]

Hey Ecliptor! It does take a lot to get it up and running but you just have to be patient and follow directions. the process is strait forward and takes at most an hour.

Here is a link to the install directions:
https://code.google....ki/Installation

Look it over and see if it is too much for you. I'm not saying that in a demeaning way, It's just the only way you'll know if you're up for the task.

If you have any questions about the install process or anything else, don't hesitate to ask!

Good Luck!

[Loc Nar]

Very interesting indeed. Carry on...

[Golden Gun]

Hey Loc Nar, I'm glad you found this thread! I think we'll be able to do the targeting idea with the higher resolution now. What do you think?

[Loc Nar]

I've been following all along (actually any hardware posts that aren't about RAM, GPU/CPU, etc I find interesting and at least lurk), but have been in a lull of posting cause reasons. Anyhow, I think you guys are on to a great thing.. 10 bit as opposed to 8 would make all the difference of whether it's worth the time to wrestle with the digital aspects rather than straight regutting with a T16000M (which would still be my personal approach due to my familiarity with TARGET).

So long as whatever emulator it is running can allow absolute inputs and you can tune them fine enough to not have negative edge behavior, this will be a fantastic controller for MWO. If there's anything I can do to help besides cheerlead, let me know. In the meantime, GO TEAM!

[HackNFly]

Can you elaborate what you mean by negative edge behavior?

As far as what controller I would go with. I would probably still nod my head torwards the T16000M. I "had" one that I tore apart for a flight sim, but it worked well before hand. At 10-bit resolution, the SB controller should actually be useable, but its the lack easily accessible buttons that irks me. I mean it looks nice and all to have 30+ buttons, but to have only 4 of them accessible without removing your hands from the sticks seems silly.

Either way, I'm looking forwards to implementing that fix this weekend. I'm also looking forwards to trying this out in Hawken. Hawken doesn't have many actual buttons, but is *MUCH* faster paced that MWO. I wrote it off initially due to the lack of precision in the joysticks, but it might actually be fun now, albeit overkill considering how few buttons I actually need.

[evilC]

oh right, yeah I forgot you were using a normal feeder app for vjoy...

Out of interest, does AHK detect the axes or buttons at all?

I think what he means by "Negative Edge Behaviour" is that in order to do his technique, you have to map stick to mouse.

Seeing as you can move the mouse more left than 100% left / right twist, you must make sure the physical stick range and the virtual mouse range match up and do not get out of synch.

[Loc Nar]

Quote

Can you elaborate what you mean by negative edge behavior?

EvilC is correct in that this has to do with mapping the stick's x/y to emulate mouse, which is currently the way to be able to use absolute inputs in MWO. However MWO is coded for actual mouse inputs, which are relative by their nature. When using a stick emulating mouse using absolute inputs, you have to keep your sensitivities within a range that does not allow you to overshoot the mech's range of travel.

When overshooting, the mech stops moving at it's max travel point but the stick continues to move. However the moment you start moving the stick back towards the other direction, the torso begins to move again, and this leads to a desynchonization between stick and torso, req 'c' centering to get it back in line again. If your sensitivity is too high, this happens too often for the mech to be properly controllable. Ideally your sensitivity setting allows 90-95% of the full travel. It changes from mech to mech, so if it's not easy to change sensitivities you have to pick one that is a good compromise.

Quote

Either way, I'm looking forwards to implementing that fix this weekend. I'm also looking forwards to trying this out in Hawken. Hawken doesn't have many actual buttons, but is *MUCH* faster paced that MWO.

Unfortunately Hawken is a terrible game to play with a zero-order joystick. For the same reasons it sucks with my setup it will suck for a functional SB controller. Hawken uses normal fps movement which means the y axis works as normal, but the x axis is slaved to your steering(!) so movement and aim in one and the same on that axis so as such you need a relative input device to manipulate it due to the req for infinite range of movement, in diametric opposition to a joystick running absolute inputs.

This kills it. I really wanted to love Hawken and knew about it years before MWO, and in fact it was doing one of my Hawken update search loops that led me to MWO's waiting arms, so for me the disappoint was very strong cause I dreamed about piloting a Hawken mech in a cockpit before MWO was even a twinkle in Russ's eye. Healthbars, strafing, etc, it's literally a standard fps with mech skins. If the mechs had multiple hitboxes it would be much better, but until the controls aren't just standard fps it's a non-starter for me cause my fancy mech joystick is a paperweight in that game and I have no desire to start mousing around, nor start playing a shooter with a first-order control joystick. Unfortuntely there is no place for a proper zero-order joystick in Hawken.

I patched and played again the other day. No change, although they did just do a huge revision of the whole game. However it's the same movement/controls, and in the end that is what makes the game absolutely unplayable for me, enhanced by the transparent gimmicky fps mechanics.

The only way my controls even sorta work is to use my stick as normal, but additionally map mouse left/right to buttons on my throttle (would use my pedals if Saitek SST didn't suck so bad...). It's possible that software other than TARGET can handle this function better, which would make the experince better, but TARGET handles this function pretty poorly (allows 360deg range but with a 'stop' at 0/360 and does not allow infinite travel), but even the best implementation by necessity involves generating conflicting mouse inputs that at best still make controlling a mech wonky.

[Golden Gun]

I was able to hobble into my man cave and re-downloaded glovePIE and set it up to convert the X/Y axis on the joystick to output as a mouse. it works okay (a bit jittery) on the desktop but there are NO variants while in the game. It's either all one way or the other for both directions.

I tried it with the normal input and the newer version with the exponential scaling. Same out come.

I hope the higher resolution will help, but I have a feeling I'll have to do some trouble shooting to get this working right.

Any ideas?

[evilC]

Are you using absolute or relative mode for the conversion?
You need absolute.

ie when you hold the stick full left, the mouse needs to be all the way to the left edge of the screen, not moving left at full speed.

So GlovePIE recognizes the controller? I would guess AHK can too then. You may be better off doing it with AHK - you would have a lot more control over the maths and such.

[Golden Gun]

Yeah, I have it running absolute. IE the joystick responds like it does in the calibration screen.

I haven't tried AHK before and I only went with GlovePIE because it is free and some one else mentioned it.

I would assume AHK would work as all I had to do was route inputs from joystick 1. Rather strait forward TBH.

Oh, I know several of you have issues with the lack of buttons on the controller, and with today's options I can't blame you. But I wanted to share with you some mods that you might be interested in.







Since everything in the controller runs to standard buttons, they are easily rerouted. the lights even light up!

The buttons that routed from the center block are easily done because the 40-pin "IDE" cable used to transfer the normal signals on uses 2/3 of the pins so the left overs are easily hijacked for what ever you want to transfer.

I don't have the schematics on how to do this, but it is 1 to 1 wiring so figuring out how it works shouldn't be too hard.


Now for my personal sticks:





















To preemptively answer your question, NO! I did not make these but were built to my specs. The guy who made them is one of the smartest people I've ever met and it took him about 4 months to do.

And seriously, most of the uses for the switches do not translate well outside of Steel Battalion and Line of Contact.

Anywho, these examples should give you plenty of ideas on how to make your set of sticks your own and/or overcome any short comings.

PS - Here is something I made myself.

https://www.facebook...=1&l=e08d197f19

Edited by Golden Gun, 20 September 2013 - 07:56 PM.

[HackNFly]

I'm thoroughly impressed with those mods. I was thinking about doing something like that myself. I figured that it would probably be easy to replace the joystick with something with more buttons, however in that case it would probably be just as easy to just use a separate joystick instead of the SB.

One thing I'm confused about is why use GlovePIE? Is it because of the lack of return to center on the right stick? The game has full support for joystick instead of mouse. I understand the reasoning for games that don't support joystick. I've also had some conflicts between vJoy and GlovePIE in the past.

[Golden Gun]

Well, I wanted to have a control scheme like Steel battalions. Not for nostalgia, well not TOTALLY for nostalgia, but the controls made sense to me.

Right now, joysticks work outside the actual way the torso twists and the arms move. this is why current mouse users have such an advantage. By mimicking the mouse input with the controller, you have much better direct control over these two axis.

Right now, if you move the stick half way to the right, the torso will keep twisting until it reaches it's maximum limit and shift the arms half way past that limit. If you push further out, the same thing happens, just faster and the arms move further out. If you center the stick, the only thing that happens is that the arms line up with the torso.

This may work for an airplane or jet where you are using other forces to move you, but a mech' should have (and does with a mouse) direct control over these axis with a joystick.

I know I can get long-winded, but I am trying to be as descriptive as I can. The weapons control scheme for Steel Battalion worked in a way that if you, using the same example, moved the joystick half way to the right, the targeting reticule, and weapons, turned halfway to the right and stopped. Moving the joystick back to dead center meant that the reticule and weapons moved back the front center as well.

I know that each mech' has it's own "twist" percentage and even that can be changed by skills. So yes, there is no way for it to be exactly perfect, but with the higher resolution added to the driver, getting it to act like a mouse fluidly and with fewer jumpy spots will make people with Steel Battalion controllers that much more lethal in the game.

Just sayin...

[HackNFly]

Just wanted to provide some progress notes.

I've finished upgrading the resolution to 10-bit. On some axis like the pedals it doesn't provide that much more accuracy, since the ADC seems to only provide updates every 4 levels or so, so nothing really gained, but the pedals were already 255*2 since I split the axis across the two pedals.

On the right stick, left stick, and thumbstick, however its DEFINITELY noticeable, you can get it to go up one level at a time by applying gentle pressure to the stick.

Unexpectedly, I also figured out a way to emulate the mouse. There was a new development with a driver that I had looked into in the past. Long story short, it will be possible to do what you're talking about. Theres a nice function, MoveMouseToScreenPosition(double x,double y), but not surprisingly it doesn't work in game. It works outside the game though. Very easy way to emulate your mouse within windows.

Instead I'm using the MoveMouseBy function which the game recognizes. I think the MoveMouseToScreenPosition is more associated with a touchpad or touchscreen, and I don't think MWO works with that. I would love if someone with a touchscreen monitor could test that theory for me.

In the meanwhile a way to implement what you're talking about is to create essentially a PID loop, where you have an Xgoal and Ygoal set by the current joystick position and you keep sending MoveMouseBy functions to the game each iteration. Additionaly each iteration you keep a counter i.e. xTemp and Ytemp and increment them. You stop sending updates when you reach your goals. An improved approach would involve a ** loop where you use bigger values on MoveMouseBy if you are far away from your goal as oppose to closer to it.

Not sure if this makes any sense, but got to get some sleep.

Edited by HackNFly, 21 September 2013 - 11:51 PM.

[Golden Gun]

first off, GREAT NEWS!!!

I was only thinking the right stick would be seeing a res boost, but having the hat as well opens up several possibilities. I'd be more excited about the left stick if your exponential algorithm didn't work so well.

As for the joystick to mouse movement coding, I think I understand what you are saying. GlovePIE must use the same commands behind the gui since I seem to have the same issues you are talking about. The second type of command sounds the other type of conversion EvilC mentioned called relative. But as you were worried about, I don't understand HALF the coding mumbo-jumbo. I'm a hardware dude; my brother is the coder of the family.

If you need a guinea pig though, I'm your man! We have touch-screens at work, but they are in use so I don't know If or when I can test this out for you though.

Edited by Golden Gun, 02 May 2020 - 10:46 PM.

[evilC]

If we can confirm that the SB controller is readable using AutoHotkey, then I can maybe help in providing a stable solution that would work with any stick.

AHK may be a more suitable choice than even C-like languages as it is designed to manipulate the mouse and provides a number of methods to do so.

What I would probably do is something like this:

A "Training" mode that lets the macro work out the mouse viewport size.
Hit "Center Torso", then hit a button to tell the macro "this is center".
Move mouse left until full twist is reached, hit another button to tell macro "this is full twist".
Repeat for up/down etc.
If I wrote using my ADHD library, this would also allow profile support, so you could have a profile for each mech with different torso twists.

Also, I could maybe use pixel detection to detect the twist indicator at the top of the HUD, like I do with my zoom mod.

Not sure on my time constraints at the moment, but I would imagine I would probably have time to knock up a proof of concept.

[Hammerhai]

That would be brilliant.
EvilC, you may want to look at Loc Nar's thread on zero order controls again. It seems he was mistaken about MWO using absolute inputs, but that they are coded as relative movement. That may explain why "MoveMouseBy" works as opposed to the other function call. I can't explain in detail, as it is way too technical for me, but that post is fairly recent.

And good luck, maybe you can offer a solution to the difficult edge behaviour Fresh Crescent's Warthog script can be prone to.

[evilC]

Hammerhai, on 23 September 2013 - 05:47 AM, said:

That would be brilliant.
EvilC, you may want to look at Loc Nar's thread on zero order controls again. It seems he was mistaken about MWO using absolute inputs, but that they are coded as relative movement.

Just seen the thread, and I dunno why he ever thought it would or could be otherwise. It never was any different for mouse, nor could it ever be. This is why I use the terms "relative" and "absolute" instead of "zero order" etc as it more accurately encapsulates the issue at hand.
The complicating factor here is for sure going to be arm lock. What I need to know is:
As mouse movement is relative, let us say for a given resolution, with arm lock ON, if you move the mouse 1000px left, that is full twist.

If you now turn off arm lock, does that change?
ie if you now center up and move the mouse 1000px left, is that torso twisted full but arms not moved at all? or does it remap the scale so to speak?

From the sounds of what loc nar is saying, I suspect the range of motion to fully move the arms would be more.

One obvious way to keep it synched of course would be to send the keyboard command for "center torso" when the joystick is inside a deadzone. That might bring it's own issues though.