Gecko dotNET release thread (version 0.65 now!)

[Mokuro]

That sounds great, dcx2. Thanks a lot for the tip and Keep up the good work.  :cool:

[dcx2]

test build r85

This is more beta-ish than normal.  I reworked searching over the past two days to get it a little cleaner, so I may have missed some things in testing.  To entice you to try this, I give you...

Undo Search!

I also added some logging.  It writes to a GDNdebug.log file.  Right now, it only writes some exceptions and the time it took to do sorting.  Sorting by address is fastest, sorting by value or oldValue is about 6 times slower, and sorting by diff is 10 times slower.  So if you have hundreds of thousands (or millions) of results, sorting will take a long time...sometimes minutes.

It should be easier to add more search functionality now.  Memory usage should go down some, too.  Until things get straightened out all the way, loading and saving is disabled.

[Dude]

I just want to once again thank all those that have been working on Gecko.net.

Even though I've not been posting that much I have still been following this thread closely and downloading the releases to use when I get the time (not had much in the way of time for posting or even hacking lately).

This app has, and still IS, turning into something truly amazing and is already more than anybody could have hoped for!  Purely phenomenal additions and functions!

Please keep up the good work guys  :cool:

[dcx2]

test build r86

- More exceptions will be written to the log, as well as more timing info
- canceled searches will populate the search results with whatever it managed to transfer
- Search History!

---

Search History is controlled by the two new NumericUpDown spinners labeled New and Old.  Every time you do a search, the results are compressed and saved to disk in the background.  A full MEM1 compressed search takes up about 10 MB or so, so you should be able to do hundreds of searches even if you have limited space.

If you change the value in Old, the Old and Diff columns will be updated with that search's values.  You can use this to see how a value is changing over the course of multiple searches.

If you change the value in New, the New and Address columns will be updated with that search's values and the matching addresses.  This is just like a multi-level undo, because you can go back to any search in the whole history.  If you do a search after going backwards, the new search will be added to the end of the history, so you never lose anything.

It is possible for New Value to point to a Search History index that is less than the Old Value index.  Older New searches can sometimes have more addresses in the dump than newer Old searches; if this is the case, you will see "N/A".  I think the way Block Search works, any value that was "skipped over" by a block search will probably have a 0 instead of N/A.

---

Potential areas to improve:

- Sub folder for search history so it doesn't clog the main folder
- Make skipped over values = N/A
- Ability to turn history on/off
- Not sure what happens if you get 0 results...it might erase the history, which would make it hard to undo

[dcx2]

When does this message appear?  Before the GUI loads?  After it connects?  Do you see anything in GDNdebug.log?

That sounds like an XML error.  There are only two of those, and they should be created if they're missing...maybe yours are corrupt?

You could try renaming gecko.xml to gecko.xml.bak and Gecko dNet.exe.config to Gecko dNet.exe.config.bak while the program is not on, then run it again and see if you get the same error.  Try gecko.xml first.

re: multi-poke...I just tested it and it does work, but I didn't have the XML error that you do.

[dcx2]

Oh, by the way, regarding Search History...

When you do a search against "Last Value", it will actually search against whatever you have set Old Value to.  So you can in theory compare a dump against any value in the whole history of your searches, even the first search.  Might help with things like the GLEE method.

The values are currently 999...I will make them initialize to 0 in the next build.

0 means no search is loaded.

Remember that the search history also includes each result list for each search.  Older new searches will have more results.  You could in theory use this to fork a search, scrolling New back to get the other list and scrolling Old back to compare against the correct older dumps...you'd just need to keep track of which dump numbers correspond to which searches.

[dcx2]

After thinking more carefully, "Last Value" is actually comparing against the New value (which *becomes* the Old Value when it's time for comparisons).

I'll rename "Last Value" to "New Value" and I'll add an "Old Value" line too.

[wiiztec]

Huh? Last value makes sense to me, it's the value immediately preceding the incoming future value, renaming it to new value doesn't make sense to me as it's actually the same thing as what you call the old value.

[dcx2]

Yes, there is a bit of a naming conundrum.  You're thinking about what it is like *after* the dump transferred.  The problem is that you hit the Search button *before* the dump transfers.

Before you hit Search, the dump that will become "Last Value" is currently "New Value".  When you click Search, the current New Value dump becomes the new Old Value dump and *that* is what the comparison is run against.  That is why, at the moment of clicking, "Last Value" actually corresponds to "New Value".

The problem is that if you scroll back the New index, it's more like undo...you will load previous search result addresses that have since been culled.  So you can't actually compare an incoming dump against the first dump.  This is why we need an Old Value in the dropdown; so you can load previous searches without loading their associated address result list.

EDIT: Perhaps "Last New" and "Last Old"?

[wiiztec]

How about "current value" before you click it's the current value, when you click it becomes the last/old value

[dcx2]

Okay, so if we want to compare a search against the values currently in the New column, we would specify "Current Value".

What should we specify when we want to compare a search against the values currently in the Old column?  Still "Old Value"?

[James0x57]

We're comparing values in RAM to values in one of the columns, so number the columns and compare column X to Current RAM. Something like that.
*shrugs*

[dcx2]

The problem with numbering or otherwise annotating the columns is that they lose their New/Old semantics.  If you just see column 1 and 2, or A and B, you don't easily know which column has the values that just got dumped from RAM.

The problem with "current value" is that if you change the New column then you no longer have the "current" value, but instead you have an older value in the New column.  Remember, the results in New can be older than the results in Old.

I would like to have consistent wording between the numeric updown spinners, the search result columns, and the compare-against dropdown box, if possible.  They are all directly related.  To that end, I think I'm still leaning slightly more toward "Last New" and "Last Old", or "New Column" and "Old Column".  However, I'm still very open to suggestions, including different column names.

...maybe I could even add another item to the dropdown list..."Diff Column".  So you'd have four; specific, new, old, and diff.

[dcx2]

test build r87

- Improved Search History
-- Replaced "Last Value" with "New Column (n)" where n is the number of the dump currently displayed in the New column of the search results
-- Added "Old Column (n)"
-- Added "Diff ([n+1] - [n])"

Old column searches can be used so that you aren't reloading culled addresses.

Diff searches can be used to find timers going in a specific direction.  For instance, if you do a Diff search for values equal to FFFFFFFF, then you will find only down-counters.  A different-by-1 search would find both up and down counters.  There are probably other uses I did not consider.

I'm still up in the air about the naming convention.  I'm leaning toward wanting to modify the column names more now.  Maybe replace Old and New with Dump(n).  I could even add (n) to the end of address, to highlight that the list of addresses corresponds to the nth search.

[dcx2]

test build r88

- Dramatically rearranged the layout of the Search tab
- Search Comparison Groups!

There's still some fine tuning needed, but this should be stable enough for people to try out.

Recall that there was once an "Upper Value Info" box that acted like a sort of second comparison, but only supported less-or-equal searches.  Well...that's gone.  With Search Comparison Groups, you can have as many search conditions as you want (up to 9999), and they can be any type of comparison and not just less-or-equal.

So, for instance, with a Specific search, the first group could be "less than 0x64", the second group could be "greater than 0xFFFFFF9C", and the third group could be "not equal 0".  This would find all addresses that are between 100 and -100, excluding 0.

To find timers, with an Unknown search, you could make the first group "different by 1", and the second group "less than" to find down-counting timers or "greater than" to find up-counting timers.

---

This is still under active development.  I plan on making it so that the comparison source dropdown (specific/new/old/diff) is part of the comparison info.  So then you can do a simultaneous specific search and unknown search.

I also plan on making it so that only one specific-equals comparison will need to be true (so you can test for equals 0, or equals 0x64, etc), or all the other non-equals searches will need to be true.