log_y(x) ≢ log(x) ÷ log(y)
Because:
log_-1(-1) = Any odd integer, including negatives. (As (-1)^-1 == -1, and (-1)¹ == -1, etc.)
log(-1) ÷ log(-1) = 1.

WHAT.

Coollog is a repeat offender of this one.
Look at one of his scripts, read the code on each line, then tell me if you are at all enlightened by the comments:

Code Select Expand

var _d,_i,_j,_c;//Dims the temporary variables for the script.

_d=0;//Sets _d to 0.
for(_i=0;_i<=string_length(argument0);_i+=1)//Loops for starting with _i=0, while _i is still smaller than or equal to the length of the first inputed string, add one to _i and execute the bracketed code.
_d[_i,0]=_i;//Sets the cell at row _i, column 0 to _i.
for(_j=0;_j<=string_length(argument1);_j+=1)//Loops for starting with _j=0, while _j is still smaller than or equal to the length of the second inputed string, add one to _j and execute the bracketed code.
_d[0,_j]=_j;//Sets the cell at row 0, column _j to _j.

for(_i=1;_i<=string_length(argument0);_i+=1)//Loops for starting with _i=1, while _i is still smaller than or equal to the length of the first inputed string, add one to _i and execute the bracketed code.
for(_j=1;_j<=string_length(argument1);_j+=1)//Loops for starting with _j=1, while _j is still smaller than or equal to the length of the second inputed string, add one to _j and execute the bracketed code.
{
  if string_char_at(argument0,_i) = string_char_at(argument1,_j)//If the character in the first inputed string at position _i is equal to the same position in the second inputed string...
   _c=0;//Sets _c to 0.
  else//Otherwise...
   _c=1;//Sets _c to 1.
  _d[_i,_j]=min(_d[_i-1,_j]+1,_d[_i,_j-1]+1,_d[_i-1,_j-1]+_c);//Sets the cell at row _i, column _j to the minimum of the above value plus one, the left value plus one, or the top-left value plus _c.
}

return _d[string_length(argument0),string_length(argument1)];//Returns the difference between the first inputed string and the second inputed string.
The whole point of comments is to help people decipher the code, not to say what each individual command does, but its role in the big picture of the script.

Code Select Expand

00402D76      64:               PREFIX FS:                                ;  Superfluous prefix
00402D77      2E:               PREFIX CS:                                ;  Superfluous prefix
00402D78      66:               PREFIX DATASIZE:                          ;  Superfluous prefix
;No, Olly, that prefix is pretty vital. NOT superfluous.
00402D79      F0:               PREFIX LOCK:                              ;  Superfluous prefix
00402D7A      36:               PREFIX SS:                                ;  Superfluous prefix
00402D7B      65:               PREFIX GS:                                ;  Superfluous prefix
00402D7C      3E:8700           XCHG DWORD PTR DS:[EAX],EAX

Do you see anything wrong with that disassembly?

That's right, all the superfluous prefixes surrounding the real one (PREFIX DATASIZE: is not superfluous) confuse Olly into thinking the command will be "XCHG DWORD PTR DS:[EAX],EAX". In fact, it executes as "XCHG DWORD PTR DS:[EAX],AX".

Small bug, but I thought it was amusing at the time.

I edited the code to do this - you won't find this in any application

Oh yeah, "xchg eax,eax" compiles, in Olly, as "90" ("nop") instead of "87C0" ("xchg eax,eax"). "xchg ebx,ebx", however, doesn't.

Since we all love it so much, (or am I the only one? ) you can either try figuring these out *without looking them up* or making your own:

(All values in hex, executing on an x86-compatible processor.)
1.

Code Select Expand

test eax,eax
setne al
and eax,1
2.

Code Select Expand

cmp al,0A
sbb al,69
das
and eax,0ff
3. An extension of the last:

Code Select Expand

mov ebx, stringvariable
mov ecx, 0DEADF00D
xor edx,edx
push 8
loop1:
  cmp dword[esp],0
  je endloop1
  rol ecx,4
  mov al, cl
  and al, 0F
  cmp al, 0A
  sbb al, 69
  das
  mov byte [edx+ebx],al
  inc edx
  dec dword[esp]
  and ecx,0FFFFFFF0
  jmp loop1
endloop1:
mov byte [edx+ebx],0
add esp,4

4. Simple one for simple folk:

Code Select Expand

xor eax,eax
not eax
xor ecx,ecx
dec ecx
xor eax,ecx ; It's like poetry: purposely long-winded but gets there in the end

Has anyone tried reverse engineering anything? (I mean from disassembly, not from guessing what it does after output)

I've gone and grabbed the encryption algorithm from some unsuspecting GM DLLs, and I've also been reversing for other means - but most GM security DLLs can be cracked with a simple XOR EAX,EAX / INC EAX / RETN XX (that number varies).

The hardest thing to reverse-engineer, IMO, is any delphi program.

I'm going to post my desktop, and you can do the same if you want.

I would make this into a game, but I'd win before you even posted.


Awesomeness.

How would I go about defining global variables in C++/EDL? I can't think of where to put a C++ code block. Would I have to just edit the source file afterwards? (Or is there something like "global void* variable_name;" in C++? I've only had experience with C)

If I wanted to maintain 2 different copies of code for one thing, one for Enigma and one for GM, I don't want to have to do everything twice... so do I have to wait until enigma is fully compatible, or will there be something like this implemented?

Code Select Expand


/*ENIGMA
Some enigma-specific code
...
etc
END*/
/*GM*/
Some gm-specific code
...
etc etc etc you get the idea
/*END*/


ds_list_size(), along with the rest of them, results in a syntax error for me, saying that the function does not exist (with latest build from time of writing).
Since it's marked as finished, what's the problem with it?

(Enigma also reports that I have an unknown D&D action while every object has only code actions. )

I also spotted this little gem while trying to work my way through the source code...
   char ordinal=(char) enigma::negmod(val,255);
Surely that can just be...
   char ordinal=(char)val; //val&0xFF is implied, as char is only 1 byte.
And thinking over that again, why do you have a function called "negmod", instead of just x%y ?

There was a hint that it's not known what these do on the progress report.

io_clear() makes GM (or in this case, Enigma) treat all mouse buttons as released and the same with keyboard buttons.
io_handle() makes GM/Enigma re-check all buttons for the keyboard and mouse (for example, if you released a button while the window was not in focus).