(e_pbBoard[(32*J)+I] & 0x80)
This is just basic array access.
This:
- Code: Select all
CHAR szString[32] = "Hello";
for ( INT I = 0; szString[I] != '\0'; ++I ) {
PrintF( "%c", szString[I] );
}
runs a variable through the string and prints the character (CHAR,
char) at each position until a '\0' character is found.
This is standard in C, C++, and almost any normal language with array access (
[ ]).
Your game might also have a string in it somewhere, such as the same one as above: “Hello”.
The difference is that the string/code I posted works entirely within its own space.
The strings/code in your games work entirely within the space of the game.
They don’t work together at all, so the code I just posted won’t print the strings in your game.
Introducing
extern.
extern allows you to use the same code as above but instead of working with data from inside your script, it works with data from inside your game.
All we have to do is modify the definition of the data to let the script know that it is in the game instead of inside your script.
- Code: Select all
extern CHAR szString[32] = { "game.exe", 0x0005FE8C };
for ( INT I = 0; szString[I] != '\0'; ++I ) {
PrintF( "%c", szString[I] );
}
The code doesn’t change at all (which is what makes it easy to work with
extern variables.
The only thing that changed is the address of the data, which you can see is at [
game.exe+0x0005FE8C] inside your game.
but then this piece doesn't look like a definition of any sort aside from conventional variable definition.
Correct.
That is why
extern is easy to use.
Following the same conventions as in C/C++, we define a variable the same way we normally would, but prefix it with
extern so the language knows it is in the game, then postfix it with
{ "module", offset } so the language knows where in the game it is.
Just a note.
You can not “initialize”
extern variables because they have already been initialized inside the game.
So at the end of the variable declaration you only need to supply the address of the variable inside the game, rather than supplying an initial value.
What I don't get is how you define the terms for LSS to know what to pull out from the target process
extern = Inside the game.
CHAR = Type of the value inside the game. Whatever type you assign here is what determines how the value will be interpreted when it is taken from the target process.
szString = Your own variable name; it can be anything.
{ "module", offset } = Address inside the game where the CHAR variable is.
One line of code tells L. Spiro Script everything it needs to know to work with the data in the game.
After all this, we can go back to the original point.
(e_pbBoard[(32*J)+I] & 0x80)
Basic array access.
(32*J)+I calculates the array index to get.
e_pbBoard is extern, so the value at that array index will come from the target process.
e_pbBoard is declared as a BYTE array, so the value taken from the target process will be one byte.
& 0x80 is the operation performed on that byte (which came from the target process).
After that operation, if the value is 0, we go into the
if statement.
L. Spiro