The part that baffles me most is that the exact same code is executed for all these conditions. I have all the code in front of me that is run when a send/zap/restore is executed (these three statements all share most of the code). And I still don't understand how this even works.
OOPReadWord will attempt to read a word from OOP code. If the first character is a number it returns nothing. If subsequent characters are numbers, this is ok (in fact valid characters are 0-9, A-Z, _, and :. That last one is for the sake of going through other targets.) But this is not the same code as used to actually search the OOP code. It uses some really messed up string matching that I don't fully understand. Even worse, variables are manipulated from within these functions so when you call them, the input values change radically.
This whole section of the OOP engine is one heaping pile of shit.
Here's the translated version of the search code:
Private Function OOPSearch(ByVal ThingData As Thing, ByVal SearchString As String) As Integer
Dim Offset As Integer
Dim CodeOffset As Integer
Dim Index As Integer
Dim SearchOffset As Integer
If (CodeOffset > ThingData.Code.Code.Length) Then
Offset = -1
SearchOffset = CodeOffset
For Index = 1 To SearchString.Length
If (ReadOOPByte(ThingData, SearchOffset).ToUpper = SearchString.Substring(Index - 1, 1).ToUpper) Then
CodeOffset += 1
Select Case ReadOOPByte(ThingData, SearchOffset).ToUpper
Case "A" To "Z", "_"
Offset = CodeOffset
CodeOffset += 1
So basically it is a match if a letter or _ does not follow what it found as a possible match in the code, and it comes back with the first discovered instance.
Also, Code.Code is due to the way strings are handled in VB, they are treated as values, not references. Therefore I had to create a class that would hold the code, so it could be referenced and shared by multiple things on the board.
Unrelated: ZZT has a 4kb limit on messages generated by OOP.