A transform code ,it works! but help me with sth

[agitohu]

it is the original code i design,it work!!!!!

 

 

:Label00A0B6

0001: wait 200 ms

00D6: if 0

0256: player $PLAYER_CHAR defined

004D: jump_if_false  ££Label00A0B6

00D6: if 0

00E1: key_pressed?0?13

004D: jump_if_false  ££Label00A0B6

00D6: if 0

80E0:  NOT player $PLAYER_CHAR driving

004D: jump_if_false  ££Label00A0B6

0352: set_actor $PLAYER_ACTOR skin_to "PLAYER2"

038B: load_requested_models

0353: refresh_actor $PLAYER_ACTOR

 

after this success .it made me filled with confidence to make it better,but when i code a reform code ,it cant work ,i have brood over this thing for long ,

cant find a solution ,want someone correct my code

 

that is my 2nd changed codes:

 

 

:Label00A0B6

0001: wait 200 ms

00D6: if 0

0256: player $PLAYER_CHAR defined

004D: jump_if_false ££Label00A0B6

00D6: if 0

00E1: key_pressed 0 13

004D: jump_if_false ££Label00A0B6

00D6: if 0

0038: $4F1 == 1 ;; integer values

004D: jump_if_false ££Labelreform

00D6: if 0

80E0: NOT player $PLAYER_CHAR driving

004D: jump_if_false ££Label00A0B6

0352: set_actor $PLAYER_ACTOR skin_to "PLAYER2"

038B: load_requested_models

0353: refresh_actor $PLAYER_ACTOR

0038: $4F1 = 0 ;; integer values

0002: jump ££Label00A0B6

 

 

:Labelreform

00D6: if 0

80E0:  NOT player $PLAYER_CHAR driving

004D: jump_if_false ££Label00A0B6

0352: set_actor $PLAYER_ACTOR skin_to "PLAYER"

038B: load_requested_models

0353: refresh_actor $PLAYER_ACTOR

0038: $4F1 = 1 ;; integer values

0002: jump ££Label00A0B6

 

 

in the main part ,i have typt this code,which make a mark to condition whether you have in skin"player2".

 

0004: $4F1 =?1 ;; integer values

 

 

the result is :

when i press "V" key,it change to "player2"skin, but press again ,it has no respon........(which i want to let it reform to "player"skin)

Edited November 24, 2006 by agitohu

[ceedj]

You're using 0038 to set your variable after refresh actor, which is incorrect. You DO have it right for the if check though. To set your variable (like you are doing as a flag) use 0004 (setgi) after your refresh actor line (in both spots) to make your variable equal 1 or 0.

[agitohu]

what a losser i am !!! i cant believe i make a blunder just discount the 0038..............

thanks dude!!!!!

I owe you

[Bigun]

Actually though, globals may work, but you're better off using local vars. If you don't need to access the global var from a different thread (or mission), then it's just a waste of space and you should use a local var instead. Assuming you are using SA, you can use local vars @0 - @31 in threads (and much more in missions...pretty much all you need. In missions, @1000 works). Local vars @32 and @33 are timers, they are local vars that start at 0 when the thread start and keep increasing by 1 every millisecond. In VC, IIRC, the local vars are @0 - @15 and @16 & @17 are timers.

You can't name local vars in MB, but you didn't really name your global anyway. Note, don't use a global variable name that is ALL numbers. That's a special type of assignation called DMA, and you don't need it.

Use opcode 0006 to set a local var to an integer value (it's 0004 equivalent, but for local vars). Use opcode 0039 (if I remember correctly) to check it (0038's local equivalent).

 

If I were you, I wouldn't use label names like :Label00A0B6. That label name "format" also, by the way, is an automatic format MB uses on "unindentified"/unnamed decompiled labels. You don't HAVE to use custom label names, but you can use them for a reason, and believe me, it makes it much easier to read your code. If you're wondering, you can use ANY name (though you can't, of course, have 2 labels with the same name). It doesn't have to start with "Label" (the : is telling the compiler its a label definition). If you look around at posted code you can see people naming labels "check","do" etc. Though it's better to prefix them with the mod's name because 99% of the mods do things like "check" etc. I usually use MODNAME_xyz for my labels. xyz can be "check","loaded" (checking for loaded models) and more. Sometimes I just get lazy and put numbers instead (MODNAME_1), though it's still easier to read than Label0A9090AD...!

 

In addition, in your first label, you can clump the keypress and 'if defined' checks, like this:

Instead of...

00D6: if 00256: player $PLAYER_CHAR defined004D: jump_if_false ££Label00A0B600D6: if 000E1: key_pressed 0 13004D: jump_if_false ££Label00A0B6

 

Use:

 

00D6: if 10256: player $PLAYER_CHAR defined00E1: key_pressed 0 13004D: jump_if_false ££Label00A0B6

 

You can do that because, what may not be guessed easily, keypresses don't reference the player (imagine them something simply like "get_keyboard_status " etc) (keypresses also still work if player isn't defined), so checking them won't crash the game if the player is undefined.

If you don't know what the integer in the 'if' opcode (if 1, if 0...) does, read the readme.

 

 

what a losser i am !!! i cant believe i make a blunder just discount the 0038..............

Don't be frustrated. Stupid minor errors occassionally happen to even the best of coders.

Edited November 25, 2006 by Bigun

[agitohu]

thanks for your elabirate reply,i learn sth more about local vars......

i didnt have nerve to use local vars just because i dont konw where and when it will disable in the game ,but after seeing your account for d local vars,i think it ends in "end_thread"may be,i will check it out

[Bigun]

 

because i dont konw where and when it will disable in the game

 

Some random insight on variables coming up...

-

Local vars are specific to each thread, so yes of course, they will be gone when the thread ends, though the 'end_thread' opcode doesn't do cleanup of the thread, like releasing models so they can be unloaded, turning special peds/cars intercepted/created by the thread to random peds/cars so they can disappear OR deleting them. So local vars keep their values until the thread has ended OR the local var was re-written (duh). IIRC, when a new thread is started, all it's local vars are initialized to value 0 (int).

 

Global vars keep their value until rewritten.

 

When saving the game, all global vars are saved. Also, IIRC, all local vars are saved (and the running threads' positions) so they remain between game sessions (...if you save and reload).

 

The main (and almost only) reason to use global vars is if you need to access the same variable from (communicate between>) more than 1 single thread/mission/external script. Global vars allocate more memory than locals, so if you don't need the above, always go for locals.

 

Global vars don't actually have names, the names are for the source code & compiler only, they don't exist in the compiled SCM file. Named global vars is a feature of the compiler (named local vars is possible too, but takes more effort since there is the need to diffrenate between threads. I think Sanny Builder 3.0 is going to have that feature). When you see global vars "named" with a number , that number is the offset in the file they are going to be compiled to. When you use named global vars, the compiler decides on an offset for you, and it's usually best that way.

Edited November 25, 2006 by Bigun