mame
mame copied to clipboard
mamedev
segaufo.cpp- BGM cannot switchable by DIP switch
MAME version
0.270
System information
Windows 11 Intel Core i7 Nvidia GeFore RTX
INI configuration details
No response
Emulated system/software
segaufo.cpp / UFO catcher 21
Incorrect behaviour
DIP1-1: 1 coin as 2 PLAY DIP1-1: 1 coin as 3 PLAY, 2 coins as 6 PLAY, 3 coins as 9 PLAY DIP1-4: 1 coin as 6 PLAY, 2 coins as 9 PLAY DIP1-8: 2 coins as 1 PLAY, 3 coins as 2 PLAY DIP2-4: Advertise BGM NORMAL #2 ? ON DIP2-8: Advertise BGM NORMAL #1 ? ON DIP2-10: Advertise BGM CHRISTMAS ON
Expected behaviour
DIP1-1: 1 coin as 2 PLAY DIP1-1: 1 coin as 3 PLAY, 2 coins as 6 PLAY, 3 coins as 9 PLAY DIP1-4: 1 coin as 6 PLAY, 2 coins as 9 PLAY DIP1-8: 2 coins as 1 PLAY, 3 coins as 2 PLAY DIP2-4: Advertise BGM NORMAL #2 ? ON DIP2-8: Advertise BGM NORMAL #1 ? ON DIP2-10: Advertise BGM CHRISTMAS #1 ? ON -> Christmas BGM #1~3 can be changed by DIP2-4 or DIP2-8 combo
Steps to reproduce
While DIP2-10 is ON, any of DIP2-4, DIP2-8 combo will cause Error beep. 2-10 + 2-4 = Error 2-10 + 2-8 = Error 2-10 = Christmas
Additional details
Not sure all of the combo of DIP SW but it looks like DIP2-4 / DIP2-8 / DIP-10 will work for BGM control.
Thanks a lot for letting us know and for the investigation!
It's very strange that nothing happens, I would definitely have expected some action. It's much like the path is rejected between picking it in the modal dialogue and passing it on to the UI. Can this be? CC @ndom91
There's a special case for trying to open wsl.localhost paths it looks like (see: apps/desktop/src/lib/backend/projects.ts:162). Are you using the windows version of GitButler by chance? If you're planning to use it with projects in WSL2, we recommend installing GitButler in WSL via our linux packages.
Sidenote: I think Gitbutler is going to have trouble with network mapped locations on linux as they generally don't trigger inotify events. This will have the adverse effect of not showing updated files / hunks in GitButler when you save changes to them.
At least thats the case with normal sshfs or nfs mapped locations, maybe windows / wsl2 does something special here though.
Yes, using GitButler from Windows.
I've used the Linux version from WSL in the past and it was OK, but window painting is a bit odd at times.
In any case I'm happy to close this issue and suggest updating documentation with this recommendation for users who are on Windows and check out repos in WSL.
Please confirm your recommendation is to close without further action.
Yes, using GitButler from Windows.
I've used the Linux version from WSL in the past and it was OK, but window painting is a bit odd at times.
In any case I'm happy to close this issue and suggest updating documentation with this recommendation for users who are on Windows and check out repos in WSL.
Please confirm your recommendation is to close without further action.
Yeah that is our recommendation when working with projects in wsl2. I'll make sure that something is added to the docs in regard to this as well 👌
On further thought--should this be an improvement in the app? The issue is that there's no messaging at all to the user. Displaying something like
Managing repos on network paths is not supported. If you are attempting to manage a repo hosted on WSL from a Windows client, please install the Linux version in WSL instead
would resolve this.
I see. Well, there's nothing in the logs. I'm looking at
C:\Users\andrew\AppData\Roaming\com.gitbutler.app\logs\GitButler.2024-09-23.log
@andrew-rosca yeah so that's the correct log file.
I just double checked and it looks like in this showError function from the screenshot above we're only showing a toast message, not logging anything. Therefore, the fact that you're not seeing anything is actually the expected behaviour at the moment. Sorry about the confusion!
Did you also not get the toast error?
That's super interesting insights, thanks for sharing, @ndom91. It will be an interesting thought to which extend GitButler could be made to work even without disk events. First of all, right now I think the UI relies on 'triggering itself' for updates, which is unnecessary as it could know when it should refetch state based on its actions, or its actions could return exactly the state that it would need right after.
Maybe then it would be possible to detect if events are working, and offer a refresh button instead to see worktree updates for example (or simply poll for updates regularly or prior to certain operations).
In any case, being less dependent on filesystem events will be beneficial for the correct functioning and performance of the application.
Regarding this issue, I agree that we should figure out why there was no error message in this case so the rejection is made known to the user.
Yeah I like the sound of that a lot.
I also, for example, see the file watcher no longer work as expected relatively often when using the appimage on a "normal" Linux system. It always works at first, but then frequently seems to stop responding after a while (30m-60m). I haven't had time to dig into it further, but suffice it to say, there seem to be more than just 1 or 2 edge cases where the current file watcher doesn't behave as expected.
Regarding the error messaging in this wsl specific scenario, I can take care of that today. I'll add logging and see why the toast doesn't appear.
@Byron as we're in the middle of a bunch of feature work at the moment, this isn't something any of us have time for right now, but I definitely want to take a closer look at this eventually and potentially implement your idea. So I'll create an issue and we can follow-up specifically on the filewatcher improvements there :pray: