• runcommand delete .nvram on exit script

    Moved Help and Support
    2
    0 Votes
    2 Posts
    307 Views
    FloobF

    @qjafri829

    This might help you get started with custom runcommand scripts
    https://retropie.org.uk/docs/Runcommand/#runcommand-scripts

  • 0 Votes
    6 Posts
    526 Views
    LolonoisL

    @rincewind said in Need for start up and shutdown user scripts?:

    Also more fundametally, would it not make sense to have a frontend agnostic hooks?

    No need to reinvent the wheel: Systemd (service type oneshot) is most likely your friend.

    https://wiki.archlinux.org/title/Systemd#Service_types

  • 0 Votes
    8 Posts
    740 Views
    S

    @mitu
    Ok. All clear now. Thanks for the clarification.
    I'm not a dev guy, so it's beyond my knowledge to modify the source code. I guess I have to prepare two set of config.txt, and reboot into the proper video mode when needed.

  • 0 Votes
    4 Posts
    1k Views
    T

    All fixed.

    It was a permissions issue. Needed to run:

    sudo chown -R pi:pi /home/pi
    sudo chown -R pi:pi /opt/retropie/configs

  • Automatic cursor movement in runcommand

    Help and Support
    25
    0 Votes
    25 Posts
    2k Views
    M

    @mitu Sorry for the late reply: Everything works fine in runcommand and RetroPie-Setup with your new version.

  • 0 Votes
    10 Posts
    1k Views
    F

    @teethree89

    2 old projects of mine, perhaps something to peek in :

    https://github.com/FollyMaddy/retropieXstation

    and

    I always use this in the desktop environment, running games directly from the explorer :
    https://github.com/FollyMaddy/RetroRun

  • 0 Votes
    7 Posts
    780 Views
    dankcushionsD

    @lilian3004 it does. we need more information - please describe exactly what you see, and provide verbose logs and full info as per https://retropie.org.uk/forum/topic/3/read-this-first

  • 0 Votes
    6 Posts
    892 Views
    dankcushionsD

    @cargorunner said in Playstation - Suddenly stopped working:

    @mitu The file has 3 lines, I just listed the one line I changed. The full file from the prebuilt image is...

    lr-pcsx-rearmed = "/opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-pcsx-rearmed/pcsx_rearmed_libretro.so --config /opt/retropie/configs/psx/retroarch.cfg %ROM%"
    default = "pcsx-rearmed"
    pcsx-rearmed = "pushd /opt/retropie/emulators/pcsx-rearmed; ./pcsx -cdfile %ROM%; popd"

    this isn't the file from Retropie's prebuilt image. it does not default to pcsx_rearmed (standalone), so not sure what happened here, but good you got it sorted!

  • 0 Votes
    8 Posts
    1k Views
    stoney66S

    @paul_uk Awesome thanks for this. I was using something from Katie Snow long ago but this seems a bit easier.

  • Adding Runcommand

    Help and Support
    6
    0 Votes
    6 Posts
    873 Views
    S

    @officialazyria the runcommand just needs to point at whatever folder you want it to look for emulators.cfg in.

    I'm seeing that "hikaru" is a Sega system similar to NAOMI and Atomiswave, so it might probably use the Dreamcast setup too, not Arcade. Gaelco is just a game publisher though, right? I don't know much about it but I've got Alligator Hunt running in my Arcade folder under FBNeo. What game(s) are you trying to play? What emulators do they require?

  • Ports and Launch Menu Art

    Help and Support
    5
    0 Votes
    5 Posts
    971 Views
    S

    I've done some more digging on this and I've come up with a solution that works for me. Though it's not exactly plug-and-play, it's pretty simple to implement on a case-by-case basis.

    What I tried above was never going to work, for a couple reasons. For starters, $IS_SYS and $IS_PORT are not, as I had assumed, mutually exclusive. "SYS" is anything that's not a special +Start system.sh script, and "PORT" is a subset of that. So, when I tried to make it "if IS_SYS, else if IS_PORT", that was never going to do anything. They're all SYS and when they're not, they're not PORT either, so the "else" part would never happen, in any case.

    So with that out of the way, I can just rewrite the test. If IS_SYS (that's basically everything), it checks the default paths. Doesn't find anything for ports, because their images are in the "ports" folder, not the individual "system." So instead of "else," I just added another "if IS PORT," then check for art in paths with ports instead of $SYSTEM dir: "If SYS, check $SYSTEM path; fi; if PORT, check 'ports' path, fi."

    But that still didn't work. Okay, so...why doesn't it work. Well. Runcommand is the part that displays the image. It looks for an image that's named the same as the game, right? But how does it know. It's looking at the %ROM% parameter that's passed to it by EmulationStation. Only for ports it doesn't work that way.

    With regular console systems, EmulationStation says (simplified):

    runcommand SYS [system] %ROM%

    ...and the "ROM" is the rom file. If Runcommand can find a picture in the "[system]" folder with the same basename then it's got a match.

    For ports, that doesn't happen. For ports, EmulationStation goes:

    bash %ROM%

    where "ROM" is the launch script. The launch script then calls up Runcommand with

    runcommand PORT [system] %FOO%

    ...where "FOO" is whatever weird stuff is used in the launch command for that particular port. It might be the path to a file or directory that may or may not share a basename with the launch script and image file, or it might be a long string of command-line flags that aren't even legal filenames. It's different for every "system." And this is what Runcommand is looking for when it tries to match a filename for the image to display. This is never going to work either. That's why they don't do it that way. That's why they have launching.png.

    So what do I do about it. As mentioned above, I can place a launching.png in the configs/ports or configs/ports/[system] dirs. Which works fine when a "system" only has one game on it, but for times when different games can all be launched with a shared system setup (like all the Doom expansions all using the same lr-prboom core), it means I would have to use the same image for all of them.

    Or would I? And in fact no, I would not. If it's looking for a launching.png I will let it find a launching.png. But I can decide what that looks like when it finds it.

    In my launch script, example (simplified):

    #! /bin/bash runcommand.sh PORT "[system]" "[%FOO%]"

    ...before the run-command, I add a line that symlinks (at first I copied, but symlink will shuffle less data around) the desired image to the expected location: ln -sf "/home/pi/.emulationstation/downloaded_media/ports/screenshots/$(basename ${0%.*}).png" /opt/retropie/configs/ports/launching.png:

    #! /bin/bash ln -sf "/home/pi/.emulationstation/downloaded_media/ports/screenshots/$(basename ${0%.*}).png" /opt/retropie/configs/ports/launching.png runcommand.sh PORT "[system]" "[%FOO%]"

    Using $(basename ${0%.*}) substitutes the name of the launch script (the one that this command is inside of) without path or extension, so I can just copy-paste this same line into every one of my scripts and they'll all link their own, individual launch art before calling Runcommand. It means that if I rename the script I'll have to rename the image, but this is just like how all the other systems work anyway, with the rom name being linked to the image name, and this way I didn't have to type out a different filename in each of my scripts.

    If you wish to use this method, you will need to substitute the path to your images based on your own configuration. Which is why it's not exactly plug-and-play, since it seems everyone has these in a different place.

    Here is an actual, non-simplified example of one in action:

    pi@retropie:~/RetroPie/roms/ports $ cat doom-sigil.sh #!/bin/bash ln -sf "/home/pi/.emulationstation/downloaded_media/ports/screenshots/$(basename ${0%.*}).png" /opt/retropie/configs/ports/launching.png "/opt/retropie/supplementary/runcommand/runcommand.sh" 0 _PORT_ "doom" "/home/pi/RetroPie/roms/ports/doom/sigil/DOOM.WAD"
  • SOLVED: joy2key_sdl.py throwing error

    Help and Support
    9
    0 Votes
    9 Posts
    1k Views
  • Running a script on ROM start....

    Help and Support
    3
    0 Votes
    3 Posts
    708 Views
    G

    @mitu Thats great, it worked, just added an & at the end. Thanks very much!

  • Help batch running arcade games

    Help and Support
    40
    0 Votes
    40 Posts
    6k Views
    B

    @luckyluca said in Help batch running arcade games:

    what is the difference between .fs and .nv files in the roms/arcade/fbneo folder?

    Basically the same thing (non-volatile ram to save cabinet settings), just different methods to save them.

  • 0 Votes
    5 Posts
    922 Views
    FroyoXSGF

    Righto, here's the solution for everyone who wants to let RetroPie handle NTSC/ NTSC progressive modes but then switch to the PAL60 equivalent:
    Put this into runcommand-onstart.sh:

    (sleep 15 && sudo /home/pi/tweakvec/tweakvec.py --preset PAL60) &

    If it doesn't work for your Pi, try sleeping a bit longer. On my Pi3, 15 seconds seems like the sweet spot.

  • 0 Votes
    1 Posts
    275 Views
    No one has replied
  • 0 Votes
    2 Posts
    745 Views
    S

    Here is the part of /opt/retropie/supplementary/runcommand/runcommand.sh that displays the launching image using either feh or fbi. If you're good with scripting, maybe you could jigger it to play a video with vlc or omxplayer, instead:

    function show_launch() { local images=() if [[ "$IS_SYS" -eq 1 && "$USE_ART" -eq 1 ]]; then # if using art look for images in paths for es art. images+=( "$HOME/RetroPie/roms/$SYSTEM/images/${ROM_BN}-image" "$HOME/.emulationstation/downloaded_images/$SYSTEM/${ROM_BN}-image" "$HOME/.emulationstation/downloaded_media/$SYSTEM/screenshots/${ROM_BN}" "$HOME/RetroPie/roms/$SYSTEM/media/screenshots/${ROM_BN}" ) fi # look for custom launching images if [[ "$IS_SYS" -eq 1 ]]; then images+=( "$HOME/RetroPie/roms/$SYSTEM/images/${ROM_BN}-launching" "$CONF_ROOT/launching" ) fi [[ "$IS_PORT" -eq 1 ]] && images+=("$CONFIGDIR/ports/launching") images+=("$CONFIGDIR/all/launching") local image local path local ext for path in "${images[@]}"; do for ext in jpg png; do if [[ -f "$path.$ext" ]]; then image="$path.$ext" break 2 fi done done if [[ -n "$image" ]]; then # if we are running under X use feh otherwise try and use fbi if [[ -n "$DISPLAY" ]]; then feh -F -N -Z -Y -q "$image" & &>/dev/null IMG_PID=$! sleep "$IMAGE_DELAY" else fbi -1 -t "$IMAGE_DELAY" -noverbose -a "$image" </dev/tty &>/dev/null fi elif [[ "$DISABLE_MENU" -ne 1 && "$USE_ART" -ne 1 ]]; then local launch_name if [[ -n "$ROM_BN" ]]; then launch_name="$ROM_BN ($EMULATOR)" else launch_name="$EMULATOR" fi DIALOGRC="$CONFIGDIR/all/runcommand-launch-dialog.cfg" dialog --infobox "\nLaunching $launch_name ...\n\nPress a button to configure\n\nErrors are logged to $LOG" 9 60 fi }

    You can see where it shows the paths and filename-patterns to look for art, (near the top) and where it defines the accepted extensions (for ext in jpg png; do). You'd want to change this part to include mp4, or whatever format your videos will be in, and possibly also add paths above to include ${ROM_BN}-video or similar if that's how you'll name them.

    Then there's the part where the image is displayed with the feh or fbi commands. You'll need to craft a command with the proper options to show your brief video snap, probably with either vlc or omxplayer. Probably also a check on which extension is used to determine whether to use the video or image command, unless you're going to only have videos, and then you'll need to remove the parts referencing images at all, including the "ports" and system-wide launch images (or change them to use the videos too.)

  • 0 Votes
    3 Posts
    506 Views
    jamrom2J

    Got it. I found the issue.

    Using that CRT/HDMI video mode switcher added a two line statement to my \boot\config.txt that wasn't there before.

    framebuffer_height=1920
    framebuffer_width=1080

    Not sure why it added this, but as soon as I commented and rebooted, my RetroPie core was back to normal size and not shrunken anymore.

    I don't have many statements active in my config.txt so I noticed an extra "list" of other video related stuff at the very bottom. It seemed to have duplicated some of the entries that are in sections above and placed them in the last [all] section of the file. I commented it all out so none of it is active.

    framebuffer_height=1920
    framebuffer_width=1080
    disable_overscan=0
    hdmi_force_hotplug=1
    enable_tvout=0
    hdmi_group=2
    hdmi_mode=82

  • Retropie - Rom Emulator Batch Finder

    Projects and Themes
    8
    1 Votes
    8 Posts
    1k Views
    L

    Hey all, just and update, I've made some revision changes and improvements on the original code. I consider the scripts relatively stable now.

    For detailed changes see:
    https://gist.github.com/Langerz82/ec7c60edd6b02da78018fa113fda27b0/revisions

    Kind regards,
    Langz

  • 0 Votes
    5 Posts
    2k Views
    johnodonJ

    Now that I am back to playing with Wayland/Sway, I found the best solution is what @etheling was doing...using imv as the image viewer. The difference is that I am using runcommand-onstart.sh to display the loading screens so I don't have to mess with editingruncommand.sh. The key is to NOT name you launch images *-launching.png (I use *-launch.png) as this will invoke feh via runcomand.sh.

    #!/bin/bash ROMPATH="$3" ROM_BN_EXT="${ROMPATH##*/}" ROM_BN="${ROM_BN_EXT%.*}" LAUNCHIMAGE="/home/pi/RetroPie/roms/$1/images/$ROM_BN-launch.png" imv-wayland -f -s full -x "$LAUNCHIMAGE" & &>/dev/null IMG_PID=$! sleep 4 imv-msg "$IMG_PID" "q"