questions about runcommand.sh

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.

meleu

@BuZz
one more question...

Premise: thinking in RetroArch only.

I'm using runcommand-onstart.sh to change a system specific's retroarch.cfg before launching the game. Is the $system passed to runcommand-onstart.sh a valid configdir?

In other words, can I use /opt/retropie/configs/$system/retroarch.cfg?

I'm doing this way and it's working fine for the classic consoles (atari2600, nes, snes, megadrive, etc...). But I'm worried if this will work for any libretro emulator.

BuZz

@meleu yes.

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

meleu

@BuZz
(* sigh * here I go bother you again...)

would you mind to export the log variable in runcommand.sh?

reason:
make it accessible in runcommand-on{start,end}.sh.

use case:
Since users can execute custom commands in runcommand-on{start,end}.sh some bugs can be inserted.
It would be a good practice for those who want to write something in these scripts, to log some info for bug tracking.
Another benefit: It helps us to help inexperienced users with problems because of third-party on{start,end} scripts.

BuZz

Just write your own log or use the same filename. Actually, I will redirect stderr to the log, so errors will get logged automatically.