Adultery

I'm happy to answer any questions you have... Your first plugin is always the toughest. I got your back. So where are ya stumped? Creating the table or reading the data from it? Smart code is efficient code. If you start using best practices and do a little research first, you'll thank yourself when it's time to add new features. Game Info is a good example... It started as iMagic and that was OK, but inefficient and super sloppy. Then I rebuilt it entirely and Game Info was born. Then three years later, I completely overhauled the code again. Now it's in a place where I know exactly what each class does or where exactly a bug that comes up might be living. You'll miss the mark here and there the first few times, it's part of learning. Start with an easy project as a test. Then add some stuff to it. Then apply what you've learned in the project you really want to do. If you're anything like me, you'll learn best by doing it as opposed to reading about it.

...and so it begins. Good luck in there!

Did you check the wiki? There are specific requirements. http://www.gameex.info/wiki/index.php/Category%3APlugIn_Development#PlugIn_Development_Overview Also, are you using VS Express? You can also send me your code add I can look at it, I'm sure it's a setting in the compiler you missed.

The short answer is to build the DLL and then copy it to the GameEx > Plugins folder and enable it in the plugin repository. Then run the GameEx EXE manually. There are other ways but it's complicated and you can't set external EXEs if you use Express. What I do is set up a dev GameEx installation on the server and set the debug build path to that installation's GameEx > Plugins folder. Then I make sure it's enabled and run the EXE after I build it. This way I can use different locations to dev (I bounce between a laptop and a PC a lot) and you don't need to install GameEx everywhere. On top of that, my cab always only uses stable builds.

Hey stigzler! So I just spent 25 minutes writing a response to this post and accidentally navigated away from the page and lost it. So this will be more of the abridged version. You should probably know first off that I do a lot of things through my own code base that the PlugIn system doesn't do on it's own. I'm going to look to your utilization of QuickLaunch for my example so that you'll know straght out what you're getting into: Any emulator data you use is my own code (ie additional artwork paths, MAME marquees, databases, etc) What I do in code is load all the emulators at the plugin startup in a DataSet and load the needed table when the emulator number changes. Then I hold that data in another class for future use, or until the emulator number changes.All configuration forms that populate emu names, numbers, file paths/file names, etc ComboBoxes and include/exclude lists, INI paths, ROM filters, EXE paths, etc are all built and retained throughout the configurations by me in a class. GameEx will not give you this data on its own.Extended ROM variables As is the case with emulator data, I will typically parse the emulator table and set my own variables for many of GameEx's game paths, like the custom artwork paths, MAME icons, MAME marquees, cabinet/cartridge/disc art, etc. If you don't see a variable for it in GameEx's enum within the plugin, you need to write code for it.It might seem like a lot of work, but I link my classes that I use often so that I can update them for one plugin and the change will apply for all of them. I learned early it's much easier to build a repo to pull from instead of trying to maintain the code in 10 different places. After all, many plugins will use the same functions and subs over and over again. So enough babbling, let me answer these questions: I think you're confusing console apps with dll libraries. The DLL will process code when GameEx tells it to, there really isn't a 'handle' per se. So try to think of events as if they were handles: When a game is run, GameEx passes through the Event_GameRun function in the same way you might attach a function to a FormClosing handle that will trigger when the form closes. You would then run your code based on what GameEx is doing in the appropriate sub/function. So for example: User selects an emulator and the game list comes up (Event_EmuSelect is called)This is where I will run a sub that grabs the emulator table from the DataSet and holds the variables for later useIn GameInfo I will also grab the emulator icon and show it on the secondary monitorUser selects a game in the list and presses the button to view the game info screen (Event_GameShowInfo is called)This is where I get the variables for the game from the IntPtr and store them in another class. You can use GameEx's enum obviously, but I prefer to grab this info and hold it myself.This is also where the GameInfo.Description contains the Game Bio from the database.User presses the button to launch the game (Event_GameRun function is called)Here I will verify that the data is the same in the external class I hold Game Info variablesThis is also where GameInfo.Description contains the ROM File with extension (RomName.iso or whatever)This would also be where you would execute a LaunchBefore commandThe command line is built and the emulator is launched (Event_CommandLine is called)This is where I will do command line manipulationFor example, Virtual Drive Loader will look for the [DTools] flag, run the code to mount the ISO, remove the variable via RegEx and return the command line to GameExThis would also be where you would execute an AlsoLaunch commandUser plays for a while and exits the game (Event_GameExit is called)This is where I will do any post-processingFor example, if Virtual Drive Loader has an ISO mounted, I will run the un-mount command hereThis would also be where you would execute a LaunchAfter commandYou get the idea. As I stated above, I will take the raw DirectCast of the IntPtr data and store it in my own class. There are examples in the wiki that nullPointer linked to above that outline how to keep that data inside the GameEx.PlugIn code, I just don't do it this way because I prefer to do as little as possible in that code section. So for example, I will pass the IntPtr to my own class: Public Function Event_CommandLine(ByVal InfoPtr As IntPtr) As String Dim GameEx_Info as New DracLabs.GameEx_Game() Dim Plugin_Work as New DracLabs.VDLoader() GameEx_Info.SetCmdLine(InfoPtr) Return Plugin_Work.CommandLine() End Function Obviously in this case I take the Command Line from my own structure I have set up elsewhere since I know where to get that info and I wouldn't need to pass it in. In this case, that function will take the command line, strip the variables from it, and return it to GameEx. My own SetCmdLine() sub will also look for and replace any GameEx variables that are there (for example, ssf.exe "[RomPath]\[RomFile]" will automatically replace my internally stored command line with the standard GameEx variable data and pass it back without the substitution since GameEx will do that itself later. So I will hold ssf.exe "C:\Games\CoolRom.iso" but return ssf.exe "[RomPath]\[RomFile]" just like I found it. Simple right? Well that kind of depends on you. As I mentioned I will write as little code as possible in the GameEx.PlugIn section. I would rather keep my code in my own structure. But that's me. You can really kind of do whatever you feel comfortable with. Most of my projects are organized within their own sets. So my PlugIn initialization work might be in one folder, my display forms in another folder, my configuration forms in still another folder... I like manageable code so I feel like everything should be under 50 lines or it needs to go into another block. For example, my PlugIn Init block will get called from GameEx.PlugIn and then that function will be ~38 lines and call some additional subs/functions for things like initializing the XML, validate user accounts, start the logger, etc. GameEx.PlugIn > DracLabs.PlugIn.Initialize >> DracLabs.XML.Load(XML_Path) >> DracLabs.Logger.Init(PlugInName, PlugInVersion) >> DracLabs.GameEx.UserVerify(UserName, PassWd) >> etc. I don't mind the questions, please feel free to ask. Some things are better explained through trial and error, but I will still try and help where I can. Just be advised it's a lot more work than it looks like, depending of course on what you want to do. There is a Source Code archive in the GameEx > PlugIns folder that Tom includes with the code for the Play Arcade Sound plugin, but that's pretty basic and might not be as helpful as you're looking for. This is really gonna require more of a knowledge of how DLLs work and best practices for well organized code. Unfortunately most everything I write is heavily personalized so I don't really have any SC that I would be able to share. I really should write something to give out that has some code examples in it or finish the wiki one of these days... But, ya know, work and real life.

We appreciate the kind words, and thanks for giving it a chance! Rave reviews like this really make the hard work pay off in a big way. Welcome to the community!

I'll have a new version for you to test with by then, and at the very least we can get some additional logging going.

Where's your runitgame.bat ?

Nope they both do the same thing. Your bat file shows an mds file which is why I asked.

Just out of curiosity does DT support Alcohol images? I'm not sure because mine are all iso.

You should not have any settings at all for this emulator in the plugin config. You're sending outdated arguments to it. Please delete the settings xml in the plugin directory entirely and run GameEx again. The plugin will act accordingly without a need to specify anything at all in the settings. I'll look at the bug here where it's putting an unmount command in there for both args erroneously (it shouldn't do that) but you can safely delete that file. You won't need it. It should detect your DTools version and run DTAgent.exe instead (I probably need to update the last mount bat to reflect that). But I'm sure it's not mounting at all because it's trying to send -mount 0 instead. Again that might just be the bat file is wrong. It's working for me with other systems. Also, make sure you tell SSF which drive is your virtual drive with an ISO already loaded. DT now creates the drive only when you load a disc, and that might be causing your drive letter to change if you have anything else taking over the drive letter like a USB drive or something.

It probably does work, but you need to point GameEx at MAME, not MAME Mapping Magician as he said or it won't parse the roms correctly. The drive doesn't matter, neither do the paths as long as they're configured properly. It takes a few minutes at best.

Hmm.. Let me check out the code and see if anything sticks out. I'll probably add more debugging as well. If you press the button in the plugin config does DAEMON Tools launch the loader screen? It's the one that looks like a command prompt icon. Also try changing the emu command from [DTools] to [DTLoader], and if possible, take a snap of the files in the DAEMON Tools install directory?

Hi, you are aware that GameEx doesn't come with the games right? You need to supply the roms and emulators on your own.

The shitty part is that I paid for this app. And no Tom, I don't think you can turn it off.

Also, can you verify that DAEMON Tools is actually installed in that directory? I wonder if perhaps it's not detecting the install path correctly... If you run a 64-bit machine the install location has changed to Program Files instead of Program Files (x86). Could be a residual from the old version. Really I'm just guessing here until I get the debug log.

They got me on this one!

Can you post your log and settings in the GameEx > Plugins > Xpadder folder? Also please try running it with controller enumeration disabled in the plugin config.

Also you shouldn't need to set any commands in the GUI at all, that may just be a bug in how it displays. I'm not too worried about that at the moment if you didn't put that in there. It's not showing the right commands for DT 10 anyhow, but I'll have to check and see if I can reproduce that here. Also please post the settings.xml file in that same folder for me?

Looks like the plugin is hitting an exception in code. Could you kindly tick 'Debug Mode' box and run it again and then post the plugin log for me?

Maybe your daemon tools needs to be upgraded after all.

Do you have any other emulators that load on a virtual drive? Could you also enable debug mode in the plugin settings and run it again?

As a matter of fact I do. Can you take a snapshot of your 'Setup Plugins' page in the Setup Wizard? If 'Virtual Drive Loader' is not checked here it should be.

Can you all try something? Disable the option where GameEx sleeps in the background (I think it's in the GameEx Online section but I'm not sure and I can't check right now) and restart your computer, then run GameEx again and see if it works.

Well thanks for the info and glad it's working! I have an app that unzips rar, zip and 7-zip and recompresses them to 7-zip which I use to prevent both issues like this and to keep my sets the same. Maybe I should clean it up, add an integrity check and release it. Thanks for the post!