Nologic

Well my first run I managed to not rename the fields correctly...so that by and large was the first primary issue...the last issue I ran into was that "Date" must be a time\date value and not text or numeric...which currently I would think is fine since we are currently only searching by yearly date. I'm still playing with things tho...however additional tables, forms, query's and such do seem to be fine...tho my Access skills are lacking these days...not that they ever where worth a shit before. I have a very crude autoit script that allows me to leech data currently from MobyGames, so I can build a basic DB fairly fast...tho I'm starting to think about making a more complex and informative DB collection...tho there is certainly going to be more data entry than I care to try and take on alone. If we can get a group effort and group discussion going...and nudge Tom into adding support...we could really boost the quality of the current db sets. Oh here are my two current additions...number of players field is bogus, and date is only good far as the year the game was released.

Well is the profile stored where the xpadder executable is?...if not thats probably your problem...as that line assumes that it is. Also you are using a current version of xpadder...because when I first started making waves about this app...it didn't support CLI. Anyways this is what I have for use with nullDC: Tho some thing cleaner would probably be: However I'm loading the same profiles every time...for per game I guess some thing like so would be in order: Ether way tho I'm storing profiles in a sub folder of the folder containing my roms...it would be nice tho if we had an alias like [EMUPATH] which would give use the working path to the emulator...like whats in MameWah. Well not sure if I helped or hurt...but best of luck ether way.

hmm even at that I'm still not getting any thing to show thus far.

Okay I'm trying to create a simple DB for the Sega Dreamcast...which I'm not that far along on...however I decided to see if that data was appearing in GameEx...and well no its not. So my question is...how does one go about making a working DB for GE...are we simply limited to a single table, or a certain set of data entry...with no forms or fliters... Anyways any help would be great as we currently are sitting short on a lot of DB's for a number of consoles and handhelds. *Update* =============================================== Okay here is a preliminary collection of db's...all of which will be redone yet again...as I've decided to add more data. These are not replacements for GameEx's current db's unless there isn't a corresponding db for a given system. List ========= [Console] Amiga CD32.mdb [Console] Atari 2600.mdb [Console] NEC Turbo Grafx 16.mdb [Console] NEC Turbo Grafx CD.mdb [Console] Nintendo GameCube.mdb [Console] Panasonic 3DO.mdb [Console] Philips CD-i.mdb [Console] Sega 32X.mdb [Console] Sega CD.mdb [Console] Sega Dreamcast.mdb [Console] Sega Master System.mdb [Console] Sega Saturn.mdb [Console] SNK Neo-Geo.mdb [Console] SNK Neo-Geo CD.mdb [Console] Sony PlayStation.mdb [PC] Microsoft DOS.mdb Note attached zip is actually a 7zip archive with its extension renamed.

This is largely a conversion of Howard_Casto's loader mentioned here to AutoIt with a few minor tweaks. This is mainly me conceding that HC's method is cleaner than ether prior loaders offered here, tho his is still a little rough and I feel the tweaks I've made help smooth things out a bit.

Xpadder simulates keypresses and mouse movements using a gamepad Grab it @ http://xpadder.com Improved settings layout, windows and interface Improved startup speed (nearly 3x faster than v4.5) Improved support for trigger axis reading Improved XInput reading speed Improved dialog window handling and memory usage Improved dialog text formatting and handling (can now be copied and scrolled) Improved sub-window handling Improved settings option naming and added default values Improved trackbar visual uniformity and access Added individual mouse, mode, deadzone, and diagonal settings Added profile order auto-opening for identical controllers Added NumPad and mouse inversions to auto-assign list Added global deadzone defaults in settings window Added tab ordering based on controller instance id Added "Scan For XInput" startup option Added version check error message Fixed a bug where triggers were read as 50% down with some drivers Fixed a bug where CreateEffect error ignored controller Fixed a bug where changing the background colour with no controller connected caused error Fixed a bug where changing the background colour after controller disconnection left an outline Fixed a bug where profile trigger deadzone slider showed 100% instead of 99% Fixed a bug where button release forced a button display without doing necessary checks Fixed a bug where controller file open failure processed auto-open profile Fixed a bug where missing profiles were not removed from profile recents menu Fixed all sub-window element tabbing orders

Yeah I read that posting...and its again another sound suggestion\issue.

Heh actually I was, now that I checked posting times. After Stu's last suggestion I really feel that joy2key should be tossed out and replaced with Xpadder. There are still some fairly major features still to be added to it...and its really shaping up as the be all end all of gamepad to keyboard mappers.

ahh stealing my thunder. However its very understandable as its key new feature was some thing you suggested.

You can check out my half hearted comparison here. However much like PimpDaddyStu stated...if you got joytokey setup and your happy with it, then there is no real reason to switch over to Xpadder...however I'll be pushing for its use with those new to emulation as I see it as far superior to all other key mappers.

Actually I haven't tried the CLI yet...even tho I was the one pushing for its inclusion the hardest. *hangs head in shame* I intend to redo my zinc loader making use of xpadder for every game...so at that point it will be getting hammered.

You can find it at Xpadder.com Here is whats new: - Added Advanced Starting Help (lists all the switches) - Added an option to show taskbar button when minimized (as requested yesterday in the chat window - allows Alt-Tabbing to Xpadder window if it's minimized) - Added controller link database duplication and corruption checking (also added duplication checking and defragmentation for recents list) - Added different icons for Xpadder, profiles and controller files in Windows Explorer - Added name display of .xpaddercontroller files in Windows Explorer (not associated with Xpadder yet though) - Added profile loading via parameters (double-click a profile in explorer, add the profile name(s) to a shortcut target or start Xpadder from the command line followed by a list of profile names) - this can be done even if Xpadder is already running - Added shortcut launching. Simply specify the full file name of the shortcut when starting Xpadder and the shortcut will be launched for you when all controllers and profiles are ready (see the Advanced Starting help for more info) - Added taskbar button flashing when Dialogs are shown (conforms with Microsoft spec) - Added this: If only one parameter is passed, more than one controller is connected and the selected controller is not number 1 then the profile loads onto the selected controller(!) - Added Vista shell icons for profile files (XP already had them but they are better now) - still some work to do here (it shows the Xpadder icon instead of the profile icon but I'll alter soon) - Fixed a bug where Controller Order column in Settings window was too short on Windows XP - Fixed a bug where extension extraction didn't handle folders with extensions - Fixed a bug where loading message flicked up if animations were disabled - Fixed a bug where opening the first profile on the recents list triggered a shutdown database save unnecessarily - Fixed a bug where parameters opened a profile even if controller was not connected - Fixed a bug where trimming of controller names from registry prevented controller linking if controller name had leading/trailing spaces (rare but some exist) - this issue is also fixed in v4.3a up on the website now - Fixed lots of profile opening display bugs (buttons not appearing when they should or appearing when they shouldn't) - Improved command line parameter parsing (added extension recognition, auto-extensions adding and general trimming) - Improved command line parsing to include these new switches: /m (minimize), /c (close), /? (help) - descriptions are available in the Help menu (or try "xpadder /?") - Improved multi-instance support. Running Xpadder while it is already running restores/minimizes the main window instead of giving a warning message - Improved Path extraction - Improved path processing and saving for command line profiles - Improved profile handling code to support all the new features in this and future v4.4 betas - Improved registry associations handling, speed and efficiency - Improved Settings Options wording and help - Improved the profile system again to prevent stray error when loading profile if it was cancelled - Improved title bar text handling. The Beta indicator is now at the top of GUI and progress text is displayed at the bottom of the GUI (the final style and position is still be worked on, I may even remove the progress text altogether) - Improved Windows version checking - Major improvements to the profile handling (again!) leading to less code and a faster core loop - Moved "Loading Profile" message from footer info box to profile name button - Open/save dialogs add profile to Recent Documents list - Re-added the "profile open error" dialogs using the new profile method - Removed beta save/overwrite confirmation prompts (the beta should now behave exactly like the final version except for the beta version displayed in the top right) - Renamed all Exit text as Close (right click any taskbar button and it says "Close" not "Exit" - I think "Exit" was an old Windows 3.x/DOS term that I've kept using!) - Restoring main window or showing Help via parameter brings Xpadder window to front of screen

most duplicate file finders will allow wild cards to be used when searching for dups by name only.

hmm... Well both have been made to work stand alone before, and certainly are not an issue to be made so again. With nether actually requiring no more effort than whats presented in GameEx. As to which is better standalone or integrated thats simply a matter of personal pref. I'll be revising my zinc loader in the next day or so, that will hopefully remove the two biggest issues with it. 1. passing info to GameEx when its used integrated 2. complexity of setting up controls Model2 no real issues other than updating the game list and some speed tweaks...it'll never be as fast as HK's loader, but it can come very close.

I generally have a roms folder for each Emu I wish to use...this add's up to a fair amount of dup's...but it also makes sure that every thing works as expected in case one of them updates and changes files used or naming. Also keep in mind that Mame is one emu of its own, and Model2 & Zinc are also their own Emu's...Mame has the same games as Model2 & Zinc...however both tend to play their given games faster than Mame currently....and this is the only reason to use them. In do time Mame will likely play those games just as fast or maybe even faster...but thats down the road some time. Keep in mind also that Zinc is completely CLI based...and you will likely find that you need a FE (frontend) of some sort to get it to play. Model2 does have its own interface tho limited and buggy...so it should be fairly easy to get up and going without resorting to any FE ahead of time. I'd suggest heading over to easyEmu to get the basics down for these two fine Emu's...and then suggest you come back here once you start running into issues dealing strictly with GameEx integration of these Emu's.

unison and held for a bit...its not instant.

Well you are using D3D...so OpenGL isn't the issue. I'll look things over in the morning & maybe I can find some thing in my code thats screwing up. Make sure to check your Zinc rom set with clrmame pro...you should be able to find the correct dat file over at Logiqx. If you've never used clrmame before be sure to make a backup of your roms just encase some thing goes wrong.

Yeah if you want to...or you could simply reuse that one and simply give it a generic name. Unless there are special needs for a given Emu..that one generally works fine for most if not all.

Are you using Vista? If so set the properties for the wrapper\loader to run with administrative rights. Also it is important not to use the OpenGL* render when first getting things going...#2 maybe very pretty to use...but it has more setup issues. In standalone your command line does look like so: ZiNc_Loader.exe "[Rom]" As is it seems like your launching Zinc without passing it a rom.

When you setup a Emu you need to select an Advanced Config: this is on the second page of the Emu setup. Check out "C:\Program Files\GameEx\CONFIG\EMULATORS\Project 64 V2.ini" for a good example of enabling gamepad exit...with the combination of D-pad upper-left + Button4 + Button5 + Button6 all being pressed at the same time in order to exit the Emu.

Yeah 4.3 should allow each gamepad\joystick to have its own profile loaded...I'll play with things and see if I can't get at least my nullDC loader to support multiple profiles at execution.

No CLI as of yet. The next version...which is suppose to be out before the end of the month. Yeah from what I understand it should support up to 16 of them...as long as windows see's them...xpadder will as well.

Xpadder allows adding gamepad\joystick support to games, emulators, and applications that ether have no or limited support. http://xpfreehost.awardspace.com/ * Improved controller link database accuracy and functionality * Major improvements to DirectInput error handling * Improved core loop speed and memory usage * Improved scan request speed and efficiency * Improved set resetting * Improved starting when minimized (no window display delay) * Improved XInput compatibility detection * Minor help improvements + Added recent profile lists based on each controller + Added Controller tab in settings window allowing for controller ordering + Added profile opening options to tray menu + Added tabs to Controller Editor: Start, XInput, Finish + Added Control Panel launching button to Controller Details window + Added support for XInput versions April 2007 and December 2005 ! Fixed a bug where key repeat emulation wasn't accurate ! Fixed a bug where mouse button release emulation was delayed by 10ms ! Fixed a bug where Shift key release while another key down was not emulated accurately ! Fixed a bug where mouse wheel scroll repeats interfered with key repeats ! Fixed a bug where key repeating was interrupted by set selecting ! Fixed a bug where set selecting with cycles caused cycling ! Fixed a bug where controller reconnection was not scanned by XInput if both APIs were in use ! Fixed a bug where XInput independent triggers weren't processed with some windows ! Fixed a bug where six or more Xbox 360 compatible controllers triggered repeated warning messages ! Fixed a bug where the debug version of DirectInput was not handled ! Fixed a bug where the Profile Settings icon was displayed even though controller was disconnected ! Fixed a bug where controller database updated when controller file was reloaded ! Fixed a bug where messages in dialog windows could wrap incorrectly ! Fixed a bug where loaded text from registry wasn't trimmed

Okay maybe I'm nuts but as I see it we have three main things here: Su_Sweet_(7523).vkm SUSWEET.D64 "Su Sweet" My question is why don't they share the same name? Su Sweet.vkm Su Sweet.D64 "Su Sweet" Also is there some large mass of supporting files for these games...or is it just the two files generally? If its just two files, why not simply place all files in one folder. With every thing in a single common folder for all games...and common naming for supporting files you could probably get away with: ROMFilter=*.D64 Command=x64.exe -flipname "[ROMPATH]\[ROM].vkm" -autoload "[ROMPATH]\[ROM].D64" -confirmexit -fullscreen "[ROM]" Now I realize you said each game has to use a different command line string...but do you really need seperate strings? Basically meaning will the emu shit its self if you pass it a bogus option...like for a file that doesn't exist? I'd personally try making a generic command line string and see about finding out if it'll break the emu or not before getting carried way with a bunch of strings..or batchs. My thoughts...

Heh sweet your found the thread. I couldn't find it for the life of me.