A new Dolphin RAM search: Dolphin memory engine

[aldelaro5]

Hi

So following some updates I posted about the situation with Dolphin debugger in the new hacker thread, I was bringing the fact I was developping a new RAM search for Dolphin because the existing solution, Cheat Engine had a tons of problems. I was told it would be interesting to keep people updated about that.

Well, I released the first beta version of the program woooooo!!!

https://github.com/aldelaro5/Dolphin-memory-engine

For binaries without build required, go to the release tab.

I should link my TASVideos thread on this because I go into MUCH more details about the program, why it will replace CE for Dolphin at one point etc...

http://tasvideos.org/forum/viewtopic.php?t=19437

But for this thread's purposes, let me make a simpler version.

This is a RAM search, a program made to browse, track, monitor and edit the RAM of a process at runtime. Basically, you run ssbm in Dolphin, use a RAM search and you get to have real time updates on the memory of ssbm as well as a way to search memory (so like stuff like percent counters or.....well anything that is memory).

Cheat Engine has been so far the only really good RAM search for Dolphin because it supports big endian memory, something that is needed because the GameCube is using big endian memory and.....well it's Cheat Engine, it's really one of the best RAM search out there.

.....but it wasn't really made for what you would try to do with Dolphin. CE is really good for stuff like pc games or honestly any process on a standards pc usually works very well. Dolphin.....well yeah it's a pc process, the problem is it uses a different endiannes (standard pc are little endian, NOT big endian), it's in PowerPC (standard PC are x86 or x86-64) and it has a custom memory mapping because the RAM of the GameCube virtually doesn't start at 0x00000000, it starts at 0x80000000 so basically, CE has a lot of problem to deal with this. Including, but not limited to:

• It cannot track pointers so no way to track dynamic memory within Dolphin
• It constatly need to be aware of Dolphin's start address which just keeps changing as of more recent revisions and ONE change requires an ENTIRE recalculation of the entire table, yikes
• You need to add type extensions for it to work with big endian, it's just annoying

I got so tired of these problems, I decided to start my RAM search from scratch, and there we are

It's beta release so don't mark it as STABLE, the UI can be clunky, but to be honest, it has a functional scanner and a functionnal watcher with file saving support so in theory, you COULD start using it over CE, but it lacks a lot of features I plan to incrementally add later (like a memory viewer).

Little screenshot

The top part when you start it will prompt you to hook to Dolphin and to do that, you need to have Dolphin running AND an emulation started so just boot SSBM before you click hook.

As for MEM2, you shouldn't care about this unless you plan to use it on Wii game, just click auto detect and it should detect it's a Gamecube game so it will disable it. The quick gist is that the Wii has an extra memory region the GC does not have and this option take the presence or absence of this region into consideration so yeah for ssbm, make sure it's always disabled.

Once it's hooked.....really it's very similar to CE, you scan, add watches and save (check the file menu it saves .dmw files, but they are just JSON so you can edit them with a text editor).

.....that's it. If you used CE before you might have a lot of question like how is the endiannes handled? Why it guessed the start address and just works? Also WUT?

POINTERS???

Okay let me start about the last one, YES this supports multilevel pointers and unlike CE, they ACTUALLY work. .....okay technically they only work for 75% of the game, but I am certain ssbm is part of these so no worries

What's actually happening is that again, it's like CE, you specify an address and then the offsets to the pointer chain and now you have an unbreakable link to the pointer. Any read will use the entire path to report the value and any write will follow back to write so essentially, they look the exact same thing as static addresses, but are clearly not static and are moving around.

The thing is, finding a pointer path altough was okay in CE, it still required you to check assembly to figure out where it would read or write from and with what offset. I can't obvsiouly get this from Dolphin, but Dolphin itself can already with its debugger. If you want to learn more, read the tasvideos thread I linked above, it's a section about a quick debugger tutorial specifically made to find pointers. It's involved, but necessary and I cannot simplify this process even if I wanted to (I technically might if it was integrated, but for many reaosns, I decided to make this program external).

But finally it works! no more "Hey guys I found this interesting address! :D but it's a freaking pointer ", instead you will actualy try to find the pointer path.

Okay about the start addres.....this is actually a surprinsignly simple solution despite the annoyance the problem caused: Dolphin is open source so I just looked at the code, checked how it initialises its memory (information about the mapping) and I basically just query with these criteria and BOOM, I have the start, but the best part is it will work EVERYTIME, even rebooting Dolphin with a new start won't change the fact that it will get it right....normally I mean if it doesn't, it's a bug (and you shoudl definetely tag me about it btw, I explain in the TASVdioes thread around the end of it how you can confirm it got the right address). It's now super simple, press hook, done (if you haven't used CE before, this is a pain, like you have to specify manually a range of address and it screws up what the ACTUALL address were).

Lastly about endiannes? This is a Dolphin RAM search so all endianness conversion is done automatically, you never have to worry about it.

This is a very simplified and short version of my tasvideos thread, but it's simply because tbh, I explain everything there and for this, my main purpose was to explain what is the project and what it can do to ssbm hacking (or heck, ANY game hacking, I already received comments that people said it would deifnetely help).

Wtih that, if you find any bugs, please actually tag me, if it's a breaking one, I will likely do a point release.

Enjoy RAM searching ssbm

BTW: idk what is going on with images links, but if they don't work, it's not me, idk why.....

 

[ssknight7]

I just used this and i have to say it's extremely fast and saved me lots of headache. I'm really surprised at how fast and efficient it is.

I also love the step by step on how you wrote it and the problems you came across.

Thanks much for this!

 

[SinsOfApathy]

How can you not track pointers within the VMEM?

Their memory is always contiguous, so if you have the base pointer to 80000000, the offset will work. Then from there, you just consider the address a uint32_t pointer, use * to access the actual contents of the address (the other pointer), then byteswap to Little Endian, subtract 0x80000000, and add the offset to the base pointer.

//memlo is a uintptr_t pointing at the address of 0x80000000. I get it from hooking Memory::GetPointer()
//First Entity is a uintptr_t in my code, since you can just write an address to that.
uint32_t* addr = reinterpret_cast<uint32_t*>(firstEntity);
entity[i].entity_addr = memlo + (_byteswap_ulong(*addr) - 0x80000000);

 

[aldelaro5]

How can you not track pointers within the VMEM?

Their memory is always contiguous, so if you have the base pointer to 80000000, the offset will work. Then from there, you just consider the address a uint32_t pointer, use * to access the actual contents of the address (the other pointer), then byteswap to Little Endian, subtract 0x80000000, and add the offset to the base pointer.

//memlo is a uintptr_t pointing at the address of 0x80000000. I get it from hooking Memory::GetPointer()
//First Entity is a uintptr_t in my code, since you can just write an address to that.
uint32_t* addr = reinterpret_cast<uint32_t*>(firstEntity);
entity[i].entity_addr = memlo + (_byteswap_ulong(*addr) - 0x80000000);

....I am trying to understand what you mean, but it seems you are saying that for CE???

because if you are, it IS possible with CE, but you need really annoying extensions that I did saw many did, but they always had problems (not being standards, doesn't necessarly work everywhere, and just the fact you need it is annoying, etc....).

Though this is c++ so I don't think it would be for CE???

Sorry I have a hard time trying to tell what you are saying. How I do it in my code sounds like what you are saying, assume the base is at 0x80000000 (which it is 75% fo the time), read 32 bit at the address's location, add the offset and recursively continue if it goes deeper. The 0x80000000 thing, I handle this in a common function where it converts dolphin process address to console address or another function that does that in reverse.

Btw, I wouldn't do that reinterpret_cast because you break an aliasing rule, that's why there's memcpy in my code.

 

[SinsOfApathy]

....I am trying to understand what you mean, but it seems you are saying that for CE???

because if you are, it IS possible with CE, but you need really annoying extensions that I did saw many did, but they always had problems (not being standards, doesn't necessarly work everywhere, and just the fact you need it is annoying, etc....).

Though this is c++ so I don't think it would be for CE???

Sorry I have a hard time trying to tell what you are saying. How I do it in my code sounds like what you are saying, assume the base is at 0x80000000 (which it is 75% fo the time), read 32 bit at the address's location, add the offset and recursively continue if it goes deeper. The 0x80000000 thing, I handle this in a common function where it converts dolphin process address to console address or another function that does that in reverse.

Btw, I wouldn't do that reinterpret_cast because you break an aliasing rule, that's why there's memcpy in my code.

I'm just saying you could add the functionality pretty easily.

If you have the base, let's say 0x80000000 is located at something like 0x00000232CDF10000, then 0x80BDA4A0 will be at 0x00000232CEAEA4A0, since you only need to add 0x0BDA4A0.

That's because Dolphin's memory layout doesn't break the MEM region up at all. So if you some address and it's a marked by the user as being a pointer, you could then read the contents of the pointer, which will be the memory address in respect to GC/Wii memory (like 0x8045D930). From there, you can simply subtract 0x80000000 from it to get the offset from the base (which is the address of 0x80000000) and then you have the ability to follow pointers.

My code was just an example from a DLL injection I do. I don't mind the reinterpret_cast, as I've just been using it to get by without issue. https://github.com/PsiLupan/DolHook-Melee

 

[aldelaro5]

I'm just saying you could add the functionality pretty easily.

If you have the base, let's say 0x80000000 is located at something like 0x00000232CDF10000, then 0x80BDA4A0 will be at 0x00000232CEAEA4A0, since you only need to add 0x0BDA4A0.

That's because Dolphin's memory layout doesn't break the MEM region up at all. So if you some address and it's a marked by the user as being a pointer, you could then read the contents of the pointer, which will be the memory address in respect to GC/Wii memory (like 0x8045D930). From there, you can simply subtract 0x80000000 from it to get the offset from the base (which is the address of 0x80000000) and then you have the ability to follow pointers.

My code was just an example from a DLL injection I do. I don't mind the reinterpret_cast, as I've just been using it to get by without issue. https://github.com/PsiLupan/DolHook-Melee

ok I think I should give you the detailled version, this OP wasn't trying to explain everything there was to explain.

Yes, I know this, the problem is CE. Let's first talk about that base issue, well that's already a huge problem for CE because recent revisions of Dolphin supports ASLR and as a conseqeunce of such is eveyrtime you start an emulation, the memory is mapped at random in the virtual memory space of the Dolphin process. What that means is unless you checked a specific log in Dolphin itself, there is NO WAY to know at 100% certain the base address. The log will only tell you for the current emulation, it won't tell you for all of them. The best solution I found someone did to solve this problem was dirthy hack: try to find the base with automated scans and the old game ID method, the problem with this is not all games have a game ID, a quite large portion doesn't.

Now, you COULD just fork CE and add a special thing (you can't ask for merge on CE itself, CE is not made to work for Dolphin specifically, it's outside the scope of the project), it would do what I am doing now which is basically doing heuristics of the memory layout of the process and "guess", but very accurately the right page. Problems with this are well CE I quickly realised is not very well coded, appart from the fact it uses Pascal, making really annoying things, but it's also just a pain to find what's going on, The other problem is jsut the very fact that CE is jsut NOT MADE for this, it's not the right tool to use, it's a tool made for x64/x86 process, not for ppc process in an emulator, big endian and with needs for a specific memory layout. At this point, might as well do one from scratch, I actually found more incentives to do so as I continued (CE uses the hard disk to save the scans result, but for 88mb on a wii game, it really is fine to just use the ram).

Now, assuming that the base issue was resolved and you could know it everytime you boot CE, endinaness is actually a big issue despite the type extensions because NOTHING can tell how to make CE understand big endian pointer. I don't even think you can add a type, this kind of logic is pretty deep into the pointer aspect. Now, here, you could arguably ask for merge something that allows that, but finally, you get to another problem: you can't just do arhythmetic with this (you could with MHS actually which is pretty weird).

So, if I was determined to use CE and solve the problems, I would have to dig into this pascal code with readability and overall organisation errors, add a feature that allows you to have a LUA to use for big endian pointer that must do the resolution recursively, add a feature that allows to use arhythmetic in the address input box (would say actuall address - 0x80000000 + the base), I also have to dictate how that resolution is supposed to happen (so CE don't freak out because 80501212 means I want this address + the base) which already goes out of the scope of CE so here I would now have this fork, AND I would need to add that base finding features....

This is why I didn't went this route, it's ridiculous and in fact, it's even less preferable to maintain a fork because in the end, what I ACTUALLY wanted to do is even more than getting pointers to work: I also want to get rid of the annoying fact that CE will show you the actuall address, not the console address which is really the only thing you shoudl care about. Like, ideally, you wouldn't need to directly mess with the base, you would just se 0x80151212 and that would be it, the details of the base with the pointer and blah blah blah should be hidden. So now suddenly, doing a fork for CE so that it does a job it was not designed too is now problematic because it's like a hack on top of this, at this point, I might as well do it correctly in its new thing where it's MADE to do this.

It's kind of like a kitchen knife or a scalpel, you shoudl normally use the kitchen knife for most usages, but you wouldn't use it for specific ones like a surgery, you would use the scalep, but ONLY for this use case (cause it would be weird to cut an apple with a scalpel). You could sharpen the kitchen knife VERY HARD to be like a scalpel, but.....why not just use the scalpel then?

This is why I made a ram search from scratch: to not have to sharpen a knife to have a specific use.

 

[ZodiacCosmos]

I'm trying to build this but I'm very confused and have no idea what I'm doing. I've never worked with github before and am very new to this. Can someone give me an in depth instructions to build it? When I run "git submodule update --init" I'm told "fatal: Not a git repository (or any of the parent directories): .git" I don't know what I'm doing wrong.

 

[aldelaro5]

I'm trying to build this but I'm very confused and have no idea what I'm doing. I've never worked with github before and am very new to this. Can someone give me an in depth instructions to build it? When I run "git submodule update --init" I'm told "fatal: Not a git repository (or any of the parent directories): .git" I don't know what I'm doing wrong.

first off, you don't need to build it if you only care to use it, you just go to the release section of the repos which you can access directly here: https://github.com/aldelaro5/Dolphin-memory-engine/releases just grab the lattest one with your coresponding platform (Windows or Linux).

But....if you actually wanted to build it, this error means that the current directory isn't a git repository. See, what you are supposed to do is first git clone the github repos by doing the command

git clone https://github.com/aldelaro5/Dolphin-memory-engine.git

This will clone the repository to a newly created folder from the current directory. Just go to that directory and this is where you can do the git submodule command. You know you are in a git repository where there's a .git folder present (I am not sure if Windows hide these by default, check your Windows explorer settings and make sure it "Shows hidden files" or something similar). After that, the rest of the instructions are in the README, It's not something you shoudl be doing if you need to just use the program because this is more aimed for developpers if you wanted to do a fork or submit pull requests so I did assumed for these instructions that the people concerned knows how to do this which is why it's not necessarly friendly.

As for how I got this URL, in the repos page, there's a button called "Clone or download", this tells you the URL to use for git clone, it's made specifically for this purpose.

 

[ZodiacCosmos]

first off, you don't need to build it if you only care to use it, you just go to the release section of the repos which you can access directly here: https://github.com/aldelaro5/Dolphin-memory-engine/releases just grab the lattest one with your coresponding platform (Windows or Linux).

But....if you actually wanted to build it, this error means that the current directory isn't a git repository. See, what you are supposed to do is first git clone the github repos by doing the command

git clone https://github.com/aldelaro5/Dolphin-memory-engine.git

This will clone the repository to a newly created folder from the current directory. Just go to that directory and this is where you can do the git submodule command. You know you are in a git repository where there's a .git folder present (I am not sure if Windows hide these by default, check your Windows explorer settings and make sure it "Shows hidden files" or something similar). After that, the rest of the instructions are in the README, It's not something you shoudl be doing if you need to just use the program because this is more aimed for developpers if you wanted to do a fork or submit pull requests so I did assumed for these instructions that the people concerned knows how to do this which is why it's not necessarly friendly.

As for how I got this URL, in the repos page, there's a button called "Clone or download", this tells you the URL to use for git clone, it's made specifically for this purpose.

Ah okay I see now, thank you! Sorry for the confusion.

 

[Sly_]

sooooo.... anyone got a convenient DMW full of memory addresses on hand?

edit: made one myself. doesnt have everything, and its not perfectly formatted. hope this is of some use

https://github.com/gadzook/ssbm-dmw/blob/master/SSBM NTSC 1.02.dmw

 

[lahma]

aldelaro5 So I'm a little bit blown away right now... How I could be unaware of this app's existence is beyond me. I've been dealing with all of the problems for so long that come with trying to modify memory in Dolphin, and I have been seriously contemplating building a tool such as this for quite a long while. Beyond dealing with all of the inherent problems that occur when using Cheat Engine in combination with Dolphin, I have spent countless hours writing custom scripts and utilities to work around those shortcomings. I came across your utility COMPLETELY by accident when making a totally unrelated search on Google. What is strange is that I've searched countless times for a utility such as this, yet I've never come across it... Then again, most of my searches were probably in relation to Cheat Engine and therefore your app never came up.

I have not yet actually used your app, because once I read through all of its functionality and such, I felt obligated to create an account here and make a post to thank you for all your hard work. As soon as I'm done writing this post though, I am immediately going to begin toying around with it. It is going to be great to no longer be forced to use a clunky combination of Cheat Engine and my custom built big-endian pointer scanning Python script! Now the only thing we need to get implemented is a PowerPC assembler so we can modify instructions on the fly l'm kidding of course... I think...

If you're short of time or are getting burned out on the project in any way, please let me know if there are any portions of the code that need work, or any new functions you would like help implementing, and I would be glad to contribute if my C++ skills are up to the task. One of my current active projects is a LaunchBox plugin (not C++) that is used to "proxy" game/rom launches through Steam for the purpose of enabling the Steam overlay (and per-rom/game controller configurations) for one's entire library ( https://forums.launchbox-app.com/files/file/972-steamlauncher/ ). It is a humble project in comparison to this, but writing a custom Steam client API (for accessing unexposed functions in steamclient.dll) was no small task. I decided to do this because existing libraries (Steam4NET, open-steamworks, etc) weren't resilient enough to prevent Steam client updates from constantly breaking their functionality. That was definitely the most time consuming part of the project, and as result of spending a ridiculous amount of time reversing steamclient.dll in IDA, I can recite some of the assembly, offsets, and vftable layouts by memory

Anyways, I just wanted to say THANK YOU! I'm off to test out your app. Have a good one.

One more thing, is there another forum/post/place that is a better place to discuss your app, or is this thread its "home base"?

 

[aldelaro5]

aldelaro5 So I'm a little bit blown away right now... How I could be unaware of this app's existence is beyond me. I've been dealing with all of the problems for so long that come with trying to modify memory in Dolphin, and I have been seriously contemplating building a tool such as this for quite a long while. Beyond dealing with all of the inherent problems that occur when using Cheat Engine in combination with Dolphin, I have spent countless hours writing custom scripts and utilities to work around those shortcomings. I came across your utility COMPLETELY by accident when making a totally unrelated search on Google. What is strange is that I've searched countless times for a utility such as this, yet I've never come across it... Then again, most of my searches were probably in relation to Cheat Engine and therefore your app never came up.

I have not yet actually used your app, because once I read through all of its functionality and such, I felt obligated to create an account here and make a post to thank you for all your hard work. As soon as I'm done writing this post though, I am immediately going to begin toying around with it. It is going to be great to no longer be forced to use a clunky combination of Cheat Engine and my custom built big-endian pointer scanning Python script! Now the only thing we need to get implemented is a PowerPC assembler so we can modify instructions on the fly l'm kidding of course... I think...

If you're short of time or are getting burned out on the project in any way, please let me know if there are any portions of the code that need work, or any new functions you would like help implementing, and I would be glad to contribute if my C++ skills are up to the task. One of my current active projects is a LaunchBox plugin (not C++) that is used to "proxy" game/rom launches through Steam for the purpose of enabling the Steam overlay (and per-rom/game controller configurations) for one's entire library ( https://forums.launchbox-app.com/files/file/972-steamlauncher/ ). It is a humble project in comparison to this, but writing a custom Steam client API (for accessing unexposed functions in steamclient.dll) was no small task. I decided to do this because existing libraries (Steam4NET, open-steamworks, etc) weren't resilient enough to prevent Steam client updates from constantly breaking their functionality. That was definitely the most time consuming part of the project, and as result of spending a ridiculous amount of time reversing steamclient.dll in IDA, I can recite some of the assembly, offsets, and vftable layouts by memory

Anyways, I just wanted to say THANK YOU! I'm off to test out your app. Have a good one.

One more thing, is there another forum/post/place that is a better place to discuss your app, or is this thread its "home base"?

Hi, I do appreciate the comments as I actually need to work on 0.5 at some point (I am currently busy in ANOTHER project I am doing)

First off, when did you searched for it? This project is about a year old and you're not the first person that tells me that they couldn't find the information about it and I even had one person that told me the information they found was conflicting. I am a bit surprised because I posted in details a comment on an issue report in Dolphin explaining the entire story, wrote a blog post on this with even more details, this thread, a TASvideos thread, etc.... To me, given that I finally offer a solution to this problem, people should know so it's weird that people don't find it.

Also, tbh your project seems difficult, but not for the same reaosns as DME, DME is like 7-8k lines of codes, but the hardest part is the thing MUST be flexible when it comes to interpreting the memory and the UI. The watch list took over a month and same for the viewer mostly because of UI and memory interpretation, it didn't help that it was my first time using Qt. RE is a huge difficulty of itself (espeically in x64 which I REALLY need a good reason to learn because I am used to REing ppc via the dolphin debugger and it's much simpelr to read).

About the ppc assembler which I know is a joke, I know the Dolphin debugger allows to edit single lines, but you do have to type the binary code, I guess an assembler could help and it's defintely going to be nicer with the new Qt frontend to integrate, but yeah, it is a huge project, one that you could merge within dolphin's debugger. If you haven't used the new Qt debugger (mainly code, breakpoints and register widget), I reocmmend it because I pretty much fixed most of the regressions a month ago.

As for discussing.....tbh I never really planned any of this, lol, I guess someone invinted me to its discord and created a channel for it, but other than that, tbh not really.

Finally, about contributions, I do actually welcome pull requests. I do have ideas in mind for 0.5 (such as implementing some settings, fixing really annoying bugs on the tracker, more viewing options for the viewer, support for the speedhack etc...), but feel free to submit pull requests. Actually, to tell the truth, even if I am not wokring on 0.5 rn, I do have time to check PR, review them and possibly merge it. A good start imo would be to check the codebase and see if you can fix some of the issues on the tracker, 2 of them in particular I don't think are hard to fix. You will want to learn Qt for this though.

Once again, thnaks for the comment

EDIT: btw, in case you are interested by why this thing was necessary, all detailled here https://aldelaro5.wordpress.com/2017/06/19/the-annoyance-when-no-ram-search-works-with-an-emulator/

 

[lahma]

Hi, I do appreciate the comments as I actually need to work on 0.5 at some point (I am currently busy in ANOTHER project I am doing)

First off, when did you searched for it? This project is about a year old and you're not the first person that tells me that they couldn't find the information about it and I even had one person that told me the information they found was conflicting. I am a bit surprised because I posted in details a comment on an issue report in Dolphin explaining the entire story, wrote a blog post on this with even more details, this thread, a TASvideos thread, etc.... To me, given that I finally offer a solution to this problem, people should know so it's weird that people don't find it.

Also, tbh your project seems difficult, but not for the same reaosns as DME, DME is like 7-8k lines of codes, but the hardest part is the thing MUST be flexible when it comes to interpreting the memory and the UI. The watch list took over a month and same for the viewer mostly because of UI and memory interpretation, it didn't help that it was my first time using Qt. RE is a huge difficulty of itself (espeically in x64 which I REALLY need a good reason to learn because I am used to REing ppc via the dolphin debugger and it's much simpelr to read).

About the ppc assembler which I know is a joke, I know the Dolphin debugger allows to edit single lines, but you do have to type the binary code, I guess an assembler could help and it's defintely going to be nicer with the new Qt frontend to integrate, but yeah, it is a huge project, one that you could merge within dolphin's debugger. If you haven't used the new Qt debugger (mainly code, breakpoints and register widget), I reocmmend it because I pretty much fixed most of the regressions a month ago.

As for discussing.....tbh I never really planned any of this, lol, I guess someone invinted me to its discord and created a channel for it, but other than that, tbh not really.

Finally, about contributions, I do actually welcome pull requests. I do have ideas in mind for 0.5 (such as implementing some settings, fixing really annoying bugs on the tracker, more viewing options for the viewer, support for the speedhack etc...), but feel free to submit pull requests. Actually, to tell the truth, even if I am not wokring on 0.5 rn, I do have time to check PR, review them and possibly merge it. A good start imo would be to check the codebase and see if you can fix some of the issues on the tracker, 2 of them in particular I don't think are hard to fix. You will want to learn Qt for this though.

Once again, thnaks for the comment

EDIT: btw, in case you are interested by why this thing was necessary, all detailled here https://aldelaro5.wordpress.com/2017/06/19/the-annoyance-when-no-ram-search-works-with-an-emulator/

Thanks for the quick and thorough response. Like you, I find it a bit strange that I didn't come across your project earlier, especially being that you've posted about it so many places. I guess at the end of the day, there just aren't that many people who are really into the whole GameCube/Wii memory modification/cheating thing. I have very little experience reverse engineering PPC, so in order to accomplish anything, I have to constantly reference the PPC instruction documentation. I've been reversing x86 and x86-64 for 15+ years now, so its almost no different from reading a book, but its definitely not that way with PPC.

Regarding QT, I actually have almost no experience at all. Its definitely something I need to dive into and get acquainted with as it really is an indispensable tool as far as cross-platform GUIs go. I have used the new Qt debugger, but only briefly. Perhaps I will dive into QT and see if I can help contribute to the project a bit. One feature that Cheat Engine has that I would find really useful in DME is hotkey support. I use this quite often as it helps overcome some of the deficiencies of Dolphin's button-activated AR/Gecko code support. For example, playing 'The Legend of Zelda: Wind Waker' in combination with Steam's controller configurator allows me to setup hotkeys in Cheat Engine to modify Link's boat's speed (fast and slow) and then I map those hotkeys in the Steam overlay to certain buttons on my Xbox One controller so that I can easily control his speed. Anyways, thanks again for all your hard work, and good luck in whatever your current project is.

 

[The Fool 255]

Thank you so much for this! I thought I was the only having a issue with locking down address on Dolphin! But know I know it's Dolphin itself. I really appreciate you making this tool.