EmulationStation parses SH files into runcommand argument for lr-dosbox
-
Pi Model or other hardware: RaspberryPi 4B 4GB model
Power Supply used: CanaKit Power
RetroPie Version Used: 4.6.1
Built From: Berryboot, created using Raspbian 10 (Buster) Lite following Manual install instructions
USB Devices connected: Logitech USB Keyboard/mouse receiver KM700/MK750
Controller used: None
Error messages received: None
Log found in /dev/shm/runcommand.log (if relevant): Combined into 2 pastebins: https://pastebin.com/8Ln2jDnF and https://pastebin.com/SLzFwHPq
Guide used: None
File: Multiple
Emulator: lr-dosboxThe issue I've run across is that if I'm trying to execute a dos based game using lr-dosbox, depending on where I run it from, either straight from a terminal or through emulation station, it determines what runcommand gets for it's arguments. The following link lists the two sh files that are used to start each game I tested this with, https://pastebin.com/ai5P53Y8. Both sh files execute runcommand, and obviously they have the 4th argument be the config file for lr-dosbox to run. The issue is when running these files from EmulationStation, it somehow changes the arguments and runcommand instead parses the executing sh file as the 4th argument instead of the dosbox conf file, as shown in the logs attached. I don't have these issues when running the games through dosbox or dosbox-sdl2. Even as I typed this I decided to test with another game of mine, and this third one also had the same issue, where lr-dosbox was trying to execute the .sh file instead of read from the .conf file and run the [autoexec] area.
-
There's no parsing for
.sh
files done by either EmulationStation or Runcommand when launching a game. The command to launch the actual game is set in theemulators.cfg
for the system in question (pc
in this case):dosbox = "bash /home/pi/RetroPie/roms/pc/+Start\ DOSBox.sh %ROM%" default = "dosbox" dosbox-sdl2 = "bash /home/pi/RetroPie/roms/pc/+Start\ DOSBox-SDL2.sh %ROM%" lr-dosbox = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-dosbox/dosbox_libretro.so --config /opt/retropie/configs/pc/retroarch.cfg %ROM%"
So if you're launching the
.sh
withlr-dosbox
, your game is launched through RetroArch and it's normal that it fails, since I don't thinklr-dosbox
(ordosbox
for that matter) knows how to interpret the.sh
files.Use
.conf
files to launch the games, they'll work in bothdosbox
orlr-dosbox
. -
@mitu That is exactly what my emulator.cfg file looks like. The %ROM% argument is suppose to interpret %ROM% as the dosbox configuration file, and as you've seen with my logs, emulation station somehow changes it from the cfg file to the executing sh file. But executing the same sh file through commandline instead of through emulationstation starts up lr-dosbox properly instead. My logs show that difference.
-
I can't reproduce this behavior - the
.conf
files are launched normally, using eitherdoxbox
orlr-dosbox
. EmulationStation doesn't alter the extension or the filename it passes toruncommand
:Parameters: Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-dosbox/dosbox_libretro.so --config /opt/retropie/configs/pc/retroarch.cfg "/home/pi/RetroPie/roms/pc/Quake.conf" --verbose --appendconfig /dev/shm/retroarch.cfg [INFO] RetroArch 1.8.6 (Git 36802f7) [INFO] Redirecting save file to "/home/pi/RetroPie/roms/pc/Quake.srm". [INFO] Redirecting save state to "/home/pi/RetroPie/roms/pc/Quake.state". [INFO] === Build ======================================= [INFO] Capabilities: NEON VFPv3 VFPv4 [INFO] Built: May 14 2020 ...
Are you sure you're not launching the
sh
files from EmulationStation, instead of the.conf
file ? Can you post yourgamelist.xml
for thepc
system on pastebin.com ? -
I'm afraid I'm not sure we're understanding one another. The Emulationstation file I execute is an sh file. It's the same file I launch through CLI. It's an sh file located in the pc folder. However I've never had issues like this. And for some reason when executing the sh file from inside Emulationstation.
Essentially, the sh files are in ~/RetroPie/roms/pc, so Emulationstation would see those when scraping. The following link shows the contents of both sh files. https://pastebin.com/ai5P53Y8
I used to have sh files just run dosbox directly instead of executing runcommand, and those wouldn't show the runcommand dialog that appears at the start of every other game.
As you can see, the files would execute runcommand, and the argument for the dosbox config is in there. However for some reason Emulationstation instead sends the sh file as the %ROM% argument, while running the same file through terminal sends the dosbox config as the %ROM% argument. It's the middle of the night right now, so I'll get you the gamelist.xml file tomorrow.
-
@Dimensional said in EmulationStation parses SH files into runcommand argument for lr-dosbox:
I'm afraid I'm not sure we're understanding one another. The Emulationstation file I execute is an sh file. It's the same file I launch through CLI. It's an sh file located in the pc folder. However I've never had issues like this. And for some reason when executing the sh file from inside Emulationstation.
Why do you expect the.sh
to work from EmulationStation ?Dosbos orlr-dosbox
doesn't understand.sh
files.It's the middle of the night right now, so I'll get you the gamelist.xml file tomorrow.
Since you're sure that you're running the
.sh
file, there's no need for it.EDIT: Corrected.
-
The standalone dosbox launch script understands .sh files. If one is passed as a ROM it's executed by the launch script.
-
So EmulationStation runs
Runcommand.sh
internally? It doesn't have to be called by an sh file? What about justdosbox
? I have no problems executing the sh files with that in emulationstation or cli. Only reason I uselr-dosbox
is because I can't seem to control the volume of my monitor's speakers directly.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.