Emulator

d70eab544ac48ccd22a36457a4fa12d6 is actually the correct MD5, as listed on GameTDB and Redump.

So if we know what Dolphin build was in play when Ishiiruka-Dolphin first became a thing, it should be easy to track forward and isolate the culprit. Unfortunately, going by forum dates, that puts it somewhere between 3.5 and 5...which is a LOT of ground to cover.

It's not that simple. Ishiiruka has been gradually merging in changes from upstream Dolphin over the years. Besides, that would only let you know that it worked at a certain point in the past, not when it broke.

You mentioned that you're getting the "Wiimote disconnected by emulated software" issue in older builds. Does the first build that does not have that issue have the issue that this issue report is about?

Ishiiruka is an ancient build of Dolphin at this point. This game does have an issue from a while ago, but I don't remember exactly what caused it.

Can you attempt to bisect? Ishiiruka is probably 6 months out of date, so, a dev build from six months ago should work. And then you should be able to bisect and figure out where it got broken.

Also note that this game disconnects the Wii Remote when a GameCube Controller is plugged in. In newer builds, hitting a button on the Wii remote reconnects it, where as in older builds you have to hit ALT F5.

JosJuice wrote:

d70eab544ac48ccd22a36457a4fa12d6 is actually the correct MD5, as listed on GameTDB and Redump.

So if we know what Dolphin build was in play when Ishiiruka-Dolphin first became a thing, it should be easy to track forward and isolate the culprit. Unfortunately, going by forum dates, that puts it somewhere between 3.5 and 5...which is a LOT of ground to cover.

It's not that simple. Ishiiruka has been gradually merging in changes from upstream Dolphin over the years. Besides, that would only let you know that it worked at a certain point in the past, not when it broke.

You mentioned that you're getting the "Wiimote disconnected by emulated software" issue in older builds. Does the first build that does not have that issue have the issue that this issue report is about?

Same problem, yes.

JMC4789 wrote:

Also note that this game disconnects the Wii Remote when a GameCube Controller is plugged in. In newer builds, hitting a button on the Wii remote reconnects it, where as in older builds you have to hit ALT F5.

In my case I'm emulating to an Xbox One controller, and that's all that's connected.

In the New Game menu (assuming I get that far), when it asks you what you're using. If I map the Classic Controller, that's all I can choose. If I have a GameCube controller mapped, the only way I can select it is with X. But in the 5.0 stable, I don't even get that far regardless of whether there's a GameCube controller mapping or not. This is at the very startup "make sure you use your wrist strap" screen where the Wiimote disconnect message occurs and you can't move past it.

I just loaded up Dolphin 5.0 and went past it? I don't know what issue you're having. The game disconnects the Wii Remote itself when it thinks a GameCube controller is plugged in.

JMC4789 wrote:

Ishiiruka is an ancient build of Dolphin at this point. This game does have an issue from a while ago, but I don't remember exactly what caused it.

Can you attempt to bisect? Ishiiruka is probably 6 months out of date, so, a dev build from six months ago should work. And then you should be able to bisect and figure out where it got broken.

I'll give it a shot and report back.

Sad thing about this one, because you have to go through tutorial, it's a VERY slow going process to test every build. That's why I figured it might not be worth trying to even fix because of the time investment just to find it. And if you can't replicate, it may just be a moot point.

Just to make the Wiimote issue clearer, what happens when you press Alt+F5? Does it just show the same message again?

Anyway the Wii Remote issue isn't important as it doesn't happen in the latest development builds.

Do you have any extra settings on?

JosJuice wrote:

Just to make the Wiimote issue clearer, what happens when you press Alt+F5? Does it just show the same message again?

So an update on this and the original issue.

I created a working save on Ishiiruka-Dolphin, exported and then imported into Dolphin to try and test whether it would keep working after the crash point. That worked, so then I booted 5.0 stable up and started a new game - no more Wiimote disconnects or issues. I can no longer replicate the crash.

So something wasn't right somewhere that I overwrote with...something. To do something. And then it worked.

(I work with software for a living) this is the reason I don't like software development. Random weird 'things'.

Anyway, we can probably close as unable to replicate, now that even I can't.

I doubt it's random. Probably a configuration thing at the very worst.

Anyway, please bisect and see if you can find whatever build changed behavior for you. I can't reproduce the issue, so I can't really help much. I did a lot of testing with this game in the past, so, if we do find out what's causing this, hopefully we'll have a jump start to narrowing down why and fixing it.

JMC4789 wrote:

I doubt it's random. Probably a configuration thing at the very worst.

Anyway, please bisect and see if you can find whatever build changed behavior for you. I can't reproduce the issue, so I can't really help much. I did a lot of testing with this game in the past, so, if we do find out what's causing this, hopefully we'll have a jump start to narrowing down why and fixing it.

Likely won't be until tomorrow or possibly Wednesday. As I said there's a LOT of builds and that beginning set of cutscenes and the tutorial just slows things down.

Upnote (maybe), I was able to get it to crash again on Stable and even on Ishiiruka immediately after the following two actions:

• loaded HD texture pack
• switched controllers

It only did it that one time though, but it was again right after a battle's final blow (a bird in front of the chest that's after the first rock skip). After that, both have loaded and have been working. So that might be back to the whole intermittent crash deal with this game I read about on the wiki.

If I didn't know any better, I'd swear it was an issue with one of the assets it needs to load not loading correctly.

Along with the bisect if I can get it to crash again I'll try to also capture a log at that point.

I'm just playing the base game with no enhancements on single core to reduce any non-deterministic variables.

JMC4789 wrote:

I'm just playing the base game with no enhancements on single core to reduce any non-deterministic variables.

So I don't know where my reply went that I thought I left late yesterday, oh well. I had a BSOD so maybe it was lost in draft.

I ran into no dissimilar build behavior, but I was able to isolate the issues down to the cheat function. Specifically Gecko, since that's all I have in there at the moment. If the cheat function is not enabled, everything works perfectly fine. I usually leave the cheat menu enabled across games, so it's not something I think of.

1. Enable the cheat menu, game works fine if no cheats are enabled
2. Enable any cheat, doesn't matter which, game will crash after battle

Now what's strange is, even if I disable the cheats and restart the game completely, it will still crash. The only way to get it to stop is to completely disable the cheat option. This is why I was getting inconsistent test results - I wasn't disabling the cheat option and if I forgot to do the portable file, it was still remembering that setting vs. if it's a full clean install.

So it's fine assuming you don't enable codes for the game, and it's fine if you don't have the cheat menu enabled at all, but if I enable the cheat menu, enable at least one, crash happens until and unless I completely disable the cheat menu, regardless of disabling the cheats afterwards. I can make this happen in every build, and it doesn't seem to matter which code(s) are or are not enabled.

JMC4789 wrote:

Can you bisect when this behavior started? This sounds like a serious, serious bug, especially if it's not happening in older builds.

No, this is happening in every build I've tested, and at this point I've gone through the majority of 5.0 development builds and the 5.0 stable build. That's what I meant by "no dissimilar build behavior". I can make them all crash with the steps.

I'm an old guy. I don't have significant time to invest into the bisect method. I assumed going in, it would just ask me for the crash point or steps, then just scan the code for any changes that would have had anything to do with that crash point and report a smaller list to test. But it just launches each one for manual unit testing.

That wouldn't be an issue if a new build of Dolphin weren't released literally every day, sometimes multiple times a day. It's too much for one person with limited time. And it feels pointless because 5.0 stable will crash too, but bisect can't be limited down to just stable builds.

I'd like to just use process of elimination to see if we can get there faster and with less human effort or at the very least, get the total list down. There are just too many builds and it takes about 2 minutes to get back to the trigger event per build because of the intro logos you can't skip, the loading of the save, walking to get into a battle, the slowness of the battle sequence, etc. And since save states are hard coded incompatible between builds you can't just freeze a state right at the trigger point which would save HOURS of time.

We know that

• Dolphin works fine if cheat menu is not enabled. That means the game is fine, and the emulator in general is fine handling it.
• Dolphin works fine if the cheat menu is enabled with no cheats. That means the code that handles the cheat menu is fine.
• Dolphin works fine on other games where cheats are enabled. That means the issue has to be specific to Arc Rise Fantasia and how codes are handled and/or being applied.
• We knew there was an issue with the 60FPS code and according to the wiki, it's still a problem. The workaround involved speeding up the disc transfer rate and 125 overclock of the CPU.
• According to the issue logged about that, the root cause was how codes are done in Dolphin: they apply at time intervals rather than the traditional (and I may get this wrong) VI hook method.

So, is it possible Arc Rise Fantasia is doing something at the exact moment a battle ends that throws off this last bullet? That's what I'd look at first. But I don't have the tools to trace that interaction; what Dolphin is specifically writing or reading at that specific point that might explain the behavior, which might highlight the problem.

Or can we think of anything in the code that would cause it to throw that specific error and look at that point? Or anything that would cause a dialog that can't be interacted with?

I just think we (or I) don't know enough about what's happening at the moment you land that last hit to isolate builds more efficiently, and because Dolphin completely freezes and won't let me interact with the dialog box at all, I can't stack trace it to see what it's trying to call.

If it crashes in both 5.0 stable and the latest development build, there's no reason to bisect between those builds. You could try some older stable version if you want to, like 4.0.2, but if there isn't an old build where it doesn't crash there isn't much point in testing different builds.

JosJuice wrote:

If it crashes in both 5.0 stable and the latest development build, there's no reason to bisect between those builds. You could try some older stable version if you want to, like 4.0.2, but if there isn't an old build where it doesn't crash there isn't much point in testing different builds.

I did try the very latest 4.0 development build the other day and it still crashed, so again, I'm thinking it's something with how the game's interacting with codes that it doesn't like.

I would say it's probably best to just close this issue or attach it to the other about the changing of code behavior from a timed interval to the VI-whatever, then I'm happy to retest to see if it still happens. But right now it's needle in a haystack with not enough data to work off of about why the game would fail at that exact point.

Thanks to everyone though.