I dropped the new aarch64 275 mame binary for rpi3,4,5.

@boxwine-exp

I mean about this script

https://github.com/GeorgeMcMullen/rp-box86wine

@mitu

pi@retropie:~ $ locale -a
C
C.UTF-8
en_GB.utf8
POSIX

this is what I get with that command. I don't think I've change any sort of system/user language..

After applying apt-get install python3-venv I was able to install dbar4gun successfully, but I still can't actually get the wiimote working.

Wow, this is amazing and very helpful. Thank you very much!

@mitu Awesome! Thanks.

Now I officially announce the release of Skyscraper 3.15. (3.15.3)

As always find the changes here

Update the RetroPie setup before you update Skyscraper to get a new helper script deployed (which you may use when you get the shown warning below).

Important: In some cases you may get a warning when starting Skyscraper

Looks like '/home/pi/.skyscraper/peas.json' has local changes. Please transfer local changes to another file to mute this warning. See topic 'Transferring Local Platform Changes' in the documentation for guidance.

Why do you get this warning?
This happens when you made changes to the peas.json or platforms_idmap.csv in the past, which was intended to be that way.
See the documentation here on how to remediate the situation.

A later release will change the current behaviour of the RetroPie scriptmodule of Skyscraper and will no longer put updated peas.json as peas.json.rp-dist (same for platforms_idmap.csv). Instead it will always replace your existing ~/.skyscraper/peas.json / platforms_idmap.csv with the upstream version. Thus, do follow the guide, when you get the warning.

There will be an extra announcement when a new Skyscraper version will change the copy behaviour. But as there is no ETA for 3.16 we are talking at least about months.

Any questions let me know.

@mitu i'm going to try it! maybe I need to adapt the flags on my system and it will work!

@kelvfimer

Cool !
I agree.

@Retrodade said in Tutorial: Handheld and Plug & Play systems with MAME:

@Folly said in Tutorial: Handheld and Plug & Play systems with MAME:

MAME Sets & Datfiles

Thanks, I updated and updated MAME but they boot back.

Run mame with verbose mode and check the /dev/runcommand.log .
Then you can find what's wrong.

Do I need to add the Datfile somewhere as well?

No

I seen pi didn't say MAME had an update, so am I trying to0 early perhaps?

You should check your version of mame.
Run a game that still works and use "tab" to go into the UI and check "about".
Or check your /dev/runcommand.log after trying to run a game in mame with verbose mode, this might also reveal the version.

If you have an old version, like 0253, and you recently updated the binary via the RetroPie-Setup then there is no new version for the original RetroPie image available.
If so, then this is due to the underlying older linux operating system which cannot run newer compiled mame binaries or canniot compile newer mame source-code anymore.
That would mean that you are stuck with using old roms and an old version of mame unless you create a new linux image, with a newer OS, by yourself with installing RetroPie on top of it.

If you still can't find a solution then I recommend you open a new help thread.

@retropieuser555 very cool

I created an account just to say thank you for this!

@sugarfree yeah, it's kinda what I had in mind.
I'm not very practical about shell scripting, however from what I could grasp it seems that they're creating a whole new mapping script to create evdev mappings.
Since I was trying to create a Python script that was going to be launched when a ROM had been selected and didn't want to add more dependencies, I tried to use SDL2 as library in my script: however the naming a of the buttons are extremely different from what you could get from evdev and had to make an intermediary translator between evdev and Dolphin passing through the SDL mapping of that gamepad.
Their solution is far more practical. However I think one of their bigger limits is that the script essentially creates a Dolphin profile for each gamepad, basically a 1:1 mapping between the gamepad and the GameCube controls. For the GameCube I think it's a pretty neat solution. Different matter is when you try to apply the same strategy when mapping a Wiimote: one profile isn't enough since you can have more peripherals setups on a Wii.
Two things I could think of are: making a profile for each possible setup (Wiimote, Wiimote+Nun chuck, Wiimote+Classic Gamepad etc...) and asking at each ROM load which profile should be loaded to each player, probably with a nice whiptail+joy2key TUI; or creating on the fly a configuration after asking which peripheral setup the player wants.

@retro777
one things,, new report

my emulator.cfg is here

ikemen-go-nightly = "XINIT:/opt/retropie/supplementary/ikemen-go-nightly/ikemen-go.sh %ROM%"
ikemen-go = "XINIT:/opt/retropie/supplementary/ikemen-go/ikemen-go.sh %ROM%"
default = "ikemen-go-nightly"

and, run .mgn on emulation station,display this.

"No config found for system mugen"

Which place do i check and fix??

es_systems.cfg here

<system>
<name>mugen</name>
<fullname>M.U.G.E.N</fullname>
<path>/home/pi/RetroPie/roms/mugen</path>
<extension>.mgn</extension>
<command>/opt/retropie/supplementary/runcommand/runcommand.sh 0 PORT mugen %ROM%</command>
<platform>pc</platform>
<theme>mugen</theme>
</system>

@mitu thanks for the heads up, will do.

@retropieuser555 said in Dolphin - GameID Identifier script help:

Ok dokay, I'll take a look. Is it usually Sony controllers that seem to have the issues? Or am I reading into that too much?

No, it's not a rule - it's just something I noticed at the time with the gamepads I tested.

First thought, it'd need to be done at the configscript point from ES mapping, as that's the point when the controller will be connected. Unless the input configuration script is run without the controller plugged in. Which I think is unlikely from a user perspective.

You can search at runtime and - if found - store it. I'm not sure if there's a rule, but tend to no assume that the device is connected and look only at the values given.

I'd envision searching for keywords to match SDL against evdev name, the only trouble is if the user has multiple controllers connected it may get it wrong.

Arcade cabinets have always controller(s) connected.

You can copy the main inputconfiguration.sh config script and then modify the path where the configuration scripts are, pointing to your own script folder (i.e. the Dolphin mapping script). You can run the script manually so you don't have to go through EmulationStation each time you want to run your mapping script.

To get more details when running a script, use either bash -x <scriptname> to see a step-by-step execution trace or modify the script header (1st line) to use bash -x for execution