project-slippi / ishiiruka Goto Github PK

hello there,

we are trying to add support for your app inside our MacUpdater but it seems there is no single thing that could be used to distuingish Slippi-Dolphin from the real/stock/upstream Dolphin.

CFBundleIdentifier, and all other values in the Info.plist file are exactly the same as 'Dolphin'. even the icon is the same!

is it possible to change something in your app so it can actually be recognized (by humans and other apps or the operating system) that this is not just plain Dolphin but Slippi-Dolphin?

technically the 'right' thing would probably to change your 'CFBundleIdentifier' to an unique value as per Apple's guidelines.

thanks!

Using appimage version from the slippi site. Have to select the directory every time.

For optimal performance/least amount of lag, Slippi should disable the current compositor when in Dolphin is fullscreen although screen tearing will be present.

Similarly to Display Names, we want to provide the slippi connect code for users so they know who they played, especially in unranked.

To do this we need to transfer the connect code between clients so this is a bit of a tougher issue.

Tested only on Windows

repro steps:

1. have browser on the same screen as dolphin
2. start dolphin in full screen mode, have no user.json
3. Ensure dolphin loaded onto the same monitor/screen as the browser
4. Hit Login, which sends focus of dolphin to background, so browser pops up in front
5. Note frozen dolphin

I am trying to play Slippi rollback with my brother who lives within the same house hold as me. We search for eachother using our codes, it sits on searching for a while until it changes to connecting, then fails and reverts back to searching. We tested with 1 of us using a VPN to simulate being on another wifi and it instantly worked. Is there a way to play through LAN with Slippi?

I downloaded https://github.com/project-slippi/Ishiiruka/releases/download/v2.2.0/FM-Slippi-2.2.0-Mac.zip on Catalina/10.5.5 and got "This application 'Dolphin' cannot be opened".

However I could get this artifact from github actions running:
https://github.com/project-slippi/Ishiiruka/suites/919726534/artifacts/11212399

maybe not high priority, but could be fixed by just replacing the release build on slippi.gg

Right now users have to go into the config files and edit the ini, which is a bit cumbersome. We expected users to be changing this value less, but since the usage is higher we want to add this to the Dolphin GUI.

ALT+F4/closing the game during the splash screen will crash the other person's dolphin.

Controller worked correctly with no issues prior to most recent update.
Older versions of faster melee and Slippi also continue to work without issue.

Here's what I've tried so far:

• Installed both libusb-win32 (v1.2.6.0) and libusbK (v3.0.7.0), but no luck.
• Tried two different controllers.
• Restarted machine
• Rebooted Slippi
• Verified adapter is detected w/ a poll rate ~ 13kHz

Any ideas?

Via IP connect or something similar?

Description

When launching a replay using Slippi Desktop App that was recorded with Slippi Online 2.1.0, the game is automatically paused (in-game pause) ~1 sec into the replay and will not continue. Older replays from the previous Slippi Online version still work correctly.

Here is a replay with the issue to reproduce: Game_20200630T082435.zip

Perhaps it has something to do with the new client-side pause feature?

Sys Info

• Slippi Desktop App: 1.4.6
• Slippi Online: 2.1.0
• Platform: Windows 10

Optional Gecko codes enabled

• Optional: Widescreen 16:9
• Optional: Center Align 2P HUD

Hello,
I installed the dev kit 10.14 and wxwidget from source but i get this error when doing cmake ..

`CMake Error at /usr/local/Cellar/cmake/3.16.5/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/usr/local/Cellar/cmake/3.16.5/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
/usr/local/Cellar/cmake/3.16.5/share/cmake/Modules/FindThreads.cmake:220 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
Externals/libusb/CMakeLists.txt:69 (find_package)

-- Configuring incomplete, errors occurred!

Any idea?

Thanks!

generateMetadata() does not get called if a match is ended via LRAS (by either player). This generates replays without dates, player names, etc.

Presumably, this is due to the new changes to pausing. I don't think ending via LRAS generates a CMD_RECEIVE_GAME_END as it did in 2.0.3, so the file is not closed properly with writeToFile(.... ,"close"); This is the same effect as if Dolphin had crashed.

Steps to reproduce

1. Enter an unranked or direct connect match
2. Quit via L+R+A+Start
3. View the replay metadata in the desktop app or slp-parser-js

Falco, Fox, on Dreamland.

Died at the same.

Opponent got peach castle I got select screen. After pressing start game crashed.

Right now we segfault if the Slot B device isn't set to Slippi. We haven't confirmed if this happens on only NTSC 1.02 Melee or all games.

Its back and i have no clue why. I tested it out myself and I agree there does seem to be a difference. Additional notes from people and someone that can look into it would be great.

Users have reported issues with starting games and it stems from the fact that their slippi replay path was empty. All users had non-english characters in their path.

Steps to reproduce:

1. Clone the slippi branch
2. Execute ./build-linux.sh playback
3. Attempt to play a SLP file, e.g.

./dolphin-emu -i INPUT_FILE -b -e ISO_FILE

Result:
The following window pops up. That's it. No playback.

I'm using g++ version 7.5.0.

A number of users have come in with the ability to connect to their opponent after searching and then disconnect before the game starts (generally before Ready is done).

All it does is start to run and dissapear. I don't know why, but it keeps happening. I've tried changing all of my settings, but none of that work. The other builds of Dolphin work fine tho, even Ishiiruka, considering this was built off of that.

We want users to be able to go to the Config->GameCube settings page and be able to toggle replay saving and set their replay directory.

This is a bit of a tougher issue, so anyone wanting to take this on should be prepared to deep dive into the codebase.

Hi Guy's !

Here is the short story : I'm building a smash melee box with Raspberry pie 4 - 8gb of memory.

Don't say it's impossible I DID IT BUT !

PROS:
I can compile with CMAKE :
Dolphin and run it with smash(playable)
TINOB Ishiruka run with smash and reallly playable.

PROBLEMS :
Unfortunately the version I need to compile to play online with smash ladder and tournament is : https://github.com/project-slippi/project-slippi don't work...

I've been trying to compile it and got as far as 99% of compilation adding libs..tweaking code... etc...I got really far actually....but cant run it.

Anybody know...WHAT IS the major change that as been done on developing DOLPHIN that makes it run perfect on RaspberyPi4 with ARM64 ARCH CPU...That SLIPPY BRANCH never got to change: that makes it not working and compiling On ARM64 CPU.

Thanks a lot !

Just so you know I did solve a lot about ARM64 CPU as it would not even start the compilation....

PLEASE HELP ! :0) I've been trying for 6 months and about to surrender ! :)

This may be the wrong place to ask this...

I built dolphin from scratch but noticed that the slippi netplay features weren't enabled and the gecko codes were not available in the properties for my melee rom.

So I then cloned and built the slipp-ssbm-asm repository and copied the Output/Netplay/GALE01r2.ini file over the one I found in the Ishiiruka Data/Sys/GameSettings directory.

This only sorta worked. Now when I run the game I get the 3 menu items, but no text shows up and if I do anything other than press A, the game will freeze and pop this message: "Invalid read from 0x3220270f, PC = 0x803a8a3c"

I suspect that I am missing a step to test slippi, but I didn't see any docs indicating as such. Maybe I missed something? Help would be appreciated.

On a fresh Ubuntu 20.04.1 lts, this shows whenever I load the appimage.
/tmp/.mount_Slippi4zFPMy/usr/bin/../lib/libgnutls.so.30: version GNUTLS_3_6_3 not found (required by /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so) Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so
Maybe it's a dependency issue?

The game seems to run fine offline and online. It just takes around 20 seconds to start the emulator.

Whenever Dolphin creates a new SLP file, the SLP file should have a unique ID. As far as I can tell, IDs are not included in SLP files (please correct me if I'm wrong and close and disregard this PR if that's the case).

Right now, if you wanted to uniquely identify an SLP file, one could currently use the filename (which is not a good way to check for duplicate SLP files), or the actual parsed JSON contents itself. Having a unique key for each SLP file would be much better than this and would help pave the way for a cache of sorts for the Desktop app among other potential useful applications.

We could naively generate some random base64 encoded string as an ID. However, then two Dolphins playing the same game together online would generate two different IDs which is not ideal. We could use a seeded random for example using the time, stage, player characters, player tags if specified, or a hash of those things in order to generate a unique ID. This would allow the two Dolphins to generate the same ID.

Without Slippi in slot B, various things break. Ideally we make it always the default setting for Slot B and keep Slot A's current default. Also it shouldn't break current configs (test with the config in Overwrite)

Users want to know who they played in the replay files. We need to write the display name (if it exists) into the metadata like we do for netplay names.

Should do nothing instead. Might not really be fixable, I forget what I saw when I first looked into the issue.

I've never seen this before so I assume it's a Slippi bug. Falco's animation froze and he started sliding around when I used back throw. I was already charging forward smash by the time I realized or I would have left him to see what happened.

Video here and SLP replay here.

Changes made in 078aa1e appear to cause eaten inputs for Marth's dashdance for me, both while mid-dash and occasionally causing difficulty starting the dashdance (just walks forward a little bit or turns around).

I know rollback's delay is supposed to be equivalent to 8 buffer on r18 1ef6f7b which is supposed to be the most similar to crt, but it feels noticeably worse for me while playing against someone with a stable ~30 ms.

It's most easily noticeable for me when hosting a local netplay lobby at 8 buffer to use unclepunch and 20xx. I tested it on fresh downloads of r18, 2.0.0-2.0.3, and all the builds (clean builds) while bisecting using unclepunch L-cancel training with Marth on FD by spamming dashdance. Nice, quick, and controlled dashdance on r18 but the same inputs have me running off in a random direction on builds starting from 078aa1e.

OS Name: Microsoft Windows 10 Home
Version: 10.0.19041 Build 19041
CPU: i7-6800k
GPU: Nvidia 1080 ti
Adapter: Official Switch Adapter (Zadig'd WUP-028 WinUSB (v6.1.7600.16385))
Controller: Smash 4 White - No electrical mods, good tests
Monitor: ASUS VG27AQ @ 144 hz

Nvidia Settings:

• Gsync Enabled for windowed and full screen mode

dolphin-emu/dolphin#8933

After some testing, we can confirm that this fixes adapter issues for the main offbrand adapter we deal with (pdobq) and it would be good to try to backport the fix.

Via IP connect or something similar?

I already asked this question here but it was closed without a reason.

Obviously this is working in the CI but is there anyone who has this setup locally?

believe I have the sdks

f00@f00s-MacBook-Pro build % ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
DriverKit19.0.sdk       MacOSX.sdk              MacOSX10.14.sdk         MacOSX10.15.sdk

have wxWidgets compiled from source

and ran the brew install

f00@f00s-MacBook-Pro build % brew install ffmpeg libpng libav pkgconfig libao sound-touch hidapi                   
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
Updated 2 formulae.

Warning: ffmpeg 4.3.1 is already installed and up-to-date
To reinstall 4.3.1, run `brew reinstall ffmpeg`
Warning: libpng 1.6.37 is already installed and up-to-date
To reinstall 1.6.37, run `brew reinstall libpng`
Warning: libav 12.3_4 is already installed and up-to-date
To reinstall 12.3_4, run `brew reinstall libav`
Warning: pkg-config 0.29.2_3 is already installed and up-to-date
To reinstall 0.29.2_3, run `brew reinstall pkg-config`
Warning: libao 1.2.2 is already installed and up-to-date
To reinstall 1.2.2, run `brew reinstall libao`
Warning: sound-touch 2.1.2 is already installed and up-to-date
To reinstall 2.1.2, run `brew reinstall sound-touch`
Warning: hidapi 0.9.0 is already installed and up-to-date
To reinstall 0.9.0, run `brew reinstall hidapi`

here's the output from cmake:
https://gist.github.com/DustinAlandzes/07117216f4548f4539b95cbbbe57d515

I saw the Github CI workflow script:
https://github.com/project-slippi/Ishiiruka/blob/slippi/.github/workflows/pr-build.yml#L295

would appreciate help c:

Issue found on Windows, confirmed on Linux as well so I would expect it to also occur on macOS

If the user drags the seek cursor past the left side of the window, the marker will not update position but the game will load the initial savestate.

Steps to repro:

1. Have an AppImage with configuration files in ~/.config/SlippiOnline
2. touch portable.txt in the same directory as the AppImage

Slippi Dolphin loads up fine, but after double clicking the melee iso, I'm met with multiple error dialogs: "Warning: Executable memory ended up above 2GB!" appears 1-3 times, then "Warning: WriteRest op out of range (0x9375d0f5 uses 0x7cd3a8)" appears 3+ times with different hex memory values. And then dolphin crashes/closes entirely.

One thing I found was that if I select a different CPU Emulator Engine other than "JIT Recompiler", the game would run, albeit very slow and not actually playable. But that leads me to believe the problem lies with the default recommended JIT Recompiler.

However, after toiling with it more, I HAVE found a workaround while using the default JIT Recompiler, which is to select the default ISO as melee and have it run the default ISO upon dolphin start, and to uncheck "Use Panic Handlers" (not sure if that part makes any real difference, other than squelching pop-up errors). With this method, I can get dolphin to start and run the game about 20% of the time, and the other 80% it will run and then crash/close immediately. Not sure why loading the ISO immediately on startup is more effective than dolphin loading my game folder list first and then choosing an ISO, but I hope that helps determine root cause.

I am running the following:
Slippi 2.2.1 w/ an authentic SSBM 1.02 ISO
macOS Catalina 10.15.6
Intel i9 9900k
32 GB Memory
Radeon RX 5700 XT 8 GB

Also, for sanity, I ran the same SSBM ISO on a vanilla dolphin emulator (dolphin-emu.org) with 100% success. Build version was 5.0-11991.

Users are seeing Dolphin crash with no way to figure out what was causing the crash. We need the stack trace to be written to the User/Logs folder as stacktrace.txt (append by default) whenever an unhandled exception occurs.

Summary
When user attempts to open Dolphin from Windows UI, it opens then closes instantly..

• There are no reports or logs generated in User/Logs
• Running Dolphin.exe -d or Dolphin -l still creates the same issues with no logs or stack trace created

Steps to Reproduce

1. Open Dolphin

Expected Results
Dolphin executable opens and remains open for user interaction

Actual Results
Dolphin immediately closes

Mitigations Attempted

• Restarted Computer
• Re-installed Slippi
• Enabled / Disabled Fast Boot
• Un-installed and Re-installed VC 2019 Redist

Details on reporter computer
OS: Windows 10 v1909 build 18363.900

Issue found on Windows, haven't tested macOS or Linux.

Ever since we enabled Pokemon Stadium for Slippi Online we've gotten a number of reports that the game was crashing only on Pokemon. The commonality between all the cases was that texture scaling was enabled.

Some users have come to us saying that their adapters no longer work after 2.2.1.

I have a testing channel in discord, just @ Nikki and say you have the issue to get access to it

Noticed this while watching Fizzi's stream. If you're trying to play with someone and they disconnect, you have to keep entering the same connect code over and over. By keeping the last entered code, you would avoid that at the expense of needing to clear the field when entering a brand new code.

This also helps when you get like server errors, which are still somewhat common.

P1 vs. P2
P1 pauses and alt+f4's
P2 is therefore stuck in the pause screen and is forced to restart.

Not sure if this is intentional or not but thought it would be worth looking into.

On a fresh install, no Gecko Codes show up.
I've verified that the Melee ISO hash is correct and that I'm actually running the Slippi Dolphin build.

Unsure if related (might need a separate issue), but icons seem to be missing:

Confirmed on Windows, unsure about macOS/Linux.

Occasionally, the timer and seekbar don't work on first load. The seek cursor will be stuck at the start of the seekbar and the timer will get stuck at 00:00/00:00. This can be mitigated by interacting with the seekbar, but ideally it never happens in the first place.

Giga-Bowser will work if player 2, otherwise will crash dolphin for both players.
Sopo works fine as either player.
Wireframes will always crash.

Not tested by me:
Hands, ive heard they always crash
Sandbag ?

Issue found on Windows, not as big of an issue on Linux (tested on Arch, works 99% of the time), unsure about macOS.

During playback the user has three options for seeking backwards, they can press left arrow, hold the seek arrow and drag it back, or click a spot on the seek bar. The third option is not consistent, where sometimes you need to click a few times for it to work.