nullPointer

Hi smd111! First let me say thanks for using SwitchDisc! Based on your message it sounds like most everything is working except for sending the ESC key to ePSXe. Does that sound correct? I’ll have the opportunity to investigate this specific issue later this evening, but I may be able to put you on the right track via alternate means. I see that you’re sending the ESC key in your Keys Before GUI setting. Are you using this as a means of exiting the ePSXe? If so, you might try using the TASK KILL operation instead (It’s in the Special Operations section of the Send Key Builder). That should kill ePSXe deader than dead with no other keys or settings necessary If you’d like to be a bit more graceful about it, you could also use send keys to navigate the ePSXe menu and exit that way. This would be something along the lines of (Alt+Enter, Alt+F, {NAVIGATE TO EXIT ON THE MENU}, Enter), where you would replace {NAVIGATE TO EXIT ON THE MENU} with the appropriate combination of arrows, etc. The above suggestions should provide a couple of workarounds to experiment with. In the meantime I’ll look into the issue with sending ESC to ePSXe. If it appears in the log, Switchdisc is making an attempt to send the ESC key to the emulator. It may be that ePSXe isn’t recognizing the virtual key as being valid. I’ve had one other report of problems with the ESC key in combination with Switchdisc, so it may be a SD issue as well. I’ll report back as I gather more info there. TBH I’ve been absolutely swamped with work lately so I haven’t had much of an opportunity to work on SD. I’ll try to make some time somewhere though! Oh hey there's one other thing. It’s probably unrelated to the problem reported, but I would recommend against using ESC as both the SwtichDisc trigger key and as part of a Send Key operation. Actually I’d recommend against duplicating the trigger key within any Send Key operation (regardless of what the trigger key is). The problem here is that the SwitchDisc trigger is registered as a ‘global’ hot key while SwitchDisc is running. That means anytime that key is used (regardless of whether it happens during a Send Key operation) it’s going to be read as the SwitchDisc trigger. In effect, SD will attempt to ‘trigger’ itself even though it’s already been ‘triggered’. Thanks again!

Works brilliantly on my Samsung Galaxy Tab 2! Thanks again.

Excellent! I'm going to check this out right now. Thanks Tom! Adultery's going to be pumped!

Taken from the GameEx F.A.Q.: So you're halfway there. You moved your GameEx installation directory to the new machine, but you still need to install GameEx over the top of wherever you copied the installation directory to. Hopefully that should get you going on the right track. If not please post a copy of your log and GameEx.ini for the GameEx installation on the problematic machine (I know - we start to sound like a broken record after a while right? ) Thanks man!

Sounds like this upgrade will help make the forum better than ever. I see improvements in there for all levels of forum membership - users, mods, and admins alike. I’m looking forward to the upgrade. Thanks Tom!

Wow! This is an awesome update! Thanks so much Tom!

That’s a bit of a toughie ceedub. It would be beneficial to see how you’ve currently got GameEx configured in order to help you troubleshoot this issue. This may be something that’s related to a configuration setting (or it may not). Would you mind posting a copy of your GameEx config as well as a copy of your log after having experienced the issue? Here are some instructions on how do that if you’ve never done so before. Thank you sir!

This may indeed be an issue with your version of MAME. It seems that MAME 0.147 has issues with Mortal Kombat as well as a number of other Midway ROMs. I’m not entirely sure how deep that issue goes, but there may be other affected ROMs as well. Apparently updating to 0.147u2 will fix many of these issues, but I prefer to stick to the full release schedule (even if it means that I’m a few versions behind) It may also be an issue with your ROMS and/or CHDs. Remember that both your ROMs and your CHDs must match up with the version of MAME you’re running. The issue with CHD versioning can creep up on you since CHDs are not updated very often. Here’s a bit of information on how to verify your CHD files and update them if necessary: unsupported .chd version please help me Re: Quick CHD Mame Version question So glad to hear about the progress on your cab BTW!

Glad to hear everything worked out for you ProCon! Don’t feel bad about the oversight. It can be easy to fall behind a couple versions in GameEx. Tom is constantly enhancing and improving GameEx to be the best darn frontend out there. That’s why he’s the Hardest Working Man in Emulation™!

Wow, a top most window logger would be awesome! I've had issues with SwitchDisc determining which window is (or should be) set as topmost and when.

It looks like you’re running a very outdated version of GameEx. In order to help you effectively troubleshoot your issue I would request that you upgrade to the most recent version of GameEx (currently version 12.91). The problem you’re experiencing may have already been addressed and fixed in a more recent version of GameEx. It will be extremely difficult to track down the root cause of your issue if it’s already been corrected in the current version of GameEx. Thank you!

Awesome! So glad to hear you got it all sorted out gamepimp. It sounds like you've got a method to get the Download Service to cooperate with your UME sets, and that your PC Engine games are running satisfactorily. I'm going to mark this one as resolved.

I gotta tell ya, that’s not a terrible lot of information to work with. In order to effectively work through some troblehooting steps we’ll need a bit more information from you. Let’s start with providing a copy of your GameEx config and your log (after having experienced the problem). Please refer to this thread if you are unsure of how to access that information. In addition to the above steps providing answers to the following questions will be immensely beneficial to help us determine what’s happening here: Do your controller problems occur within the GameEx interface or only when in game? If your controller problems are occurring in game, what game or emulator are we talking about? Are you using any controller mapping software (i.e. Xpadder, Joy2Key, etc.)? Are you using a control panel with a keyboard encoder of some sort (i.e. IPAC, KeyWiz, etc.)? What controller are you using? Thanks nestlund! The above information will help us to get the ball rolling to help you resolve your problem.

Awesome! Glad to hear you got this sorted out John10583! Welcome to the GameEx forums by the way! I don't know why I didn't think to suggest this when I originally saw your post. Headkaze (the author of WinUAE Loader) is one of our forum admins, and a regular around these parts. Glad you got it sussed! Nicely done.

Hmm ... someone with more experience using UME may have to step in here. Does UME require that games are unzipped prior to loading or does it support running zipped ROMS? If it supports the use of zipped ROMs, then you may want to change this setting: emu_3_gamesin7zips=True Are your ROMs stored with a bunch of individual ROMs in one zip, or does each zip only contain one ROM? That may also have some bearing on the above suggestion.

Happy Birthday celly! Thanks for giving us the opportunity to celebrate your birthday! I hope it's not a turkey! Uh ... hello ... is this thing on? Dangit ... where's Draco when I need him, what with his charming witticisms and heartfelt sentiments!? OK, how's this - I yam wishing you a very happy birthday! No? Well I hope everybody's been stuffing your presents with cool swag!? Ah screw it. Happy Birthday celly! Thanks for being such a great member of the community. Here's wishing you many more excellent birthdays to come!

Thanks ProCon! That does provide some very good information for troubleshooting purposes. Hey one other thing - would you mind attempting to run one of the non-existent ROMs (one that you know is not part of your collection), and post your runitgame.bat after having done so? I'm curious to see what happens there. Additionally it might be helpful to follow step 4B in the How to Ask For Help and follow these instructions to view the console output (this may provide a helpful error message): Thanks ProCon!

Please provide a copy of your GameEx.ini (and possibly a copy of your log). That will be the best means of determining what's going on with your setup. Here's a primer on how to retrieve that information if you are unsure of how to do so. Thanks!

Having a look at your emulator config would help to determine the exact adjustment that needs to be made, but GameEx does have functionality to pass the ROM name minus extension. [ROMFILE] will pass the the full ROM file name with extension [ROM] will pass the ROM name without the file extension. See how that goes for you. If that doesn't work please provide a copy of your emulator config and your runitgame.bat (maybe your log too, but these first two items should be enough to go on).

Glad it worked out for you man! Emulator groups are awesome. I use them for N64 and PlayStation where different emulators have varying levels of compatibility depending on the game. GameEx FTW!

Howdy Felix! As always, thanks for your feedback! As I compile a list of ‘recommended function keys’ for SwitchDisc, I’ll most likely make a note to advise against the use of ESC for the purpose of SD functions. It’s just such a widely used key in various emulators and frontends that there’s a good chance it will cause unpredictable behavior. I see where you’re going though. The Task Killer operation would certainly do the trick as far as killing the underlying emulator, but currently there’s no mechanism which would trigger the operation under this circumstance (it currently operates as a dedicated special send keys function). It may be that I need to assign a new dedicated ‘Kill ‘Em All’ key which would kill SwitchDisc and the underlying emulator. I have noticed instances where ePSXe remains resident in memory despite having seemingly closed (I believe this relates to the memory leak issue you describe below). As near as I can tell it’s a bug in ePSXe, so the best I can offer is a workaround. The wrapper has functionality to kill all running instances of ePSXe which may help in this capacity (I have been unable to reliably reproduce the issue, but I’ll attempt to duplicate the steps you describe above). It’s worth a shot any way. Here’s that command: ePSXecutor_wrapper.exe –q Good point. It would probably be better to simply log this error rather than spitting out an error message. I’ll probably go that route for a future release, meaning that SwitchDisc will simply take no action under this circumstance (it will appear to do nothing). I don’t know that I have a really clean answer for you on this one. Unfortunately it can get a bit ugly when you need to run multiple processes as part of the Launch Before parameter. I do have some plans for SwitchDisc in this regard, but not in the immediate future. I’ve been a bit leery to make SwitchDisc into an outright launcher, but I suppose it’s half-way there already by definition of what it does. If you can hold out for a while I might have an integrated SwitchDisc solution for this issue, otherwise you’re faced with the option of using a batch file as your Launch Before parameter and passing the necessary arguments from GameEx into the batch file. Like I said, it gets ugly. Let me know if you’d like to have another go at that, and we can try to work something out in the meantime. That’s good news about the wrapper. I’ve been unable to recreate the issue, but that doesn’t mean it’s not hiding in there somewhere. I have absolutely seen ePSXe continue to run resident in memory after apparently closing. Like you I’m not exactly sure what triggers it, but I notice it more often when I’ve been starting and stopping ePSXe a number of times in succession. Something to be aware of. I have been tooling around with ePSXe 1.8 and so far it seems to be a great piece of kit. I’m specifically hoping that the issue described above has been resolved, but this release still acts wonky when you attempt to close ePSXe using the X button, so I’m not getting my hopes up. I’ve recorded a few more thoughts on this release right here.

Waddup Felix I’m afraid I don’t have a lot of personal experience to share regarding MUGEN. I’ve used it (putting Rorschach into a fighting game was just too good to pass up), but it’s been forever and a day since I did anything with it. I believe that Elecbyte’s site is still the main base of operations for MUGEN software (someone please correct me if I’m wrong). It certainly was back in the day (Elecbyte was the original developer of MUGEN). That would be a good place to start. Finding pre-made set is definitely the way to go, particularly if you find ones that maintain a consistent look and feel in terms of characters, backgrounds, animations, and resolutions (this last one is huge). The sets I have tend to be small focused sets (although as I mentioned I haven’t even opened up MUGEN for a very long time). Sets that include EVERYTHING! OMG!! LOLZORZ!!! tend to be a hot mess as far as I’m concerned. It seems like it would be awesome but tends to be an unwieldy disaster in terms of execution (IMO). Having said that, finding pre-made sets can be a bit tricky depending on where you look. As you probably know the MUGEN eco-system tends to be divided into rather insular communities and release groups. It’s a bit of a tough nut to crack, and (in my experience) not particularly noob friendly depending on where you look. I’d start with some of the better known release groups to see what you can find (Mugen Fighters Guild, Infinity Mugen Team and Mugen Infantry are some of the big ones). If that turned up a blank I’d go off the beaten path and take a look at the untraveled ground.

Any reason you couldn't simply configure this as two (or possibly 3) separate emulator slots? Going that route you would simply separate the disc images associated with each emulator slot into separate directories. Here's the way I see this going (where each bullet is a separate emulator slot): Wii Slot #1 - points at a directory containing only those disc images associated with Wii slot # 1 Wii Slot #2 - points at a directory containing only those disc images associated with Wii slot #2 Gamecube slot - self expanitory Once you get the above all set up you can use the Emulator Group feature to combine slots #1 and #2 (the Wii slots) into a single game list. You shouldn't have to modify DB settings at all for this as the databases only contain metadata related to individual games, not how they are grouped in GameEx.

This is absolutely awesome Tom! In light of this fantastic deal, may I be the first to say Hail Britannia!

Happy Thanksgiving to all my friends at GameEx. I truly am thankful to be a part of such a cool community. I'm extremely thankful for my wife Roxy, whose patience and kindness are beyond my comprehension, and for my kids who help me to laugh everyday.