Need help w/ random atk

[Confuzed_Person]

ok, ive been workin on trying to get my random atk to work and it never does. can some1 tell me wut is wrong.

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Tue Apr 11 18:04:37 2006
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 151 Zealot (protoss\zealot.grp)
.headerstart
IsId 163
Type 21
Init ZealotInit
Death ZealotDeath
GndAttkInit ZealotGndAttkInit
AirAttkInit ZealotGndAttkInit
SpAbility1 [NONE]
GndAttkRpt ZealotGndAttkRpt
AirAttkRpt ZealotGndAttkRpt
SpAbility2 [NONE]
GndAttkToIdle ZealotGndAttkToIdle
AirAttkToIdle [NONE]
SpAbility3 [NONE]
Walking ZealotWalking
Other ZealotOther
BurrowInit [NONE]
ConstrctHarvst [NONE]
IsWorking [NONE]
Landing [NONE]
LiftOff [NONE]
Unknown18 [NONE]
Unknown19 [NONE]
Unknown20 [NONE]
Unknown21 ZealotUnknown21
randcondjump specialweapon
.headerend
# ----------------------------------------------------------------------------- #

ZealotInit:
imgul09 152 0 0 # ZealotShad (protoss\pzeShad.grp)
ZealotOther:
playfram 0x55 # frame set 5
goto local00

local00:
wait 125
goto local00

ZealotDeath:
playsnd 678 # Protoss\ZEALOT\PZeDth00.WAV
playframno 0
playfram 0xdd # frame set 13
wait 2
playfram 0xde # frame set 13
wait 2
playfram 0xdf # frame set 13
wait 2
playfram 0xe0 # frame set 13
wait 2
playfram 0xe1 # frame set 13
wait 2
playfram 0xe2 # frame set 13
wait 2
playfram 0xe3 # frame set 13
wait 2
end

ZealotGndAttkInit:
playfram 0x00 # frame set 0
wait 1
ZealotGndAttkRpt:
playsndrand 2 662 663 # Protoss\ZEALOT\pzeAtt00.WAV, Protoss\ZEALOT\pzeAtt01.WAV
playfram 0x11 # frame set 1
wait 1
nobrkcodestart
playfram 0x22 # frame set 2
wait 1
imgul09 298 0 0 # MissleTurretShad (terran\tmiShad.grp)
playfram 0x33 # frame set 3
wait 1
playfram 0x44 # frame set 4
attack1c 1 664 # Protoss\ZEALOT\pzeHit00.WAV
wait 1
playfram 0x33 # frame set 3
wait 1
imgul09 298 0 0 # MissleTurretShad (terran\tmiShad.grp)
playfram 0x22 # frame set 2
attack1c 1 664 # Protoss\ZEALOT\pzeHit00.WAV
wait 1
playfram 0x11 # frame set 1
wait 1
playfram 0x00 # frame set 0
nobrkcodeend
randcondjmp 250 specialweapon
gotorepeatattk
ignorerest
ZealotGndAttkToIdle:
goto ZealotOther

ZealotWalking:
move 4
wait 1
playfram 0x55 # frame set 5
move 4
wait 1
playfram 0x66 # frame set 6
move 4
wait 1
playfram 0x77 # frame set 7
move 4
wait 1
playfram 0x88 # frame set 8
move 4
wait 1
playfram 0x99 # frame set 9
move 4
wait 1
playfram 0xaa # frame set 10
move 4
wait 1
playfram 0xbb # frame set 11
move 4
wait 1
playfram 0xcc # frame set 12
goto ZealotWalking

ZealotUnknown21:
imgol08 154 0 0 # Unknown154 (protoss\zealot.grp)
goto local00
specialweapon:
nobrkcodestart
useweapon 31
wait 1
nobrkcodeend
wait 1
goto ZealotGndAttkRpt

[MidnightGladius]

You don't put the special attack block in the header... also, I recommend taking out the two nobrkcodes in the special attack, as well as giving it a gotorepeatattk line.

[Confuzed_Person]

nope, that didnt seem to work

[Holocaust]

Change the gotorptattk to ZealotGndAttkRpt
Change the randcondjmp to __1e_condjmp
Lower the chance number

You need to copy this ZealotGndAttkToIdle
to it's air counterpart or ELSE IT WILL CRASH

If nothing works, go download IceCC from another source.
If that doesn't work eitherthen your IceCC is screwed, I reccommend a small test to see if it's in working order, a test like changing the speed or number of attacks.

[Confuzed_Person]

well hasnt worked yet. and i also talked to another modder that said something about the Waits needin to b syncronized. o and i know it works becuz i have been usin it for a while.
# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'data\scripts\iscript.bin'
# created on: Tue Apr 11 18:04:37 2006
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 151 Zealot (protoss\zealot.grp)
.headerstart
IsId 163
Type 21
Init ZealotInit
Death ZealotDeath
GndAttkInit ZealotGndAttkInit
AirAttkInit ZealotGndAttkInit
SpAbility1 [NONE]
GndAttkRpt ZealotGndAttkRpt
AirAttkRpt ZealotGndAttkRpt
SpAbility2 [NONE]
GndAttkToIdle ZealotGndAttkToIdle
AirAttkToIdle ZealotGndAttkToIdle
SpAbility3 [NONE]
Walking ZealotWalking
Other ZealotOther
BurrowInit [NONE]
ConstrctHarvst [NONE]
IsWorking [NONE]
Landing [NONE]
LiftOff [NONE]
Unknown18 [NONE]
Unknown19 [NONE]
Unknown20 [NONE]
Unknown21 ZealotUnknown21
specialweapon specialweapon
.headerend
# ----------------------------------------------------------------------------- #

ZealotInit:
imgul09 152 0 0 # ZealotShad (protoss\pzeShad.grp)
ZealotOther:
playfram 0x55 # frame set 5
goto local00

local00:
wait 125
goto local00

ZealotDeath:
playsnd 678 # Protoss\ZEALOT\PZeDth00.WAV
playframno 0
playfram 0xdd # frame set 13
wait 2
playfram 0xde # frame set 13
wait 2
playfram 0xdf # frame set 13
wait 2
playfram 0xe0 # frame set 13
wait 2
playfram 0xe1 # frame set 13
wait 2
playfram 0xe2 # frame set 13
wait 2
playfram 0xe3 # frame set 13
wait 2
end

ZealotGndAttkInit:
playfram 0x00 # frame set 0
wait 1
ZealotGndAttkRpt:
playsndrand 2 662 663 # Protoss\ZEALOT\pzeAtt00.WAV, Protoss\ZEALOT\pzeAtt01.WAV
playfram 0x11 # frame set 1
wait 1
nobrkcodestart
playfram 0x22 # frame set 2
wait 1
imgul09 298 0 0 # MissleTurretShad (terran\tmiShad.grp)
playfram 0x33 # frame set 3
wait 1
playfram 0x44 # frame set 4
attack1c 1 664 # Protoss\ZEALOT\pzeHit00.WAV
wait 1
playfram 0x33 # frame set 3
wait 1
imgul09 298 0 0 # MissleTurretShad (terran\tmiShad.grp)
playfram 0x22 # frame set 2
attack1c 1 664 # Protoss\ZEALOT\pzeHit00.WAV
wait 1
playfram 0x11 # frame set 1
wait 1
playfram 0x00 # frame set 0
__1e_condjmp 250 specialweapon
nobrkcodeend
gotorepeatattk
ignorerest
ZealotGndAttkToIdle:
goto ZealotOther

ZealotWalking:
move 4
wait 1
playfram 0x55 # frame set 5
move 4
wait 1
playfram 0x66 # frame set 6
move 4
wait 1
playfram 0x77 # frame set 7
move 4
wait 1
playfram 0x88 # frame set 8
move 4
wait 1
playfram 0x99 # frame set 9
move 4
wait 1
playfram 0xaa # frame set 10
move 4
wait 1
playfram 0xbb # frame set 11
move 4
wait 1
playfram 0xcc # frame set 12
goto ZealotWalking

ZealotUnknown21:
imgol08 154 0 0 # Unknown154 (protoss\zealot.grp)
goto local00

specialweapon:
useweapon 31
wait 1
goto ZealotGndAttkRpt

[Holocaust]

Unknown18 [NONE]
Unknown19 [NONE]
Unknown20 [NONE]
Unknown21 ZealotUnknown21
specialweapon specialweapon
.headerend
# -----------------------------------------------------------------------------

Remove the damn special weapon codeblock, it DOESN't need to be there -_-

Why don't you look at the scripts of some mods that have used the random attack?
From looking at the script this time and from the last time y'made a thread like this, it doesn't look like you've changed anything

[Echo_8]

Holocaust:
Stop harassing the poor guy. At least tell him why it doesn't need to be there. Not everyone learns the same way, and he might just need to have things explained to him explicitly.

------
Confuzed_Person:
When you said it didn't work, did you mean it doesn't compile, or doesn't work in game?
I'll assume it compiled since I can't be bothered to see for myself.

Ok, the header section defines the animation types that a particular sprite uses, and where to find the code for those animations. Now, each pair of tokens (that's what IceCC calls them) defines each particular animation. The first token is the animation's name, the second is the label pointing to the code of that animation.
For example:
GndAttkInit ZealotGndAttkInit This says "When the unit begins to attack a ground target, call the code pointed by ZealotGndAttkInit." Now, the random attacks, contary what you appear to believe, is not one of the animations used by SC. Instead, they are merely concepts which take advantage of __1e_condjmp and are part of the "normal" attack scripts. That is why Holocaust is getting frustrated with you. You have a basic understanding of this since you have the __1e_condjmp in there.
Also, don't separate the attack code and your random attack code by too much. It only reinforces the above misconception. Plus spaghetti code won't do you too much good.


ZealotGndAttkInit:
playfram 0x00 # frame set 0
wait 1
ZealotGndAttkRpt:
nobrkcodestart
__1e_condjmp 250 specialweapon
playsndrand 2 662 663 # Protoss\ZEALOT\pzeAtt00.WAV, Protoss\ZEALOT\pzeAtt01.WAV
playfram 0x11 # frame set 1
wait 1
playfram 0x22 # frame set 2
wait 1
imgul09 298 0 0 # MissleTurretShad (terran\tmiShad.grp)
playfram 0x33 # frame set 3
wait 1
playfram 0x44 # frame set 4
attack1c 1 664 # Protoss\ZEALOT\pzeHit00.WAV
wait 1
playfram 0x33 # frame set 3
wait 1
imgul09 298 0 0 # MissleTurretShad (terran\tmiShad.grp)
playfram 0x22 # frame set 2
attack1c 1 664 # Protoss\ZEALOT\pzeHit00.WAV
wait 1
playfram 0x11 # frame set 1
wait 1
playfram 0x00 # frame set 0
goto AfterSpecialWeapon

specialweapon:
useweapon 31
wait 1

AfterSpecialWeapon:
nobrkcodeend
gotorepeatattk
ignorerest
ZealotGndAttkToIdle:
goto ZealotOther
As you can see, the "special weapon" code is part of your attack code. Normal attacks just jump past it.

It will also help if you told us which IceCC version you are using - the one made by the original author, or the one with updated names. It will help a lot in ridding of any confusion.
For example, __1e_condjmp which is the random jump instruction in the original, is renamed to randcondjump in the updated version. Based on the other instructions you used, it looks like you're using the original.

[MidnightGladius]

Echo, that's not going to work - your special codeblock will simply stall the script, since there's no direction past it. What you need is:



specialweapon:
useweapon 31
wait 1
gotorepeatattk
goto ZealotGndAttkToIdle

[Confuzed_Person]

Yeeeeeeeeeesssssssssssss!!!!!!!!!!!!!!!!!!!!! It Worked

[Echo_8]

I don't see what's wrong with it. It will simply "fall through" and continue executing the next instruction (which is in the AfterSpecialWeapon block). Though, looking back at it, I did notice that there was a nobrkcodeend without a matching nobrkcodestart if went through the special weapon block. Unless of course you are telling me that execution model is completely different to how I see it, where SC executes it in a linear manner, moving the instruction pointer only when it has a new animation it has to play.

[MidnightGladius]

It's not linear at all, Echo, and it most definitely won't " fall through" and keep going to the next one.

Though, it does seem that this discussion is effectively over.

[Echo_8]

Though, it does seem that this discussion is effectively over.Ok, I realize that, but for the sake of argument, I'll keep going a little longer. I think it's better if other people have a chance to offer their input on this matter, so I decided against sending a pm.

------------------------

What is the difference between the transition between the animation "blocks"

ZealotInit:
imgul09 152 0 0 # ZealotShad (protoss\pzeShad.grp)
ZealotOther:
playfram 0x55 # frame set 5
goto local00
And the one here?

specialweapon:
useweapon 31
wait 1

AfterSpecialWeapon:
nobrkcodeend
gotorepeatattk
ignorerest
Sure, I stuck an extra line return, so what? It's not like they affect the script in any way. If it had anything to do with the ignorerest, I would have no idea why the ignorerest was put in, but since the guy used it in his code, I just left it in there.


Each script begins with a label, and then proceeds with lines of instructions. You will notice that in the middle of
this Init animation script, the AirAttkInit script also starts with the label ScourgeAirAttkInit. This demonstrates a
key feature of the iscript: different animations can share code. In fact, different animation sets can share code (you
can have the firebat and marine have the same GndAttkInit script for example). This is very useful if you don't want
to have to rewrite a lot of stuff for many different animation sets. However, it can also become hairy if you have too
many headers jumping around everywhere. This is the nature of coding. :)
This is the effect I exploit in my code, and the point we are at odds with. Granted, picking a paragraph where the author wrote AirAttkInit when AirAttkToIdle was used in its example, does seem to lessen the effect of its use as an argument, since it could be seen as defective.

It's not linear at all, Echo, and it most definitely won't " fall through" and keep going to the next one. Then how does it run? Why won't it fall through? What does it do instead? With the exception of a few special instructions namely the jumps, ignorerest, and end, it moves onto the next instruction which appears in iscript.bin. Iscript.bin isn't a collection of animation instruction sets. It's a single, gigantic, set of animation instructions, with headers at the end so SC knows which instructions to play for each sprite. If it weren't for the all the jumps put in there, a scourge sprite will simply run through every single instruction in there till it hit the end. Blizzard takes advantage of this fact. Why else would so many animations jump to the exact same place? If I recall correctly, there are 5 or so "global script loops." Use ICE or a full iscript.bin decompile without the -s option in IceCC, to verify this.

I may sound hostile, but I hate being told "Nope, you're wrong" without the evidence or explanation to back it up. I'll accept I'm wrong if, and only if, there are satisfactory arguments that say so. However at this point of time, your point of view just seem like empty words to me.

[MidnightGladius]

So be it.

You're kind of right, but your reasons are wrong.

The way the scripts run is through the unit's corresponding orders that are set in its internal AI (read: hardcoded). You can see this by running DE's Orders.dat tab and looking at the different orders with their associated label.

The reason why GndAttkInit -> GndAttkRpt -> GndAttkToIdle all run together is not because they're located one after another on the script, but rather because their internal AI has them running in that way. To test this, I randomly moved around the placement of all of the codeblocks (Death, GndAttkInit, Other, Init, GndAttkToIdle, GndAttkRpt, in that order) and ran the game using that code set. It works perfectly.

You're right - jumps, ignorerest, and end do have special properties; they override the normal internal AI that sets the units normal behavior. To further demonstrate this, try taking out all of these special lines in a Scourge iscript. When I did, it simply screwed up the Scourge, rather than, as you say, going through each of its animations in order (which doesn't even make sense, since their attack is a suicide that removes it from the game, so everything below that simply wouldn't occur).

Anyways. The reason why Init and Other work like that is, as I said, Orders.dat. The reason why "specialweapon" won't go to AfterSpecialWeapon is because its not designated to do that in the AI. Really, those two blocks are both "local" blocks - they're not designated in the header, and they will never be run unless you use a goto, a special code. Just try putting in a local codeblock with no goto leading to it, and (if you're using my old version of IceCC) it won't compile, or (using the new one) IceCC will ignore it, but you'll never actually see that code in game.

Do the above arguments/points set themselves as satisfactory? If not, I can provide some scripts, and you can try them out yourself.

[Echo_8]

Yep. I had assumed SC parsed it in the same way IceCC does. Since the manual and decompiled iscripts was all I had to go on, I came to the conclusion I did. Thanks for clearing it up.

Though I'm still confused by what are you telling me: How does SC know when to stop running an animation? And how would you know where SC will stop running a script? I still can't see why a point in the script which is targeted by a jump somewhere else would suddenly flag a stop.

*Sigh* This reminds me of the old book-smarts and street-smarts thing. Never underestimate experience.

[MidnightGladius]

No problem. That's partially what I'm here for, after all.

Though I'm still confused by what are you telling me: How does SC know when to stop running an animation? And how would you know where SC will stop running a script? I still can't see why a point in the script which is targeted by a jump somewhere else would suddenly flag a stop.

If you mean an animation as in a unit/building, it runs until it's dead. A weapon flingy runs until it hits its target. Non-unit non-weapon sprites all have limited lifespans - usually, they're just an Init and a Death, both with "end" lines. As for images - if its dependent and spawned by another animation (unit turrets, for instance), it dies when its host dies. If its independent, either it also is limited life-span, or its unlimited conditional. If you look at Maelstrom Overlay, you'll see that it has no end - it just loops over and over. The spell (more specifically, the orders.dat entry for that spell) tells it when to start playing, and when to stop. Thus, it's hardcoded, so you can't modify durations of inidividual spells.

On the other hand, if you mean and animation as in a codeblock, it runs from top to bottom, executing everything in that order. Code blocks as a whole, as we discussed earlier, do not function this way.

[Echo_8]

Well, since I'm not really getting it, what defines a code block, after the compilation process and if possible after loaded in memory, since all those local headers just complicates things?

Edit:
Should I have made a new thread for these questions, since the discussion has strayed so far away from the original point of this one?