Take your time. We are not in a hurry. The search engine will be the hardest part to dial in. Once good it will open the door for some very cool new features.
Just to report the print is fixed but there is 100 less tables found.
Still mixed results but now I dig into the debug log and check some of the hit counter strings.
In the debug log the search strings all seems valid with all possible combination. Only one issue here with variable search. If variable have more that 1 address found it make search strings only for the first address. Can you add functionality to make strings for all found addresses and possible some form of identification at the search.
Now how program handles search strings and interprets results is not visible in the log. I do found that at some instances the hit counter provides false hits. I run a search on random v6 file and 1 strings reports 11 hits. Manually searching the string in the bin occurred at 1 place only.
What might bog the counter is that the table address is found in a multiple search strings that have the same table address but differ in length.
For example this string
[36 38] 91 16 32 7C 03 20 D6 49 31 C3 AD 1E [36 38] 91 16 D6 49 31 C3 AD 1C 34 78 85 0C 31 CA AE 94 31 CA AE 96 [36 38] AC 0C 42 44 06 43 04 00 [24 7C] [00 07 6F E8] F8 12
You will get 36 38 at 3 different places. before you hit 24 7c. Depending on the gap between 36 38 and 24 7C. I guess the hit counter is having trouble with that kind of situation.
Also the hit counter behaves differently between ** and val1:2:hex settings.
To find the problem for mixed results we might need more info in the debug log and to print on the found field, each address where the string is found. with ;;: format
0.12.11
Now searching with all variable addresses.
Currently hit counter is like this:
if (thisFileTables[ts].Data == tsr.Data && thisFileTables[ts].Name == tsr.Name && thisFileTables[ts].origSearchString == tsr.origSearchString)
thisFileTables[ts].hitCount++;
You can see all these in "searched tables" tab, except "origSearchString", but probably you can guess what it means...
Should I use another criteria when calculating hits?
Since we are on the variables, Can we specify a variable value.
for example we type in the item field only var1=38 32;36 32; 34 32; 34 38 and use this in the search string or take a value for a variable from the bin, example var1=@00008000:2:hex.
It will be really useful when there are some different values for table lookup.
I think that for the hit counter we need to have the exact search string at different addresses.
For example string xxyyzzww is found at address 8000 and at 9000 and at 10000 than we have the exact string at 3 places in the bin.
In the v6 I tested the hit counter showed 11 hits while the exact string was found only once in the bin.
kur4o wrote:Since we are on the variables, Can we specify a variable value.
for example we type in the item field only var1=38 32;36 32; 34 32; 34 38 and use this in the search string or take a value for a variable from the bin, example var1=@00008000:2:hex.
It will be really useful when there are some different values for table lookup.
I think that for the hit counter we need to have the exact search string at different addresses.
For example string xxyyzzww is found at address 8000 and at 9000 and at 10000 than we have the exact string at 3 places in the bin.
In the v6 I tested the hit counter showed 11 hits while the exact string was found only once in the bin.
I look at this tomorrow.
Should we continue searching with another combinations after one searchstring have a match?
For example:
Searchstring: 32 38 0-10 74
With searchstring "32 38 * * * 74" get match at address 1234.
Should we continue with other combinations and see, if for example "32 38 * * * * * * * 74" match too at address 1234 ?
For pattern matching we might need to break on exact match and than check the whole string[including found address] for alternative location. Than if alternative location is found add the alternative address to found field and increase hit counter.
Edit:
Can we add in the config window // in front of search string to skip the string from searching. It will make debugging much easier, since I can disable individual lines instead of erase and readd.
kur4o wrote:For pattern matching we might need to break on exact match and than check the whole string[including found address] for alternative location. Than if alternative location is found add the alternative address to found field and increase hit counter.
Edit:
Can we add in the config window // in front of search string to skip the string from searching. It will make debugging much easier, since I can disable individual lines instead of erase and readd.