questions about runcommand.sh

caver01

@meleu Couldn't you setup another "emulator" such that the runcommand calls your alternate, only the emulator it calls is a script you create that runs your command and then the emulator it replaces? If you want the command to run for one or two emulators this might work, but gets less practical if you want a command before EVERY emulator.

For example, I want the same thing--I want to launch MESS such that it runs a command before opening a disk image. The command will copy configs around to make a custom keymap tailored for that specific disk image. Sounds very similar to what you want to do.

meleu

@caver01
Yep, I've already thought of this solution. But I wouldn't like to change so many files.

OK, it can be satisfactory if it's just for me. But my intention is to implement it and release for everyone. And I think that messing with so many files will add an unwanted complexity to the joystick selection process.

Thanks anyway! :-)

meleu

I've just realized one thing: There is no need to execute a command AFTER runcommand. It can be before.

meleu

As reported here:
you can now place scripts at /opt/retropie/configs/all/runcommand-onstart.sh and /opt/retropie/configs/all/runcommand-onend.sh

Really useful for what I want to do!

caver01

@meleu And can these include variables (like selected ROM name)? This is fantastic for what I want to do too!

meleu

@caver01 said in A question about runcommand.sh:

@meleu And can these include variables (like selected ROM name)?

oo oh... I don't think so...

Look how they are invoked:

runcommand-onstart.sh:
https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/runcommand/runcommand.sh#L763

runcommand-onend.sh:
https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/runcommand/runcommand.sh#L829

The ROM name usually is the 4th argument given to the runcommand.sh and the runcommand-on[start|end].sh do not have access to these arguments.

I think the function get_params on runcommand.sh creates a global variable rom, as we can see here (this variable isn't declared as local, so it's a global variable). Maybe you can give to @BuZz a good reason to export this variable and access it in runcommand-onend.sh.

OR BETTER YET: change the the commands that invoke these scripts adding $@ in the end so they both can get access to the runcommand.sh parameters.

caver01

@meleu Yeah, it makes sense to have access to these variables. Looking back a few years, I had a system running the Maximus Arcade front end. Many of us probably remember this one. Anyway, one of the settings you could configure per emulator is a RUN BEFORE and a RUN AFTER command (with variables passed). Not everyone used it, but you could do some really flexible things with it that are very similar to how our runcommand is used to set the display resolution, for example. I used it to do a pre-config by copying a configuration file matching the ROM NAME (or rather, a disk image for MESS using that forwarded parameter) into the working directory for MESS on the pre-execution, then on post, I would save that config back to it's holding folder. This allowed me to load my keyboard map for a given disk image, and more importantly, edit the mapping using the MESS GUI, and when I exited, it would be saved. Later, that saved file would be recalled and copied back into place when that ROM (disk image) was selected.

This required two (three) things. 1. A pre/post execution script. 2. Passing parameters so the script was aware of the ROM selected. (3. a parameter for the emulator chosen).

Looking back, I suppose I could have used the ROM parameter in the emulator launch command to point to the appropriate config. I don't remember if I tried that or not. Maybe I did and it failed when the config didn't exist and this was my workaround.

Anyway, I'd really like to be able to do custom keys on disk images (mostly games) for the Apple II emulator. As far as I know, I can't customize the keys in LinApple via configs, so I am looking at MESS.

meleu

@caver01
I added it and made a Pull Request:
https://github.com/RetroPie/RetroPie-Setup/pull/1610

Let's wait if it'll be merged. Crossing fingers!

meleu

Ooops! It didn't... :~(

caver01

@meleu Bummer, but I don't fully understand the reason. Thanks for asking a clarifying question.

BuZz

@caver01 I put some more details on the PR.

edmaul69

@caver01 the newest version of linapple does let you configure which controller, buttons and axis. If you download the newest one you need to copy the linapple.conf from the /opt/retropie/emulators/linapple/ to the /opt/retropie/configs/apple2 folder overwriting the old config

caver01

@BuZz Makes sense. There is a better way obtain the chosen ROM and Emulator then? I'd certainly rather work within the overall vision than branch off on my own, especially if it's something others might be able use.

caver01

@edmaul69 said in A question about runcommand.sh:

@caver01 the newest version of linapple does let you configure which controller, buttons and axis. If you download the newest one you need to copy the linapple.conf from the /opt/retropie/emulators/linapple/ to the /opt/retropie/configs/apple2 folder overwriting the old config

I want to pick this up on another thread. This sounds promising!

BuZz

There is - processing order needs to change - I will implement it.

BuZz

the PR didn't actually work btw - it would try and launch a script with the parameters as the name of the script. You would need to do bash "$configdir/all/runcommand-onstart.sh" "$@" not bash "$configdir/all/runcommand-onstart.sh $@"

BuZz

implemented in https://github.com/RetroPie/RetroPie-Setup/commit/0c39c7438b7986997313e74707e9873e820bbfa1

meleu

@BuZz Really cool man! Thanks!

meleu

Another runcommand question:

Why runcommand.log went to /dev/shm?

BuZz

ram based.