Xpadder

[Nologic]

Okay in my fumbling around working on a rewrite of my Zinc loader...which entails switching from JoyToKey to Xpadder for very clear reasons...I've been mildly annoyed at not being able to count on where Xpadder will be located on a given persons system.

It being placed with in "Program Files" is simple enough:

start %PROGRAMFILES%\Xpadder\Xpadder.exe "%cd%\Player 1" "%cd%\Player 2"

It being placed in the "Windows" folder is also simple:

start %WINDIR%\Xpadder.exe "%cd%\Player 1" "%cd%\Player 2"

or

start %PATH%\Xpadder.exe "%cd%\Player 1" "%cd%\Player 2"

It being placed in the "System32" folder is also simple:

start %PATH%\Xpadder.exe "%cd%\Player 1" "%cd%\Player 2"

or

Xpadder.exe "%cd%\Player 1" "%cd%\Player 2"

However I strongly feel that Xpadder should never be in the Windows or System32 folder...as its just making a mess.

Placing it in "Program Files" is proper but not portable.

Heh yeah I'm being anal.

Now we could add Xpadder to the Application Paths; Example using "Program Files":

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Xpadder.exe]
@="C:\\Program Files\\Xpadder\\Xpadder.exe"

Doing the above then makes Xpadder portable to some degree...tho ideally Xpadder is on something like Z:\ drive.

Anyways then coding for it is simply:

start xpadder "%cd%\Player 1" "%cd%\Player 2"

heh plus you can also start the Run Box (Win+R) and type "Xpadder" and it'll fire up Xpadder.

Now we can take it another step further...and generally viewed as improper...but less so than dumping stuff into Windows & System32 folders...and thats to add Xpadder's path to the environment variables paths; Example using "Program Files":

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"Path"=...;C:\Program Files\Xpadder\

That can also be done from the AutoExec.bat...but I'm suffering from OldTimers..hehe so not recalling how right now.

Anyways then we can code for it like so:

xpadder "%cd%\Player 1" "%cd%\Player 2"

Well looking for the thoughts of others as to what should be done...as I can write scripts to automate adding the required registry entries based on where Xpadder is currently.

Or am I simply having one of those blond moments and over thinking the simplest of things?

[Tom Speirs]

I think the "cleanest" and most "proper" is with the registry. Although ideally XPadder itself should "install" and set in the registry where it is installed, but you probably couldnt easily retrieve that value from a batch file, youd have to use some other code/script.

[Nologic]

Well I'm not sure Xpadder needs to run a installation routine...tho I have put forth a feature request that it checks the "Applications Path" in the registry to see if there is a value..and if its correct...and to automatically inject itself into the registry or the correct value. Followed by a secondary request to allow the end user to added Xpadder to the environment paths.

Well not really looking to retrieve the value...but to invoke the value.

App Paths

start xpadder "%cd%\Player 1" "%cd%\Player 2"

The above actually works in a batch script...provided there is the Apps Path value entered into the registry.

[headkaze]

If it's an AutoIt script why not use an ini file that has a setting you can change?

[General]
XpadderExe=C:\Program Files\Xpadder\Xpadder.exe

Check out the IniReadSection, IniRead, IniWrite and IniDelete functions.

[Nologic]

Yeah I've done that before...but looking to make it far more simplistic for the end user...thus easier to get GX up and running.

With the above Apps Path value set I can then use ether of these bits of autoit code to perform the same thing as the batch script.

Run(@ComSpec & ' /c start xpadder "' & @WorkingDir & '\Player 1" "' & @WorkingDir & '\Player 2" /M' )

#Include <Process.au3>
_RunDos ( 'start xpadder "' & @WorkingDir & '\Player 1" "' & @WorkingDir & '\Player 2" /M' )

Basically it removes the need to edit half a doze ini files...by just setting one registry value.

[LB11]

Is this supposed to replace the zinc loader that gameex already uses?

[Nologic]

Well this applies to work being done on a loader that would replace GX's.

[LB11]

Maybe tom could add something in gameex to ask where the executable is similar to how it asks where zinc is? Then it could write it to the ini file?

Or use the ini file and have it default to C:\xpadder\ Then where they setup zinc in the config it could tell them edit the ini if xpadder is in another location.

Or maybe he could just add a launch before and launch after in the zinc section. Then everyone could set it up just like a regular emu.

Just some thoughts I guess.

Why does the loader need a joystick mapper anyways? I didn't realize the current one used joy2key.

[Nologic]

Well I'm trying to avoid the use of an INI file just store the location of where Xpadder is...and the dozens of ini files required to store that value.

Setting the Apps Path value for Xpadder not only makes it simple to use Xpadder with Zinc but also nulDC & whatever else...basically its a single point of failure or success.

The current GX Zinc loader doesn't use JoyToKey...but my current Zinc loader does...this allows you to play the CHD games supported by Zinc...and thats not fully correct.

The bases of my Loader is to by default use WinterBlast's JoyStick Controller plugin for Zinc so that you have better responsiveness from your controls, compared to Keyboard mapping.

The problem is the JoyStick plugin doesn't work with the CHD games...so you have to revert to the Keyboard plugin in this case we are looking to make things appear seemless rather than fucked up like they are. So we use some sort of Joystick to Keyboard mapper application...which prior to Xpadder, JoyToKey was the popular pick so things where coded to that....which was an ugly hack.

The current GX Zinc loader doesn't appear to map any keys to gamepads...nor show any way of doing so....so from my point of view the current GX loader is broken. Now I certainly could be wrong about a number of things...if so I'm gladly open to being enlightened.

Anyways Zinc is sort of off topic even tho its what spurred this discussion.

[LB11]

Ok, I see now. Is there a way to write your program to:

A. Go to xpadders download page

or

B. search the HDD

on first load, then if

A. It would just tell them install the program to this directory.

Or

B. if it finds xpadder.exe on the system. Just copy it over to the folder needed while leaving the original in place for whatever it was being used for?

Both with a popup that would ask if its ok first of coarse.

The only other thing I can see helping you would be to ask the author to include xpadder with your script, or wait till he finishes trex as I believe he will have an installer. All though I dont believe he will be adding much to the registry as he seems against installers in the first place.

[Nologic]

hmm think we got two different things going at the same time.

Far as adding Xpadder to App's Path, I can write a script that searches the current directory for Xpadder and if found, make the required registry entry...if not found ask end user if its installed & if yes prompt end user for location...then make registry entry...if not installed fire up IE at users request and direct it to Xpadder home page.

I don't really care where its installed on the system...only adding the pathing of Xpadder so that its known by the OS, so that I and others can script against it.

So

R:\some\messed\up\path\xpadder

is just as good as

C:\Program Files\xpadder

So where ever its at...is fine by me...not looking to move it anywhere.

As for ?Jonathon? hehe been awhile since I spoke to him...yeah he's not keen on installers...and an installer is not fully required here...as for the registry he seems to prefer keeping things portable...not that he's against the registry...just if it doesn't need to be in the registry...then it wont go into the registry. In this case he would likely add the registry entry as it kind of does need to be there to do whats desired. I posted about this to some degree on his forum...and have yet to hear yay or nay about it.

Hehe T.Rex is going to be cool.

[LB11]

Far as adding Xpadder to App's Path, I can write a script that searches the current directory for Xpadder and if found, make the required registry entry...if not found ask end user if its installed & if yes prompt end user for location...then make registry entry...if not installed fire up IE at users request and direct it to Xpadder home page.

So this is where you are going with it? I was a little confused. Sorry

I thought you wanted xpadder to be in one place so you could just put that path in your script and it would all be good. But you want to have a way to automatically enter any path it might have in your script. Correct? Which is why the registry key would be best.

[Nologic]

Okay I think we are now on the same page.

Heh shit no reason to be sorry, hell I'm in debt to you over the fine work you have done on the db's.

Yeah the basic idea is to use very generic code in the scripts (AutoIt, Batch, AutoHotKey,...) to where all its required is for the end user to make sure that Xpadder has a valid value in App Paths with in the Registry.

That way it limits the amount of trouble shooting involved, and the difficulty getting things setup right the first time.

So basically picking peoples minds about what they thought of this method...along with digging for newer\better suggestions.

I nearly have my basic Zinc loader written out with all the required support files...so I should be able to bang on this here in a bit to see how well things work when actually used with GX.

heh after this is all worked out...then I'll be see about tackling the age old problem of dealing with OpenGL in a GX environment...get that solved and I'll be feeling rather studly...until bug reports come rolling in.

[Nologic]

wOOt! just heard back...this will be getting added to Xpadder in a future release.