Debugger: Implement subsequent searches/next scan for Memory Search

[Daniel-McCarthy]

Description of Changes

Implements #9720. Adds Next Search functionality to the debugger, allowing the user to filter their search results by doing a second scan.

Rationale behind Changes

Currently when a search is done, a user might want to search again to filter out addresses whose value has changed, or to find specific addresses which can be found by comparing a series of values over time.

This is useful search functionality that will be expanded on later.

Suggested Testing Steps

The scope of changes impacts all Memory Search functionality. It includes a Reset button to start a new search (rather than do a Next Search).

Suggestions:

• Validate search works for different data types. (That search functionality contains no regressions).
• Validate Next Search is working as intended (filtering out addresses that do not match subsequent scans).
• Reset brings Search to a valid state that allows a new search to occur.

Demonstration

PCSX2-NextSearch2.mp4

Notes

I'm interested in any feedback and happy to make changes/improvements. I tried to avoid duplication of logic causing the need to maintain the same logic in multiple places, the drawback is that the implementation is not as clean as I would have preferred it to be.

[github-actions]

Thank you for submitting a contribution to PCSX2

As this is your first pull request, please be aware of the contributing guidelines.

Additionally, as per recent changes in GitHub Actions, your pull request will need to be approved by a maintainer before GitHub Actions can run against it. You can find more information about this change here.

Please be patient until this happens. In the meantime if you'd like to confirm the builds are passing, you have the option of opening a PR on your own fork, just make sure your fork's master branch is up to date!

[refractionpcsx2]

I think having "Next Search" is a bit confusing, cos it sounds like I'm doing the next search, not the same one again but narrowing it down. I'm not sure what you'd name it but I feel like there should be a normal search button (as before) but maybe another "narrow search" button, or something, because I might look for one number, then look for another, and the behaviour won't be as I expect.

[landodragon141]

Maybe call it "Advanced Search" or "Filter Search"

[Daniel-McCarthy]

I think having "Next Search" is a bit confusing, cos it sounds like I'm doing the next search, not the same one again but narrowing it down. I'm not sure what you'd name it but I feel like there should be a normal search button (as before) but maybe another "narrow search" button, or something, because I might look for one number, then look for another, and the behaviour won't be as I expect.

Hey, thanks for the feedback.

If we no longer need a "Reset" button, then Search can stay where it is, and the Reset Button can be replaced with the "Next Scan" which appears after a first search has happened. A new search would then be done by clicking "Search".
Though, I can see that also being a little confusing, because one button relies on the existing results state and the other does not. The nice aspect of reset was that it cleared the results list and made it clear it was searching from scratch (in that state).

If it's more of a naming issue and Search becoming another term (while having Reset to bring it back) is fine, we could rename it to a lot of things:

• "Next Scan"
• "Filter Search" (as mentioned by landodragon141)
• "Re-Scan"
• "Filter Results"
• "Search Results"
• "Refine Search"

Or, maybe "Reset" should be "New Search".

[refractionpcsx2]

What if the button was more dynamic? so it becomes "filter search" if you don't change the value, but the moment you change the contents it becomes "Search"?

[Daniel-McCarthy]

What if the button was more dynamic? so it becomes "filter search" if you don't change the value, but the moment you change the contents it becomes "Search"?

That would unfortunately remove a potential use case of this feature.
So, if you're looking for a value that changes but you know the value the value it will change to, you can search for the initial value, get an address list that hold 10 (for example), then if you know it's going to change to 9, after it changes, you would change the value and do a filter search to get all only addresses that were 10 but are now 9.

Unfortunately, if it goes to a new search when you change the value, then this next scan feature would only be able to target making sure an address still holds the value you expected.

As a side note, related useful search functionality that I'd be interested in adding would be doing search for addresses who's value is >, <, ==, != to a value. This, in combination with the next scan, would be quite helpful in finding very specific memory addresses.

[refractionpcsx2]

oh I see what you mean, yeah separate buttons then.

[Daniel-McCarthy]

Here is my suggestion: "Filter Search" button present after an initial Search. "New Search" is present after an initial search and resets to original state.

This allows you to filter as many times as you need, and when you want to do a new search it is clear on how, and clear more clear on what each button does.

[refractionpcsx2]

The only thing I don't like about that is people who don't want to filter now have to do 2 clicks where it was 1 previous, I'd rather the "new search" button actually made a new search, didn't just "reset"

[Daniel-McCarthy]

New iteration:

• "Search" is always present, never changes, always starts a new search.
• Below Search is "Filter Search", it is always present, but disabled by default. Enables when a search occurs, but will be disabled when the results list is empty.

Starting a new search is 1 click, filtering the results list is 1 click. There is space open on the row to allow for future dropdowns for different types of search.

[refractionpcsx2]

I like this iteration :)

[RedDevilus]

You could look at inspiration from cheat engine as well, it's starting to look like it anyway from a GUI standpoint (kinda):

[refractionpcsx2]

Please don't make it look like cheat engine :D

[ghost]

@Daniel-McCarthy Thank you SO MUCH for your hard work! <3

[ghost]

Also, this will likely lead someone into requesting bigger than/smaller than/ decreased value/increased value, next. And you don't have to do it if you don't want to, but if you can, that would be wonderful!

[Daniel-McCarthy]

My intention is to include some functionality from CE that I think enables some very useful debugger functionality that isn't already here, like the >, <, ==, !=. But without all the complexity, just some of the bare functionality that I think would really benefit users.

But that's for after this PR. I'd like to get this one landed and then give a try at that after.

[F0bes]

I left some comments.
I do notice an issue (that may have been before this PR) when searching for 111111111 (nine ones) during a 4 byte search. The button appears to re-enable (indicating that it has completed?) but the entire UI locks up as QT tries to render all the text. It takes a good 10/15 seconds on my computer and I immediately thought the UI thread was in a deadlock. I don't know how to proceed with that issue (maybe only render the first x amount of results but still keep the others in memory like cheat engine?)
From my quick tests the memory search filter works good though. Good work 👍

[Daniel-McCarthy]

I left some comments. I do notice an issue (that may have been before this PR) when searching for 111111111 (nine ones) during a 4 byte search. The button appears to re-enable (indicating that it has completed?) but the entire UI locks up as QT tries to render all the text. It takes a good 10/15 seconds on my computer and I immediately thought the UI thread was in a deadlock. I don't know how to proceed with that issue (maybe only render the first x amount of results but still keep the others in memory like cheat engine?) From my quick tests the memory search filter works good though. Good work 👍

I have noticed this behavior prior to this PR, but it's likely a good moment to tackle it. It seems to struggle when returning a large amount of results and loading them all at once. I'll look into ways to load an initial amount, and display more as one scrolls, or another solution in that style.

Thanks for the feedback, I'll address the comments and then look into options for the UI freezing with high amounts of results.

[Daniel-McCarthy]

Adding this for reference. I have now implemented a lazy loading style way of displaying the search results and adding more as the user scrolls. This allows us to avoid stalling from loading massive amounts of results at once.

All current feedback should be addressed/resolved, thanks everyone!

[F0bes]

Looks good and functions as I expect.
Just fix that warning and it's all good from me.

[ghost]

I don't want to overburden you with requests, but being able to see the current value and being able to delete offsets from the results list would be nice to have. But then again, bear in mind that it's not that consequential to have. Thank you for all the word you've done :D! <3

[Daniel-McCarthy]

I don't want to overburden you with requests, but being able to see the current value and being able to delete offsets from the results list would be nice to have. But then again, bear in mind that it's not that consequential to have. Thank you for all the word you've done :D! <3

Hey there, I'm not opposed to picking those up, particularly removing a result from the list. But it might be best to create issues for those ideas to track the ideas. 👍 Good suggestions