Drastic Measures for dealing with idle timeout reset

[nzbsolo]

I got fed up with software solutions to forcing idle timeout. Nothing worked. 

So I glued two switches together and used a dremel to bore some holes into the switches so it will fit in a happ style button.

One connects to my Ps2 keyboard to force hardware event. The other goes to my d-input device that runs the joystick.

It works! If it is a bit janky looking. 

[Metalzoic]

What exactly is this for? You mention Idle Timeout, but for that I just set mine to 3 minutes and if no one has touched a control it closes the game and returns to the menu.

For audio Idle Timeout I use Tur-Volume to auto-mute after 3 minutes as well.

 

EDIT: Just noticed you said you're using a joystick controller instead of a keyboard encoder. I'm guessing it conflicts with the standard timeout settings?

[nzbsolo]

Rocketlauncher's idle timeout function.

IE: no button press, the game quits after a pre-determined amount of time back to the menu.

Problem is that Rocketlauncher only registers hardware input for idle timeout. You can't fake an input via AHK, X-Padder, Inputmapper, ect. USB devices (that aren't keyboards) also have no effect. And I tried everything. Even wiring the keyboard and joystick buttons together on a circuit. Nothing worked. I went the through the forum history and nobody had a good answer. Keyboard encoders are out of the question because of how X-Input/D-Input works, and many PC games will throw a fit due to either the double-tap bug, or games that will dynamically switch between control sets. If I were just emulating I wouldn't bother with all this and use a keyboard encoder, but that is not the case.

What I was doing in the interim was using Inputmapper to emulate an X-Box controller using a d-input device and keyboard for the P1 start button. Problem is with this current version of Inputmapper, there is no way to isolate the channels. So if you pushed a button on the d-input device, it would fire the X-Box controller, and the d-input controller. Keyboard and X-box controller was the same. This is what I called the double-fire bug.

Some games could be fixed by adding more X-Box controllers to Inputmapper, like Castle Crashers. With only two emulated controllers, the double fire bug would start player 3/4 if you used player one or two. Add two more X-Box controllers via Inputmapper that are not attached to D-Input devices would take P3 and P4 slots eliminating the double-fire bug in that game.

Street Fighter 4 and Marvel vs Capcom have an incredibly stupid setup where whatever device was used last would take precedent as the primary controls. For MvC3, the d-input devices could be disabled, but the keyboard press would literally stop the game and not do anything for a second. Using AHK and and the new double button, I was able to fix the double-fire bug with the new double switch I made. This was easy, as D-Input could be disabled in MvC3 and you can use X-Box controls only.

Street Fighter 4 was worse than MvC3: any active controls would take precedent, even in game. Inputmapper would map to all the controls, and would fire all the buttons, including Player 1/2 start. In single player, Pushing start on P1 would fire the double-fire bug and start P2 on the player one control set. Essentially, single player was unplayable if you didn't know about this (people jam start to get to the next match starting player 2, breaking the game). And considering this was a public machine that will piss people off if it didn't behave properly, this was unacceptable.

So in order to fix SF4, I have a Powershell script running in the background looking for active processes. If Street Fighter 4 fires, it will kill Inputmapper, forcing only d-input. No more double-tap bug, making the game playable. The double switch runs d-input start and keyboard input solving the idle timeout issue and control issue. The script will start Inputmapper as soon as Street Fighter 4 closes.

Depending on the game, I have that same Powershell script that will disable Inputmapper if certain games turn on (Street Fighter 4, Hyper Dragon Ball Z, Shank) and only use the d-input devices as the controls so I will not get any double-tap bug situations.

All this to enforce idle-timeout which was a requirement in the office. The double switch is really ugly, but a very practical solution to a incredibly frustrating bug.

It also makes control setup for games complex. There are up to 5 places you need to address controls for games on my setup: Inputmapper, AHK, X-Padder, the Powershell script, and the game itself. When adding a new game, you need to figure out what you will use in order to make the game work properly.

But all that work is worth it: all games work like a champ now. Control switching is seamless, and there is no need to 'teach' people how to use the machine.  In other words, the control issues for my machine are now addressed. My build is done, besides adding new games and a vinyl cover for the Tankstick. 

[Metalzoic]

Wow, that sounds like a lot of frustrating troubleshooting and work.

 

I use just an iPac keyboard encoder and have never had any problems with idle timeout or PC games and I run quite a few PC games on my cab. Generally they just work although many need to be remapped using AHK from within RocketLauncher.

I've never had any control hangups or the double tap issue you mention on SF4, MvC3, Killer Instinct, SFxT, MKX or Guilty Gear Xrd etc... Castle Crashers works fine on mine with just player 1 & 2 set (although I use the x360kb hack to make that game work). However I've never had to get a Tankstick working either, but there have been several threads here before of people having issues with them. Glad you figured out a workaround.