xokia Posted Tuesday at 09:37 PM Posted Tuesday at 09:37 PM (edited) I know its hard to produce useful comments. But something other then cant find a file would be useful. Like what file were you searching for? What path were you passed that you could not locate. There is nothing to be gained from this log other then to guess. 2025-03-04 01:30:28 PM Unbroken.LaunchBox.Windows.Desktop.ViewModels.MainViewModel.window.Activated Start 2025-03-04 01:30:28 PM Unbroken.LaunchBox.Windows.Desktop.ViewModels.MainViewModel.window.Activated Before JoystickTimer Enabled Set 2025-03-04 01:30:28 PM Unbroken.LaunchBox.Windows.Desktop.ViewModels.MainViewModel.window.Activated Before Resume Video 2025-03-04 01:30:28 PM Unbroken.LaunchBox.Windows.Desktop.ViewModels.MainViewModel.window.Activated Before Check Already Focused 2025-03-04 01:30:28 PM AddEditGameViewModel Closed Updating GameDetailsViewModel 2025-03-04 01:30:28 PM Resolving assembly System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=hjsgdhg438574398... 2025-03-04 01:30:28 PM FIRST CHANCE EXCEPTION: Could not load file or assembly 'System.Runtime, Version=9.0.0.0, Culture=neutral, PublicKeyToken=hjsgdhg438574398'. The system cannot find the file specified. I am trying to override the current params with a custom param. This one file needs to load a different core then the others. The others can use genesis_plus_gx_wide_libreto.dll It works if I use the default genesis_plus_gx_wide_libreto.dll. Just the image is messed up. So something I am doing wrong in the custom param but the log isnt helping debug it. Edited Tuesday at 11:10 PM by xokia Quote
xokia Posted Tuesday at 11:42 PM Author Posted Tuesday at 11:42 PM (edited) So after some trial and error I figured it out I needed to remove the quotes around "%romfile%" Would be really useful if the launchbox "debugger" spit out what it was trying to pass to the command line. Would have made this super easy to debug. If this functionality exits I am missing it in the logfile. Entirely possible I missed it. I did grep but didnt find anything. Edited Tuesday at 11:44 PM by xokia 1 Quote
JoeViking245 Posted Wednesday at 12:34 AM Posted Wednesday at 12:34 AM I can't attest to what is or isn't in the log file. But I can tell you is that what's passed in place of the variable %romfile% directly depends on what's in the emulator settings. You can also either turn on Logs in RetroArch or pass -v to create a Log file. (\Retroarch\logs\retroarch.log) I understand this all in retrospect/hindsight. But may help in the future or someone else reading this sometime down the line. Quote
xokia Posted Wednesday at 01:51 AM Author Posted Wednesday at 01:51 AM (edited) 1 hour ago, JoeViking245 said: I can't attest to what is or isn't in the log file. But I can tell you is that what's passed in place of the variable %romfile% directly depends on what's in the emulator settings. You can also either turn on Logs in RetroArch or pass -v to create a Log file. (\Retroarch\logs\retroarch.log) I understand this all in retrospect/hindsight. But may help in the future or someone else reading this sometime down the line. Problem is it never launched retroarch. Since it "could not locate the file" it never passed anything to retroarch. So the retroarch log filed would produce nothing. Which left me the launchbox logfile. It would be useful if as part of the launchbox "debugger" it output what it was passed or what it thinks it was passed. Or maybe I am over simplifying launchbox. It's parsing and forming those commands but ultimately its outputting "something" to a cmd line. It would be useful if it would print out the "something" to the logfile. Edited Wednesday at 01:53 AM by xokia Quote
JoeViking245 Posted Wednesday at 03:10 AM Posted Wednesday at 03:10 AM 43 minutes ago, xokia said: Problem is it never launched retroarch. Since it "could not locate the file" it never passed anything to retroarch. So the retroarch log filed would produce nothing. Which left me the launchbox logfile. RetroArch will create a Log file in this situation if adding in the -v parameter. Even though it doesn't appear to launch. Looking closer at the partial debug log you shared, the missing file has to do with the assembly file System.Runtime. So, not related to launching the game. LaunchBox knows the games' file exists because of what's in the games Application Path. In fact, you'd get a popup message box [from LaunchBox] stating it doesn't exist if it didn't. Also, LB doesn't care about what's in the command line parameters, either correct for the emulator or otherwise. As long as the physical game file exists (except in the case of MAME) and the emulator application exists, it'll attempt to pass the parameters as shown to the emulator. 50 minutes ago, xokia said: It's parsing and forming those commands but ultimately its outputting "something" to a cmd line. It would be useful if it would print out the "something" to the logfile. The command line LaunchBox passes to the cmd line is [typically*] what's shown in my screenshots above under the Sample Command. RetroArch is unique in that you also need to figure in the core that is passed. i.e. add in -L cores/xxxx.dll *Also note that any parameters (if any) shown in the Associated Platforms section of the emulator for the specific Platform will take precedence over what's shown in the Details section. LaunchBox will always pass the result of %romfile% at the end the command line string, taking into account the checkboxes that are checked. The exception is if you manually insert %romfile% in the middle of your parameters. Then it won't [also] add it to the end. Quote
xokia Posted Wednesday at 03:19 AM Author Posted Wednesday at 03:19 AM (edited) 34 minutes ago, JoeViking245 said: RetroArch will create a Log file in this situation if adding in the -v parameter. Even though it doesn't appear to launch. Looking closer at the partial debug log you shared, the missing file has to do with the assembly file System.Runtime. So, not related to launching the game. LaunchBox knows the games' file exists because of what's in the games Application Path. In fact, you'd get a popup message box [from LaunchBox] stating it doesn't exist if it didn't. Also, LB doesn't care about what's in the command line parameters, either correct for the emulator or otherwise. As long as the physical game file exists (except in the case of MAME) and the emulator application exists, it'll attempt to pass the parameters as shown to the emulator. I can try to recreate this, I had both the Launchbox logfile turned on AND the retroarch logfile (I went into the console and turned it on) turned on. Retroarch produced no log launchbox produced the log I copied. Let me add the -v option to retroarch and see if that makes a difference. *edit* -v doesnt appear to make any difference here. Launchbox logfile create 7:26pm Nothing created -v added to the command line AND I manually turned on logging before hand in retroarch. This should be easy to replicate. Just choose a sega core and add quotes around %romfile% 34 minutes ago, JoeViking245 said: The command line LaunchBox passes to the cmd line is [typically*] what's shown in my screenshots above under the Sample Command. RetroArch is unique in that you also need to figure in the core that is passed. i.e. add in -L cores/xxxx.dll *Also note that any parameters (if any) shown in the Associated Platforms section of the emulator for the specific Platform will take precedence over what's shown in the Details section. LaunchBox will always pass the result of %romfile% at the end the command line string, taking into account the checkboxes that are checked. The exception is if you manually insert %romfile% in the middle of your parameters. Then it won't [also] add it to the end. That was the hope. This particular game did not like the genesis_plus_gx_wide_libretro.dll core so I was trying to override what was being assigned to all the other games. In this case the logfile just wasnt useful because I could not see what was being passed. Debug would be easier if the logfile contained the command line that launchbox assembled. Just my $.02 You are correct that the exception mentioned at the start doesnt appear to be the issue. I still see the exception in a passing case. Although I dont know that that helps the launchbox debugger. Just makes the debugger even less useful Edited Wednesday at 03:46 AM by xokia Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.