417 replies to this topic

[Golden Gun]

Hey Scum,

Exactly what part of the switch is broken? Is it the the silver rod part or something at the base

If it is the rod part, I've seen this fixed by driving a semi-long screw down the hollow center of the shaft so the switch can still be used.

If this is not the case and you can't fix the screw, don't worry too much. The current set of drivers you run for the SB controller do not require every button and switch be working. You can just comment out that switch from the code (not as bad as it sounds) and you still have everything else available.

As for parts and stuff, good luck. Sammy doesn't support it anymore and I've never seen anyone post a part for part replacement list.

If you have any other questions, feel free to ask! And welcome to the thread!

Golden Gun

[Scum of the Earth]

Golden Gun, on 06 March 2015 - 09:30 PM, said:

Hey Scum,

Exactly what part of the switch is broken? Is it the the silver rod part or something at the base...

Golden Gun

Here is what it looks like right now.







I found that plastic peg when it fell out of the car part. It's in perfect shape which makes me think it was supposed to be melted onto the bottom of the metal switch to act as a peg for more surface area for the two plastic pieces to hold onto each other. Perhaps maybe it was even supposed to melt completely to be a part of the weld...? If you look carefully, you can see where the two pieces were welded/melted to each other. I don't think it was glue so much as heat that melted the two pieces together.

I'm at a real lose of something within my possession that can join them back together. I have modeling clue and even plastic glue laying around but the force at which the switch is pushed at, I'm 98% sure they would never hold together again. Plus, even with the utmost of care, I can easily leak glue down into the car part and gum the whole thing up and not move at all.

I have looked at electronics stores about replacing the switch but so far any switch that seems to match up to the 6 holes in the board are flat and wide and not the round pegs that go through them. I'm way to nervous (and not confident in my abilities) to widen the holes on the board to make them fit through. Perhaps it would be all good once I soldered them back into place and was careful to keep the contacts together correctly but God forbid with my luck, I would split the board in half while I was trying to widen one of the holes... ;P

[TheKennanator]

Gents, sorry to quasi necrosis but I just finished reading through all your work. I just finished building a new PC Rig for playing MWO, SC, War Thunder, and ED. I can happily say I have some cables on order and will be joining you all in dusting off the SBC.

Also, I have a MS Force Feedback 2 sitting on my desk right now. I feel like I stepped back 15 years to my childhood.

Anyhow, did you guys figure ou a way to make the stick work in a way similar to Steel Batallion? I have access to some great I/O programmers so I may make a stab at it.

[HackNFly]

Hey guys, I finally have had some time / motivation to work on this again. Are any of you using Windows 8.1 Pro? I upgraded about 6 months ago and ended up wasting most of tonight getting even the most basic part of the drivers working again. Everything has to be signed for it to work on Windows 8.1 Pro, can't just use the INF file I had included before, even though it simply links to an already signed driver. Anyways, ended up self-signing and was able to make it work, albeit in test mode. Still working through some other issues though. Main goal here is just to have it work on Windows 8.1 Pro and link the code up to the new version of vJoy to allow the extra axis / buttons.

Edited by HackNFly, 24 April 2015 - 09:04 PM.

[Golden Gun]

I'm still on Win 7.

What issues are you facing on 8? I thought the driver would work on both the same?

That aside, I'm super excited to hear you working on this cool driver again. I know you mentioned these ideas and updates in the past, but since you are doing all of this for free I didn't want to pester you.

Good luck and let us know if you have anything that needs to be tested!

[HackNFly]

TLDR; I've got it working in Windows 8, going through some higher detail design issues at this point.

So there's a few parts to this. The issue I was having before is that being in Test Mode isn't enough anymore. Somewhere along the way a patch that was sent through on Windows 8 makes it so that all .INF files must be signed, even in Test Mode. Windows 8.1 has a way to turn that off, but it gets reset everytime you restart. This goes along with the stuff that the author of vJoy had to do in order to get his driver to install without all those pesky notices.

I went through the learning process of how to sign a driver and got that straightened out. Of course it'll still say this is an untrusted source, but in test mode it allows you to install it and the SBC is working.

Second bug, took me a few days to track this one down. I relied on DirectX.DirectInput in the original program. I didn't remember any real issues with it, and I was playing a lot more games then, so I probably had a version installed. Well, you need to have it installed to work.

Windows 8 now includes DirectInput as part of Windows. They've deprecated some things and changed other things, and it just doesn't work. Luckily all I was using DirectInput for was their enumeration of Keys, as I'm emulating key strokes at a lower level so that it would work with older games like MW4. I ended up copying that enumeration, including it in a different file and got it working without any reference to DirectInput, which I see as a good thing. The less moving parts to getting the controller working the better.

Only problem is that it is going to require some changes to previous .cs files

Microsoft.Directx.DirectInput.Key.Space

becomes

SBC.Key.Space

or just

Key.Space

Not a big change.

The higher level issue I'm pondering right now is that the author of vJoy split up the way his program works and made some changes. The biggest thing is the support of 128 buttons, which is half the reason I'm doing this update. Problem being he has always supported 2 ways of updating the vJoy joystick, and efficient way, and a robust way.

The efficient way, you update all the changes you want to make, buttons, axis, etc, then send one update to the vJoy library.
The robust way, you make a change and immediately send an update to the vJoy library.

I wrote my own wrapper back in the day and did it the efficient first way, because I wanted the program to have minimal overhead. Problem with that is that you have to know the data structure to set it up. Well, due to the addition of buttons, the data structure has changed to accommodate the extra buttons. I'm trying to decide how I want to handle this.

Last problem,
The official C# wrapper that now exists uses this format:

joystick.SetAxis(controller.AimingX,1,HID_USAGE.HID_USAGE_X);

mine used this:

joystick.setAxis(1,controller.AimingX,HID_USAGE.HID_USAGE_X);

Identifying which vJoy id you want to update just made more sense to me to be the first parameter. But it makes more sense now to support the official wrapper. So these are higher level design issues, but I have to figure out how to make it easy to use the old .cs files without issue.

~HackNFly

Edited by HackNFly, 27 April 2015 - 10:46 AM.

[Golden Gun]

So on your end the coding is ALMOST the same but different just enough to make you want to pull your hair out...

I'm not much more then a script kitty so I can mostly follow what you are saying. It sounds like the best bet is to make sepperate folders for the different OS versions of scripts. That way we (I'm more then willing to help) could do some direct translations of current .CS files and have them ready to distribute with the Windows 8 version of the driver.

Would it be hard to make an internal Identifier at the begining of each script so when loaded it can warn the user if they are loading the wrong type? Since the syntax is going to be different by default, maybe an initial snoop on a string that is present in every .CS file but different depending on the version of Windows could do the trick.

[HackNFly]

As far as that issue is concerned, I think I can make it transparent. I'll have it write out a temporary file depending on which .cs file you provide, and I'll programmatically make the appropriate search and replaces on the file. Writing out the problems I mentioned I think I know what I'm going to do. I should have this wrapped up in a few days. Its very rare for me to have spare time to program, so I'm trying to get this update done while I have time.

[Golden Gun]

Man, you are awesome! I wish you the best of luck too.

BTW, since the coding will have to be adpted for Win 8.1, will this do anything for us users on Windows 7?

[Boomaholic]

First off I would like to extend great thanks to both of you, Golden Gun and HackNFly. Because of your near tireless efforts enthusiasts and owners of the Steel Battalion controller like myself can dust off our cockpits and delve into the fray again, this time in any game we choose to do so with.

That being said I've scripted out my controller as to how I am Currently using it for Elite: Dangerous. and it has been quite a thrill. Although I've recently been toying around with the idea of using the TunerDial for targetting select subsystems. Now assigning the tuner dial as SL1 in place of Gear Shift allows this to work in the way I want but not without its faults. As it only triggers the button hits in game(when set to axis+ and axis-) when the dial is in 0 state or full state, regardless of how i change the calibration).

So with this in mind I wanted to try to take a different approach and just assign D9 and D0 key press values when TunerDial is turned in a Positive State or Negative state. Which has lead me to the current code I have below:

knowing that TunerDial is an Int as stated in the SBC.cs, that gets read from 0-15 state. I figured something along the lines of this for baseline to work off of.

if (controller.TunerDial++)
{
controller.AddButtonKeyMapping(ButtonEnum.TunerDialStateChange,Microsoft.DirectX.DirectInput.Key.D9, true);
}
else if (controller.TunerDial--)
{
controller.AddButtonKeyMapping(ButtonEnum.TunerDialStateChange,Microsoft.DirectX.DirectInput.Key.D0, true);
}

I've realized there are many issues with this though. First being that if statements cant consist of Bool modifiers. Second being that TunerDial is readonly and cannot be directly modified. so then I modified to this

int weapChange = controller.TunerDial+1;
if (controller.GetButtonState(weapChange++))
{
controller.AddButtonKeyMapping(ButtonEnum.TunerDialStateChange,Microsoft.DirectX.DirectInput.Key.D9, true);
}
else
{
controller.AddButtonKeyMapping(ButtonEnum.TunerDialStateChange,Microsoft.DirectX.DirectInput.Key.D0, true);
}

This introducing the weapChange integer to allow modifying. Now this works in an extent that turning the dial actually produces key press. however regardless of which way i turn the dial it only produces 0 key.
Over the course of the week I've modified and messed around with the code introducing for while do, many combinations, but to little to no success, which I won't bother with producing every variation and telling of the results. I was wondering if by chance You could help me out if at all possible.

I honestly feel like I am almost there, I am just missing one final little modifier that I have not thought of.

[HackNFly]

What you need to do is keep track of the previous value of the tuner dial.

So add a variable to the top of the script.

using System;
using Microsoft.DirectX.DirectInput;
namespace SBC{
public class DynamicClass
{
SteelBattalionController controller;
bool currentResetValue;
bool lastResetValue;//used in assessing when to flip lights
vJoy joystick;
int lastTunerDial = 0;
...

Then in your section do:

int weapChange = lastTunerDial - controller.TunerDial;
if (weapChange > 0)
{
controller.AddButtonKeyMapping(ButtonEnum.TunerDialStateChange,Microsoft.DirectX.DirectInput.Key.D9, true);
}
//not using else, because we don't want to do anything in the case that the value is the same.
if(weapChange < 0)
{
controller.AddButtonKeyMapping(ButtonEnum.TunerDialStateChange,Microsoft.DirectX.DirectInput.Key.D0, true);
}
lastTunerDial = controller.TunerDial;

This is of course pseudocode, I haven't tested it out, but the idea should be sound.

~HackNFly

[HackNFly]

Golden Gun, on 27 April 2015 - 01:43 PM, said:

Man, you are awesome! I wish you the best of luck too.

BTW, since the coding will have to be adpted for Win 8.1, will this do anything for us users on Windows 7?

Only difference out of this is that I'm going to try and streamline the installation process once I'm done. This should also make it easier to support whenever Windows 10 comes around. I'm planning on upgrading to that when its finally out.

[Golden Gun]

Hey Boom, don't thank me man, it's all Hack 'n' Fly. He created the driver, has stuck with it as Widnows and PPJoy then Vjoy constantly changed and put up with are icessant questions.

The dude is a Superman.

Me, I'm more of a cheer leader / Good idea fairy...

[HackNFly]

I've put way more hours into this update than I originally anticipated. I've got it working though. The whole signing drivers thing threw me off for several days. Ended up finding a work around in Zadig. Its a program that bypasses having to sign a driver that does nothing more than make use of an already signed kernel driver, as the case with the SBC.

Another hang up, was the fact that the libusb library I was using was terribly dated. It hadn't been updated in years, and although the newest version of that library has been signed at the kernel level code, the older version I used hadn't. Unfortunately they made some application level breaks in the codebase since the last time I used it.

I ended up deciding to just adapt my codebase to make use of winusb instead of libusb. Winusb comes with windows Vista and up I believe and is up to date since its supported by Microsoft. I managed to find a nice project winusbdotnet that made it relatively easy to get working. I actually got that part of the project up and running in an hour. Once I understood the whole GUID INF file thing it was easy.

Then came fighting a blank Windows 8.1 install forever. The same program would work on my machine and on the windows 7 64 bit laptop I have, but not on the Windows 8.1 clean virtual box build I had. That took most of tonight to figure out. Ended up being I didn't have the Visual Studio 2013 Redistributable installed on that machine. And since I was making use of the vJoyInterface.dll which isn't managed code, I needed to include that distributable. Took using the nifty and free dependencywalker program on the virtual machine to figure that out.

The last thing I have to do is use vJoy config program to change the default number of buttons to 39, that way Simple.cs can simply update the numbers as necessary.

So I finally have a set of 3 installers that allow me to control the SBC on a fresh Windows 8.1 build. My end goal is to have a single installer that will call the installers / programs in the right order.

I'm quite happy with the progress I've made and the things I've learned, I hope to have this finished soon. I'm running out of steam.

Edited by HackNFly, 03 May 2015 - 09:06 PM.

[Golden Gun]

First of all, congratz! I know this is taking more time an energy then you wanted, so thank you for being so dedicated to the project.

On a different note, I have to take off for a 10 day training tomorrow so I won't be able to help play test it to until I get home. I'll let you know when I'm back thought.

Once again, you rock!

Edited by Golden Gun, 04 May 2015 - 12:41 AM.

[HackNFly]

Lots of changes on this one.
Main improvement is that it now works in windows 8.1 and program has a rudimentary dedicated installer. Removed dependencies on DirectInput, old code referencing directinput will still work.[/color]
Upgraded from libusb to winusb, allows seemless installation of drivers through wdi-simple, which is embedded in installer.
Making use of newest version of vJoy which allows 128 buttons. Allows support for all 39 buttons on SBC, but game support may vary, as games may be expecting max of 32 buttons.

Here is a link to the latest release.

UPDATE: Did move it to sourceforge, here is the new project page:

https://sourceforge....l-batallion-64/

And the latest release, with installer, tested it on Windows 7 64 bit and Windows 8.1

https://sourceforge.....0.zip/download



~HackNFly

Edited by HackNFly, 08 May 2015 - 08:27 PM.

[cainsblade]

Thanks a million guys.

My girlfriend was pushing me today to throw away my dear steelbattalion controller, but thanks to this kind of efforts, I will play with it till the XXXI century.

Thanks again.

[TheKennanator]

I'll have to give it another shot. I was able to get the console and rudder pedals working well enough with MWO to give it a few attempts.

The biggest issue I ran into is a best practice on mapping the controls. Only having 3 buttons and POV switch is severely limiting for most mechs.

I am running Windows 7. I used the older vJoy setups and was able to get almost everything up. I ran into some issues with the configuration on the emulator, but nothing game breaking. I wasn't able to get the radio dial to work. That was the only big I/O point that I had trouble with.

[Golden Gun]

I'm home and downloading as we speak!

me = EXCITED!!!!!!

[Golden Gun]

Okay, here it goes.

General: NO MORE NEED TO RUN IN TEST MODE!!!!!! This is by far the best part of this update! by having it run w/o test mode, you have opened this up to so many more people who aren't as tech savvy as others.

All-in-one-installer: Excellent! I actually downloaded the latest version of VJOY and installed it on reflex only to realize it was already part of the package. For thouse of you who haven't tooled around with this in the past, you had to install several, I think four, different programs and add a few files manually just to get this to run so having it all in one package is da' BEST!

Full Button Support: Very very nice! I edited the "simple" .CS file you packaged and all the buttons worked flawlessly. If you want to use the Dial, Gear Lever or the Toggle switches, you'll still need to program those in.

Controller inputs: This area has always been very touchy. the Rotation lever has ZERO dead space so you need a light touch to keep moving strait. The Aiming lever is also, very hard to keep center. Unfortunately the "mouse" style input files I made in the past error out. Lastly, I noticed that most of the input axis (center/right pedals, Rotation Lever and the "Slider" part of the Sight Change) give a mirrored output. This is easily corrected in most game's controls area, but it would be nice to not have to do that. Is there a way to make the sight change into a HAT/POV input?

Programming: Haven't touched it yet (c'mon, I've only had it for an hour or two!) but with the all the buttons unlocked, I can only imagine it being boiled down to a minimum. Before you had to figure out every buttons keyboard equivalent. now you just do it in-game. I was able to map everything I wanted in MWO in about 15 minutes while trompsing around the Proving Grounds.

Again, you'll need to program manually the following:
Tuner Dial
Toggle Switches
Gear Lever (maybe?)

So! Final review grade: A++++++++++++++!

HackNFly, if I had a money cannon, I'd shoot you repeatedly with it until you were filthy rich. You have done so much to keep this controller alive there is very little more I could say or do to thank you.

Edited by Golden Gun, 15 May 2015 - 11:02 PM.