Report, edit, etc...Posted by EzDay281 on 2005-06-17 at 20:04:08
Alright, I'm trying to set my Tank to do an extra attack whenever it's close enough to an enemy using the "If Target within range of %1(pixels?) goto offset %2" script, but it's not working.
I set %2 to 1 higher then the Initial Ground attack's offset, and then put that into the "Jump to offset".
I paste the entire attack animation into it, and then add the part that I want, and it changes the initial attack too.
Or it can do any of several similar, but some more annoying, problems...
I set %2 to 1 higher then the Initial Ground attack's offset, and then put that into the "Jump to offset".
I paste the entire attack animation into it, and then add the part that I want, and it changes the initial attack too.
Or it can do any of several similar, but some more annoying, problems...
Report, edit, etc...Posted by scwizard on 2005-06-17 at 21:55:55
You use the trgtrangecondjmp command. Here is a detailed discription from the IceCC Manual, which I consider to be highly recomended reading for all modders.
So the code that you will want to put in should go something like this:
"trgtrangecondjmp 2 ghostairattackint"
You put that command at the begining of your ground attack line.
Then you have your header say:
Groundattackint = Ghostgroundattackint
Airattackint = Ghostgroundattackint
This way the "air attack" is used when you are within a certain range.
You can do something similer with local labels (ones that aren't attacked to the header) if you want to have the unit still have seperate ground and air attacks.
QUOTE(Manual)
trgtrangecondjmp <num> <label> − If target within range of <1> (pixels?) goto label <2>: This is used
in certain attack animations (such as the regular archon’s). Basically, when the animation gets to this point, if the
sprite’s target is within range of <1> pixels (maybe different unit of measurement), then goto offset <2>.
Otherwise if the target is not within range then ignore this instruction. This is useful if you want a unit (like the
archon) to have different attack animations for units that are at different distances away (at different distances, for
example, the archon’s energy attack has a different length tail). You can use a little logic and combine these as
well for attacks at many different distances (e.g., If target within 5 then goto X, else if unit is within 10 goto Y,
else if unit is within 15 goto Z, else... etc.).
in certain attack animations (such as the regular archon’s). Basically, when the animation gets to this point, if the
sprite’s target is within range of <1> pixels (maybe different unit of measurement), then goto offset <2>.
Otherwise if the target is not within range then ignore this instruction. This is useful if you want a unit (like the
archon) to have different attack animations for units that are at different distances away (at different distances, for
example, the archon’s energy attack has a different length tail). You can use a little logic and combine these as
well for attacks at many different distances (e.g., If target within 5 then goto X, else if unit is within 10 goto Y,
else if unit is within 15 goto Z, else... etc.).
So the code that you will want to put in should go something like this:
"trgtrangecondjmp 2 ghostairattackint"
You put that command at the begining of your ground attack line.
Then you have your header say:
Groundattackint = Ghostgroundattackint
Airattackint = Ghostgroundattackint
This way the "air attack" is used when you are within a certain range.
You can do something similer with local labels (ones that aren't attacked to the header) if you want to have the unit still have seperate ground and air attacks.
Report, edit, etc...Posted by EzDay281 on 2005-06-17 at 22:33:49
Um, ya, problem is whenever I try to use IceCC, it gives me an error if I try to open my NovaCraft scripts, and there's no way in hell I'm starting over.
I need to know how to do it with ICE or get my IceCC problem solved.
I need to know how to do it with ICE or get my IceCC problem solved.
Report, edit, etc...Posted by BSTRhino on 2005-06-17 at 22:41:10
Yeah, there's nothing wrong with using ICE, but if you want to start using offsets, like you do now, it can begin to get complicated. Depending on how offset-intensive you get, it can get downright ugly, but for a simple case like this, it's manageable to use ICE, although personally I would prefer IceCC because it handles all the offsets for you.
So, two things:
1. The range there is stated in pixels, and that's 16 times the size of Arsenal III weapon range units. So, for example the marine has a max range of 8 in Arsenal III, and that would be the same as 8 * 16 = 128 pixels. So, make sure you multiply by 16 if you're thinking in Arsenal III, or else you range will be substantially smaller than you think it is, and it might even be so small that it's smaller than the unit's size and could never be reached.
2. Offsets. Notice whenever you click on an item in the list of instructions in ICE, down below it says "Op Offset"? Pretty much the idea with jumping to offsets in ICE is to go to the instruction you want the code to jump to, click on it, memorise the op offset it has, and then use that number as the offset you're going to jump to in your "(if blah) goto offset" instruction. That tells the code to jump straight to that instruction.
3. I wasn't going to include this in my post, but it might also be relevant. Whenever you try to insert instructions into a script in ICE, if the script is not at the end of scripts\iscript.bin then ICE will copy everything and create a new script at the end. That is because it is impossible to insert new instructions into the middle of scripts\iscript.bin without moving everything after the inserted instruction down and then updating all the offsets so they point to everything correctly. However, you can add instructions at the end of scripts\iscript.bin without having to move anything down. That's so much easier, and so that's what ICE does.
Take notice of the way ICE copies your entire script and adds it at the end of scripts\iscript.bin and when it does it, because that means that your new script is now at a new offset. So if there's anything pointing to the old location of the script, you need to update all the offsets that point to the old location to point to your new script location yourself, ICE can't do this for you. So if you start pasting code into a script, watch out, the offset of that script will just have changed, there's an old copy of your script lurking somewhere, and other scripts might be pointing to that and not using your new one. Also, if I remember right, this is also the only way to create a new code block in ICE, so this trick is not only annoying, but it's useful.
That's the general background of range-based jumping in ICE. To be more specific to your problem of how you want your tank to attack multiple times at short range, I really don't recommend doing it in ICE, you could get it done ten times faster in IceCC, even if you've never used IceCC before. There are several ways to do it, but all of them would involve jumping and what I call "losing offsets" which means you need to memorise an offset in notepad because ICE won't have the features to keep track of extra code blocks you need to create for this. You can try if you want to see how hard it is, but it's unlikely you'll be able to do it on your own unless you really understand how scripts\iscript.bin gets rearranged when you use the different functions in ICE.
Heh, I tried to start off explaining how to do it in ICE, that was my original idea when I started this post, but it looks like it would be too much to explain. It's so much easier to do it in IceCC. It is a lot of fun (well it was for me) to work out how to do it with ICE, I remember I used to do it for my first few versions of Terran Doom, but if you're looking for the easiest way, and not the most challenging way, then go with IceCC.
Edit: I just read your other thread. I didn't realise you didn't have a choice. Here's the basic idea:
You want code that looks like this instead of your standard "Attack with 1" instruction:
Those parts in <angle brackets> should be replaced with the offsets of the commands which start with those labels, like I wrote up there in part 2.
Now, it's best to do this in a certain order to make things easier on yourself.
1. copy and paste the second "Attack with 1" command, because that will copy entire script to a new offset, and it's good to get that out of the way first because you won't need to mess around with offsets getting screwed after that like I said in point 3 up there.
2. Add the "If target within 64 pixels go to offset <shortrangeattack>" next. Don't worry about adding the offset now because it is going to change once you add in the next command.
3. Click on the first "Attack with 1" instruction and memorise its op offset.
4. Add in your Goto offset command. All the commands below will disappear ("losing offsets") but you memorised the op offset in part 3 so you could still get back to them.
5. Type in that offset you memorised in the "Goto Offset" box and click "Goto" to jump to it. You'll see that the first two lines say "Unidentified offset..." This is because you're reading part of the Goto offset command which you just inserted to take the memory at the offset you just memorised.
6. Click on the first Attack with 1 instruction you see now, and memorise its new offset. This will become your <shortrangeattack> offset.
7. Click on the second Attack with 1 instruction and memorise its offset. This will become your <normalattack> offset.
8. Now, go back to your initial ground animation (you're still leaving it as a ground attacking script, right?) and scroll down until you see your "If target within..." and "Goto offset" commands and fill in the offsets with the ones you memorised in steps 6 and 7.
You're done. I hope you understood what happened there, you were constructing the script described in the code up there. But because of jumping, offsets, and everything getting hidden after the "Goto offset" command, these four lines have become disconnected when they're displayed in ICE. However, if you could hex edit the iscript, you would see that all of the four commands are lined up one after the other. If you could decompile your iscript with IceCC, you would also see the four commands are lined up one after the other. It's just ICE that has split them and made things kind of difficult for you.
So, two things:
1. The range there is stated in pixels, and that's 16 times the size of Arsenal III weapon range units. So, for example the marine has a max range of 8 in Arsenal III, and that would be the same as 8 * 16 = 128 pixels. So, make sure you multiply by 16 if you're thinking in Arsenal III, or else you range will be substantially smaller than you think it is, and it might even be so small that it's smaller than the unit's size and could never be reached.
2. Offsets. Notice whenever you click on an item in the list of instructions in ICE, down below it says "Op Offset"? Pretty much the idea with jumping to offsets in ICE is to go to the instruction you want the code to jump to, click on it, memorise the op offset it has, and then use that number as the offset you're going to jump to in your "(if blah) goto offset" instruction. That tells the code to jump straight to that instruction.
3. I wasn't going to include this in my post, but it might also be relevant. Whenever you try to insert instructions into a script in ICE, if the script is not at the end of scripts\iscript.bin then ICE will copy everything and create a new script at the end. That is because it is impossible to insert new instructions into the middle of scripts\iscript.bin without moving everything after the inserted instruction down and then updating all the offsets so they point to everything correctly. However, you can add instructions at the end of scripts\iscript.bin without having to move anything down. That's so much easier, and so that's what ICE does.
Take notice of the way ICE copies your entire script and adds it at the end of scripts\iscript.bin and when it does it, because that means that your new script is now at a new offset. So if there's anything pointing to the old location of the script, you need to update all the offsets that point to the old location to point to your new script location yourself, ICE can't do this for you. So if you start pasting code into a script, watch out, the offset of that script will just have changed, there's an old copy of your script lurking somewhere, and other scripts might be pointing to that and not using your new one. Also, if I remember right, this is also the only way to create a new code block in ICE, so this trick is not only annoying, but it's useful.
That's the general background of range-based jumping in ICE. To be more specific to your problem of how you want your tank to attack multiple times at short range, I really don't recommend doing it in ICE, you could get it done ten times faster in IceCC, even if you've never used IceCC before. There are several ways to do it, but all of them would involve jumping and what I call "losing offsets" which means you need to memorise an offset in notepad because ICE won't have the features to keep track of extra code blocks you need to create for this. You can try if you want to see how hard it is, but it's unlikely you'll be able to do it on your own unless you really understand how scripts\iscript.bin gets rearranged when you use the different functions in ICE.
Heh, I tried to start off explaining how to do it in ICE, that was my original idea when I started this post, but it looks like it would be too much to explain. It's so much easier to do it in IceCC. It is a lot of fun (well it was for me) to work out how to do it with ICE, I remember I used to do it for my first few versions of Terran Doom, but if you're looking for the easiest way, and not the most challenging way, then go with IceCC.
Edit: I just read your other thread. I didn't realise you didn't have a choice. Here's the basic idea:
You want code that looks like this instead of your standard "Attack with 1" instruction:
CODE
(other script stuff up here)
If target within 64 pixels go to offset <shortrangeattack>
Goto offset <normalattack>
<shortrangeattack>: Attack with 1
<normalattack>: Attack with 1
(rest of the script)
If target within 64 pixels go to offset <shortrangeattack>
Goto offset <normalattack>
<shortrangeattack>: Attack with 1
<normalattack>: Attack with 1
(rest of the script)
Those parts in <angle brackets> should be replaced with the offsets of the commands which start with those labels, like I wrote up there in part 2.
Now, it's best to do this in a certain order to make things easier on yourself.
1. copy and paste the second "Attack with 1" command, because that will copy entire script to a new offset, and it's good to get that out of the way first because you won't need to mess around with offsets getting screwed after that like I said in point 3 up there.
2. Add the "If target within 64 pixels go to offset <shortrangeattack>" next. Don't worry about adding the offset now because it is going to change once you add in the next command.
3. Click on the first "Attack with 1" instruction and memorise its op offset.
4. Add in your Goto offset command. All the commands below will disappear ("losing offsets") but you memorised the op offset in part 3 so you could still get back to them.
5. Type in that offset you memorised in the "Goto Offset" box and click "Goto" to jump to it. You'll see that the first two lines say "Unidentified offset..." This is because you're reading part of the Goto offset command which you just inserted to take the memory at the offset you just memorised.
6. Click on the first Attack with 1 instruction you see now, and memorise its new offset. This will become your <shortrangeattack> offset.
7. Click on the second Attack with 1 instruction and memorise its offset. This will become your <normalattack> offset.
8. Now, go back to your initial ground animation (you're still leaving it as a ground attacking script, right?) and scroll down until you see your "If target within..." and "Goto offset" commands and fill in the offsets with the ones you memorised in steps 6 and 7.
You're done. I hope you understood what happened there, you were constructing the script described in the code up there. But because of jumping, offsets, and everything getting hidden after the "Goto offset" command, these four lines have become disconnected when they're displayed in ICE. However, if you could hex edit the iscript, you would see that all of the four commands are lined up one after the other. If you could decompile your iscript with IceCC, you would also see the four commands are lined up one after the other. It's just ICE that has split them and made things kind of difficult for you.
Report, edit, etc...Posted by EzDay281 on 2005-06-18 at 16:48:39
Well, I haven't tried using your instructions yet, or reading the first half of your post, and knowing my luck I'll probably encounter some problem, but thanks much for your time anyways! 
ADDITION:
Alright, I followed the steps and got what I think is the right scripting, but when I attack it crashes, and I can't figure out why...
ADDITION:
Alright, I followed the steps and got what I think is the right scripting, but when I attack it crashes, and I can't figure out why...
Report, edit, etc...Posted by BSTRhino on 2005-06-18 at 19:44:55
EzDay, wow, you've almost done it! I didn't expect that you'd have it done so quickly, that offsetting work really is quite hard to get your head around at first, so I thought it'd at least take you a few days.
You're so close, the thing that is causing StarCraft to crash is just one little instruction, everything else is fine. If you look at the code that the iscript jumps to at 39786 in your iscript, you'll see right at the bottom it says "Go to offset 0"? At offset zero there aren't any commands StarCraft can read. I think you want to go to the "return to idle from ground attack" animation offset there. Look under the entry header tab for that. On this tab there is an offset for every animation that iscript entry has, including "return to idle from ground attack." Take a note of what's on that tab, it might be useful in future expeditions into ICE.
You're so close, the thing that is causing StarCraft to crash is just one little instruction, everything else is fine. If you look at the code that the iscript jumps to at 39786 in your iscript, you'll see right at the bottom it says "Go to offset 0"? At offset zero there aren't any commands StarCraft can read. I think you want to go to the "return to idle from ground attack" animation offset there. Look under the entry header tab for that. On this tab there is an offset for every animation that iscript entry has, including "return to idle from ground attack." Take a note of what's on that tab, it might be useful in future expeditions into ICE.
Report, edit, etc...Posted by EzDay281 on 2005-06-18 at 20:24:56
I use the Entry Header tag a lot for quickly changing units' repeated attacks to use the same offset as their Initial attacks.
I'm still kind of confused by offsets(I look ones one or two higher then whatever I'm modifying, and they're similar but slightly different and yet nothing I know of uses them), but I'm learning.
Oh, that. Crap, I had the feeling I was overlooking something obvious- I have a really annoying tendency to do that, and I'm used to the goto offset already being set to whatever it's supposed to.
One off-topic question, do you know why the Return to Idle has wait 125 ticks?
And Return to Idle from walking?
I use the Entry Header tab all the time to match-up my Initial and Repeated Ground/Air attacks, or in rare cases to give an air-only or ground-only attacking unit a ground or air attack, respectively.
QUOTE
that offsetting work really is quite hard to get your head around at first, so I thought it'd at least take you a few days.
I'm still kind of confused by offsets(I look ones one or two higher then whatever I'm modifying, and they're similar but slightly different and yet nothing I know of uses them), but I'm learning.
QUOTE
If you look at the code that the iscript jumps to at 39786 in your iscript, you'll see right at the bottom it says "Go to offset 0"?
Oh, that. Crap, I had the feeling I was overlooking something obvious- I have a really annoying tendency to do that, and I'm used to the goto offset already being set to whatever it's supposed to.
One off-topic question, do you know why the Return to Idle has wait 125 ticks?
And Return to Idle from walking?
QUOTE
Look under the entry header tab for that.
I use the Entry Header tab all the time to match-up my Initial and Repeated Ground/Air attacks, or in rare cases to give an air-only or ground-only attacking unit a ground or air attack, respectively.
Report, edit, etc...Posted by Shadow on 2005-06-18 at 22:00:11
I have a question about something related to this action.
If I were to do the target range to have a ghost do a melee attack. How would I make it look as if it were fighting something. If I made it look like it was fighting, what action deals the damage. I.E. domissledmg. What I am asking is what action makes the melee attack give out damage. I know what makes it turn, I just need to find out what does that damage.
If I were to do the target range to have a ghost do a melee attack. How would I make it look as if it were fighting something. If I made it look like it was fighting, what action deals the damage. I.E. domissledmg. What I am asking is what action makes the melee attack give out damage. I know what makes it turn, I just need to find out what does that damage.
Report, edit, etc...Posted by EzDay281 on 2005-06-18 at 23:04:02
I've wondered this myself, and I think that it's atleast related to the Randomly Play Sound A or B(Ice will glitch if there aren't 2 sounds) script.
Report, edit, etc...Posted by Voyager7456(MM) on 2005-06-19 at 09:06:12
Shouldn't you be able to use the attack25/attack26 command? Or you could try useweapon. I'm not sure whether you mean a regular melee attack, or a special attack like the Zealot in Doom Dragoon.
In order to make it look like it's fighting something, you'll have to use RetroGRP to add new frames, and then make it play those frames during the attack animation.
In order to make it look like it's fighting something, you'll have to use RetroGRP to add new frames, and then make it play those frames during the attack animation.
Report, edit, etc...Posted by EzDay281 on 2005-06-19 at 14:16:06
Look at a melee unit's attack animation in ICE.
You'll notice there's no Attack with 1, Attack with appropriate weapon, or Use # ID scripts anywhere, just the waits, the frames, and the sounds.
You'll notice there's no Attack with 1, Attack with appropriate weapon, or Use # ID scripts anywhere, just the waits, the frames, and the sounds.
Report, edit, etc...Posted by Voyager7456(MM) on 2005-06-19 at 17:54:46
QUOTE(EzDay2 @ Jun 19 2005, 12:16 PM)
Look at a melee unit's attack animation in ICE.
You'll notice there's no Attack with 1, Attack with appropriate weapon, or Use # ID scripts anywhere, just the waits, the frames, and the sounds.
[right][snapback]238683[/snapback][/right]
You'll notice there's no Attack with 1, Attack with appropriate weapon, or Use # ID scripts anywhere, just the waits, the frames, and the sounds.
[right][snapback]238683[/snapback][/right]
When I look at the Zealot's attack animation in IceCC, it has a command "attack1c" (this could be why there is some confusion). Attack1c not only randomly plays a sound, but it attacks in a similar method to the attack25 command. [Thank you IceCC manual] So it does have an attack command.
Report, edit, etc...Posted by EzDay281 on 2005-06-19 at 18:40:19
Ya, but ICE and IceCC are different.
Report, edit, etc...Posted by Voyager7456(MM) on 2005-06-19 at 18:44:37
Well if IceCC has that command in the Zealots script, ICE should have somethihng similar. Or you could just use IceCC.
Report, edit, etc...Posted by BSTRhino on 2005-06-20 at 05:33:53
Yes, the random sound one in ICE is the same as attack1c in IceCC, they're just interpreted differently. It's a melee attack command, meaning it doesn't create a weapon sprite. I remember we were talking about this in the other thread.
When you're editing things in modding, just imagine what you're actually doing is hex editing, but you're using a tool to speed up your hex editing, so it's not so slow and tedious. When you think of it like that, you can learn two things.
1. ICE and IceCC are reading the same data, except ICE said it is a random sound and IceCC says it's an attack with a random sound. But it's the same command, not two different ones. If in doubt, IceCC is more recent and probably right.
2. In the day when people really did hex edit the iscript, all they saw was 0s and 1s (well... 0-9s and A-Fs, but 0s and 1s sounds better), and played around with them to see what they might mean. They gave names to all the ones that they had a reasonable idea about, and left all the other ones unknown. But these are just what the creators of the program have guessed, there's nothing to say that the command names are wrong. Take attkprojangle in IceCC and the vertical shift in ICE for example, both were (kind of) wrongly interpreted by the program creator, but how were they supposed to know that when all they saw was 0s and 1s?
Oh sorry, I didn't realise that, I'll remember that next time I suddenly get the urge to describe what the entry header tab does.
Well if you think about the Zealot, when it's idle, it just stands there. Zealots don't have idle animations like bored Terran units do. Since there's nothing for the Zealot to do when it's idle it just waits and waits and waits until something happens. I guess 125 seemed like a nice number of ticks to wait for to Blizzard.
When you're editing things in modding, just imagine what you're actually doing is hex editing, but you're using a tool to speed up your hex editing, so it's not so slow and tedious. When you think of it like that, you can learn two things.
1. ICE and IceCC are reading the same data, except ICE said it is a random sound and IceCC says it's an attack with a random sound. But it's the same command, not two different ones. If in doubt, IceCC is more recent and probably right.
2. In the day when people really did hex edit the iscript, all they saw was 0s and 1s (well... 0-9s and A-Fs, but 0s and 1s sounds better), and played around with them to see what they might mean. They gave names to all the ones that they had a reasonable idea about, and left all the other ones unknown. But these are just what the creators of the program have guessed, there's nothing to say that the command names are wrong. Take attkprojangle in IceCC and the vertical shift in ICE for example, both were (kind of) wrongly interpreted by the program creator, but how were they supposed to know that when all they saw was 0s and 1s?
QUOTE
I use the Entry Header tab all the time to match-up my Initial and Repeated Ground/Air attacks, or in rare cases to give an air-only or ground-only attacking unit a ground or air attack, respectively.
Oh sorry, I didn't realise that, I'll remember that next time I suddenly get the urge to describe what the entry header tab does.
QUOTE
One off-topic question, do you know why the Return to Idle has wait 125 ticks?
Well if you think about the Zealot, when it's idle, it just stands there. Zealots don't have idle animations like bored Terran units do. Since there's nothing for the Zealot to do when it's idle it just waits and waits and waits until something happens. I guess 125 seemed like a nice number of ticks to wait for to Blizzard.