Dolphin, the GameCube and Wii emulator - Forums

Full Version: Hexadecimal Searches Cheat Manager
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I might be stupid and missing something, but the ability to search for Hexadecimal values seems to be gone since the overhaul of the Cheat Manager?

The idea is to search for a value which was Hexadecimal to begin with. Now I seem to need to convert it to Base 10 (Integer) first so that I can search for the hex value I wanted to search for in the first place. 9 out of 10 times I am more interested in search for Hex values rather than Base 10 values, mostly in combination with the Debugger Interface enabled so I can look through the memory of the game. When selecting the data type for running a new Search Entry there doesn't seem to be an option to search for Hex values, which might be the proper place to add that data type. There's only Signed Integers, Unsigned Integers and Floats. I am not even sure what the checkbox below it even does.

It's odd because you can show the results in Hexadecimal values by checking a checkbox, but not search for them this way.

Another issue is that the Dutch GUI (and probably other localizations as well) aren't properly adjusted. Some GUI elements are cut off to not visible enough. Take the Base 10 value I search for which doesn't fit. Resizing the window works and fixes this, but it doesn't seem to be permanent when rebooting Dolphin, so it's kinda annoying.

While the new GUI looks like it could be a definitive upgrade, right now because of those issues it's actually less practical to use it than the old GUI. That, or maybe I am missing something and didn't know about it yet.

Thanks.

English
[attachment=19871]

Dutch
[attachment=19872]
Just prefix the number in your search with 0x, like this:

[Image: zcA31mj.png]

I figured that was intuitive, but maybe not?


As for the size issue, yeah we should probably make that window remember its dimensions. I'll do that sometime this week.
(10-27-2021, 02:40 PM)AdmiralCurtiss Wrote: [ -> ]Just prefix the number in your search with 0x, like this:

I figured that was intuitive, but maybe not?

As for the size issue, yeah we should probably make that window remember its dimensions. I'll do that sometime this week.

Ahh thanks. Then I at least know it works. Maybe I expected it from the old GUI design too much in which you specifically had to set if you searched in hexadecimal or decimal. Maybe some tooltip or some small info tidbit could inform about this that adding 0x turns it into a hexadecimal search.

The only annoying thing would be that you have to add 0x to every search. While I know it's the proper technical use for hexadecimal values it doesn't seem very streamlined for in a GUI. Most of the time, I either only want to search as Hexadecimal or as Decimal. So I usually do a few searches using the same type. Adding 0x everytime slows down this process a bit. A checkbox to toggle between decimal or hexadecimal input would not only be more intuitive I believe, but also would have a faster workflow. That, or maybe use both ways. So adding 0x always does a hexadecimal search and the checkbox basically toggles whatever that 0x prefix is mandatory or not for a hexadecimal search. Adding 0x isn't much of an issue that would get in your way if both methods exist.

Anyway, thanks for the answer. At least I know it's still working now.

One more question since this seems new as well? Is there any difference between "Aligned" and "Unaligned"? It does seem to affect the results (aka, addresses) you get, but I am not sure how it works.
It's got to do with aligned and unaligned memory accesses. For a type that is N bytes big, aligned access allows the values to only be on a addresses that are a multiple of N, where as unaligned allows them to be anywhere.

So as an example, a 32-bit (4 byte) integer type aligned search checks 0x8000'0000, 0x8000'0004, 0x8000'0008, 0x8000'000C, 0x8000'0010 etc, while unaligned would check 0x8000'0000, 0x8000'0001, 0x8000'0002, 0x8000'0003, 0x8000'0004, 0x8000'0005 and so on. The vast vast majority of games only ever store their values in an aligned manner, so only checking that can filter out useless results early -- plus it's a bit faster.
(10-28-2021, 06:33 AM)AdmiralCurtiss Wrote: [ -> ]It's got to do with aligned and unaligned memory accesses. For a type that is N bytes big, aligned access allows the values to only be on a addresses that are a multiple of N, where as unaligned allows them to be anywhere.

So as an example, a 32-bit (4 byte) integer type aligned search checks 0x8000'0000, 0x8000'0004, 0x8000'0008, 0x8000'000C, 0x8000'0010 etc, while unaligned would check 0x8000'0000, 0x8000'0001, 0x8000'0002, 0x8000'0003, 0x8000'0004, 0x8000'0005 and so on. The vast vast majority of games only ever store their values in an aligned manner, so only checking that can filter out useless results early -- plus it's a bit faster.

Ohh I see. That's useful to know. Thank you. Makes sense. Yup. I was just unfamiliar with the checkbox since it was new, otherwise I should have just known this lol. I tend to need to find unaligned stuff as well at times, so this could come in handy.

Thanks for your explanation again! Other than the issues I named, it's definitely a major step up from the old design. I really like how it's no longer limited to 50 searches and the GUI seems more flexible which is always nice.
The latest dev build should now address the issues you were talking about. Feel free to report if you run into any others!
I do have one small request though.

When searching a new start, would it be possible to use the last saved settings? So for example when "Parse as Hex" was checked last time, it will be checked again when running a new search. This checkbox doesn't seem to be saved on exit or on new searches. Likewise when it's unchecked it should remain unchecked on subsequent searches. This also applies to the "Show value in Hex" checkbox.

Another suggestion is to allow spaces in searches as well, in which case the space is removed internally for the search. I find it useful for human readability for example to put my hex values in sections (like per 8 bit, or per 16 bit or per 32 bit). So I could so a search for example on "00000042 80000000" which is a 64-bit search but consists out of two 32-bit addresses. The Dolphin memory viewer in the debug menu also splits it per 32-bit.

Finally, I would also love it if I can moved the tabs back and forth (searches) like with Chrome. So I can for example put my 32-bit aligned search tab in the front even when I added it the last. I would also be nice if the tab could be renamed so I can immediately see which search it is without going to that tab first, and if the tabs can be saved for subsequent runs (I am aware the RAM has to be refreshed so maybe it can just auto-remember which search types it did last and re-activate those as soon a game is loaded) as I am usually interested in doing the same type of searches on each subsequent run.

I must say that the addition to allow for 64-bit searches is wonderful. It's probably the best new addition. And aligned searches are extremely useful though. You wouldn't know you missed this until you had it. Great work!