Page 1 of 1

A limitation in memhack, a bug or an ID10T error on my part?

PostPosted: Sat Jun 04, 2011 2:23 pm
by esco
Hey Spiro, I have been playing with some different types in Memhack, and I noticed 2 quick things:

1)When i set up a simple if statement with a pointer value to be checked, it returns false even though it's true. Yet when I put in the equivalent decimal value for it, it returns true and runs this script. Is this a bug of some kind?

Code: Select all
extern LONG newarmcode[1] = { "", 0x00b118}; 
extern LONG oldarmcode[1] = { "", 0x167934}; 

//this works
if (oldarmcode[7] == -1400766460) {newcode = 1;}

//this doesn't
if (oldarmcode[7] == 0xA4820006) {newcode = 1;}

//this fails too of course
if (oldarmcode[7] == 0x060082A4) {newcode = 1;}


2)When using a script involving a LONG type var, when I set it to write in the value of -2,147,483,648 , it would instead write in -2,147,483,647. According to your documentation the limit for a long is -2,147,483,648 . Why does this happen? Yet if I tell it to --1 from the value if it is -2147483647, it will set it to -2147483648 like it should be.

3) When using #include to link to a text file with code, I noticed that just editing the txt file, and resaving it wasn't enough to update my scripts. It seems that I also have to compile it in the code editor, and then reopen the locked value with the script in it, copy and paste the same script info in (since only the info in the txt has changed) and then hit ok to get it to work. And sometimes this seems to possibly fail too, so I just take the info out of the txt and paste it into the code file itself and it works fine. What am I doing wrong?

Re: A limitation in memhack, a bug or an ID10T error on my part?

PostPosted: Sat Jun 04, 2011 8:23 pm
by L. Spiro
#1:
-1400766460 is 0xAC820004, not 0xA4820006.
If that is not the problem, use unsigned typed or manually cast the constant. (LONG)0xAC820004.

#2:
Sounds like a bug.


#3:
It is normal that the code will not be updated after changing a header file until you manually save the file and recompile the scripts.
As for updating script-locked values, pasting the header contents into the editor is unnecessary and overkill.
Add a new line or blank comment to get it to realize there has been a change and recompile.


L. Spiro

Re: A limitation in memhack, a bug or an ID10T error on my part?

PostPosted: Sun Jun 05, 2011 2:24 am
by esco
L. Spiro wrote:#1:
-1400766460 is 0xAC820004, not 0xA4820006.
If that is not the problem, use unsigned typed or manually cast the constant. (LONG)0xAC820004.


Yeah I was off a digit..... I need to stop coding at 4 am after having a bunch of drinks. :oops:

It is normal that the code will not be updated after changing a header file until you manually save the file and recompile the scripts.
As for updating script-locked values, pasting the header contents into the editor is unnecessary and overkill.
Add a new line or blank comment to get it to realize there has been a change and recompile.


Cool, thanks for the help bro. How is business out in japan after all the hell that went on out there? You doing aight?

Re: A limitation in memhack, a bug or an ID10T error on my part?

PostPosted: Sun Jun 05, 2011 8:29 am
by L. Spiro
Not much in my life changed, although I was hit by the earthquakes (you have probably seen the pictures).
Shops are still leaving their signs off at night, making it hard to notice if they are open or not, but I normally don’t go out at night so this is no real change for me.

Professional life is normal.
Just working on my new engine, and it is coming along super great.


L. Spiro