Figured it out! Dental Pick!

I'm on 3.8.1 and my PS3 controller is working via Bluetooth just fine. I should mention that it is a fresh install (I did not upgrade from a previous version).

Do you have a PS3? If you plug it in to that and turn it on with the PS button I think it resets itself. Then go to RetroPie setup and try to setup the controller again?

Hey,

I was looking for a way just a day or so ago. Here are some relevant topics:

https://github.com/Aloshi/EmulationStation/issues/371
https://www.reddit.com/r/emulationstation/comments/3gilif/hiding_roms/

I have not tried any of the solutions I've read, but if you try any of this, please report back.

Awesome Thanks !!! That worked.. :)

@mat03111984 Excellent news, glad you were able to resolve the problem

Which emulator(s) are you seeing this with?

I see lots of entries for the same game with the PlayStation emulator, as Emulation Station is displaying all the files which make up the game (at least, all those with extensions it 'recognises', as specified in the es_systems.cfg file for that emulator)

A long while ago I watched one of the excellent RetroPie videos on YouTube from forum user @Floob in which he covers using a tool to combine the elements of a PlayStation game into a single file (Iso, or similar, if I recall correctly), which cleans up the list in ES

In the Spectrum emulator I generally see a couple of entries if I've unpacked an archive file and left both the archive and the original in the Roms directory

Hi,

If you can place a copy of your broken .cfg somewhere, Pastebin, DropBox, etc, I'd be happy to run a diff against versions I have to see if I can find where the problem is.

I think, from looking at the forked github repo for EmulationStation used by RetroPie, and the original parent project, that es_systems.cfg is generated by code - I was hoping there was a full copy of the file in the repo which you could retrieve for any given version of RetroPie.

[edit}
As suspected, the es_systems.cfg is generated when the system is being set up

From the README.md file in the parent project:

"When first run, an example systems configuration file will be created at ~/.emulationstation/es_systems.cfg. ~ is $HOME on Linux, and %HOMEPATH% on Windows. "

@gandarez Hi,

Does the system display the temperature correctly if you issue the following command:

vcgencmd measure_temp

If so, you could run raspi-config, and use option 5 (or similar, depending on your specific version) to access Internationalisation Options, then configure your locale to see if this helps

sudo raspi-config

@Loxley I'm currently using it on my Gameboy zero build without an issue with my controls on version 3.8

Did you ever solve this problem in the end? I had the opposite problem. My splashscreen sound was going through the headphone jack and I had to force it through HDMI. I think you got the order of the line wrong. Try using this:

omxplayer -b -o local --layer 10000 "$line"

I updated to 3.8 and my 8bitdo SNES30 controllers which I set up and used the UDEV file as shown above still worked. I, however, purchased an NES Pro pad and cannot get it to pair. I downgraded the firmware on it to 1.68, but it still does the same thing. When I try and pair it, it is detected and identified correctly. When I select it, and it asks for the security mode and I select EITHER one, it crashes the system and displays the text pictured below. Any ideas?

screen shot

@jayfry I don't have a 2.8 screen but I do have a 3.5 tft from adafruit. I never tried it on a pi3 befor so I installed retropie 3.8 on it and was able to set up the screen using adafruit's guide. I would double check the /boot/config.txt for the correct HDMI settings. Fat-fingering something there can cause it not to display on the tft screen. Also about the Device Tree. It is set on by default as of January 2015. This link from raspberry pi forums will explain it. https://www.raspberrypi.org/forums/viewtopic.php?t=97314. Let me know if this helps.

That, I don't know. It sounds like you've been through a few version updates, so maybe something changed.

you could check the last modified times of the files with ls -l. Maybe one of the updates caused RGUI not to work anymore, and rolling back to using just one of these files will fix it. Maybe. you could compare the files to see what changed during the backup or what's different with the Sony-named vs. non-Sony-named files with diff file1 file2.

I would personally either edit both files or one at a time and see what works and what doesn't, or change the filenames one at a time to something non-.cfg to see which is being used. I haven't had to deal with redundant configs, so now's your chance to learn your system really well and be the new expert and help the next person down the line! :)

No automatic updates, you update through the RetroPie-Setup script.

I didn't predict a glitch of this magnitude would ever happen.

I think everyone has that moment when they learn why backups are so universally recommended. :) Best of luck out there! You'll be up and running again in no time.

@Rion it's a wiki. Anyone can add to it provided the content is valid.

Try here: https://www.reddit.com/r/RetroPie/comments/4ceyty/you_cant_get_cheats_to_work_well_heres_how/

Game Genie codes are only provided for some systems, but there is information in the comments about manually adding more.

@matalog said in Controller index:

@meleu

I have been using this http://github.com/meleu/Retropie-input-selection that you suggested to me, and in game my Wii U Pro controller is always is the first controller, it's great.

your Wii U controller is the first in RetroArch only. It's not the js0. My script only let you change the input_playerX_joypad_index (player1 for the first controller in RetroArch). It doesn't change the /dev/input/jsX order.

Although, if I have a wired controller and my wirreless controller connected - in the runcommand screen that appears just before a game loads, that lets you choose which emulator and video options - my Wii U Pro controller doesn't have any control there. I have to use the wired controller.

Does this mean js0 doesn't have priority until in game or how is the controller that has control on the runcommand screen chosen?

I took a look at runcommand.sh and found this line of code:

__joy2key_dev=$(ls -1 /dev/input/js* 2>/dev/null | head -n1)

This means that runcommand will take the first joystick found in /dev/input/, usually it's the js0. If you are using the wired controller for runcommand menu, I think it's your js0.

(Sorry if my answer is too technical. I hope it's clear. )