|
 |
|
|
|
|
|
GTA Modification Forums
Store variable value to memory how to ?
 |
|
 |
| |
Ashwin the new boy  |
|
I am The Most Confused Person

Group: Members
Joined: Nov 14, 2010


|
| QUOTE | | 1. Yeah but what do they do? |
these are the Converted Symbols of Binary language, like HEX > > > Decimal > > > Binary > > > size 9E > > > > -98 > > > > 1001 1110 > >(1 Byte) i don't think i should tell you more what binary actually is  so, Hex Show you the Value of that Byte --------------------------------------------------------------- | QUOTE | 2. That is exactly what I want. And then stored value in memory should change if some claims are true, and then value will be drawn in text box. |
i knew it, because i also had nee of them ha ha ha, I used some Unused Stats memory address for that purpose This post has been edited by Ashwin the new boy on Tuesday, Aug 7 2012, 15:13
|
|
|
|
|
 |
|
 |
 |
|
 |
| |
fastman92  |
|
фастман92 | ف

Group: Members
Joined: Jul 28, 2009


|
| QUOTE (Deji @ Monday, Aug 6 2012, 22:10) | No, a label is no representation of data. It's simply a 'label' for the current position in the script. You get the address of the script position using 05F7 and you write your data to it.
And I no longer recommend the 'ExtraVars' method. It's not completely stable in every situation. I got crashes which were solved by simply adding 0000: before using them in a very rare case which I still don't fully understand. It took quite a while to figure out, but in theory, there should've been no problem. |
Maybe i can explain. If you're using additional variables such as 0@(0@,1i) ; 1@(0@,1i) where 1@ is index pointing to label When it comes to CLEO opcodes - you can put | CODE | | 0AB0: key_pressed 1@(0@,1i) |
But not | CODE | | 0AC6: 1@(0@,1i) = label @label offset |
You can use additional variables in a read context, not write to them. A workaround to this problem is | CODE | 0AC6: 5@ = label @label offset 0085: 1@(0@,1i) = 5@ // (int)
|
On other hand ExtraVars are impossible in GTA VC since there is no array support.
|
|
|
|
|
 |
|
 |
 |
|
 |
| |
fastman92  |
|
фастман92 | ف

Group: Members
Joined: Jul 28, 2009


|
SCM Label - they occur in source to allow programmer refer to them by putting a '@' sign + name of label. Labels do not exist in source in sense that they're registered/defined somewhere. Instead label is turned into negative offset when it points to current script. It's possible to go outside the boundaries of the current script's code, especially when creating threads, go to into other parts of main.scm In that case a positive offset > 0 is being used. Any offset < 0 is assumed automatically to point to the current script, while offset >= 0 is relative to the beginning of main.scm. While coder sees label in project source, labels are simply negative offsets of different codes compiled somewhere else. Note that label offsets are ABSOLUTE, unlike in Assembly code where the rule of relative offsets is respected strongly. | QUOTE | | but it shows the offset or Location when used in opcodes by taking 4 Byte, |
It actually depends upon the compiler used to create a code. Offsets may be 1-byte, 2-byte or 4-byte, however due to limitations of R* compiler and Sanny Builder, they always occupy 4-bytes.
|
|
|
|
|
 |
|
 |
 |
|
 |
| |
Deji  |
|
Coding like a Rockstar!

Group: Members
Joined: Dec 24, 2007


|
| QUOTE (fastman92 @ Tuesday, Aug 7 2012, 15:16) | | You can use additional variables in a read context, not write to them. | You especially shouldn't local vars for offsets... the pointer of the script data can sometimes be placed before the script and it doesn't seem to quite like using negative indexes. Global offsets were better, because they are statically allocated and will always result in a positive index. However, I got crashes simply comparing the value of one in a very rare case. The rest of the script ran fine with them, but comparing one to a normal local var somehow started causing a crash, precisely after the array var was parsed. It didn't even matter if I switched the order of the local and global array, it would crash after the global array was parsed, getting an incorrect pointer overall (I calculated the array info myself and it was conclusive). A remedy was placing 0000: (or anything) before this check. That seemed to change where the data was allocated and resulted in a good pointer when the array was calculated. Maybe something to do with the fact I used it in a SCM Function? Not sure, but a crash that occurs 'sometimes' is hard to pinpoint, so I wouldn't feel good recommending this as a solution to lack of vars, knowing modders may end up spending ages puzzled about why their mod is crashing so randomly. But fear not, because this unfortunate discovery encouraged me to come up with a much better solution which has plenty of perks to come soon. It requires an ASI, however... @Ify24 In coding terms, an offset is the name of the difference between too memory locations. So 4 would be the offset of 2 and 6. Here we're writing to offset 0x598 of the ped struct: | CODE | 0A96: 0@ = actor $PLAYER_ACTOR struct 0@ += 0x598 0A8C: write_memory 0@ size 4 value 0 virtual_protect 0 |
|
|
|
|
|
 |
|
 |
 |
|
 |
| |
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:
Pages:
(2) [1] 2
Track this topic
Receive email notification when a reply has been made to this topic and you are not active on the board.
Subscribe to this forum
Receive email notification when a new topic is posted in this forum and you are not active on the board.
Download / Print this Topic
Download this topic in different formats or view a printer friendly version.
| |
 |
|
 |
|
|
|
|