Scan Relative... (command Search/Scan Relative...)


Search for all instances of a find string relatively in a file. The dialog allows you to choose whether you want to search for the next instance in a specific direction. You may search for strings containing the characters (A - Z), (a - z), and (1 - 9). Any other character in the find string is treated as a byte-wildcard. You can save results to a file from this dialog. You can also generate a skeletal "Thingy" Table from the relative offsets of one of the resulting found sequences. If the search string contained only lowercase letters the table would only contain (a - z). If uppercase and numbers where in the search string then they too would be in the resulting table. Please not this is only useful for finding strings using the western alphabet (arabic alphabet).

If I want to search for string but I don't have a table for the file's text encoding then I have to search for it relatively. This works only if the string does not make use of DTE. Please note that the reason DTE (Dual Tile Encoding) is considered to be a pain among table makers is because you cannot easily search for strings relatively if they use DTE. MTE (Multiple Tile Encoding) is hated even more. In addition, it must be noted that just because a string was found in the file matching your search string it does not necessarily mean that it IS in fact equal to the search string. It just means that the found string's characters are RELATED to each other in exactly the same way as the search string's characters are RELATED to each other.

This works best when there are at least 2 of each type of character (I.E. if there is one lower case letter in the string, adding a few more would work better. The same goes for upper case & for numbers)

Example
SEARCH FOR POSSIBLE RESULTS
"Chocobo" "Chocobo", "Zhocobo", "4hocobo", "Qipdpcp", etc.
"Cho*o*o" "Chocobo", "Cho o o", "ChoZoZo", "QipQpQp", etc.
"I am here" "I am here", "ILamLhere", "Zeamqhere", "QQbnQifsf", etc.
"uR8tE5" "uR8tE5", "vS9uF6", etc.

You may wonder why you would get a result like "Qipdpcp" when searching for "Chocobo". The answer to this is that the letters in "Qipdpcp" are related in the same way as the letters in "Chocobo". This illustrates why relative search is not an exact science. The likelihood of someone choosing to encode (or encoding by accident) "Qipdpcp" AND "Chocobo" in the same file is not great but it is something to be aware of. The shorter the search string and the more common the letter combinations the more likely it is that you're results will not be what you want.

Technique Explanation:

You may wish to read about "Text Encoding" before you read this.

What relative search does is it will take a word you give it that you know is going to
appear somewhere in your file, and searches for words of the same length whose characters are related in same way (by the same offsets) as the characters in the search string. It searches by assuming that if the letter A is for example entry $00, then B must be entry $01, and so on. It uses the offset between each character in a string as the comparison. For example, the difference in the offset between A and B is almost always 1. So, if we searched for "ABBA" then we would find all words whose characters have offsets matching (1,0,1) as "ABBA" does. This can turn up a number of inaccurate matches if a short string with common letters is used.