Whats wrong

[coin-god]

 

:LIFE0001: wait 0 ms0226: $6459 = actor $PLAYER_ACTOR health 00d6: if and0256:   player $PLAYER_CHAR defined 8118:   not actor $PLAYER_ACTOR dead 8028:   not  $6459 >= 110  004d: jump_if_false @LIFE0245: set_actor $PLAYER_ACTOR walk_style_to "DRUNKMAN"0002: jump @LIFE

 

It suppouse to change the walkstyle to DRUNKMAN when his health is less than 110.

 

but nothing happens.

[mido_vip]

i think the opcode 0245: works only with peds

0245: set_actor $PLAYER_ACTOR walk_style_to "DRUNKMAN"

 

[Wesser]

Yes, the opcode 0245 works only with peds not with player. You can't do this change!

[Doomed_Space_Marine]

how was walking style changed in 2 players mod? Or in SA-MP?

[Midnightz]

Your code:

 

 

:LIFE0001: wait 0 ms0226: $6459 = actor $PLAYER_ACTOR health00d6: if and0256:   player $PLAYER_CHAR defined8118:   not actor $PLAYER_ACTOR dead8028:   not  $6459 >= 110  004d: jump_if_false @LIFE0245: set_actor $PLAYER_ACTOR walk_style_to "DRUNKMAN"0002: jump @LIFE

 

 

First mistakes, get that 0256 out of that check and if this is your entire thread,

bump 0256 up so it checks before you refer to player... like so:

 

 

:LIFE0001: wait 0 ms0256:   player $PLAYER_CHAR defined004d: jump_if_false @LIFE0226: $6459 = actor $PLAYER_ACTOR health00d6: if and8118:   not actor $PLAYER_ACTOR dead8028:   not  $6459 >= 110  004d: jump_if_false @LIFE0245: set_actor $PLAYER_ACTOR walk_style_to "DRUNKMAN"0002: jump @LIFE

 

 

Never combine 0256 with other conditions and always use it before referring to player. Try again... if no worky, try using $PLAYER_CHAR in 0245. No good? Find another way/opcode. Wesser is probably correct.

 

Good luck,

-Midnightz

[coin-god]

Yes, the opcode 0245 works only with peds not with player. You can't do this change!

Oh that's a sh*t.

 

 

I will check what midnigthz said and if it dont work i will try another way.

[mido_vip]

if you use $PLAYER_CHAR the game will crash.

[Midnightz]

 

if you use $PLAYER_CHAR the game will crash.

*puts $$$ on it* But I must say, without exploring the possibilities, he/she may never know the full potential or true limitations of any opcode. Some do more &/or function differently than used by R* or as described by INIs and people discover this because they are willing to... not assume anything.

 

Any luck yet goin-god?

(search PLPynton's INI if you keep looking but don't find what you need - in my opinion, his descriptions of opcodes are more sensible and often, more accurate)

 

 

[ceedj]

if you use $PLAYER_CHAR the game will crash.

*puts $$$ on it* But I must say, without exploring the possibilities, he/she may never know the full potential or true limitations of any opcode. Some do more &/or function differently than used by R* or as described by INIs and people discover this because they are willing to... not assume anything.

Let me save you some trouble and crashing:

 

PLAYER_CHAR will NOT work anywhere that takes ACTOR_NAME or PLAYER_ACTOR.

 

You're welcome.

[Doomed_Space_Marine]

if you use $PLAYER_CHAR the game will crash.

*puts $$$ on it* But I must say, without exploring the possibilities, he/she may never know the full potential or true limitations of any opcode. Some do more &/or function differently than used by R* or as described by INIs and people discover this because they are willing to... not assume anything.

Let me save you some trouble and crashing:

 

PLAYER_CHAR will NOT work anywhere that takes ACTOR_NAME or PLAYER_ACTOR.

 

You're welcome.

I know how to describe this easy :

Player and actor are different things. Actor $PLAYER_ACTOR is an actor controlled by player $PLAYER_CHAR.

[coin-god]

Guys i think we all know the diferences betwen Player_Actor and Player_Char

 

 

Well no luck. Ass Wesser said that opcode must dont work for the player. So i do something quick and made this:

 

 

:LIFE0001: wait 0 ms04EF: release_animation "PED" 0226: $6459 = actor $PLAYER_ACTOR health 00d6: if0256:   player $PLAYER_CHAR defined 004d: jump_if_false @LIFE00d6: if and8118:   not actor $PLAYER_ACTOR dead 8028:   not  $6459 >= 110  004d: jump_if_false @LIFE:life_loop0001: wait 0 ms00d6: if0611:   actor $PLAYER_ACTOR animation == "WALK_player"004d: jump_if_false @life_loop0050: gosub @loadwalk 0605: actor $PLAYER_ACTOR perform_animation_sequence "WALK_drunk" from_file "PED" 4.0 loop 1 0 0 0 1750 ms  0002: jump @LIFE:loadwalk0001: wait 0 ms04ED: load_animation "PED" 00d6: if04EE:   animation "PED" loaded 004d: jump_if_false @loadwalk0051: return

 

At least he plays the anim, but dont move forwards or backwards. Stay in his position playing the anim as it were 3d max.

[ceedj]

04EF: release_animation "PED"

 

is a really, REALLY bad idea, as most of the game uses this animation set.

[Doomed_Space_Marine]

Guys i think we all know the diferences betwen Player_Actor and Player_Char

 

 

Well no luck. Ass Wesser said that opcode must dont work for the player. So i do something quick and made this:

 

 

:LIFE0001: wait 0 ms04EF: release_animation "PED" 0226: $6459 = actor $PLAYER_ACTOR health 00d6: if0256:   player $PLAYER_CHAR defined 004d: jump_if_false @LIFE00d6: if and8118:   not actor $PLAYER_ACTOR dead 8028:   not  $6459 >= 110  004d: jump_if_false @LIFE:life_loop0001: wait 0 ms00d6: if0611:   actor $PLAYER_ACTOR animation == "WALK_player"004d: jump_if_false @life_loop0050: gosub @loadwalk 0605: actor $PLAYER_ACTOR perform_animation_sequence "WALK_drunk" from_file "PED" 4.0 loop 1 0 0 0 1750 ms  0002: jump @LIFE:loadwalk0001: wait 0 ms04ED: load_animation "PED" 00d6: if04EE:   animation "PED" loaded 004d: jump_if_false @loadwalk0051: return

 

At least he plays the anim, but dont move forwards or backwards. Stay in his position playing the anim as it were 3d max.

If you put

0605: actor $PLAYER_ACTOR perform_animation_sequence "NULL" from_file "NULL" 4.0 loop 1 0 0 0 1750 ms

after

0605: actor $PLAYER_ACTOR perform_animation_sequence "WALK_drunk" from_file "PED" 4.0 loop 1 0 0 0 1750 ms

then I think it would be able to turn.

[Midnightz]

I just have to say, good job goin-god!

 

Some more reminders/tips to help...

 

- You don't need to load/release any PED animations at all actually. (they are always running)

- You can remove single condition IFs to save byte size.

- Unless this is only part of a thread (and you have the check elsewhere prior), again I say: 0256 BEFORE referring to the player at all. (whether $PLAYER_CHAR or $PLAYER_ACTOR)

- Your JF in the loop is going to prevent re-checking the player's health. (not what you want, I think?)

 

Also...

 

- You don't need to but if this is a CLEO script, put a jump-to-next label unless you want to lose your thread structure when compiled/decompiled.

- Keep your label names less than 7 characters always ("loadwalk" is too long).

- If you don't want the animation to loop, change the "1" to "0" and add a wait after if needed &/or adjust the other params.

 

I think this is what you intended... or it's close anyways:

 

 

:LIFE0001: wait 0 ms0256:   player $PLAYER_CHAR defined004d: jump_if_false @LIFE0226: $6459 = actor $PLAYER_ACTOR health00d6: if and8118:   not actor $PLAYER_ACTOR dead8028:   not  $6459 >= 110  004d: jump_if_false @LIFEjump @LIFE_LOOP:LIFE_LOOP0001: wait 0 ms0611:   actor $PLAYER_ACTOR animation == "WALK_player"004d: jump_if_false @LIFE0605: actor $PLAYER_ACTOR perform_animation_sequence "WALK_drunk" from_file "PED" 4.0 loop 1 0 0 0 1750 ms  0002: jump @LIFE

 

 

Please compare code to see what I'm saying above^...

 

Hope this helps,

-Midnightz

 

[mido_vip]

 

At least he plays the anim, but dont move forwards or backwards. Stay in his position playing the anim as it were 3d max.

hey goin-god if you want the player to move try to put your animation in an "as pack", but he will move forward forever , hope this helps ...

 

:life_loop0001: wait 0 ms 00D6: if 0611:   actor $PLAYER_ACTOR performing_animation "WALK_PLAYER" 004D: jump_if_false @LIFE 0615: define_AS_pack_begin [email protected] 0812: AS_actor -1 perform_animation "WALK_DRUNK" IFP_file "PED" 10000.0 loopA 1 lockX 1 lockY 1 lockF 1 time 0 // versionB 0618: assign_actor $PLAYER_ACTOR to_AS_pack [email protected] 

 

and like ceedj said it's a bad idea loading/releasing the ped file and note that if you load the ped file the game will freeze.

[ceedj]

- Keep your label names less than 7 characters always ("loadwalk" is too long).

Seriously, are you making this stuff up???

[coin-god]

Midnigthz thanks for the help and the recomndations buddy.

I will test your code to see if it works. I think my main problem is 0605

 

oh, im not using CLEO, its normal scm.

 

 

and like ceedj said it's a bad idea loading/releasing the ped file and note that if you load the ped file the game will freeze.

Well, it never crashed to me. And it is not the first time i release the PED ifp file.

 

 

edit: same problem, he still dont move.

Edited November 30, 2007 by goin-god

[mido_vip]

 

Midnigthz thanks for the help and the recomndations buddy.

I will test your code to see if it works. I think my main problem is 0605

 

oh, im not using CLEO, its normal scm.

 

 

and like ceedj said it's a bad idea loading/releasing the ped file and note that if you load the ped file the game will freeze.

Well, it never crashed to me. And it is not the first time i release the PED ifp file.

 

 

edit: same problem, he still dont move.

yeah i guess no harm releasing the ped file, anyway test this it should work then modify the player's health, good luck ...

 

:LIFE03A4: name_thread 'LIFE' 0001: wait 0 ms 04EF: release_animation "PED"00D6: if and0256:   player $PLAYER_CHAR defined 0611:   actor $PLAYER_ACTOR performing_animation "WALK_PLAYER" 004D: jump_if_false @LIFE_3 0002: jump @LIFE_2 :LIFE_20001: wait 0 ms 00D6: if 0611:   actor $PLAYER_ACTOR performing_animation "WALK_PLAYER" 004D: jump_if_false @LIFE 0615: define_AS_pack_begin [email protected] 0812: AS_actor -1 perform_animation "WALK_DRUNK" IFP_file "PED" 10000.0 loopA 1 lockX 1 lockY 1 lockF 1 time 0 // versionB 0618: assign_actor $PLAYER_ACTOR to_AS_pack [email protected] :LIFE_300D6: if 0002: jump @LIFE 

 

 

EDIT: only loading the ped file freeze the game.

Edited November 30, 2007 by mido_vip

[ceedj]

You should never EVER need to load/unload "PED"; it's taken care of by the exe. Just because it's not crashing YOUR game doesn't mean it won't crash at all.

[Midnightz]

 

Seriously, are you making this stuff up???

Seriously... Is a good habit a bad idea? (That was a rhetorical question.) People tend to name their labels the same as they name their threads and as I recall, there IS a char limit to thread names.

 

 

Midnigthz thanks for the help and the recomndations buddy. icon14.gif

You're welcome and thank you too, for listening. I wasn't sure of the effect you wanted but I think I understand your exact goal now. You have been trying very hard to get this working so this should do the trick...

 

Remember I said to first change the parameters of the animation? Using "1" instead of "0" turns a param ON. So, I have turned the looping OFF, set lockX and lockY ON - this forces the animation to run once only and the camera now follows CJ... Technically this is an illusion, because what we've really done is create start and end points for our animation on-the-fly. You wanted to control the direction CJ walks so we must interrupt/force continue the animation somehow. Another approach is this: leave the animation alone, just move CJ where we want him according to joystick manipulation thus permitting him seamless movement.

 

100% Tested Code:

 

:LIFE0001: wait 0 ms0256:   player $PLAYER_CHAR defined004d: jump_if_false @LIFE0226: $6459 = actor $PLAYER_ACTOR health00d6: if and8118:   not actor $PLAYER_ACTOR dead 8028:   not  $6459 >= 11084AD:   not actor $PLAYER_ACTOR in_water // Don't forget or he'll walk drunken when swimming044B:   actor $PLAYER_ACTOR on_foot  // Don't forget or he'll walk drunken while driving004d: jump_if_false @LIFE0494: get_joystick 0 data_to [email protected] [email protected] [email protected] [email protected] 0093: [email protected] = integer [email protected] to_float 0013: [email protected] *= .01 // Increase this number to make him turn L/R/Around faster 0172: [email protected] = actor $PLAYER_ACTOR Z_angle 0063: [email protected] -= [email protected] // (float)jump @LIFE_CTRL:LIFE_CTRL  00d6: if or00E1:   player 0 pressed_key 0 00E1:   player 0 pressed_key 1004d: jump_if_false @LIFE0173: set_actor $PLAYER_ACTOR Z_angle_to [email protected] 0605: actor $PLAYER_ACTOR perform_animation_sequence "WALK_drunk" from_file "PED" 4.0 loop 0 1 1 0 1750 ms0002: jump @LIFE

 

...let me know if you have any trouble using it.

 

Also, if you want to retain your thread name, be sure to include 03A4 as mido_vip suggested above.

 

Good luck,

-Midnightz

 

EDIT: P.S. Make sure your SASCM.INI's opcodes match the ones I posted in terms of param order etc.

Edited December 1, 2007 by Midnightz

[ceedj]

Sigh....

 

http://www.gtaforums.com/index.php?showtop...dpost&p=2952155

 

The ONLY reason you should ever need to "name" a thread is if you're going to use another thread to stop/close it. So even if there IS a limit to thread names, there is no such limit for labels. Well, there might be the 256 char limit, but were talking 8 chars vs 256.

 

Setting LockX and LockY has nothing to do with how many times the animation runs; it "locks" the x and/or y position of the animation. Example, you have an actor in a car and you fire the IDLE_CHAT animation. Without setting the "locks", the animation will play but the actor will stand up in the middle of the car to do the animation. The locks prevent this. The animation runs as long as the last parameter has a time, like 1750 in this case, which is 1.75 seconds.

 

I think it's great you want to help, but I've seen some questionable advice. Maybe research what you're saying a bit better before posting it, mmmkay?

[Midnightz]

 

The ONLY reason you should ever need to "name" a thread is if you're going to use another thread to stop/close it.

I disagree. I name my threads to retain their names (as I said above) when decompiling so I can easily find my way around, else I get a lot of NONAME threads and that's a pain in the butt. So, no... NOT the only reason we might name a thread.

 

 

Setting LockX and LockY has nothing to do with how many times the animation runs;

I never said it did. Please re-read my post.

 

 

I think it's great you want to help, but I've seen some questionable advice. Maybe research what you're saying a bit better before posting it, mmmkay?

Open-minded is what you've seen. A person willing to take risks, you've seen. Perfection, you have not seen. You seem more compelled to challenge what I say than you are to help this guy. Why?!? This isn't the first time I taught you something accidentally, yet you feel you have the right to tell me to do more research? Wow. I am a novice... and not afraid to be wrong, not afraid to help people either. I was taught there is a char limit to thread names and since, like I said... most coders name their labels the same as their threads... keep it short and sweet = lessen room for mistakes. Where's the harm here?

 

C'mon dude... play nice.

-Midnightz

[SteaVor]

The ONLY reason you should ever need to "name" a thread is if you're going to use another thread to stop/close it.

I disagree. I name my threads to retain their names (as I said above) when decompiling so I can easily find my way around, else I get a lot of NONAME threads and that's a pain in the butt. So, no... NOT the only reason we might name a thread.

Is there a reason to decompile your OWN code?

I've never felt the need to decompile the code I had written (and commented) myself, so I'd like to know what I'm missing out on.

[ceedj]

Remember I said to first change the parameters of the animation? Using "1" instead of "0" turns a param ON. So, I have turned the looping OFF, set lockX and lockY ON - this forces the animation to run once only and the camera now follows CJ...

Seems pretty clear to me, but whatever.

 

And I have no problems with open-mindedness. I'm only compelled to challenge what you say when it's wrong.

 

Good grief I'm turning into Demmy. Argh.

[SteaVor]

 

So, I have turned the looping OFF, set lockX and lockY ON - this forces the animation to run once only and the camera now follows CJ...

Seems pretty clear to me, but whatever.

Midnightz is actually right here - read his her sentence again. The bolded part refers to him her having 'turned the looping OFF [...]'

Edited December 1, 2007 by SteaVor

[ceedj]

 

So, I have turned the looping OFF, set lockX and lockY ON - this forces the animation to run once only and the camera now follows CJ...

Seems pretty clear to me, but whatever.

Midnightz is actually right here - read his sentence again. The bolded part refers to him having 'turned turned the looping OFF [...]'

I did. And at first glance, it suggests that the lockx/y has anything to do with looping. Perhaps it's just semantics; what do I know, I'm just the PEDS guy.

 

@Midnightz - Truce dude.

[Midnightz]

Thank you both for re-reading me. I am a female btw - don't hold it against me.

 

Truce

 

@SteaVor: Yes, I decompile my mods and the mods of others and it helps greatly when they've named their threads (I can find stuff more easily). So when I code, I do the same in turn... (nothing released yet but a sh*tload of mods are coming). In fact, my upcoming rollerblade mod uses this method (posted here).

 

 

[Seemann]

 

- You don't need to but if this is a CLEO script, put a jump-to-next label unless you want to lose your thread structure when compiled/decompiled.

No, you don't need that, as well as in the SCM. So,

 

 

jump @LIFE_LOOP:LIFE_LOOP

 

= useless anywhere in the scripts .

 

As for the labels, there’s no limit for them actually. They could even be more than 256 chars in length (hah, who needs it?) .

 

 

 

[SteaVor]

 

  Thank you both for re-reading me.  I am a female btw - don't hold it against me. 

Sorry - I knew (subconsciously) something was 'wrong' when I checked my post before submitting, but I didn't know at that point what caused that feeling.

 

 

@SteaVor: Yes, I decompile my mods and the mods of others and it helps greatly when they've named their threads (I can find stuff more easily).  So when I code, I do the same in turn... (nothing released yet but a sh*tload of mods are coming).  In fact, my upcoming rollerblade mod uses this method (posted here).

Which is why I'm all for including the complete source code with your mods - the moment the compiled SCM is published the code is free to be used and copied by anyone anyway, so there's no harm in distributing the uncompiled script as well.

 

EDIT: Seemann, what's the internal limit for labels in SB then? 65536?

 

@Midnightz:

The game doesn't use the label names at all - you can change all the labels in the script and the compiled file would still be exactly the same. The game jumps to offsets - labels are just there for better reading. SB even allows you to change the label format - try to decompile the SCM with label format set to 'global, hexadecimal offsets'.

Edited December 1, 2007 by SteaVor

[Midnightz]

Seemann, I love you - you butthead.

 

 

No, you don't need that, as well as in the SCM.

Yeahhh I discovered that too actually - forget to edit my post though.

 

You're the one who told me stay less than 7 chars for thread names in SCM! Maybe you're talking about no limits in CLEO? Maybe I misunderstood? Please enlighten... I certainly don't want to post bad info when trying to help others. *smacks forehead*

 

 

SteaVor, understood.

 

 

so there's no harm in distributing the uncompiled script as well.

I will.

 

EDIT:

 

you can change all the labels in the script and the compiled file would still be exactly the same. The game jumps to offsets - labels are just there for better reading.

Oh I agree. Exactly why I support the use of that opcode.

Edited December 1, 2007 by Midnightz