search

altf4 / libmelee

Open Python 3 API for making your own Smash Bros: Melee AI that works with Slippi Online
GNU Lesser General Public License v3.0
237 stars 47 forks source link

Error running dolphin #56

Closed nathan-miller23 closed 4 years ago

nathan-miller23 commented 4 years ago

I followed your setup instructions by building dolphin from the commit here and installing your PyPI package. I run run ./dolphin-emu and interact with the GUI just fine. However, when I try to start the game, I get the error

This does not seem to be a copy of Super Smash Bros. Melee. Please use regular Dolphin (https://dolphin-emu.org/) for running games other than Super Smash Bros. Melee.

I am confident it is not an issue with my ISO. I verified the checksum, and it works with both the official version of dolphin, as well as the slippi r18 build. My question is, should I be building dolphin from the exact commit I linked or is there a different version used to reproduce your results?

Command

Run ./dolphin-emu and manually select the ISO from the GUI. Running ./example.py -e PATH/TO/DOLPHIN breaks with the same error

Expected Behavior

I should be able to launch the SSBM game either from inside dolphin or from the example.py script

System info

OS: Ubuntu 18.04 Python 3.6

altf4 commented 4 years ago

That's definitely Dolphin complaining that the ISO is wrong. I'd double-check that you're using the ISO that you think you are.

nathan-miller23 commented 4 years ago

Thanks for the reply! Like I said above, I am confident I have the correct ISO, the checksum is 0e63d4223b01d9aba596259dc155a174 which uniquely identifies the v1.02 NTSC ISO. I can, however, properly run the game by building the dolphin linked in the slippi branch of your forked repo here which tells me it's likely a bug in the gamma branch build.

I guess my main question is whether it's essential to build exactly the dolphin version linked in the setups, and whether using the one I linked above will cause issues down the line. I really like your code here, it's by far the cleanest melee environment code I've seen, and I want to make sure I can get everything working without any weird dolphin errors

altf4 commented 4 years ago

Actually, the spectator server just got released into upstream Slippi. It should work without needing to build anything from source at all anymore. Though I haven't tested it yet myself. Definitely will shortly.

altf4 commented 4 years ago

Slippi support is here! There's just one minor-ish issue still using the Linux appimage and gecko codes I still have to hammer out.

nathan-miller23 commented 4 years ago

Thanks for all the updates! I'm excited to interact with a repo author who is actually responsive. So the way I understand it, I can either boot up a Slippi-dolphin process on my local machine, start hosting a game as a spectator, and have libmelee connect to that game using the SlippiStreamClient, or I can manually run the dolphin process as a subprocess spawned by the libmelee console class. Are you saying that I can now do both of these things with the Slippi distribution of dolphin? Because so far I have failed to do both.

When I run console.run(iso_path='/path/to/iso'), it boots a starts a dolphin instance, but then controller.connect() hangs when it tries to open the pipe with which it will try to communicate with dolphin.

Running console.connect() fails to find my locally hosted slippi spectator server.

My use case here is fairly simple: no online play, just want to be able to play bot v bot and human v bot games, both with and without rendering. Is that at all feasible with this library?

altf4 commented 4 years ago

If you're using the Linux appimage, use this as a gecko code: https://gist.github.com/altf4/6679f2f050520fe9d65eedc8630955f3

It goes in .config/SlippiOnline/GameSettings/GALE01.ini

I'll fix that up to be clearer / more obvious soon. But you'll want that.

As for your questions: 1) Libmelee can launch dolphin for you, but doesn't need to. If you execute console.run() it will run the console. But you can very well just connect to an already running dolphin.

Have you seen the sample code here? https://libmelee.readthedocs.io/en/latest/#quick-example

2) Are you using the appimage install of dolphin? Make sure you're updated, as I recently added some things in 0.18.0 that's relevant to the Linux appimage.

nathan-miller23 commented 4 years ago

I was using both the linux appimage as well as the macos version, and it appears the issue in both cases was mis-specification of the dolphin_user_home path. Pulling in your changes and adding some minor tweaks, I was able to get everything working! Woo!

nathan-miller23 commented 4 years ago

My last question, however, is kind of unrelated, and there's already a separate issue opened for it it seems, so if you'd rather migrate discussion there just let me know, but I'm wondering how much tweaking it would require to get the null rendering working again. It appears Slippi has no plans to support the null renderer, but it does appear to be working just find in vanilla dolphin. I'm wondering how difficult it would be for me to adapt your code to work with upstream dolphin instead of slippi. My aim is to train RL agents here, so netplay is not required, but the speed boost offered by the null renderer is essential to training.

altf4 commented 4 years ago

Just to be clear: is version 0.18.0 working "out of the box" for you? Or did you have to adjust some things?

As for the null renderer, there's two options: 1) Wait. There is a project underway already to migrate Slippi to upstream dolphin. (Away from Ishiiruka) When that actually happens, we'll have the null renderer. 2) Port the null renderer yourself. I haven't looked into how hard it would be. It may be very simple, it may be quite hard.

As for using upstream dolphin itself, it won't work well. Trust me, you want to use Slippi. I actually deliberately moved all of smashbot's backend away from mainline and TO slippi.

nathan-miller23 commented 4 years ago

Just to be clear: is version 0.18.0 working "out of the box" for you? Or did you have to adjust some things?

It worked out of the box on ubuntu but failed on Mac because the dolphin user directory wasn't where libmelee thought it was. I fixed this by making dolphin_user_dir a parameter to the console so I could configure it for my specific directory structure.

As far as getting upstream dolphin to work, it appears other users like this guy have done it a long time ago, but I for the life of me couldn't replicate it, so I think I'll stick with Slippi like you recommended. I'll poke around the slippi source code to see if I can implement a hacky null renderer, but otherwise plan to wait.

altf4 commented 4 years ago

It worked out of the box on ubuntu but failed on Mac because the dolphin user directory wasn't where libmelee thought it was. I fixed this by making dolphin_user_dir a parameter to the console so I could configure it for my specific directory structure.

Good to know. I don't have a mac to test on, so it's tricky to debug there. I'll try looking into that.

As far as getting upstream dolphin to work, it appears other users like this guy have done it a long time ago, but I for the life of me couldn't replicate it, so I think I'll stick with Slippi like you recommended. I'll poke around the slippi source code to see if I can implement a hacky null renderer, but otherwise plan to wait.

Yea that's xpilot. Who actually just recently switched everything over to libmelee / slippi too. :) So yea, I would not recommend trying to use upstream.