skizzosjt

technically they could have added the folder to import instead because it does search subfolders. I've done it for bin/cue files which were in individual game folders.....downside is it will list all the bin files too so you gotta delete all them out of the import list first. for ex add a Playstaion folder to import. now it will import all the folders in there which are individual game folders with bin/cue files in them, it would add all files present to the import list. so in the end, each method has a little bit of manual tinkering. doing it this way would also mean you lose specific entry data, such as number of plays and playtime, date added etc sort of stuff since they would be reset from deleting and reimporting them

I looked at what that parameter does, and....I've never used the software stuff either, so I'm really only familiar with the sort of arcade use of MAME. taking a stab in the dark I could guess it is a good idea to enable it for computer systems. like it sort of changes how the computers "emulated keyboard" receives inputs, whether it goes to the "emulated keyboard" (would send the inputs to the emulated Apple II system) or to MAME (also sends inputs to the emulator, in order to use the menu/UI). so maybe when you hit TAB without that parameter it's being sent to the emulated keyboard instead of MAME to activate the menu.......just thinking out loud here lol so I don't know how to help further, but I think that might offer an explanation on what is going on. I do think HeadRush69 is correct too since that was what I meant, you could not use that parameter in Retroarch because you're mixing up program A's parameters (MAME) by trying to using them in program B (Retroarch), you would instead need to place those option values into the appropriate ini here's a bit from the MAME docs

even if running a MAME core in Retroarch you can still access the MAME menu with TAB which is the default button, or use the button you have alternatively assigned to bring up the MAME menu if you changed it. so if it works in standalone MAME, by theory you should have no problem doing the same with the MAME Retroarch core Retroarch menu comes up with a F1 key press by default Since those are MAME parameters they will not work with Retroarch. You will always get an error trying to do something like that.

A bezel for MAME is more than just an image file, it also requires a layfile and (just repeating what c-beats mentioned) it is the syntax of the layfile that is deprecated and therefore giving you the error. Read up on this here for understanding and adjusting your current (but deprecated) layfiles.

you could open the platform's xml file and do a find and replace on the directory path. It's the <ApplicationPath> tag. If you do this, back up the file first.

glad I stumbled onto this thread! that is a good piece of info to know, now it opens up more possibilities to mod an existing non-CTC made theme without having to recreate the whole thing in CTC!

hmmm ok trying to consider this from a dev point of view....if you have a main config that has setting ABC in it and load up a game that has custom override setting XYZ....now these XYZ settings are loaded......now you save the main config which means it takes all those XYZ custom override settings and overwrites the ABC settings in the main config.....which is surely not what any user would want. you just over wrote your default/global settings with customized ones!.....it's a total guess but that is my thought process on it

All my testing was done with Retroarch instances I manually downloaded and unpacked myself, no LB automation involved. My assumption is there would be no difference with what gets automated within the frontend or else it would more or less be a fork of Retroarch. I assume the frontend downloads it from the same source anyone going to their website would, so it's still the exact same emulator, same files and all that in the end....at least that's my assumption lol So I'm thinking LB needs to be taken out of the equation based on my troubleshooting. It's a Retroarch issue, rather than a LB + Retroarch issue in my opinion And yes I agree the implementation is not ideal, there are shit ton of forum threads out there discussing this, but only that one github page did I find anyone who appears to be a dev on the program to provide a real technical answer. We are all clearly not the first to be confused by this, but at the same time, I think it makes sense from developer point of view, they are trying to prevent settings from unintentionally being overwritten or corrupted I think. On the other hand.....I'm sure there is some way to prevent whatever issue they did this for, while not confusing the user. To me, a simple change of the error message would be sufficient. If it detects an override is active, then the pop up on the OSD notification should be "Override currently detected - configuration will not be saved. Please remove override in order to save configuration or alternatively utilize the core, directory, or game overrides" The current one is super misleading, as I too would have immediately assumed it was a permissions issue if others weren't already sharing that didn't help them out

@Hamburglin @vaderag I can recreate this error. At first I thought it was related to whether or not a game was running. In my "main" Retroarch instance that is used in LB/BB, if I am running a game and try to save the main config in Main Menu > Configuration File > Save Current Configuration this error happens every, damn, time! But if you try to save the config when NOT running a game, it works fine! This happens whether Retroarch is launched "normal" in Windows or from LB or BB. My Retroarch version is 1.9.3. So this suggests it has nothing to do with LB/BB, I can recreate the problem when LB/BB isn't even opened. However I also have another version of Retroarch I setup to do some testing/troubleshooting on at one point. This is version 1.10.3 and this issue is NOT present on that version.....that is.....until I load up a config/overlay setting for the game being ran! AKA a configuration override! At the very least this is the reason why the issue occurs for me. If there is an "Configuration override loaded" happening at game boot, it doesn't seem to allow me to save the main config when said game is running. I can close this game, and then it allows me to save the config. This behaves like this whether launched from Windows or LB/BB. For me this comes down to settings within Retroarch, and general confusion on how settings interact with each other. Now I'm wondering if this is intentional to prevent settings from being overwritten or potentially corrupted or if it's a legit bug.....so google time...."cannot save retroarch config when override is active" google search got me this answer.....which I now feel like an ass I didn't do this right away instead of spending 30mins dicking around with this lmao! This is intentional! And I quote... when overrides are active you can't save the current config, it is by design so it doesn't get mixed up. Save the core or game override instead or close content https://github.com/libretro/RetroArch/issues/3605 So all this testing in the end does makes sense to me because basically every game that runs on Retroarch in my library has some sort of override so explains why it behaved the way it did in v1.9.3 which is my main install, but behaved different in my troubleshooting install v1.10.3 which is a "fresh" install with no user settings saved. To be clear when I removed the user made custom configs in my main Retroarch 1.9.3 it also worked fine saving the config file. I have no explanation as to why anyone was able to get it to work outside of LB/BB so therefore thought it was LB/BB fault, other than you may have tested it when a game wasn't running, therefore no config override active so the config save goes through fine. If you're still having issues after knowing this info then there must be some more funny business going on in your setup, but I wouldn't know what that is we are on the same page! the overlay configs are a configuration override, which as far as I can tell prevents a user from saving the config while an override is active

I downloaded the latest and greatest update to CTC which is now version 2.5.5 and the above mentioned issue has been resolved. so if you're having this problem with 2.5.0 - 2.5.2 then update CTC and you should be good to go! the wheel's color conditions are behaving as expected now

you will need to add the script as an Additional Application. here's a photo example I've made before. this is in the Edit Game window (right click on a game and then click Edit Game, or select a game and hit Ctrl+E).

yes, AHK can manipulate folders. I'll transpose my previous example to use FileCopyDir. This does the same thing but with folders instead ;at boot of game copy the game specific save folder to normal/shared location with normal/shared name ;1st parameter = source / 2nd parameter = destination / 3rd parameter = overwrite (1 = will overwrite / 0 = will not overwrite) FileCopyDir, C:\Users\*USER-NAME*\Documents\My Games\Transformers\TransGame\*GAME SPECFIC SAVE FOLDER*, C:\Users\*USER-NAME*\Documents\My Games\Transformers\TransGame\SaveData, 1 ;Waits for game to exist WinWait, *GAME EXE NAME*.exe ;Waits for game to exit WinWaitClose, *GAME EXE NAME*.exe ;Pauses script to ensure enough time has passed for the save file to be written prior to copying it Sleep, 5000 ;will take the save folder in the normal/shared location that was made at exit of current game session and overwrite the game specific save folder ;1st parameter = source / 2nd parameter = destination / 3rd parameter = overwrite (1 = will overwrite / 0 = will not overwrite) FileCopyDir, C:\Users\*USER-NAME*\Documents\My Games\Transformers\TransGame\SaveData, C:\Users\*USER-NAME*\Documents\My Games\Transformers\TransGame\*GAME SPECFIC SAVE FOLDER*, 1 this is just an example since you will need to fill in the * marked stuff. when all is said and done, in the "TransGame" folder you will now for ex have three folders 1) SaveData 2) TWFC Saves 3) TFOC Saves if you want to learn, doing something basic like copying a folder or file around would be an excellent first training mission for you! here's these commands doc pages for reference. I do think It's better to teach a man to fish rather than to give a man a fish as the saying goes https://www.autohotkey.com/docs/v1/lib/FileCopy.htm https://www.autohotkey.com/docs/v1/lib/FileCopyDir.htm Check this out https://www.pcgamingwiki.com/wiki/Transformers:_War_for_Cybertron https://www.pcgamingwiki.com/wiki/Transformers:_Fall_of_Cybertron According to PCGamingWiki this suggests you would also have a problem with the "configuration file" being overwritten by each game because it says they are both in the same location. but maybe both games were developed so similar that whatever data they are after in the config file is the same. nothing to worry about since you haven't noticed a problem, just thought it's funny they did the same mistake to more files. also according to their database the save file(s) are in a folder called "SaveData" with the full path being %USERPROFILE%\Documents\My Games\Transformers\TransGame\SaveData. the script I shared here uses this directory path since I'm assuming you just accidentally left off the SaveData part

"could not recognize file" is the culprit here .7z file format is a compressed format that Dolphin doesn't work with. I recommend you unpack that .7z file and use whatever is in it in it's uncompressed format (likely is an .iso file). should work fine like that!

this sounds like it's the users internet connection. I'm on slow internet and downloading stuff directly from Big Box is a hit or miss for me as a result. gets stuck at XX% or like what you're describing will time out on the Please Wait text to generate the list. the problem has nothing to do with a Windows version or whether it is up to date. I prefer to download directly from the forum when possible I realized this when I tried reaching this page when not connected to the internet...then I thought why would it be implemented like this.....many users purposely disconnect their cabs from the internet. so to prevent a user from using one of the most basic and sought after features, using and changing themes, due to not being connected to the internet would be a bad idea all around. you don't need to go to the manage page to just select which one you want to use. though you can do it that way, it doesn't seem to be that pages main purpose the Manage Theme/Pause Theme/Startup Theme pages are for managing theme within the frontend. ie install, update, or uninstall if you want to switch themes whether the main theme, pause theme, or startup theme you can do that easier from another page that doesn't require an internet connection Main theme = Options > Views > Theme Startup theme = Options > Game Startup > Startup Theme Pause theme = Options > Game Pause > Pause Theme

you can "bulk edit" multiple games at once. select two or more games and then either right click on one of the selected games and then choose edit, or you can hit the edit hotkey which is Ctrl+E. then select the "Broken" field and then change the checkmark depending on whether you're marking them broken or not broken also there is a way to hide or show games marked as broken. in LaunchBox go to the toolbar View > Hide Games > Marked Broken this setting will toggle on/off when selected and it's hotkey is Ctrl+Alt+R alternatively you can audit a platform or all your games and in this list that is generated it will tell you which games are marked as broken. from what I can tell this column doesn't appear if every game you selected for the audit is marked as not broken. so if you do not see it at all it implies all games for that audit are not broken

it's on the left hand side after you go into editing a game entry. here's a photo for reference this was from another post I made so in your case if you're setting it up like this you would NOT want to check that box "automatically run before main application" instead fill in that "application path" field with the Dolphin VR emulator and then in the field below it, "application custom command-line parameters", enter in the launch argument to launch the ISO file. assuming that VR version uses the same launching arguments, it would be the same arguments listed in your normal Dolphin emulator here in LaunchBox's Edit Emulator window -b -e "Enter\Full\Path\To\File\In\Quotes\game.iso" and the last bit was saying you can tab over to that "Metadata" tab and enter in the data you want and this way it will list it out as a game version instead of an additional app the other way involves putting an AHK script into the Application Path field but this time checking "Automatically run before main application", it would look just like the photo example since in that I am doing just that, launching a script at start of a game to remap some controls. the script would be like this for you in order to launch an emulator and game Run, Enter\Full\Path\To\DolphinVREmulator\file.exe -b -e "Enter\full\path\to\game\file\in\quotes\game.iso"

lol oui oui apparently they like American Laser Disc - oh the irony, going to French site for American Laser Disc emulator 🤣 sorry the plan didn't work out this weekend, here's to hoping it comes together next weekend then! 🍻 do let us know how it goes and if you end up needing any more help I'll do what I can for ya!

Hi all Colorful theme users! I am looking for some feedback on using this theme with the new 2.5.X version of CTC, going further, doesn't matter which 2.5.X version whether 2.5, 2.5.1, or 2.5.2 I've noticed since the recent 2.5.X versions that color conditions on the wheel no longer function properly, this impacts view TextGamesView. What this essentially does is not apply the proper dynamic color per the selected item, per what platform it is a part of. *Important to note that I notice all other color conditions work fine still, as in if a background is supposed to be red for Sega Genesis it is, if it's yellow for Game Boy Color, it is yellow. So it seems like color conditions work OK in all situations with exception of this one element in this one view* (there could be more issues but this is all I know for certain) This problem is not found if using CTC version 2.3 and I can load up version 2.3, publish the theme, and the color conditions work appropriately. I'm literally copy/pasting the themes folder into the newer CTC versions as normal but the same settings don't seem to work on 2.5.X and why I'm asking for feedback is I cannot get it working even taking other methods I decided to test by putting in a new text box, in which it has text that displays the Game Platform metadata. So "Sega Genesis" when said platform or game from said platform is selected. I then made the color condition to use the newly created element I appropriately named "Platform Text" and if that text box has text in it that says "Sega Genesis" then be red ...etc etc....this is weird because THIS works....BUT....ONLY in CTC is the color condition now working with such a method. When I publish the theme and boot into Big Box it's like the color condition doesn't exist and only uses the foreground color for the selected item. I am using the normally assigned Colorful_ListBoxStyle style source. I have not altered it either since I never worked with XML. Though the problem seems to be the same on any of the presets or other styles available in the drop down Any feedback and/or help to get this ironed out is appreciated! Came here first to get input to see if it's theme specific before I would bring it to y2guru's attention if it ends up being something that appears like it's CTC specific. Thanks for reading! Normal method and using the normal conditions profile (or any profile really) doesn't work in CTC or in BB Using my funny method of making a separate text box with the game platform in it (populated through Game Platform metadata) only works in CTC, but if I publish this, in BB it will still look like the above photo where all selected text is black

well that is some of the worst file management I've ever heard of from so called professionals 🤦‍♂️. you can use a script to move/copy the file(s) around as needed to keep things sorted for yourself. Lets consider the structure of what you need done here. I'll call them game A and game B for the ex. When game A boots it first needs to look for a game A specific save file. It will take this game A save file and copy it to the normal save file location with the normal file name. Now the game uses this game A save file that was placed in the normal location and you play the game. After exiting the game the save file that was just created in the normal save file location must be copied to overwrite the previous game A specific save file. Rinse and repeat each time this game is launched. Then change things accordingly for game B and you're done I assumed for the example here that the save file is called savefile.dat and recommend keeping these files in the normal save location. change out the save file and game exe as needed. You will need a separate script for each game. Please note this script needs to run before the main application since you need to make sure the game specific save file is copied to the normal save file location prior to the game booting. This script also requires you have already created the game specific save files manually prior to first using it. in the end this means you will have three save files in the same folder: normal save file, game A specific save file, and game B specific save file. they all get copied and overwritten as needed per the scripts. I have that sleep bit in there because who knows when the game is actually writing the save file, if anything waits until the game exits it needs a brief moment to finish making the write. so this may not be needed, but it's there out of an abundance of caution ;will copy the game specific save file to normal save file location with normal/shared file name ;1 value = the file will be overwritten if it already exists FileCopy, C:\Users\GamerPC\Documents\My Games\Transformers\TransGame\TWFCsavefile.dat, C:\Users\GamerPC\Documents\My Games\Transformers\TransGame\savefile.dat, 1 ;Waits for game to exist - insert game's exe file name WinWait, TWFC.exe ;Waits for game to exit - insert game's exe file name WinWaitClose, TWFC.exe ;Pauses script to ensure enough time has passed for the save file to be written prior to copying it Sleep, 5000 ;will take the game save that was made at exit of current session and overwrite the specific game A or game B save file ;1 value = the file will be overwritten if it already exists FileCopy, C:\Users\GamerPC\Documents\My Games\Transformers\TransGame\savefile.dat, C:\Users\GamerPC\Documents\My Games\Transformers\TransGame\TWFCsavefile.dat, 1

it is possible! there are potentially two ways I can think how to do this. how I would do this is leave the regular Gamecube version as is and do the special stuff with the VR version. One method would require to go into edit the game entry and create an additional app and tell it to use custom settings. Make the application path the VR version of Dolphin for the emulator, and in the custom command-line parameters field add in all the arguments you need to launch the iso file. another way is you will need to create an additional app that runs a script to launch the game. the script will just be a basic line of telling Dolphin VR to run and load the game. for either method, assuming the VR version uses same launch syntax you can take a peek at how it looks on the normal Dolphin's Edit Emulator window and use that same format for launching it on the VR emulator. also you can call the additional app a game version by putting in data into the metadata tab which will list it as a version of the game instead of an additional app. this way when you right click on it in LB or go into the game details page in BB you can select which version to play

yea you're catching on that you're in the wrong spot. where you listed does indeed change stuff for LB. you need to be in Retroarch to make changes to the controls in the emulator. Global inputs are Main Menu > Settings > Input > Port X (X being the player #) or once a game is booted Quick Menu > Controls > Port X (X being the player #) which are used to specify things per core, directory, or game physical controller is represented on the left, the virtual controller is represented on the right not 100% sure what is going on because as far as I know controllers don't behave different due to if they are connected to a system over bluetooth or a USB cable. so this really doesn't make sense that you state it works with Steam games over both, but only works with Retroarch over a USB cable. if you setup bezels in Retroarch that could explain the custom config message since that makes a config for every game that has a bezel. The config details game ABC needs to use overlay file ABC. wouldn't want to delete that or the bezel wouldn't work anymore. otherwise you likely saved an override at some point in time. hopefully the solution for you is just reassigning the controller properly but I'm skeptical there isn't some other issue going on

Rather be lucky than good lol! any chance you and/or your buddy got this straightened out or are you having problems with T2 now much like how it was giving you problems with Area 51? Essentially all MAME lightgun games I've setup require the same rinse and repeat process so that's odd if you're going about it the same way but not having any luck. you don't need any special devices for T2. I believe it's controls are listed a little different in MAME because it used different tech in the arcade. but in the world of emulating it's the same setup process as you did before. T2 wasn't really "lightgun" in the traditional sense of actually using light/photo sensing. it used potentiometers and is the main reason why those guns were in a stationary position sort of like a swiveling turret rather than being capable of picked up and waved around like say Time Crisis and The House of the Dead. it kinda worked the same way that modern analog sticks work with a pot for each axis. voltage A and voltage B = gun is pointing at these coordinates on the screen. Since the Arcade1Up cab remake used Sinden tech for the guns those can be picked up and waved around. In the end digital vs analog isn't important here since you can use either type of device, for ex you can use your keyboard for a lightgun if you wanted and a keyboard is digital. What you need likely is just setting up the controls in the "this machine" page or get the config and/or ini files ironed out whether the old school way or using the AG Softwares MAME utility

awesome thanks for sharing! you have proved the arcade gun software has the Utility tab that can handle the device and button remapping! which is neat feature....but NOW I'm no longer confused wondering how you got it working without necessarily following the traditional process. basically that is a integrated GUI to create (or edit) the .cfg and .ini files through getting the data from the verbose output and places them in the right folders etc. so I've never used it since I set it up the old school way initially so I definitely appreciate you sharing! it's nice to know that feature is there and it still works. I was thinking how do your lightguns still work if you changed the device name by changing the player # but didn't update the ctrlr config with the new device name....that will ALWAYS break devices from being mapped right. so now I must admit that arcade gun software does make that easier for the user in this regard - less setup time!

Configuration override loaded? That is a message from Retroarch rather than LaunchBox are you sure the controller even works wirelessly? unless you know for certain it does you need to prove that it works over bluetooth, use gamepad-tester.com and make sure that site recognizes it. if it works OK there, then you know the problem is with Retroarch and whatever custom settings you saved. you could try deleting the custom config, but since we have no idea what type of config override you made, who knows which folder it is in other than it will be in Retroarch\config. Also who knows what settings it's actually overriding....kinda complicating giving any good help. From what I can tell you might be able to delete them under manage core options in the UI if it's a .opt file....but I think the "Configuration" term would mean it's a .cfg file. the config might just be for bezels even meaning you might NOT want to delete it and you just happen to have a problem with how the inputs/controller are configured. as in you might just need to reassign which controller button aligns with which emulated button.

instructions are good, as the saying goes "RTFM" 🤣! I think what it does is enable/disable some of the "bulbs" so the area it projects in is either bigger/smaller. I too didn't notice it works better/worse, just seems to change the area/distance you can stand away from the display. so if you're in the right area that works for both, say maybe only 4ft away it would perform the same with the switch in either spot. but if you're OK with the extreme setting say standing 10ft away, if you then switch back to standard and try 10ft away it might perform crappy because it's too far away for that setting. So cool I think that sounds just like my experience with it! Yes I did catch that about the software. I'm not 100% sure I understand what you mean about changing their numbering and they still worked, you'll have to clarify for me please. For ex you setup your guns as P1 and P2 in the arcade guns software and got everything working OK in MAME. You then close MAME, open the arcade gun software, changed your guns from P1 and P2 to now P3 and P4.....and then booted back into MAME and the game worked fine with the lightguns?