EDIT2: This tutorial is no longer maintained as a newer and overall better alternative to Cheat Engine was made by me called Dolphin Memory Engine. It includes a CT file importer so if you did used this tutorial prior, you can now easilly import your entire table. For more information, please visit this thread:
Thread #19437: Dolphin memory engine, a new RAM search made for Dolphin
EDIT: as of Dolphin 5.0-3981, it will randomnise the start address on every platform (Windows and Linux) so you CANNOT use the recommended method I talk about in this post, but you can use the "Alternative method to get the START address" section to have it work, however, as I say in this section, it is also more annoying to use so if you cannot endure to use it, use AT MOST Dolphin 5.0-3977.
However, you can try this:
RibShark wrote:
aldelaro5 wrote:
EDIT: as of Dolphin 5.0-5981, it will randomnise the start address on every platform (Windows and Linux) so you CANNOT use the recommended method I talk about in this post, but you can use the "Alternative method to get the START address" section to have it work, however, as I say in this section, it is also more annoying to use so if you cannot endure to use it, use AT MOST Dolphin 5.0-5977
The randomisation of the start address can be disabled by editing Dolphin.exe to not use ASLR. Here is one tool that can do so. The necessary command line to use this tool would be:
setdllcharacteristics -d Dolphin.exe
Hi everyone, I am aldelaro5, glitch hunters of Paper Mario games and I once had the idea to give a general purposes tutorial about using Dolphin and Cheat engine (CE). The reasons another tutorial is needed is because the Abahbob one actually explains a much more complicated way to set up CE, only explains with a 32 bit dolphin while 64 bit works (and the 32 bit dolphin is no longer supported by the dolphin team) and finally, I felt it lacked some in my opinion very important information that glitch hunters or tasers should know about better using CE.
This tutorial should apply to both Windows and non Windows version of Dolphin. To save you some trouble, use either the Windows 64 bit version or the Linux version because the process to set it up is very easy and has been tested. If you are using 32 bit Windows or OSX dolphin, there is still a way that is harder to do, but works no matter what (it's an alternative method that is explained further in this tutorial). Preferably, use dolphin 4.0.2 or later as the older versions can have more trouble to have a static start address for the memory. The one thing I need to point out is due to a compatibility issues, there is chances that windows 10 users will have trouble with CE and the workaround to fix this issue isn't very convenient so if possible, don't use Windows 10.
EDIT: This is confirmed to work on Dolphin 5.0 too.
Preparation
Assuming you got dolphin and your games already, get the latest version of CE on this site: http://www.cheatengine.org/downloads.php You can either get an installer that installs the program on the system or a standalone folder containing the program. Use the one you want for your convenience, they both work the same way.
If you are not using Windows
You will also need to make sure you have "Wine" installed on your system. For more information about wine and installing it, you can go to this link: https://www.winehq.org/ Basically, it allows Windows programs to have the services they need to work under other operating system and for CE, it's almost seamless. Then, you will also need the ceserver program from the CE site link above (check under "Server") because unless you use Wine to run dolphin, which I don't recommend, you will not be able to view the memory of dolphin and other programs that runs natively from your operating system.
Setting up CE (must be done no matter what version of dolphin you are using)
Start CE and if you are unfamiliar with ram search, I recommend to say yes to the tutorial, but stop once you got to step 5, only the first 4 steps would be of any help here. After that, go to edit -> settings and you should see this windows:
Change the 3 intervals at the bottom to something low, such as 10ms. The default interval are so long that you won't be seeing changes as you should be. This might cause some flickering and if it bothers you, try to increase the intervals, but keep it as low as possible.
Then go to scan settings from the left menu:
This is VERY important, always, ALWAYS have MEM_MAPPED checked because this is required to be able to even see the memory from any emulated memory (not just dolphin). While you are here, under "The all type includes" section, check "All Custom types" and "Byte", but uncheck everything else. We will not be using the native memory types CE uses except the byte.
click OK and that's it for the scan setting.
In theory, we could start using dolphin with CE, but the problem is CE's native types are in little endian. Without getting into details, little endian is a way to encode memory into a computer and in this case, the most significant digit is the rightmost one. The Gamecube and Wii however uses big endian memory which is the opposite, the most significant digit is the leftmost one (aka, how humans write numbers). CE natively doesn't support big endian, but we can add that as custom type.
Go to file -> open (or click the PC icon on the top left) and select any processes in the list, I will use cheatengine-x86_64, but it really doesn't matter which one you pick. By the way,, if you use wine to run CE here, ignore the warning dialogues, I don't know why, but it seems to to do that since CE 6.5 and it's really nothing to worry about.
Next, right click on the box next to "Value Type" and click on "Define new custom type (Auto assembler)"
A window should appear with a bunch of text:
Delete all the text in there. You will then have to copy and paste some texts and then click OK for each types. We will be adding 3 types so each time you add one, repeat the process to add another one.
The texts to paste are as follows:
2 Byte big endian
alloc(TypeName,256)
alloc(ByteSize,4)
alloc(ConvertRoutine,1024)
alloc(ConvertBackRoutine,1024)
TypeName:
db '2 Byte Big Endian',0
ByteSize:
dd 2
//The convert routine should hold a routine that converts the data to an integer (in eax)
//function declared as: stdcall int ConvertRoutine(unsigned char *input);
//Note: Keep in mind that this routine can be called by multiple threads at the same time.
ConvertRoutine:
//jmp dllname.functionname
[64-bit]
//or manual:
//parameters: (64-bit)
//rcx=address of input
xor eax,eax
mov ax,[rcx] //eax now contains the bytes 'input' pointed to
xchg ah,al //convert to big endian
ret
[/64-bit]
[32-bit]
//jmp dllname.functionname
//or manual:
//parameters: (32-bit)
push ebp
mov ebp,esp
//[ebp+8]=input
//example:
mov eax,[ebp+8] //place the address that contains the bytes into eax
mov ax,[eax] //place the bytes into eax so it's handled as a normal 4 byte value
and eax,ffff //cleanup
xchg ah,al //convert to big endian
pop ebp
ret 4
[/32-bit]
//The convert back routine should hold a routine that converts the given integer back to a row of bytes (e.g when the user wats to write a new value)
//function declared as: stdcall void ConvertBackRoutine(int i, unsigned char *output);
ConvertBackRoutine:
//jmp dllname.functionname
//or manual:
[64-bit]
//parameters: (64-bit)
//ecx=input
//rdx=address of output
//example:
xchg ch,cl //convert the little endian input into a big endian input
mov [rdx],cx //place the integer the 4 bytes pointed to by rdx
ret
[/64-bit]
[32-bit]
//parameters: (32-bit)
push ebp
mov ebp,esp
//[ebp+8]=input
//[ebp+c]=address of output
//example:
push eax
push ebx
mov eax,[ebp+8] //load the value into eax
mov ebx,[ebp+c] //load the address into ebx
//convert the value to big endian
xchg ah,al
mov [ebx],ax //write the value into the address
pop ebx
pop eax
pop ebp
ret 8
[/32-bit]
4 Byte big endian
alloc(TypeName,256)
alloc(ByteSize,4)
alloc(ConvertRoutine,1024)
alloc(ConvertBackRoutine,1024)
TypeName:
db '4 Byte Big Endian',0
ByteSize:
dd 4
//The convert routine should hold a routine that converts the data to an integer (in eax)
//function declared as: stdcall int ConvertRoutine(unsigned char *input);
//Note: Keep in mind that this routine can be called by multiple threads at the same time.
ConvertRoutine:
//jmp dllname.functionname
[64-bit]
//or manual:
//parameters: (64-bit)
//rcx=address of input
xor eax,eax
mov eax,[rcx] //eax now contains the bytes 'input' pointed to
bswap eax //convert to big endian
ret
[/64-bit]
[32-bit]
//jmp dllname.functionname
//or manual:
//parameters: (32-bit)
push ebp
mov ebp,esp
//[ebp+8]=input
//example:
mov eax,[ebp+8] //place the address that contains the bytes into eax
mov eax,[eax] //place the bytes into eax so it's handled as a normal 4 byte value
bswap eax
pop ebp
ret 4
[/32-bit]
//The convert back routine should hold a routine that converts the given integer back to a row of bytes (e.g when the user wats to write a new value)
//function declared as: stdcall void ConvertBackRoutine(int i, unsigned char *output);
ConvertBackRoutine:
//jmp dllname.functionname
//or manual:
[64-bit]
//parameters: (64-bit)
//ecx=input
//rdx=address of output
//example:
bswap ecx //convert the little endian input into a big endian input
mov [rdx],ecx //place the integer the 4 bytes pointed to by rdx
ret
[/64-bit]
[32-bit]
//parameters: (32-bit)
push ebp
mov ebp,esp
//[ebp+8]=input
//[ebp+c]=address of output
//example:
push eax
push ebx
mov eax,[ebp+8] //load the value into eax
mov ebx,[ebp+c] //load the address into ebx
//convert the value to big endian
bswap eax
mov [ebx],eax //write the value into the address
pop ebx
pop eax
pop ebp
ret 8
[/32-bit]
Float big endian
alloc(TypeName,256)
alloc(ByteSize,4)
alloc(ConvertRoutine,1024)
alloc(ConvertBackRoutine,1024)
alloc(UsesFloat,4)
TypeName:
db 'Float Big Endian',0
ByteSize:
dd 4
UsesFloat:
db 01
ConvertRoutine:
[32-bit]
push ebp
mov ebp,esp
mov eax,[ebp+8] //place the address that contains the bytes into eax
mov eax,[eax] //place the bytes into eax
bswap eax
pop ebp
ret 4
[/32-bit]
[64-bit]
//rcx=address of input
mov eax,[rcx] //eax now contains the bytes 'input' pointed to
bswap eax
ret
[/64-bit]
ConvertBackRoutine:
[32-bit]
push ebp
mov ebp,esp
//[ebp+8]=input
//[ebp+c]=address of output
push eax
push ebx
mov eax,[ebp+8] //load the value into eax
mov ebx,[ebp+c] //load the address into ebx
bswap eax
mov [ebx],eax //write the value into the address
pop ebx
pop eax
pop ebp
ret 8
[/32-bit]
[64-bit]
//ecx=input
//rdx=address of output
bswap ecx
mov [rdx],ecx //place the integer the 4 bytes pointed to by rdx
ret
[/64-bit]
Unfortunately, 8 byte big endian can't be used due to a CE limitations.
If everything is done correctly, you should be able to select all 3 types in the value type menu.
So when scanning, you will use all these types along with byte, string, binary, array of bytes and all. Don't use the others because like I said, it will not work with Dolphin memory.
That's it! You have now set CE to see and change correctly the Dolphin memory. The rest is setting up where to look for in the memory of dolphin to edit the game memory.
Linking CE and Dolphin
First, if you are not using Windows, there is extra steps to do with ceserver
ceserver (if you are not using Windows)
Before starting dolphin and CE, you will need to start ceserver. Make ceserver as executable and run it as root in a terminal. You do need root access because this program essentially allows CE to see the memory of your system, but if you are careful and you don't mess with anything other than dolphin, you shouldn’t worry about giving root access to this program. From there, you should see some stuff in the terminal output.
Sometimes, it will just quit and you will have the hand again which means that you had another ceserver running so just kill it and run it again. All you have to do after to see your Linux process is in CE, click file -> open then click network and don't touch anything in the connect window and click connect, you should then see all your process including dolphin.
The following applies to every versions
Have CE and dolphin opened. On CE, click file -> open (or click the computer icon on the top left) and open dolphin.exe (you will need to do this every time you start CE, connect before if you use Linux, dolphin is dolphin-emu in such case). In dolphin, right click on a game in your game list and select properties (this by the way means you should setup an iso directory from dolphin and put your games here so they will appear in the list).
Go to the info tab and take note of the Game ID. We will need this to confirm that CE works as the Game ID is actually the start of the game memory when it is being run. It doesn't matter which game you use for this, but as long as you use the same game for this procedure, it should work.
Next, start the game you used in the previous step. then, click add address manually in CE and enter in the address box "7fff0000" if you use Windows or "2580000000" if you use Linux as type Text of length 6 with a description of START (it doesn't matter, but I highly recommend to be descriptive when you write description and this address is special since it's the start of the game memory).
Click ok and the address should appear in the address list. If everything is done correctly, you should see the same ID as before in the value column. If you do not see the ID, something is wrong, so double check you have done everything correctly. If you are sure everything was fine, then you have to look for the address which is described a bit further in this tutorial how to do so or you could try to restart dolphin and CE since it can happen that 7fff0000 isn't reporting the ID until you restart dolphin. Note that Wiiware game may not report their ID at thsi address, but it woudl still be the correct base, more tests would have to be done to tell the start pattern.
If it works, then it would be a good thing to add the address where the memory ends. click add address manually, but this time, the address is "817F0000" on Windows or "2581800000" on Linux with whichever type you prefer and a description of END. The type here doesn't matter because it's a huge section of nothing, the only reason we add it is for further references because this will be useful when scanning memory to know both the START and the END of the memory.
At this point, I suggest you save the file (file -> save) because this will be your basic template to work with any games on dolphin.
So now, you can now start scanning Gamecube games memory, however, if you intend to use CE with Wii games, you want to add 2 addresses if your START and END worked previously. The reason is the Wii has an extra memory region that games can use and although the first region is more used, the extra region can contain important informations that you might want to search.
On Windows, you would want to add 8fff0000 as its start and 93ff0000 as its end. On Linux, that would be 2590000000 and 2594000000 respectively. Add them as byte, but it doesn't really matter as all these addresses are telling you is that you want to look for the addresses between the 2, they will belong to that extra Wii memory.
Congratulations! Your CE can now be used as a ramsearch for Wii and GC games on dolphin.....unless you are using Windows 10.
Additional steps for Windows 10 users
Windows 10 has a big issue with dolphin. Adding addresses, scanning and viewing values changes works fine (even editing the value from the memory viewer works), but what doesn't work is editing the value from the address list which is really the most important feature of CE here. If you have this issue, trying to change the value of an address in the table will cause a section of the memory to report a value of ?? and they won't be writable any more. This is a compatibility issue and the only thing you can do is use a workaround that frankly, I cannot guarantee will work every time, but you should at least try it because I know it worked on some people.
Copy and paste the following text and save it with a .lua extension:
openProcess([[cheatengine-x86_64.exe]])
reinitializeSymbolhandler()
autoAssemble([[
alloc(NewVirtualProtectEx,256)
alloc(OriginalVirtualProtectEx, 8)
registersymbol(NewVirtualProtectEx)
registersymbol(OriginalVirtualProtectEx)
label(notself)
NewVirtualProtectEx:
cmp ecx,ffffffff
jne short notself
call [OriginalVirtualProtectEx]
ret
notself:
xor rax,rax
ret
]])
s=generateAPIHookScript("VirtualProtectEx", "NewVirtualProtectEx", "OriginalVirtualProtectEx")
--stupid bug in generateAPIHookScript forgets the alloc originalcall0
s=[[alloc(originalcall0, 64, VirtualProtectEx)
]]..s
autoAssemble(s)
Place this file where you can find it.
Now, every time you boot CE, you will have to not only open dolphin but also make sure you opened a cheat table BEFORE you run the script (I don't know why, but it just crashes if you open the table after). To run the script, click the memory view button and a window will appear. On that window, go to tools -> lua engine.
From there, you can either load the script by pasting the text into the bottom text box or opening the lua file with file -> open script and I suggest you try both because for some reasons, I had different results on both methods. After you have done that, click execute and CE should NOT crash at this point, wait a bit to be sure, but if it crashes than maybe the script just doesn't work and you are out of luck, but if it seemingly doesn't crash, then in theory, the issue should be fixed and you can now edit from the address list. I know there is a way to have the script run when cheat engine starts, but because it will open it before opening a table, it will crash and really, I have no idea why it does that. Also, please note that if you had Dolphin linked to CE before running the script, it will get disconnected so just open the dolphin process again.
Like I said, this workaround is inconvenient and not guaranteed to work, but if it does, you can at least use CE with dolphin.
Now, if the START address didn't worked, we have to look for it.
Alternative method to get the START address
Now here, we will have to find the start address by searching it. we can have the end address once the start has been found, but we need the start one first. To do so, perform a scan with the type set to string and the text being the game ID you just noted (it's case sensitive so make sure you entered the exact one). Some addresses should appear in the addresses list on the left. There might be a lot of them, but check the addresses and try to spot one that has the most amount of "0" at the end of it. it should have minimum 4 "0" at the end but if you can find 7 and it works, it's better. You could add a bunch of them while you are there because you might have to do some trial and error. Assuming dolphin is running the game which correspond to the ID you entered, it should have the ID in the value column. Then, this might just work, but to be sure, close Dolphin, open it again, reopen dolphin in CE (say keep the table on the prompt) and run the same game again, the ID should still be there. If you REALLY want to make sure it works, save the table (file -> save) and then reboot your machine before setting up again with the file you saved and check to see if they still work. If they do, then pick the one you want and delete the others. Double click on the address and change its description to START and its type to string length 6.
However, this might not work because Dolphin might not be keeping this address statically and change place in the memory.
Make sure that the above does not work at anything you try before trying the following!
Perform a search and pick an address like before, but this time, right click on it and select pointer scan for this address. Leave everything default and click ok. It will prompt to save to a file, save it wherever you want, you won't need this file anyway, but you need to save it. Wait the scans to end and once it ends, double click on the first one that appears in the list, it should now appear as a pointer in the list open the main window. then, save the file and perform the reboot test and if it works, then you have it, if not, try to do this on another addresses until you have one that works, there should always be at least one that works.
Once you have your start Address, if it's a static address, open a calculator in hexadecimal base and add both the address you found and the value "1800000" and add the result as your END address in CE then you should be done. If it was a pointer however, you will double click on the address of the pointer and copy the bottom most textbox, this is the pointer base. Then click add address and check the pointer box and paste the pointer base you copied at the same place it was. then, enter "1800000" in the offset box. Name it END with a type of string of length 6 and click ok. you should be good now. By the way, if you were using Windows 10, you will have to perform the additional steps written above.
As you can see, this method is very complicated to do, but if the address you found was static, then it's not this bad to deal with when you add a bunch of address because you just add them directly when you found them. The pointer address is however very inconvenient to deal with. What you would do is find the address, calculate the offset this address is from the address pointed by the start pointer and put that as offset of a new address using the base pointer you got. This would have to be performed EVERY TIME you add one address which is why this method is really in case you are desperate because it's just the worst to deal with. if you don't want to deal with this, use the Windows 64 bit or the Linux version or just try to find a static address that works.
So from that point, you can now use Cheat Engine as a ram search so if you know how to use Cheat Engine, you should be good with basic features, but I learned myself a lot from experience that you could use some features of CE that enhances what you can do while they are not obvious. So I will generally detail how to use CE, there';s others in-depth tutorial about how to do efficient ram search, but I will concentrate on CE here.
START and END
The reason it's cool to have both address is you can define what range of the memory CE will scan in. To do so, paste the start address in the start box and the end address in the stop box.
That way, you will CONSIDERABLY reduces the time you take to find addresses. This is very VERY recommended because if you don't do that, you might even get the exact same address at multiple places, some even out of the start and end block you found!
Oh and by the way, if you wonder why the start and end are 0x1800000 apart, it's because this is exactly equivalent to 24mb which is actually the amount of RAM the GC and Wii uses for its games. The memory starts at 0x80000000 and ends at 0x81800000 in the real console. You might notice that the linux version is the real console address + 0x2500000000 which is convenient, you can know the real console address right away and this actually is very useful for documenting or even create codes that write to these addresses if you want to test hacks on console.
The same goes for the extra memory the Wii has. Its memory is from 0x90000000 to 0x94000000 which is exactly 64mb. To scan there, you will have to change your range and because these areas are in 2 separate regions, you might consider switching between ranges. The thing to note is you should search in the 24mb area in priority as this is the region where most of the game memory is in and search in the 64mb area if the 24mb area doesn't seem to contain the addresses you need.
General tips and recommendations
I won't go into details about the process of ram searching (explore the different scan types options), but I can give some general advices:
Scanning
Don't spam the unchanged value after the first scan is done, it's very long and there's better ways to do it, do so after you narrowed down the list a bit.
You might have to double check a lot of time what is the type of the data you found is, it's sometime important to know this because if you say an address is one byte while it uses 2, it will give very fake and weird value in the address list, I've had this happen several time and these issues can be tricky to detect so just make sure you use the right type.
Try to check addresses near the one you found already, sometime, I found addresses by just looking what was near another one and they turned out to be very useful.
Think about rescanning with different types if you can't find what you are looking for.
Just be aware that if you are trying to figure out how the data works while you scan them, it's going to be a long trial and error session and is very hard to do. The best example I can give is trying to find the RNG seed, you don't know how it changes until you found it so, just be determined if you come into these situations, it's normal if it takes time.
Editing values
You can edit without having to enter text in a box, just select the address, press enter and you can enter the value right away before pressing enter again to edit it.
Remember about the active checkbox, this essentially locks the value in place which is useful if you want to force an address a value that just doesn't like you write to it or simply for testing.
You can select multiple addresses and edit them in one shot.
Some addresses will take a simple edit, but some will just come back to where they were, this means that the game is somehow preventing changes or the address simply is read only. Use the freeze features or try to find a writable version of the same address, I have seen this before.
Memory viewer
Because we work in big endian memory, we can easily read the memory as normal numbers because it uses a similar encoding. This is why the memory viewer can become an interesting tool for just reading numbers and sometime even editing. to have the viewer open on one address of the table, right click on it and select browse memory region. that way you can see addresses near it or check an array content in byte hexadecimal format. It's not pretty to look and to analyses, but it can be of a great use. For example, if you are hacking your item inventory, it would be much better to have the first slot stored in the table of CE and to edit the rest, you would open the viewer instead of having a lot of addresses of items slots.
However, the most useful thing you can do with the memory viewer is basic reverse engineering. Basically, when you add an address in the CE table, the value column would be the raw data (what you see in the memory viewer) encoded into the format of the type that you told CE to use. This is very convenient, that way you can edit the value without having to worry about hexadecimal conversion and it's quick to do. However, and I already alluded to this in the scanning section, this is only reliable if you know for sure that the type CE encodes the data is the right one. A quick example would be 00 01, this is 0 if it;s a byte, and 256 if it's 2 byte. So you basically can't trust the type CE uses until you know it's the right one.
Which is when the viewer comes into play, by being able to see the raw data before any encoding, you can see (and maybe "feel") what encoding makes the most sense. An exhaustive tutorial on how to efficiently figure out this reverse engineering will be too long, but I suggest you simply try all the type and pick the one that makes the most sense. To preview it, right click on the first byte of the address you have doubts and select add this address to the list and you will have a prompt, just change the type and check what is written right next to the address number (it's "=something"). Don't worry if this sounds hard, it takes experience before you get good at reverse engineering. I myself was able to figure out an entire data base with this viewer so I really recommend you check it sometime.
Misc advices
You can have the addresses you found with different color, right click -> change color. It's useful if you want to categories the addresses. One use I do for this is having the first slots of arrays in a different color, same for the START and END address.
You can make groups of addresses for example, the data of an actor, however.....tbh, they are a bit funky with how they work, but they have some good features. To add one, right click in an empty space of your list and select create header.
If somehow your table is broken, you can open the table with a text editor, it uses xml like tags and are self explanatory in how they work.
You can change some display format depending on the type by right clicking on an address. You could show the same value in hexadecimal, binary (with binary type) or toggle between signed and unsigned value. The unsigned values can't be negative, but can go higher while signed supports negative numbers, but can't go as high as unsigned (the range is evenly distributed between negative and positive).
Conclusion
That';s all I have to say about how to use CE with dolphin. I hope it would help people to tas or glitch hunt games with it since the old Abahbob tutorial does work, but it felt very over complicating the process while easier methods has been found. CE is a very powerful tool that I think should be known by people who wants to monitor the memory or test it.
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
Lmao, how is using pointers complicated? I have no idea how you’re even making CE work without using pointers. Nice info about when the memory ends though.
how is using pointers complicated? I have no idea how you’re even making CE work without using pointers.
If you don't know the concept of how pointers work, it can be quite difficult to understand at first. And it's obviously much more of a hassle to add the pointer to every single address you found, instead of just double clicking.
Good job aldelaro5, this detailed and easy to understand tutorial will probably help a bunch of people. (As long as Dolphin doesn't finally get its own RAM Watch and general useful features for TASers and/or glitch hunters)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
Lmao, how is using pointers complicated? I have no idea how you’re even making CE work without using pointers. Nice info about when the memory ends though.
Actually, this was found by a TTYD glitch hunter "Zephiles" which was later tested a bunch of times and it worked. I use Linux so I myself found the linux method.
It's complicated because each time you add an address, you have to do an hexadecimal math which most of the time needs a calculator because they can't be calculated by head easily (unless you are really good). I have been using them for months and the one thing I can confirm is it's really frustrating to deal with because I feel less tempted to add addresses that MAY have been useful because I need to do something that makes it not worth it.
So after these methods were discovered, well there was no point of ever using pointers again, you just double click on the value you add and then you save. It's just straight forward with the only skill required is to actually be good at ram searching which is actually what CE is supposed to do well.
It's just an unnecessary difficulty that I felt needed to be removed for people who wants to use CE.
ALAKTORN wrote:
Masterjun wrote:
(As long as Dolphin doesn't finally get its own RAM Watch and general useful features for TASers and/or glitch hunters)
To be honest Cheat Engine is pretty damn good and easily superior to any RAM Watch currently existing if you know how to use it.
Actually I agree on this one, I never saw a so powerful ram search, idk how MHS works, but I know MHS cannot use big endian. The memory viewer on CE helped me multiple times which is a feature that i don't see much often on ram search tbh. The only thing CE can't do is breakpoint on memory access, but that can be done in Dolphin if you have a debugfast build and you are not using Linux (that feature doesn't work on Linux).
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
It's just an unnecessary difficulty that I felt needed to be removed for people who wants to use CE.
The thing is that it’s not unnecessary… it’s supposed to be required for the addresses to even work. I’m not sure how it’s working for you without pointers, but when I tried, it worked for 2 restarts and after the 3rd it didn’t, so I just started using pointers at that point. It doesn’t really require math or a calculator either, you just go from right to left and do simple 1-digit additions. You just need to know that hexadecimal goes from 0 to F.
aldelaro5 wrote:
The memory viewer on CE helped me multiple times which is a feature that i don't see much often on ram search tbh.
RAM Search/Watch and memory viewing are usually (always?) separate options. Not sure how many emulators have both though… BizHawk and DeSmuME do.
aldelaro5 wrote:
The only thing CE can't do is breakpoint on memory access
I thought it could do that? I’m not sure if it’s on access but it can do breakpoints.
It's just an unnecessary difficulty that I felt needed to be removed for people who wants to use CE.
The thing is that it’s not unnecessary… it’s supposed to be required for the addresses to even work. I’m not sure how it’s working for you without pointers, but when I tried, it worked for 2 restarts and after the 3rd it didn’t, so I just started using pointers at that point. It doesn’t really require math or a calculator either, you just go from right to left and do simple 1-digit additions. You just need to know that hexadecimal goes from 0 to F.
aldelaro5 wrote:
The memory viewer on CE helped me multiple times which is a feature that i don't see much often on ram search tbh.
RAM Search/Watch and memory viewing are usually (always?) separate options. Not sure how many emulators have both though… BizHawk and DeSmuME do.
aldelaro5 wrote:
The only thing CE can't do is breakpoint on memory access
I thought it could do that? I’m not sure if it’s on access but it can do breakpoints.
It really worked with 7fff0000 for so much people that it really felt consistent enough. Even better, for Linux, I never had any problems for months and hundreds of reboot with always 2580000000. In fact, I can even confirm that I have another Windows laptop I did the 7fff0000 test and it worked. It just seems to be a place where dolphin always have its memory here. So tbh, it should work.....unless your dolphin version is old or 32 bit, then idk, but i can be sure that the static addresses I told does work.
That actually sound annoying because CE, you have directly the option to go in the viewer where an address is at. Being separate means you would have to go to it all the time....yeah :(
It actually cannot for Dolphin. I had someone (a certain jdaster64) who knows a lot more than me on assembly and maths and he clearly told me a lot of times that what CE sees is the decoded instructions by the emulator so your x64 cpu can understand it. However, we care about the original PowerPC instructions and having the decoded one does nothing to help you. The memory check feature on dolphin however, this allows to break the real emulated address and to see the real instructions. I even tried when I was using Windows and the debugging features on CE just never worked like they should. So it can break in theory, but it won;t be useful for dolphin.
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
It really worked with 7fff0000 for so much people that it really felt consistent enough. Even better, for Linux, I never had any problems for months and hundreds of reboot with always 2580000000. In fact, I can even confirm that I have another Windows laptop I did the 7fff0000 test and it worked. It just seems to be a place where dolphin always have its memory here. So tbh, it should work.....unless your dolphin version is old or 32 bit, then idk, but i can be sure that the static addresses I told does work.
From my Windows experience, Dolphin used to have changing game-RAM start addresses, but from the later 3.5 versions up to now (at least 4.0-8814), it seems like the valid start address(es) never change as long as you stick to the same version of Dolphin. And as far as I know, for any version in that same range, 7FFF0000 happens to be one of the valid start addresses.
Most of the Dolphin versions I've seen have most of the game RAM values duplicated in 4 addresses simultaneously. My test of Dolphin 4.0.2, for example, indicated that start addresses of 0B1A0000, 7FFF0000, FFFF0000, 13FFF0000 could all work just fine. I tend to use the 3rd address out of 4, since in my experience it was the only one that showed results on CE's "Find out what writes to this address" function. (Sometimes disabling those writing instructions is useful to figure out what an address is.)
Here's my Windows experience with various versions and their valid start addresses, using 64 bit when available:
3.5-0, 3.5-663, 3.5-1188: Changes if you quit your GC/Wii game and then open a game again. Addresses I've seen are 0B3F0000, 7FFF0000, FFFF0000, 13FFF0000, 180070000, 200070000, 240070000, 242070000, 2C2070000...
3.5-1696: 0C150000, 7FFF0000, FFFF0000, 13FFF0000. This version also might be subject to changing addresses, I don't remember exactly.
3.5-2302: 0B3B0000, 7FFF0000, FFFF0000, 13FFF0000
4.0.2: 0B1A0000, 7FFF0000, FFFF0000, 13FFF0000
4.0-1997: 08750000, 7FFF0000, FFFF0000, 13FFF0000
4.0-2826: 095F0000, 7FFF0000, FFFF0000, 13FFF0000
4.0-3599: 09940000, 7FFF0000, FFFF0000, 13FFF0000
4.0-4191: 7FFF0000, FFFF0000, 13FFF0000. Yes, only 3 in this case.
4.0-5702: 7FFF0000, 27FFF0000, 2FFFF0000, 33FFF0000
4.0-8814: 7FFF0000, 27FFF0000, 2FFFF0000, 33FFF0000
-----
Overall, I agree that pointers aren't needed for the start address, at least so far. However, often the GC/Wii game itself will use pointers for important addresses.
In F-Zero GX, a bunch of interesting values like position, orientation, in-race vehicle stats, etc. will move to a different location for different modes (Time Attack/Practice, Grand Prix, Story, Versus). In Super Mario Galaxy, position values move whenever you load a different area - not just for different galaxies, but even different levels of the same galaxy! When the values have over 50 different possible addresses depending on where you are in the game, it can get really annoying to create an address list for each case.
So in that case, it makes sense to find a pointer. A pointer, for our purposes, is just a RAM value whose purpose is to track the address of another RAM value (or a block of multiple RAM values). In general, the pointer's value isn't going to be exactly the same number as the address you're looking for. But whenever the address moves by X bytes, the pointer's value should change by that same amount, X. That's the principle we use to scan for pointers.
To find pointers, see this post from RachelB:
... find the address once, save state, then do whatever to make the address change, then find it again, and save state again. From there, search for 4 byte value > 0x80000000, load the other save state, then filter by changed by the difference between the two addresses.
To clarify, once you have those savestates:
1. Load your first state. Let's say you're looking for position, and position is at address 800 here.
2. Search for 4 Byte Big Endian in the address range you're interested in. If you already specify your RAM range in Memory Scan Options like aldelaro does, just scan for 'Unknown initial value'.
3. Load your second state. Let's say position is at address 8D4 here, which means the address increased by D4.
4. Scan for "Increased value by..." with D4 in the box (with the 'Hex' checkbox checked).
5. Now, any scan results that are changing constantly (when you don't expect the position address to change) probably aren't what you need. Use some Unchanged value scans to prune out those bad addresses. Eventually you should be left with a reasonably low amount of addresses. If not, you might want to add a third savestate to your procedure to increase your confidence in picking a pointer address.
6. Pick one of those results to use as your pointer address and test it. For example, let's say that when position was at address 800, this pointer had value 600; and when position was at address 8D4, this pointer had value 6D4. In this case, the position address is (pointer value + 200), so you'd use a pointer offset of 200.
-----
Other than that, I highly appreciate the detailed tutorial, aldelaro. I'll definitely be linking it to anyone interested in researching GC/Wii games.
It really worked with 7fff0000 for so much people that it really felt consistent enough. Even better, for Linux, I never had any problems for months and hundreds of reboot with always 2580000000. In fact, I can even confirm that I have another Windows laptop I did the 7fff0000 test and it worked. It just seems to be a place where dolphin always have its memory here. So tbh, it should work.....unless your dolphin version is old or 32 bit, then idk, but i can be sure that the static addresses I told does work.
From my Windows experience, Dolphin used to have changing game-RAM start addresses, but from the later 3.5 versions up to now (at least 4.0-8814), it seems like the valid start address(es) never change as long as you stick to the same version of Dolphin. And as far as I know, for any version in that same range, 7FFF0000 happens to be one of the valid start addresses.
Most of the Dolphin versions I've seen have most of the game RAM values duplicated in 4 addresses simultaneously. My test of Dolphin 4.0.2, for example, indicated that start addresses of 0B1A0000, 7FFF0000, FFFF0000, 13FFF0000 could all work just fine. I tend to use the 3rd address out of 4, since in my experience it was the only one that showed results on CE's "Find out what writes to this address" function. (Sometimes disabling those writing instructions is useful to figure out what an address is.)
Here's my Windows experience with various versions and their valid start addresses, using 64 bit when available:
3.5-0, 3.5-663, 3.5-1188: Changes if you quit your GC/Wii game and then open a game again. Addresses I've seen are 0B3F0000, 7FFF0000, FFFF0000, 13FFF0000, 180070000, 200070000, 240070000, 242070000, 2C2070000...
3.5-1696: 0C150000, 7FFF0000, FFFF0000, 13FFF0000. This version also might be subject to changing addresses, I don't remember exactly.
3.5-2302: 0B3B0000, 7FFF0000, FFFF0000, 13FFF0000
4.0.2: 0B1A0000, 7FFF0000, FFFF0000, 13FFF0000
4.0-1997: 08750000, 7FFF0000, FFFF0000, 13FFF0000
4.0-2826: 095F0000, 7FFF0000, FFFF0000, 13FFF0000
4.0-3599: 09940000, 7FFF0000, FFFF0000, 13FFF0000
4.0-4191: 7FFF0000, FFFF0000, 13FFF0000. Yes, only 3 in this case.
4.0-5702: 7FFF0000, 27FFF0000, 2FFFF0000, 33FFF0000
4.0-8814: 7FFF0000, 27FFF0000, 2FFFF0000, 33FFF0000
-----
Overall, I agree that pointers aren't needed for the start address, at least so far.
That explains a lot of stuff I lived in the past with 3.5. I was sceptical when somone found about the magic 7FFF0000 because I never got them to not change. Thanks for these tests, I will put a note in the post about it.
And yeah, outside of the game memory, there isn't much reaosns to use pointers, there was back then, but not anymore since like.....4.0.2 which is around for one or 2 years. Even today, I feel the recent dev revisions are much better than 4.0.2 and since 5.0 is comming soon, 3.5 is just a really bad version now.
yoshifan wrote:
However, often the GC/Wii game itself will use pointers for important addresses.
In F-Zero GX, a bunch of interesting values like position, orientation, in-race vehicle stats, etc. will move to a different location for different modes (Time Attack/Practice, Grand Prix, Story, Versus). In Super Mario Galaxy, position values move whenever you load a different area - not just for different galaxies, but even different levels of the same galaxy! When the values have over 50 different possible addresses depending on where you are in the game, it can get really annoying to create an address list for each case.
So in that case, it makes sense to find a pointer. A pointer, for our purposes, is just a RAM value whose purpose is to track the address of another RAM value (or a block of multiple RAM values). In general, the pointer's value isn't going to be exactly the same number as the address you're looking for. But whenever the address moves by X bytes, the pointer's value should change by that same amount, X. That's the principle we use to scan for pointers.
To find pointers, see this post from RachelB:
... find the address once, save state, then do whatever to make the address change, then find it again, and save state again. From there, search for 4 byte value > 0x80000000, load the other save state, then filter by changed by the difference between the two addresses.
To clarify, once you have those savestates:
1. Load your first state. Let's say you're looking for position, and position is at address 800 here.
2. Search for 4 Byte Big Endian in the address range you're interested in. If you already specify your RAM range in Memory Scan Options like aldelaro does, just scan for 'Unknown initial value'.
3. Load your second state. Let's say position is at address 8D4 here, which means the address increased by D4.
4. Scan for "Increased value by..." with D4 in the box (with the 'Hex' checkbox checked).
5. Now, any scan results that are changing constantly (when you don't expect the position address to change) probably aren't what you need. Use some Unchanged value scans to prune out those bad addresses. Eventually you should be left with a reasonably low amount of addresses. If not, you might want to add a third savestate to your procedure to increase your confidence in picking a pointer address.
6. Pick one of those results to use as your pointer address and test it. For example, let's say that when position was at address 800, this pointer had value 600; and when position was at address 8D4, this pointer had value 6D4. In this case, the position address is (pointer value + 200), so you'd use a pointer offset of 200.
I appreciate the clever suggestion (which is self explanatory), but the reality is if you HAVE to deal with pointers, good luck because it's very annoying.
CE, as much as I think it's the best ramsearch I used and heard of, lacks imo very important features. One of them is to basically have an address calculated off of another one in the table. Because CE only recognises your PC pointer, not GC one which are 4 bytes and goes from 80000000 to 81800000 and in big endian.
What happens is you could find a pointer to a dynamic memroy region, but you will not only need the pointer, but also the address itself EVERY TIME you want to monitor it. So the only thing you alleviate by having the pointer is knowing the address instead of searching. That helps a lot of course, but the problem of having to have the address pointed into another entry in the table is just very frustrating. I wish SO MUCH there woudl be a way to tell ce to basically have a linked address where it checks the value of the pointer and output the value of that address + something.
Like I don't deal much with pointers fortunately because TTYD and SPM don't have much dynamic memory (TTYD has battles in dynamic memory however, that is actually annoying), but with a game that has a lot of important info dynamic.....I can't imagine how annoying it would be to ramsearch :(
Currently, CE only understands little endian PC pointers. If only you could have a custom type to have ce add soemthing to the value and then follow the address......I would be very happy because you would only add it once and never bother with it again.
Speaking of custom types, another features I would love with ce is to actually be able to not just have primitive types but also objects. It would help a lot with reverse engineering to have an easy way to have one memory location with multiple attributes you could figure out. Kind of a group, but on the type instead. Because otherwise, you have to use the viewer which for figuring out types, it's fine, but not for finding them once you figured them out which complicates editing.
So, unfortunately, you sometime have to use pointers because the game is made to be dynamic. However, outside of the game, there is just no reasons to. I would definetely use pointers more if CE didn't made it so inconvenient to deal with.
yoshifan wrote:
Other than that, I highly appreciate the detailed tutorial, aldelaro. I'll definitely be linking it to anyone interested in researching GC/Wii games.
Please do because some weeks after I made it, I realise how much people should read it more. It's now more clear what you are trying to do with CE rather than.....trying to figure out on your own which took me a VERY long time to do. I didn't wanted people to live this anymore so I had that idea :)
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
Ah, okay. It's been quite a while since I used Cheat Engine's address list for pointers, to be honest, so I'd forgotten just how inconvenient it was. Hopefully there will be an easier solution to deal with Dolphin pointers in the future.
Incidentally, if you want to try your hand at Lua scripting, I made a rough Lua framework for more customized Cheat Engine displays: https://github.com/yoshifan/ram-watch-cheat-engine
I wouldn't call it super easy to use, but if you can get things up and running, then it could save a lot of time with games that use pointers/dynamic memory.
Here is an example of a display I made with the framework.
Oh and by the way, if you wonder why the start and end are 0x1800000 apart, it's because this is exactly equivalent to 24mb which is actually the amount of RAM the GC and Wii uses for its games. The memory starts at 0x80000000 and ends at 0x81800000 in the real console.
I'm afraid to say it but you are missing critical information for Wii software. GC has a 24MB MEM1 memory which you've mentioned. Wii also has a 64MB MEM2 memory in addition to the GC memory.
MEM2 is mapped to the 0x90000000 - 0x94000000 region in Wiis.
I'm using r5962 and MEM2 is normally mapped to 0x8fff0000 on my Win 7 64-bit.
It may have changed but it is interesting that the region size for MEM1 is rounded up and there is empty padding until MEM2 to keep addresses round.
Ah, okay. It's been quite a while since I used Cheat Engine's address list for pointers, to be honest, so I'd forgotten just how inconvenient it was. Hopefully there will be an easier solution to deal with Dolphin pointers in the future.
Incidentally, if you want to try your hand at Lua scripting, I made a rough Lua framework for more customized Cheat Engine displays: https://github.com/yoshifan/ram-watch-cheat-engine
I wouldn't call it super easy to use, but if you can get things up and running, then it could save a lot of time with games that use pointers/dynamic memory.
Here is an example of a display I made with the framework.
I tried the script sample and it even works under my linux with CE and ceserver. So I guess maybe if I really need to check pointer stuff I might use it, but yeah, I don't know much about lua and getting the display right sounds a bit time consuming so yeah :)
Btw, I added the note about preferably using 4.0.2 or later with the tests you have done, thanks :)
Zanoab wrote:
aldelaro5 wrote:
Oh and by the way, if you wonder why the start and end are 0x1800000 apart, it's because this is exactly equivalent to 24mb which is actually the amount of RAM the GC and Wii uses for its games. The memory starts at 0x80000000 and ends at 0x81800000 in the real console.
I'm afraid to say it but you are missing critical information for Wii software. GC has a 24MB MEM1 memory which you've mentioned. Wii also has a 64MB MEM2 memory in addition to the GC memory.
MEM2 is mapped to the 0x90000000 - 0x94000000 region in Wiis.
I'm using r5962 and MEM2 is normally mapped to 0x8fff0000 on my Win 7 64-bit.
It may have changed but it is interesting that the region size for MEM1 is rounded up and there is empty padding until MEM2 to keep addresses round.
Interesting, did you ever found useful addresses in these memory region?
Because I am doing a lot of ram searching on Super Paper Mario and I never checked that memory range. if that memory part is important, then I will be sure to add a section in the tutorial. I really thought that the hardware being similar, they had the same ram system.
Maybe a detailed explanation of that ram region would help me because that could change a lot for me (and the tutorial of course because I care to keep it as exhaustive as possible).
But yeah, I am very interested about this information.
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
Oh and by the way, if you wonder why the start and end are 0x1800000 apart, it's because this is exactly equivalent to 24mb which is actually the amount of RAM the GC and Wii uses for its games. The memory starts at 0x80000000 and ends at 0x81800000 in the real console.
I'm afraid to say it but you are missing critical information for Wii software. GC has a 24MB MEM1 memory which you've mentioned. Wii also has a 64MB MEM2 memory in addition to the GC memory.
MEM2 is mapped to the 0x90000000 - 0x94000000 region in Wiis.
I'm using r5962 and MEM2 is normally mapped to 0x8fff0000 on my Win 7 64-bit.
It may have changed but it is interesting that the region size for MEM1 is rounded up and there is empty padding until MEM2 to keep addresses round.
Interesting, did you ever found useful addresses in these memory region?
Because I am doing a lot of ram searching on Super Paper Mario and I never checked that memory range. if that memory part is important, then I will be sure to add a section in the tutorial. I really thought that the hardware being similar, they had the same ram system.
Maybe a detailed explanation of that ram region would help me because that could change a lot for me (and the tutorial of course because I care to keep it as exhaustive as possible).
But yeah, I am very interested about this information.
MEM2 is just an extension to MEM1. The games I've researched generally used the smaller MEM1 memory for executable code and static data while using MEM2 as working memory. MEM1 is only ~25% of total memory available to Wii games.
In FFF: Chocobo's Dungeon, I easily found all the basic static data that would never need to be unloaded. When I started to search for more valuable information, it was nowhere in MEM1. I spent a total of 8 hours trying to figure out what black magic the game was using to hide the dynamic memory. It wasn't until I decided to look into the Wii's memory map that the mystery of missing memory was solved.
How I found the emulated MEM2 memory was really easy. Knowing what addresses I was missing, I just searched everything for the addresses and looked at the list of memory regions to get the start and size. The emulated MEM2 memory region was exactly 64MB so I didn't bother verifying that everything was correct.
The 7fff0000 address doesn't seem to give me the Game ID for a WiiWare game (specifically Lost Winds).
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
The 7fff0000 address doesn't seem to give me the Game ID for a WiiWare game (specifically Lost Winds).
Sorry for the delay on this, but the reason I didn't replied right away is because to tell the truth, you aren't the only one I heard of this issues and it seems to randomly affects people without a seemingly common thing between them.
But thanks to your comment, I was reminded of this and since lately I have been studying the Dolphin codebase (mainly the debugger), I got the info of how Dolphin actually allocate its memory for the emulation and let me tell you what it does so it can serve other people that might browse this thread.
For 64 bit and NOT on Windows, the base is hardcoded to 2300000000 (the tutorial says otherwise, but it is a copy so it's fine until I notice some differences). The reason why they do this is unknown to me, but thye msut have their reasons I guess.
For Windows 64 bit however, it's not hardcoded, they find the first memory page that has lots of contigous free memory. On most people, it usually is 7fff0000, but on at least one person I talked with, it's 180020000 which is way later.
What is sure is that the cause of the problem is either that 7fff0000 is already used/allocated or that something is preventing to allocate there so it takes the next page it can allocate.
I am currently trying to find people that has the issue so I could give steps to them to try to troublehout this (it doesn't happen on my virtual machine of windows 10) because it's unknown what the problem is.
So far, it doesn't seem to be ram usage. If you have this issues and have access to discord OR the #tasvideos IRC, pls send me a forum PM of where I can chat with you in realtime (have quite soem time on your hand because it is likely to take a while).
Btw, if you want to know your base address, it's a bit complicated, but you need a debug configurated build of dolphin and have the logger configured to log in debug mode and log "MI & Memmap" so when you start the game, it would say that it initialised sucessfully followed by an address.
Oh btw, the game doesn't matter, MEM1 shouldn't change based on the game.
As a workaround for now, use the base Dolphin reports when it logs, but like i said, you need a debug build for this.
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
Talked to aldelaro on discord, turns out it really was a wiiware/vc thing. Still the 7FFF0000 base address though.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
I think your assembly for 4 bytes big endian is bad, can it show signed values if you right click -> “Show as signed”? If it can then I guess it’s fine. If it can’t I got mine from here and it can: http://tasvideos.org/forum/viewtopic.php?p=292784&b=28#292784
Your 2 bytes big endian has that problem, and the one in the post I linked is even more broken (when doing scans it won’t show correct values if they’re too high). Does anybody know how to fix the problem with showing signed values for 2 bytes big endian?
Also, I asked on the CE forums and they told me a different workaround for Win 10: http://forum.cheatengine.org/viewtopic.php?t=603753
“after enabling kernelmode read/write, also execute this lua command:
dbk_writesIgnoreWriteProtection(true)”
It works nicely for me, I haven’t tried your workaround though.
^
This post is by ALAKTORN btw
I think your assembly for 4 bytes big endian is bad, can it show signed values if you right click -> “Show as signed”? If it can then I guess it’s fine. If it can’t I got mine from here and it can: http://tasvideos.org/forum/viewtopic.php?p=292784&b=28#292784
Your 2 bytes big endian has that problem, and the one in the post I linked is even more broken (when doing scans it won’t show correct values if they’re too high). Does anybody know how to fix the problem with showing signed values for 2 bytes big endian?
Also, I asked on the CE forums and they told me a different workaround for Win 10: http://forum.cheatengine.org/viewtopic.php?t=603753
“after enabling kernelmode read/write, also execute this lua command:
dbk_writesIgnoreWriteProtection(true)”
It works nicely for me, I haven’t tried your workaround though.
Unfortunately, idk about how to do these types so i can't really help :)
I haven't chexked for 4 bytes.
as for the workaround, idk, mine i had several people that said it worked for me, it is a script so it miight be similar.
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
EDIT: as of Dolphin 5.0-5981, it will randomnise the start address on every platform (Windows and Linux) so you CANNOT use the recommended method I talk about in this post, but you can use the "Alternative method to get the START address" section to have it work, however, as I say in this section, it is also more annoying to use so if you cannot endure to use it, use AT MOST Dolphin 5.0-5977
The randomisation of the start address can be disabled by editing Dolphin.exe to not use ASLR. Here is one tool that can do so. The necessary command line to use this tool would be:
EDIT: as of Dolphin 5.0-5981, it will randomnise the start address on every platform (Windows and Linux) so you CANNOT use the recommended method I talk about in this post, but you can use the "Alternative method to get the START address" section to have it work, however, as I say in this section, it is also more annoying to use so if you cannot endure to use it, use AT MOST Dolphin 5.0-5977
The randomisation of the start address can be disabled by editing Dolphin.exe to not use ASLR. Here is one tool that can do so. The necessary command line to use this tool would be:
setdllcharacteristics -d Dolphin.exe
I edited the OP with this post as I think people might make a use of this.
However, let it be known that the fragility of the initial setup made such complications was in my opinion inevitable to happen. The CE setup problem and its MANY limitations in ragards to Dolphin has been a problem for years and several people I saw are annoyed by them, mainly about the fact that CE cannot support dynamic memory among other things.
Which is why I decided to start my own project: an external RAM search made to work with Dolphin from scratch that utilises what imo a RAM search for dolphin should be. There's been many issues with CE that made me want to do this a very long time ago, but the PIE issue made me start it the next day, I am just personally tired of these problems, a RAM search shouldn't be so annyoing to setup and use.
I actually started a couple of days ago, but I rather profit from the occasion to say it in case people were interested. I have done an analysis of the project and so far, everything is doable :)
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
Which is why I decided to start my own project: an external RAM search made to work with Dolphin from scratch that utilises what imo a RAM search for dolphin should be. There's been many issues with CE that made me want to do this a very long time ago, but the PIE issue made me start it the next day, I am just personally tired of these problems, a RAM search shouldn't be so annyoing to setup and use.
I actually started a couple of days ago, but I rather profit from the occasion to say it in case people were interested. I have done an analysis of the project and so far, everything is doable :)
Thank you so much if you make that happen.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Which is why I decided to start my own project: an external RAM search made to work with Dolphin from scratch that utilises what imo a RAM search for dolphin should be. There's been many issues with CE that made me want to do this a very long time ago, but the PIE issue made me start it the next day, I am just personally tired of these problems, a RAM search shouldn't be so annyoing to setup and use.
I actually started a couple of days ago, but I rather profit from the occasion to say it in case people were interested. I have done an analysis of the project and so far, everything is doable :)
Thank you so much if you make that happen.
Just a psa to everyone, It happened, at least the first beta release is ready:
http://tasvideos.org/forum/viewtopic.php?t=19437
Please note however that because I don't consider it stable yet and CE still has usefull feature that my ram search don't, I will still be maintaining this thread and support CE problems if they arise, there is still reasons to use CE right now. Eventually, enough will be done for me to recommend the new ram search over CE, but until then, either continue to use CE or try the new one, it has enough to get you started on scanning and watching (with file saving support).
Even if it's a sequel, lots of people have to give their all to make a game, but some people think the sequel process happens naturally." - Masahiro Sakurai
It may have changed but it is interesting that the region size for MEM1 is rounded up and there is empty padding until MEM2 to keep addresses round.
