Please don't re-post the same topic multiple times.

@TPR said in How can I create a "list of games" - Just the titles only?:

Clearly, Emulation Station must pull the data from somewhere to display it on my screen so there's got to be a way to instead have it go to a text file, right?

EmulationStation checks if the file exists on disk before adding it to the list, but it still reads from the gamelist.xml.

You can output the game name and the path at the same time and then read the output in a script that would check if the path is still valid before printing the game. Here's a command that outputs a tab separated list of game path values.

xmlstarlet sel -t -m '//game' -v 'name' -o $'\t' -v 'path' -n gamelist.xml

@tpr glad you like it. for basic stuff it was really good.

I just wanted to answer here and ask for more information, then I noticed that you already gave it in your second thread. Please don't open multiple threads about one topic.

I was not able to figure this out. For my purposes, I wanted to restrict access to the other lists anyway as this machine is for a workplace arcade setup so I wanted a very straightforward setup, so I updated the ES config to not allow the B button to work. It loads All Games by default, and I turned off the ability to go from system to system, so for now it's working for me. Thanks for the input that was received.

I thought those errors and the aplay results would be descriptive enough, but I think I left out some key pieces of info. I had added a couple of sound files based on this forum when my first solutions didn't work. I went back and deleted those files and purged pulseaudio. I also set my audio to Headphones in es_settings.cfg. Everything seems to be working, though my splashscreen video is much louder than emulation station.

Edit: This feels like the dumbest question ever. How do I mark something solved? As far as I can tell I'm supposed to edit the title of the thread, but I'm not seeing that option. My only topic tools are to delete the post...

@daviddraper said in MayFlash F500 configuration:

@agrajag Good times. I use my keyboard as my primary controller for my Daphne roms. Intellivision, because of its unique rotating dist controller, strikes me as a pain to use with a fight stick. I have used an 8BitDo SNES style gamepad to play Intellivision games, but it is not ideal.

David,

Dumb question: How do you go about changing controllers? That part of Retropie is a mystery to me at this point. Everything I have running is setup to run on the Mayflash and since it's seen as a generic Xbox controller (and my other controllers are almost all Xbox wired and wireless actual controllers) I'm really concerned about being able to easily switch back and forth.

For example, I want to play the game Dungeon Explorers on SegaCD or TurboGrafx with four of us, but I have NO idea how to essentially remove the Mayflash, plug in four game controllers and have it all just work without screwing up all the work I did to get the Mayflash to work.

thank you!

lucky I took an image to restore from...

BTW - the issue appear with his repo is that if I install his GSplus, it forces an update from raspberry.org and deletes or renames(?) the opt/config folder!

I'll post there. thanks again for the info how to revert.

@Peeteris said in Switching Emulation Station to the TurboGrafx-16 and Genesis logos doesn't work:

IS there any changes in newest Retropie that breaks this functionality?

No, nothing changed here. You're supposed to re-install one of the systems' emulators for the change to take effect.

@hex I know this thread is a bit old but I want to see if there is interest.

I've added three new events to support integration with the Pixelcade LCD Marquee:

game-select
system-select
screensaver-select

How would I go about incorporating these into the main branch?

RussellB

Thanks for the update.

@E3L1 said in Can’t built emulationstation:

@Clyde it’s more.... why can’t raspberrypi release a SBC with a GPU faster that 300mhz.....

Because the Raspberry Pi was never meant to be powerful. It was (and is) developed first and foremost to be an educational device "to promote teaching of basic computer science in schools and in developing countries" (Wikipedia).

@mitu thank you, Mitu! I bought another memory card and it works!! You're the best :)

thanks guys indeed now it works thanks again

Update: Please use PR 560 (note the 6) from now on for testing. Needed to reapply PR since fork and upstream diverted too much. So:

git clone --recursive https://github.com/RetroPie/EmulationStation.git cd EmulationStation git fetch origin pull/560/head:event-scripting git checkout event-scripting cmake . && make ./emulationstation --debug

Yep! Thank you :)

@clyde That's right, edit 10 solved my initial query from the topic post, and edit 9 solved the second problem of poor wifi performance caused by wminput.

I think for most users who are trying to fix the latter issue, wminput -q -w would be perfectly acceptable. This way, wminput will keep searching (-w, waiting) for the Wiimote until it connects (clobbering wifi in the process). The "risk" here is that you can't find your Wiimote, or it's out of battery or something, so your Internet will go dead until you manage to get it synced. For me, when the entire network is relying on the Pi maintaining its connection, I'm better off with it timing out "just in case" the Wiimote isn't available, vs. the extra convenience of being able to connect any time after EmulationStation starts.

The biggest loss here is not being able to reconnect Wii Remotes after a disconnect, e.g. because of drained batteries, especially if it happens mid-game. Presumably you can SSH in and run attachwii again whenever you're ready to reconnect. Not terribly pretty, but for users who need their wifi up it's the best tradeoff I can see, short of changing how you handle your connections (e.g. wired internet, separate Bluetooth dongle, etc.)

There's probably a middle ground somewhere where you have a version of attachwii running in the background that periodically runs an hcitool scan and greps the result for your Wiimote, launching a wminput -q [-w] to reconnect if it finds it. Depending on how often you ran the scan it might not have the same devastating effect on your wifi, and it would otherwise be similar to running wminput -d, in terms of getting you (re)connected at arbitrary times. I'm just spitballing here though, I'm not sure how much impact hcitool scan has on wifi performance on a Pi 3 or other setups where BT/wifi interference is a major issue. For all I know, running hcitool scan constantly is just what wminput is doing behind the scenes that's causing all the problems.

EDIT: I also quickly threw together /home/pi/RetroPie/roms/ports/Attach Wiimote.sh:

#!/bin/bash attachwii >/dev/null 2>&1

This can be run from the Ports menu in EmulationStation to sync the Wiimote without having to exit to command line to do it. It's of limited use, basically just if you forget to connect or get disconnected while you're in the EmulationStation menu. It's no help if you get disconnected mid-game, ssh is still the best option there currently.

Well, I've half-answered my question. I somehow suspected CEC to be an issue, and lo, when I changed hdmi_ignore_cec_init to hdmi_ignore_cec, ES stalls on launch, spits out "lvl0: CECInput::mAdapter->Open failed", runs, and then works perfectly, so it's probably an issue with the libcec I'm using.