RetroArch 1.4.1 Netplay
-
Not to bump but did anyone find a work around to get netplay working again?
-
Until the RetroPie team is able to implement an appropriate fix to it's own method of dynamically launching with netplay, you should be able to treat RetroArch as if it was no different from any other installation and statically set all the necessary configs in
/opt/retropie/configs/all/retroarch.cfg
. As is to be expected, it'll just take a fair bit of trial and error to get it straight between the two setups. -
This might have actually been fixed a couple of days ago...
https://github.com/RetroPie/RetroPie-Setup/commit/387b2d19be8eaf5515e9e049e3046c210e1549f4
https://github.com/RetroPie/RetroPie-Setup/commit/ecc75e6d7b39f20a988d7847edd13c31a827467cIf you update the RetroPie-Setup script and do a full update, you can test to see.
-
It seems to be working great now. The other thing people need to remember is you need to be on the same version of the same core. For example if you download the core list on a windows install of retroarch and decided to startup a game of SMB 3 of FCEUmm then the git version beside the core will show 4 something where the core on an install of retropie will show git 3 something. You'll need to run the Retropie update script and I chose to rebuild all the core's from source. You may find doing it from binary's works but I'm not sure how quickly they are updated and knew the source would be the newest. Using this method I was able to make a retopie on rpi3 work and netplay with a brand new windows installation of retroarch.
-
Can you help me with a few bits please. What do you mean by "Windows Install of Retroarch"? Is that a different installation process to that of updating core packages from source or binary?
Do you mind writing out the exact steps e.g. 1.) Go to X 2.) Update from source etc?
My retro arche says 1.4.1 - No Core but the core I believe is the emulator so I guess we need to check that we are using the same emulator which we might not have done.
-
It seems there is a subdomain now that shows the open netplay games: http://lobby.libretro.com/
-
@eDrinker By windows install I mean installing retro arch on my windows laptop to test.
What you need to do is go to the run command and update all your cores from binary if you're on 1.4.1 if you notice when you go to the GUI in retroarch while you're playing a game, at the bottom you'll see the name of the emu ie. FCEUmm then git 318a5bdf or something along those lines.
The git # is the important part of this. You have to update it to be sure you're both on the same VERSION of the emulator core.
Once done and verified you're both on the same git # of the core you'll be using to netplay then verify your port is open if you're the host.
Next verify you're using the same rom. After that you've got smooth sailing.
-
@Swagman89 said in RetroArch 1.4.1 Netplay:
318a5bdf
Yeah we checked this "318a5bdf" and it was the same. I have no doubt the windows version works.
It's Pi to Pi that I can't get working and I haven't seen anyone else confirm either.
-
Ok so there was an update to 1.5.0 and it works now. It takes the config file from retropie settings and then retroarch netplay menu. We set one client and one host and same ROM and emulator and bingo. You can also connect in game by select x and connect to host. So manual is fine.
Net rooms doesn't state the game or at least I dont think so as I cant find comparable content with anyone.
My next question would be in retro arch settings and network. You have input and frames. You can set either 0-15. We found 6 and 6 was smooth from Spain to UK but I don't understand the difference even with the explanation. There's a bit of input lag and maybe they don't have to be the same so I'm unsure. A bit more tweaking but great stuff. Any advice on frames vs input please config in network would be appreciated.
-
I wasv talking about Pi yo Windows btw!
-
Every once in a while I look at this again and on my last attempt, I learned something about the new quick connect feature. As it's still mostly undocumented at the moment, some of the information I was looking at previously was supposition on various forums. This time, I started a game of 'Dr. Mario' with verbose logging and just let it sit.
Whenever someone tries to connect with me and fails I get a error that reads "Failed to receive netplay info payload." Searching for that error gave no results, but breaking it down to the three keywords, "RetroArch", "netplay" and "payload" took me to this github page. There it lists all the possible netplay payloads, including one named "Info". The description of the info payload reads:
Command: INFO Payload { core name: char[32] core version: char[32] content CRC: uint32 } Description: Send core/content info. Mandatory handshake command. Sent by server first, then by client, and must match. Server may send INFO with no payload, in which case the client sends its own info and expects the server to load the appropriate core and content then send a new INFO command. If mutual agreement cannot be achieved, the correct solution is to simply disconnect.
This falls in line with the visual errors that were being shown with the yellow text prompts on my previous attempts where the potential second player was being turned away for not having the right core or ROM. I looked to see if the log had registered the CRC of my ROM, even though I have not scanned it in and sure enough it had. I still believe that it likely references it's own database mentioned above, so it can name the game being hosted in the room selection menu, but the extra step of scanning to the library doesn't seem to be needed, which will make this a lot easier for RetroPie users.
Given that my previous attempts most commonly blamed mismatched RetroArch software for the failures, I think the main connection issue here is less about the ROMs and more that the people trying to connect don't have matching cores to RetroPie. When I look to see what others are using, it always seems to be a standard version number of some kind, whereas RetroPie users have a version that begins with "git". As a result, I think it's going to be more common for RetroPie users to be able to connect and play with other RetroPie users and not with anyone else, but I may be mistaken. Even if that's true, it would still be quite a number of people who we are able to connect with do to the popularity of the project.
-
In my experience it just depends on the core. Git is just a way to show it came from github I believe. The newest PCengine Core does not use the git prefix while something like fceumm does. I will tell you that cores that are downloaded by default from an install on a PC are the same (if done at the same time (for the most part!))as what is found on a RetroPi
-
@Swagman89 said in RetroArch 1.4.1 Netplay:
(if done at the same time (for the most part!)
I hope so, but the smallest discrepancy in version numbering makes all the difference between matching and not and I've seen quite a few examples this evening that didn't line up. I just spent a good bit of additional time testing on multiple cores and I've found that after the recent changes referenced above, launching with netplay enabled from the runcommand now works with both manual and quick play methods of netplay connection without any additional settings beyond configuring the 'RetroArch Netplay' in the RetroPie menu of Emulation Station.
Also, anyone who hardcoded their nickname earlier, no longer has to. -
Well, I've finally got the quick connect netplay lobby feature to work and it really is pretty keen.
launching with netplay enabled from the runcommand now works with both manual and quick play methods of netplay connection
Turns out that three quarters of that statement was correct. Launching netplay using the current runcommand option in RetroPie will cover manual host, manual client and even automatic host. However, getting it to work as an auto client for the quick connect matching feature requires that a RetroArch session be aware of the following:
- Core location
- Core information
- Rom location
- Rom Information
It then uses all that to pair a netplay session. The problem is that after RetroPie launches a RetroArch session from the command line, it doesn't have a record of even where the currently running core is located, let alone what it is and what it is capable of running. The same is mostly true with the currently running ROM. Once the user selects a potential match from the lobby, RetroArch needs to reset the environment, but is at a loss as to the location of the necessary components to make it happen.
When it's all said and done, the RetroPie team will have a streamlined way to handle this, but for anyone who wants to jump into some quick netplay action right away, I have a working solution that should suffice until this can be officially implemented in a more elegant way.
First, add the following to
/opt/retropie/configs/all/runcommand-onstart.sh
if [[ "$2" = "lr-"* ]] then mkdir /tmp/lr-core ln -sf /opt/retropie/libretrocores/$2/*.so /tmp/lr-core/ fi
Then, add the following to
/opt/retropie/configs/all/runcommand-onend.sh
if [[ "$2" = "lr-"* ]] then rm -r /tmp/lr-core fi
Next, add the following two lines to
/opt/retropie/configs/all/retroarch.cfg
libretro_directory = "/tmp/lr-core" netplay_nickname = "YourNicknameHere"
The rest will be done inside RetroArch itself, so now launch any game that you have set to open in RetroArch and invoke the RetroArch menu 'Select+X'. From there, navigate to 'Online Updater' and select 'Update Core Info Files', followed by 'Update Databases'. Once that is complete you'll want to navigate back to the root menu and then to 'Import Content' and then 'Scan Directory'. This can take A LOT OF TIME, so you may just want to do a single system at first. Even then, it can take quite a while. When it's complete, anything you just scanned is ready to be hosted and paired to automatically.
I know this seems like a lot of effort on it's face, but once it's going, you can just launch the game you want from Emulation Station, navigate to 'Netplay Rooms', hit 'Refresh' and pick a hosted game to connect to. Of course this is all still contingent on using the same core/core version and ROM as the host, but when it all comes together, it really is an improvement and I think it'll have a massive impact here on the forums for those who want to connect and play painlessly without having to post their IP address openly.
-
Very excited about all of this! Thanks for all of your work testing this out! I tried to get this working a year ago long before the RetroArch update, and nothing we tried seemed to work.
-
followed by 'Update Databases'. Once that is complete you'll want to navigate back to the root menu and then to 'Import Content' and then 'Scan Directory'. This can take A LOT OF TIME, so you may just want to do a single system at first.
So this database scan only needs to be done the first time (only once)?
Unless you have added new ROMs, you shouldn't need to run it everytime you want to use the Netplay Rooms?
-
That's correct. The two main pieces of information it keeps afterward for each game is the location of the ROM file and its CRC32 identification.
-
To avoid the lengthy scanning process for any systems that aren't currently working with netplay, you can reference this page from the netplay author himself, detailing his own findings on the current state of compatibility.
-
I just tested out spectator mode and it worked as well. I joined someone's SNES 'Secret of Mana' game and it was a little bit choppy. I probably slowed the player's game down as well while I was connected. There are frame-related settings to fix that, but I don't want to wreck a bunch of people's games trying to figure it out.
-
@mediamogul thank you for posting this detailed walkthrough for configuring Netplay in Retropie.
Hopefully @BuZz has plans for integrating/automating these required steps to get Netplay working.
I haven't yet tried this method, but haven't had any luck with the default Retropie Netplay configuration.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.