skizzosjt

no, install "A" cannot control install "B" better to make a copy first instead of out right moving. rename the old folder to make sure the new folder works as intended (this makes sure the new folder isn't only working due to using paths that still call to the old folder). then once you're sure the new setup is OK, then you can nuke the old instance anything that doesn't use relative paths will need to be relinked if using a new drive letter. TP uses absolute paths by default. you can edit them manually by opening the game's user profile XML and making the path relative. for ex.. <GamePath>..\..\ROMS\TeknoParrot\The House of the Dead 4\disk0\elf\hod4M.elf</GamePath> if you had them setup like this, and assuming you keep same folder structure, the drive letter can change to anything and it continues to work. if you edit the paths from within TP's UI then it will continue to use absolute paths so if the folder ever moved again, the paths would again need to be updated.

Step 1) Copy Step 2) Paste that's it. don't over think it then that means setting up paths again. keep everything the same if you want it to be a real simple copy and paste job. otherwise you have to spend time relinking all the paths that are broken. make it easy and use the same drive letter, and at the very least, same folder structure. if drive letter changes, anything not using a relative path will be broken and must be relinked. if you change the folder structure at all then basically everything falls apart and must be relinked.

very nice! if you want to get into details then you should read up on the docs. here is the override page link https://docs.libretro.com/guides/overrides/ this is one of the main take aways you want to know. the order of precedence of the config and overrides you can even apply shaders at global, core, directory, or game level. it gets pretty deep in customizing options for almost every parameter available in Retroarch.

it's telling you the problem, you cannot save to the main config with an active override. so, turn off the override before saving! or make the save before loading any content, as in before making any override active! think about it. if you could save to the main config with an active override, then your overrides become part of the main config. and that's not an override anymore because it's now default settings. it was designed like this to stop users from turning overrides into default settings. you're clearly trying to save at the main config menu since you get that error message. which means you're trying to make vulcan used at a global level. not sure if you wanted it global or not so pointing that out. if you want it at whatever level your override is, then you just change the setting and then update the override. if you used core override then use save a core override again for ex.

those links on page 1 have been broken for a long time on this main discussion thread. the links are available on the file page. go to post below for the CTC files @Light Sock if you do not have an old version of CTC you got a handful of work to do to make it look good. you can find a post from me on the previous page detailing the issue and solution. CTC 3.1.5 is def superior to 2.5.5 so I think it's worth doing it, assuming you want to keep all the animations and opacity fades etc type stuff.

it seems that the nested name field is only available for categories or playlists. with that said, it could not be applied to a platform. so if you wanted to use a nested name on a platform you could instead create a playlist and give it the nested name you want, and then add that playlist to the appropriate spot in your tree.

oh in that case you could call to the command prompt in AHK with comspec variable (path to the command prompt) this way you can use the command prompt way of calling to Windows utilities. this way Windows still knows it's correct location despite just using "pnputil" to call to it. for ex, little test output for proof of concept Run, %comspec% /c pnputil > textout.txt or for elevated Admin privileges, note if you try this one as it will output to \Windows\system32 folder (I thought, why isn't the file showing up on the desktop for a sec when I tested it lol) Run, *RunAs %comspec% /c pnputil > textout.txt I know it is resolved, just wanted to point out you can make use of the command prompt through AHK to make that a little more straight forward, especially if you're more familiar with batch files

there are ways. one is keep the files where they are supposed to be by default. instead, use a script to copy folder A to folder B at exit of emulator (or vise versa). for ex launch game with emulator A. play game, game creates/updates save files. exit game. script copies save data location from emulator A, to emulator B save data location, overwriting existing data. you can sync files across your systems through your network, rather than have them live on what I assume is acting like a NAS. I was gonna say prove that yourself by trying a local location, but then thought, I can try too in a few mins. I got it to work OK when not assigning a drive letter to the network share, just calling directly to the share like this it did not get changed from launching through LB/BB/command line I then made it with a drive letter like this still works fine I then disconnect the mapped network disk, so T: no longer exists. As expected it reverts back to the default location based on the location of the exe at time of launch I'm stumped to be honest, but I know beyond any reasonable doubt it's not related to a frontend or command line launching. Something is unique to your setup and causing it to occur. It is potentially related to a network issue, but take that with a dump truck full of salt because like I said, I'm stumped on what could be a root cause. Only good I've done is prove a few things aren't the problem. It's progress, but I'm not sure what to test next to narrow it further

Yuzu works OK from LB/BB and/or command prompt I use LB/BB across two PCs and have done quite a bit to make it seamless between each system. that being I use controller "A" on PC "A" and controller "B" on PC "B". Yuzu remembers controllers by their GUID so if I setup PC "A" to work fine, and then launch it with PC "B", inputs will not work because it's still expecting controller "A". This means it uses the config file as it's supposed to, no bypassing occurs. The same GUID stays present in the config until I change it. no idea what you're doing to accomplish this issue but it's not the fault of a frontend or launching via command prompt. It does allude to that Yuzu sees no config file, due to the fact Yuzu will load all the default paths like that when it needs to generate a brand new config. the only way I got this path to change by simply launching Yuzu (double click launch at that) is if said path does not exist. same thing as above, if Yuzu cannot find this path (NAND or SD Card), it will instead use the defaults which means it will edit the existing config in this scenario.

good! that should be expected since you stayed in Windows the whole time. Even if in a VM, it's still Windows to the disk. The issue potentially occurs when macOS gets involved. I used to think it was when ever the contents got accessed by macOS these files are created, but that seems it's only part of the reason. As I now think about it, this only occurred on my external disks but I never really investigated further until now to check my theory. These pages explains why this all happens very clearly. It actually only occurs if you also copy contents to an external disk (doesn't really need to be external, just a non macOS formatted disk, which 99.9% of the time is going to be connected externally rather than internally), which is exactly what you did, and what I did in the past. all the dots are connected now, makes total sense to me. https://kb.synology.com/en-ro/DSM/tutorial/Why_are_dot_underscore_files_created https://apple.stackexchange.com/questions/14980/why-are-dot-underscore-files-created-and-how-can-i-avoid-them

ahh ok, I've been out of the modern macOS loop, since my Apple systems are kinda old at this point lol. I see there is a difference between the Intel and Apple chips based systems. Bummer it's not as straight forward as it used to be. So, the drive format isn't so much the direct issue. And the file name might not really be an issue. It's the fact there are additional files being created due to macOS accessing the disk, and their contents will be garbage data for Windows let alone LaunchBox. Lets pretend the exFAT drive is brand new formatted on a Windows system. Everything will work perfectly fine for LaunchBox at that point. The very second that macOS touches that disk, or at least specific folders/files, it will begin creating those duplicate files prepended with "._" and that is when you will start having issues. I'm not sure there is a good way around this situation. Maybe this doesn't occur if the exFAT disk is connected internally vs externally? I'd guess no, but would be worth doing a quick comparison. If your internal disk is HFS+ or APFS these duplicate files with "._" prepended on them are by default hidden in macOS. So, maybe that is why LaunchBox works from the internal disk, but not the external one. Internal disk is hiding these files so LaunchBox doesn't try to use them and works as expected. But eternal disk is making them visible to the OS so will create errors on boot of LaunchBox. It should work from the external disk if none of those ._ files existed. You would need to make sure those are removed every time you boot LaunchBox or it will keep trying to use them as a platform XML file. Maybe some scripting to check if the files exist and if so, delete them. But you would then likely want to launch LaunchBox or Big Box through this script to make things user friendly Here is a proof of concept on that idea I tested out. You would need to put in the proper path to your folder where the XML files are in the "XML_Directory" variable. Also, adjust the path to LaunchBox, or Big Box, in the Run command. What this does is delete any file that starts with ._ before launching the program, that way they are never attempted to be used by LaunchBox or Big Box. This my only idea on how to automate getting around this whole situation. Otherwise you're likely looking at figuring out another way to setup your system or would have to do this script work by hand manually deleting the files any time they are regenerated #SingleInstance, Force SetWorkingDir, %A_ScriptDir% XML_Directory := "D:\Frontends\LaunchBox\Data\Platforms\" Loop, Files, %XML_Directory%._*.*, F FileDelete, % A_LoopFileFullPath Run, D:\Frontends\LaunchBox\Core\LaunchBox.exe Paste this script into a text file, and save it as something like "Launch LaunchBox.ahk" If the .ahk file does not run with a double click, you need to assign an AHK executable to the .ahk file extension, please do the following: Right click on the .ahk file Go to Open With > Choose Another App On the pop up window that appears, click on More Apps Scroll down to bottom of list and click on Look for another app on this PC Navigate to the AHK exe included with LaunchBox. It will be located in \LaunchBox\ThirdParty\AutoHotkey Select the AHK exe

Hi @Whatscheiser v1.1 is now uploaded. I got all the issues fixed, including being able to scrape Modern Marvels in its entirety. I do notice I am getting errors from TVDB more often. That "whoops looks like something went wrong" and "502 bad gateway" web page response kinda stuff. When that is occurring and you try to scrape it will not work and the script will likely return a error stating it timed out. To be clear, this is not the script's fault, it's the website/servers not responding or being down. It can be deceptive too. It might be able to download say the first three seasons of some series, but then hang up on number four. Not only does the user provided URL need to be responding properly, but the specific season number for that season type as well for the script to fully work. For ex with Modern Marvels. This main page must be responding correctly https://thetvdb.com/series/modern-marvels/allseasons/official But also the season specific pages must respond correctly too, using Season 12 here https://thetvdb.com/series/modern-marvels/seasons/official/12 If the main page doesn't work right, nothing scrapes. If the main page works, but the season specific page doesn't work, it will not be able to download the season specific image and will eventually give you a time out error. You can keep trying, or would exit the script at that point. This likely explains why the official airing for Miami Vice gave you issues, but then the dvd order worked fine. One page was not responding properly, while the other was. All of this BS doesn't happen with TMDB and the API v2.0 of the script. So, I'll return my focus to that so users can stop having to deal with this seemingly random unreliability

Hi @AOR I re-read this, and now I know exactly what is going on! This is an eccentric macOS issue. macOS creates a hidden file prepended with "._" for every file. so due to you're putting your LaunchBox install onto I assume a NTFS drive connected externally, this will keep occurring. Said files must be getting accessed from Windows from the external disk, which reads them and says "what is this?!" because it's data is going to be nonsense to LaunchBox. The whole idea of running things through a VM is a bit of an exotic setup. Prolly should consider making a native Windows install and boot into that when you want to use LaunchBox I used to see this same thing occur all the time when I had one of my HDD's formatted as exFAT so I can share TV and movies between macOS and Windows. Drove me nuts to always see these ._ files everywhere in Windows. They are otherwise harmless, but in your case, they are a problem because LaunchBox is going to continually try and use them as a platform file.

it's impossible, you cannot put a playlist under a playlist. playlists can go at the root level, or under a category or platform. Some potential ways to set this up -Light Gun games (category) --Sony Playstation (Playlist) --Sega Dreamcast (Playlist) and so on... or if starting with platform... -Light Gun games (platform) --Sony Playstation (Playlist) --Sega Dreamcast (Playlist) and so on...

well I noticed the XML file is called "._Arcade.xml" ? I would think that is causing your issues. That likely is not a proper name. One would assume you mean to call your Arcade platform "Arcade" not "._Arcade". If you named it appropriate as "Arcade" it would create an XML file called "Arcade.xml" Otherwise the error is referring to the contents of the file. Literally the first character inside the file is a period "." per that error message and that is def not how it should be. Assuming there are not further issues, deleting the period would take care of that error. But, depending on how messed up the file is, a different error may pop up afterwards. Maybe due to what I am pointing out. Do you now have both "._Arcade.xml" and "Arcade.xml" in the data folder? guessing both are messed up, so it may produce throwing two errors

the light guns are seen as both a mouse device, and a dinput device. they are not a xinput device. not sure about what input API the tanksticks use though. check the user manual for your specific model, it should specify it somewhere. I'm not so sure the avg user would want them to go to P3 and P4 by default. then you got to remap light gun game controls to P3 and P4. likely cannot do that by core/system since I would bet most would be playing some standard conroller and light gun games that share same core. So would instead need to use directory or game level remapping. when you consider that, this default behavior of them going to P1 and P2 in my opinion is how it should be. TEC75 points out you can make use of Retroarch's device remapping, which has worked for me in the past. It's the same concept as device remapping in MAME (using the config files inside the ctrlr folder), using PIDs (product IDs) to identify the individual device and remap it's controls or player #. This does work, so maybe you went wrong somewhere? Unless you have a use case where you really need them on P3 and P4 all the time, it might not be worth the hassle to set them up like that. That lead me to share my point there is an easier solution with only plugging them in when in use

delete the red ones. leave the green one. the NES one without backup in it is 3MB in size so should have some data it in. If it does not show up you may have 0 games linked to that platform. the old one is dated from 2018, kinda obvious which one is the new one. or if you want to go this route instead..... yes, that's just starting that platform over per their date, got to think back to 2018 to figure that out.

Hi @Whatscheiser coming back with an update TVDB was back up later and script is working as expected so seems any issue with getting nothing returned was issues with their site/servers. Once I noticed they were back up, I had to recreate the issues you communicated and test my solutions. Good news, the issues are resolved. Found a couple other things and fixed them up too. Bad news, there is something funny going on with Modern Marvels. That is the most incomplete series I've seen on TVDB and I'm not sure if this is lending to the issue quite yet since I have not been able to recreate this specific issue for any other series. I created dummy files through the end of season 13 using the batch file renamer and was just shy of 600 episodes. Not once did it ever scrape metadata beyond part way through season 12, always ending at episode #35, Mountain Roads. The scraping loop is stopping prematurely, it should instead scrape the entire webpage the user provides. This explains why it acts like it is suddenly stopping part way through such a large series and why later seasons get zero responses. The scraping loop should only stop if there are no more "class names" to scrape, it would return an error that triggers the loop to stop. So, I know why it's stopping, but I haven't had enough time to dig into why an error is thrown at that specific spot. I will upload a new version as v1.1 to fix all other issues though. Hopefully will have time to do that in the next day. Then I will likely return my focus to working on v2.0, specifically get the beta test to you with relevant details. Thanks for your patience on all this stuff!

@Truest1 I experience similar behavior with light guns always going to P1 and P2. My approach is quite simple. The easiest way to deal with this is to only plug in the light guns when you use them. When you use them, you want them to be P1 and P2. So, who gives a crap where other stuff ends up when light guns are plugged in, it's not like you're using two light guns and the other devices like your xarcade tankstick at the same time. When you're done, unplug the light guns and your tankstick and other controllers return to their normal player # positions. Don't overthink things and take the path of least resistance, this is a "KISS" approach

I am getting no connection to thetvdb.com either. I would have to assume this is the issue with scraping not working until they clear this up and we know for sure. When I try the script just now, it doesn't grab any data from them. This is evident due to the "Total Series Webscrape Progress" count is only 1 rather than the number of episodes I think it should still find "S12E51 Coffee" assuming that is the file name, and "Coffee" is the episode's title. Last fallback is just the episode title, so that should work. I'll have to assume right now, likely part of this issue with their website. So far sounds like you stayed in the guidelines just fine. Sorry, this is another hurry up and wait thing before I can properly diagnose I also think I found the reason the network is being grabbed if the air date is absent. Gotta wait to test to know for sure. In risk of sounding like a broken record, I'll hurry up and wait to test lol. Kinda weird situation, I have been playing with their API in the last week, and it still works fine right now. So, they are must be having some issues that are purely website related. Not kidding you, I watch some of those Modern Marvels on youtube recently lol! It's interesting stuff! No judgement from me! Lastly, thanks for being willing to give the new version a whirl! I'm gonna get my ducks in a row on that and will shoot you a message with the new script and any details on what's new or different.

well that sure didn't take me long to find.....gotta love google and the internet..... might want to watch this thread

lmao pretty glad I snagged the newest copy of yuzu a few days ago....literally just in case of something like this. on the other side....wow....I did not think they would take this path. just a total collapse great.....fn Nintendo wins. what giant L for the emulation community. blame the literal idiots who did stuff like stream themselves playing games before they even released. too much negative attention was brought to project due to stuff like that. I got yuzu 1732 the other day (3/2/24) had I know Citra was connected to Yuzu I would have gotten that too before this went down. I unfortunately don't know any place hosting stuff like that

so to help explain, the Utilities > MAME tab allows the software to auto setup the stuff that is being discussed here. Hence why it asks for the path to the MAME exe and ini file. It's just remapping controls as every guide out there tells people to do by hand. Due to this discussion, I finally take a moment to see how this feature works, this software just automates some of the setup. For instance, soon as I click the enable check box it will edit the ini file, the most obvious edit being adding the Ctrlr config name, and when looking into your ctrlr remap folder you will see the newly created remap file. My point here is it's always better to know how things work rather than "I click this button and it works now....." and never understand the reasoning. So this is going to burst your bubble, it's bursting mine too......the software doesn't even do the controller (device) remapping as I assumed it did lmao. It is only remapping controls. I know that might sound the same, but it is not. All this software can do is "make trigger be player 1 button 1" kinda remapping. It does NOT do "make PID_1601 always player #1". so you have literally never even once needed stable controller ID's. I scan through the entire cfg file the software makes, no controller (device) remapping, just controls remapping. Here for ex the MAME ini edited, with the new cfg file created. Though, the contents of the file have no stable ID controller remap going on. Don't be fooled by the header, it is blocked off by comments so those VID and PID #s and Light Gun #1 business is like it's not even there to MAME. That's not even the right syntax to declare that stuff anyway Controller (device) remapping looks like this. They can be in the same file, but, this software only does remapping of controls. This is kinda lame it does not do this controller (device) remapping automatically too. And kinda proves how blown out of proportion this can be. You've been running for how long without one, without any problems lol. Obviously it's not needed for your use case. That's not a bad thing. Consider yourself lucky it works for you without any further intervention. So to be clear, this program doesn't remember anything about your lightguns being called player #1 or player #2 in MAME between reboots. You would need lines like the below file in your cfg file for that to be 100% guaranteed. For me, without this file, it normally assumes my two light guns are player #2 and player #3. So in my experience this reduces setup a little bit since I have less games I need to custom remap for. Better chances stuff works right out of the gate. When I enabled this feature in Arcade Guns, it broke my setup due to my light guns reverted to this issue for me being #2 and #3, further proving this utility does not do any device remapping

Hey there Whatscheiser, I'll address all your points here. I really appreciate the feedback you continue to give. 1) 400 episodes sounds like a lot. Largest show I know I scraped is 300 something episodes. The qty of episodes impacts the time taken. The script first scrapes all the relevant data from the website before anything else. So, it might act like it's frozen during that first scraping process since it's downloading said data. The message you got comes up when it detects a scrape is completed, so, it must have thought it went through everything. That can happen if you get no responses from the website. If it's still not working for you, that is strange, not like it went through some update and the code changed. To be clear for me, are you saying it doesn't work at all anymore, no matter the show or season? Doesn't work for a specific show? Doesn't work for a specific season for a specific show? 2) I actually thought I took care of ampersand character (&) as I'm well aware about that issue, but as I think about it, I likely did that for a different tool and not this one lol. That is a easy fix for me to implement, I'm kinda surprised I didn't run into that issue myself. Glad your hands on enough to understand the issue and fix it with a manual edit of your platform file when it occurs! 3) The air date not being on TVDB is bizarre. I wouldn't think they allowed incomplete entries like that (like at least put in the year rather than blank if exact date is unknown), but as I continue to work on this project I'm less of a fan of TVDB and more of a fan of TMDB now. After looking at TVDB's site with inspector, I think I know why this is occurring but I will need to recreate it to know for sure. With all that said, can you please provide an example of the 1st and 3rd issue, as in what show and season type are your scraping? I'll need you to please provide the URL address you enter into the script for both issues. In case you wonder, I don't need relevant video files on my PC. I can rename a bunch of files to mimic having them in my library for troubleshooting so this will give me a chance to recreate and hopefully fix these in a reasonable time frame. Now I actually have a favor to ask of yourself! Any chance you would be willing to test a brand new version of this script? As I alluded to above, I looked into using other databases to improve this script, and TVDB is not as good as TMDB (The Movie Database - which despite the name does have an extension database of TV series). So I am making this new version use their database, and it's using API rather than class names, among a handful of other improvements I hope users will like. It would be great to get some feedback on it, especially since you are already familiar with the current version. Please let me know if you would be into giving it a test drive.