Emulator

Edit: I used Windows 8.0 to test this, but it has also been reported on other OS's, such as Windows 7.

Duplicate of https://bugs.dolphin-emu.org/issues/8974

Fog wrote:

Duplicate of https://bugs.dolphin-emu.org/issues/8974

That post has nothing to to with this one. This one has been a problem for a long time, and it is simply that you cannot find the start of the game's RAM address. You would normally find this by searching for the game ID as a string, and it would show up as xxxx0000, but this doesn't work with versions of Dolphin after 4.0.2.

Apolgies, misunderstood 8974.

Cheat Engine was working for me up on version 4.0-6734, so I'm not too sure where it broke.

Cheat Engine was working for me up on version 4.0-6734, so I'm not too sure where it broke.

I just tested 4.0-6734, and it has the same problem as all the other newer versions of Dolphin.

I can use Cheat Engine up to 4.0-7365 at least, on 64-bit as well.

You have MEM_IMAGE and MEM_MAPPED checked in Cheat Engine's Edit -> Settings -> Scan Settings, right? At least one of those is important for Dolphin scans.

If that's not it, I believe one of the game properties settings caused problems for my Cheat Engine scans at one point. I want to say it was Synchronize GPU Thread, or maybe something related to MMU. So you could try messing with one of those settings.

yoshifan wrote:

I can use Cheat Engine up to 4.0-7365 at least, on 64-bit as well.

You have MEM_IMAGE and MEM_MAPPED checked in Cheat Engine's Edit -> Settings -> Scan Settings, right? At least one of those is important for Dolphin scans.

If that's not it, I believe one of the game properties settings caused problems for my Cheat Engine scans at one point. I want to say it was Synchronize GPU Thread, or maybe something related to MMU. So you could try messing with one of those settings.

I have those settings checked in Cheat Engine, and it still doesn't work, even for that specific version of Dolphin that you specified. I messed with those settings as well, and got no different results.

Perhaps I should specify: I can load up Dolphin 4.0.2 and do the scan for the game ID, and I will always find the address that it is supposed to be. Then, I can open a newer version of Dolphin, open it in Cheat Engine without messing with the settings at all, and do the scan, and the correct address will not show up. So to sum that up, Cheat Engine is not the problem.

Hmm... so on newer Dolphin, what addresses does the scan turn up for you? I actually tend to get 3 or 4 addresses ending in 0000 when I scan with a game running. For example, on 4.0-7365 I get 7FFF0000, 27FFF0000, 2FFFF0000, and 33FFF0000.

yoshifan wrote:

Hmm... so on newer Dolphin, what addresses does the scan turn up for you? I actually tend to get 3 or 4 addresses ending in 0000 when I scan with a game running. For example, on 4.0-7365 I get 7FFF0000, 27FFF0000, 2FFFF0000, and 33FFF0000.

Those addresses do show up, but they will not work. You need addresses that are not that far into the memory. For example, on 4.0.2, the one that works for me is around the 0BD00000 area, and it can increase/decrease depending on how much memory is being used by my computer at the time.

I see. Yeah, I do remember that earlier versions would have one of the xxxx0000 addresses around there. According to my tests some time ago, in 4.0.2 I observed 0B1A0000, and in 4.0-3599 I saw 09940000. 4.0-4191 has the earliest xxxx0000 address as 7FFF0000. I didn't test between 4.0-3599 and 4.0-4191.

I actually don't ever remember getting the 0B... address to "work" as far as finding useful addresses (such as position, velocity, health, etc.), yet I was able to work with 7FFF0000 and later. Maybe both of them work, but the offsets to find the useful addresses are just different?

You could try re-scanning for the addresses you are interested in (position, health...) and keep track of them based on, say, 7FFF0000. See if the address offsets remain consistent when you restart your game and restart Dolphin. Maybe the offsets will be different from what you were used to before, but as long as the offsets are consistent, that base address should be usable.

yoshifan wrote:

You could try re-scanning for the addresses you are interested in (position, health...) and keep track of them based on, say, 7FFF0000. See if the address offsets remain consistent when you restart your game and restart Dolphin. Maybe the offsets will be different from what you were used to before, but as long as the offsets are consistent, that base address should be usable.

This is the problem though. The offsets do not stay the same. Every time you close and reopen Dolphin, the offsets will change. So if you use 7FFF0000 as the base, the offsets will change every time. Therefore, you can't use 7FFF0000 as a base address.

Zephiles wrote:

yoshifan wrote:

You could try re-scanning for the addresses you are interested in (position, health...) and keep track of them based on, say, 7FFF0000. See if the address offsets remain consistent when you restart your game and restart Dolphin. Maybe the offsets will be different from what you were used to before, but as long as the offsets are consistent, that base address should be usable.

This is the problem though. The offsets do not stay the same. Every time you close and reopen Dolphin, the offsets will change. So if you use 7FFF0000 as the base, the offsets will change every time. Therefore, you can't use 7FFF0000 as a base address.

Edit: When I said offsets, I meant the addresses.

Does the offset from the base address change too? Just to be clear, here's what I mean by the offset: in Super Mario Galaxy, I can find the X value of the control stick input at (base address) + 0x61D3A0. So here I call 0x61D3A0 the offset of the X stick input.

If you are saying that the offset of something is changing with respect to the base 7FFF0000, but is constant with respect to the base 0B..., then maybe I'm on the wrong track here. I've only worked with RAM watch for a select few games so I can't claim to have seen everything.

yoshifan wrote:

Does the offset from the base address change too? Just to be clear, here's what I mean by the offset: in Super Mario Galaxy, I can find the X value of the control stick input at (base address) + 0x61D3A0. So here I call 0x61D3A0 the offset of the X stick input.

If you are saying that the offset of something is changing with respect to the base 7FFF0000, but is constant with respect to the base 0B..., then maybe I'm on the wrong track here. I've only worked with RAM watch for a select few games so I can't claim to have seen everything.

The offset from the proper base address does not change. If I were to use 7FFF0000 as the base address, several problems would occur. For starters, I am 100% certain that all of the game's RAM actually ends before that address. If I tried to apply an offset to this address, it would have to be a negative one, which does not work properly. Secondly, 7FFF0000 will not ever change, while the game's addresses do. This would cause the offsets to change. Obviously, the offsets are not supposed to change, otherwise the pointer wouldn't work in the first place.

Zephiles wrote:

The offset from the proper base address does not change. If I were to use 7FFF0000 as the base address, several problems would occur. For starters, I am 100% certain that all of the game's RAM actually ends before that address. If I tried to apply an offset to this address, it would have to be a negative one, which does not work properly.

So you don't see any interesting scan results (position, health, etc.) beyond 7FFF0000?

Secondly, 7FFF0000 will not ever change, while the game's addresses do. This would cause the offsets to change. Obviously, the offsets are not supposed to change, otherwise the pointer wouldn't work in the first place.

I've found that many interesting values do have their addresses changing, yes, even as the base stays the same. But these values can often be reached with a two-level pointer from the base address. Again taking Mario Galaxy as an example, there's a value I call the "reference pointer". To find the reference pointer, I first take the value at the address (base + 0xF8EF88), then add base to that value, and subtract 0x80000000. Then, for example, I can find Mario's XYZ position at (reference pointer + 0x3EEC).

While it's not the easiest thing to reach interesting addresses this way, it is possible. I haven't had a ton of luck with using CE's address list interface to keep track of multi-level pointers, but I've made a Lua script demonstrating this kind of thing if you are interested (https://github.com/yoshifan/ram-watch-cheat-engine/).

yoshifan wrote:

Zephiles wrote:

The offset from the proper base address does not change. If I were to use 7FFF0000 as the base address, several problems would occur. For starters, I am 100% certain that all of the game's RAM actually ends before that address. If I tried to apply an offset to this address, it would have to be a negative one, which does not work properly.

So you don't see any interesting scan results (position, health, etc.) beyond 7FFF0000?

Secondly, 7FFF0000 will not ever change, while the game's addresses do. This would cause the offsets to change. Obviously, the offsets are not supposed to change, otherwise the pointer wouldn't work in the first place.

I've found that many interesting values do have their addresses changing, yes, even as the base stays the same. But these values can often be reached with a two-level pointer from the base address. Again taking Mario Galaxy as an example, there's a value I call the "reference pointer". To find the reference pointer, I first take the value at the address (base + 0xF8EF88), then add base to that value, and subtract 0x80000000. Then, for example, I can find Mario's XYZ position at (reference pointer + 0x3EEC).

While it's not the easiest thing to reach interesting addresses this way, it is possible. I haven't had a ton of luck with using CE's address list interface to keep track of multi-level pointers, but I've made a Lua script demonstrating this kind of thing if you are interested (https://github.com/yoshifan/ram-watch-cheat-engine/).

The RAM addresses for games in Dolphin don't go anywhere near 7FFF0000. From the base address, the end of the game's RAM addresses is usually around 0x330C040 away if you apply it as an offset. So if you apply this to the base address that I stated earlier, it doesn't even come close to 7FFF0000. So yes, there are no interesting addresses after 7FFF0000, or even close to it.

As for using two-level pointers, they really don't interest me, and they probably wouldn't work for in this scenario anyway.

I see. Sorry that it took some time to confirm, but it sounds like our use cases were different after all.

I'm not sure where I stand on this as far as Dolphin issue tracking is concerned, since I'm not sure how much the RAM layout is under the developers' control. As far as helping you RAM watch your game, though, maybe someone could help further if you provided a specific game and address example?

yoshifan wrote:

I see. Sorry that it took some time to confirm, but it sounds like our use cases were different after all.

I'm not sure where I stand on this as far as Dolphin issue tracking is concerned, since I'm not sure how much the RAM layout is under the developers' control. As far as helping you RAM watch your game, though, maybe someone could help further if you provided a specific game and address example?

I'm doing this with GameCube games, and the RAM addresses for all of them act the same. The base address is also always around the same area for all of them.

I just did a lot of testing, and I found that Cheat Engine stopped working properly with Dolphin at version 4.0-4017. I did the exact same tests on 4.0-4006 and 4.0-4017, and only 4.0-4006 gave me the address that let me make a proper pointer.

4.0-4017: https://dolphin-emu.org/download/dev/3042fdbc5adc4cedbab9de1c1f767cc44af45f37/

JosJuice wrote:

4.0-4017: https://dolphin-emu.org/download/dev/3042fdbc5adc4cedbab9de1c1f767cc44af45f37/

Why did you link this? I already tested it.

To have easy access to the code for looking for the cause of the problem. I don't think there's an easier way to get to a revision with a specific number than looking through the list of revisions - if there is, please tell me so that I don't look for builds in that way when it's not needed.

JosJuice wrote:

To have easy access to the code for looking for the cause of the problem. I don't think there's an easier way to get to a revision with a specific number than looking through the list of revisions - if there is, please tell me so that I don't look for builds in that way when it's not needed.

Oh, OK. That makes a lot of sense. And there probably isn't an easier way.

there probably isn't an easier way

This is off-topic, but there's another list here: https://changes.dolphin-emu.org/

There's also multiple pages, for which I keep forgetting the syntax: https://changes.dolphin-emu.org/page.01.html

This issue is now old and as a result, I have figured out a lot on how Dolphin works and how it pertain to Cheat Engine usage since. For the sake of everyone that were interested in this, let me tell you the whole story.

For Windows, it used to be that Dolphin would initialise its memory by finding the first rather large contiguons free memory and map it. Because of this, the start address was never a guarantee to begin with, however, for unknown reasons, for most people, it ended up being 0x7FFF0000, I myself still have no idea why, but I suspect it has to do with how Windows allocate memory

For Linux however, it used to be hardcoded to 0x2380000000, this was a guarantee unlike Windows.

This explains why it would be random to work with, some users has the Windows base changes while others, it stayed at 0x7FFF0000.

Since Dolphin 5.0-3981 though, this changed, now the start is random and has a chance to completely change after each emulation start, even staying Dolphin open and stop + play could cause a change (this is because Dolphin supports ASLR since this version). This changes how you setup with Cheat Engine because on every platform, it not only is never a guarantee, but it will be random most of the time which means you cannot possibly guess it. There is an older method that you can use by finding a pointer, but this has many of its own issues (adding addresses requires doing hex math and changing Dolphin breaks table).

About pointers, they never worked with Cheat Engine because Cheat Engine cannot understand big endian pointers as well as it cannot understand the custom memory mapping the GameCube and Wii uses (Cheat Engine will think the memory starts at 0x0, but it actually starts at 0x80000000). There is no current solution to this problem for Cheat Engine.

JMC linked a RAM search I made that solves most of these problems. For further reading, please refer to these threads I made on TASVideos:

http://tasvideos.org/forum/viewtopic.php?t=17735 Very complete tutorial on setting up Cheat Engine, I will support this thread until I am satisfied with my RAM search so feel free to post Cheat Engine related issues here.

http://tasvideos.org/forum/viewtopic.php?t=19437 Much more detailled usage instruction for my new RAM search, if you plan to use it, I highly recommend this read.

Hopefully my post will clear up a lot of confusions about using Cheat Engine with Dolphin.