So I've been working on a small unit mod; got the Rocket Trooper .grp off of Static Maplantis, renamed it to firebat.grp, and .dat edited so that he could shoot missiles. Tested it, it seemed to work fine; exept that whenever he was ordered to attack, he'd spew out three missiles and a flamethrower overlay. So I cracked open IceCC for the first time (god help me), extracted the iscript file, and poked around the firebat scripts. I started with this: [quote]FirebatGndAttkInit: playfram 0x00 # frame set 0 FirebatGndAttkRpt: wait 1 nobrkcodestart imgol 421 0 0 # FlameThrower (thingy\flamer.grp) playfram 0x11 # frame set 1 attkshiftproj 24 wait 1 attkshiftproj 52 wait 1 attkshiftproj 80 wait 5 playfram 0x00 # frame set 0 wait 2 ignorerest FirebatGndAttkToIdle: goto FirebatWalkingToIdle[/quote] And modified it to this: [quote]FirebatGndAttkInit: playfram 0x00 # frame set 0 FirebatGndAttkRpt: wait 1 nobrkcodestart playfram 0x11 # frame set 1 attkshiftproj 24 wait 5 playfram 0x00 # frame set 0 wait 2 ignorerest FirebatGndAttkToIdle: goto FirebatWalkingToIdle[/quote] Then I re-compiled it, stuck in the .mpq with the rest of the files, and tested. The firebat worked as planned (no flame overlay, only shot 1 missile, exept that the .dat specified 20/missile and the weapon icon still showed 60 damage), exept that he froze right after shooting and wouldn't respond to any commands. I tried building another one and had him attack to verify the results, same thing happened. I then built a marine and gunned down the first firebat. The second one started moving as normal again, until he fired another missile and froze. Help plz.

So I've been working on a small unit mod; got the Rocket Trooper .grp off of Static Maplantis, renamed it to firebat.grp, and .dat edited so that he could shoot missiles.

Tested it, it seemed to work fine; exept that whenever he was ordered to attack, he'd spew out three missiles and a flamethrower overlay.

So I cracked open IceCC for the first time (god help me), extracted the iscript file, and poked around the firebat scripts.

I started with this:

Quote

FirebatGndAttkInit:
playfram 0x00 # frame set 0
FirebatGndAttkRpt:
wait 1
nobrkcodestart
imgol 421 0 0 # FlameThrower (thingy\flamer.grp)
playfram 0x11 # frame set 1
attkshiftproj 24
wait 1
attkshiftproj 52
wait 1
attkshiftproj 80
wait 5
playfram 0x00 # frame set 0
wait 2
ignorerest
FirebatGndAttkToIdle:
goto FirebatWalkingToIdle

And modified it to this:

Quote

FirebatGndAttkInit:
playfram 0x00 # frame set 0
FirebatGndAttkRpt:
wait 1
nobrkcodestart
playfram 0x11 # frame set 1
attkshiftproj 24
wait 5
playfram 0x00 # frame set 0
wait 2
ignorerest
FirebatGndAttkToIdle:
goto FirebatWalkingToIdle

Then I re-compiled it, stuck in the .mpq with the rest of the files, and tested. The firebat worked as planned (no flame overlay, only shot 1 missile, exept that the .dat specified 20/missile and the weapon icon still showed 60 damage), exept that he froze right after shooting and wouldn't respond to any commands.

I tried building another one and had him attack to verify the results, same thing happened. I then built a marine and gunned down the first firebat. The second one started moving as normal again, until he fired another missile and froze.

Help plz.

Removing the flame overlay got rid of the nobrkcodeend command needed to let the unit do commands. Just add that command in right before ignorerest and it should work.

Removing the flame overlay got rid of the nobrkcodeend command needed to let the unit do commands. Just add that command in right before ignorerest and it should work.

[quote=name:DiscipleOfAdun]Removing the flame overlay got rid of the nobrkcodeend command needed to let the unit do commands. Just add that command in right before ignorerest and it should work.[/quote] I thought that a lack of nobrkcodeend might have been the problem, but what confused me was that the lines that I deleted didn't seem to contain anything of the sort. I'll go punch that in and test it. EDIT: Got a new bug now: The firebat doesn't freeze anymore, but he doesn't loop the attack script = I have to manually order each missile launch.

Quote from DiscipleOfAdun

Removing the flame overlay got rid of the nobrkcodeend command needed to let the unit do commands. Just add that command in right before ignorerest and it should work.

I thought that a lack of nobrkcodeend might have been the problem, but what confused me was that the lines that I deleted didn't seem to contain anything of the sort.

I'll go punch that in and test it.

EDIT: Got a new bug now: The firebat doesn't freeze anymore, but he doesn't loop the attack script = I have to manually order each missile launch.

You'll need to add in the repeat attack loop instead of going to the attack to idle loop. since you don't want the attack to idle loop to be doing that, you'll have to add in a completely new goto command after ignorerest. try putting goto FirebatGndAttkRpt after it and see if that'll do it.

You'll need to add in the repeat attack loop instead of going to the attack to idle loop.

since you don't want the attack to idle loop to be doing that, you'll have to add in a completely new goto command after ignorerest.

try putting goto FirebatGndAttkRpt after it and see if that'll do it.

Nevermind, DOA beat me to it.

Nevermind, DOA beat me to it.

Adding the goto command seems to have had no effect (it was probably ignored by the ignorerest command).

Adding the goto command seems to have had no effect (it was probably ignored by the ignorerest command).

[quote=name:DiscipleOfAdun]since you don't want the attack to idle loop to be doing that, you'll have to add in a completely new goto command after ignorerest. try putting goto FirebatGndAttkRpt after it and see if that'll do it.[/quote] [quote=name:HailFire]Adding the goto command seems to have had no effect (it was probably ignored by the ignorerest command).[/quote] Surprisingly, DoA has it wrong, you have it right. You want it to stop executing commands after it attacks (to wait for its cooldown), however, you need to tell the game that the attack is finished, and it can call the repeat attack script when the cooldown is done. Add a [font=monospace]gotorepeatattk[/font] opcode right before the ignorerest, and it should work. This was probably also in the firebat's flame script.

Quote from DiscipleOfAdun

since you don't want the attack to idle loop to be doing that, you'll have to add in a completely new goto command after ignorerest.

try putting goto FirebatGndAttkRpt after it and see if that'll do it.

Quote from HailFire

Adding the goto command seems to have had no effect (it was probably ignored by the ignorerest command).

Surprisingly, DoA has it wrong, you have it right. You want it to stop executing commands after it attacks (to wait for its cooldown), however, you need to tell the game that the attack is finished, and it can call the repeat attack script when the cooldown is done. Add a gotorepeatattk opcode right before the ignorerest, and it should work. This was probably also in the firebat's flame script.

Thanks, Laser! I was actually on the verge of solving it myself, exept that I had the gotorepeatattk on the wrong side of the ignorerest. :bleh: The missile trooper works now, I just have to impliment the .tbl edit and get an updated version of the .grp that doesn't waddle. :rolleyes: However, the trooper does 30 damage, while claiming on it's weapon icon to do 60. I suspect this is a .dat issue, though. Also, does anyone know where I can get a Shock Trooper .grp that doesn't crash?

Thanks, Laser!

I was actually on the verge of solving it myself, exept that I had the gotorepeatattk on the wrong side of the ignorerest.

The missile trooper works now, I just have to impliment the .tbl edit and get an updated version of the .grp that doesn't waddle.

However, the trooper does 30 damage, while claiming on it's weapon icon to do 60. I suspect this is a .dat issue, though.

Also, does anyone know where I can get a Shock Trooper .grp that doesn't crash?

[quote=name:HailFire]However, the trooper does 30 damage, while claiming on it's weapon icon to do 60. I suspect this is a .dat issue, though.[/quote] There's a value in weapons.dat for changing the factor which changes the damage displayed. If your iscript only uses one weapon, you may want to change this to 1. [quote=name:HailFire]Also, does anyone know where I can get a Shock Trooper .grp that doesn't crash?[/quote] This might be because the iscript is calling framesets that don't exist. You should probably check if the iscript is calling any frames that don't exist. Unfortunately for you, IceDC decompiles into hexadecimal format, wheras most GRP editors use decimal. Besides finding a program that convert from one to the other, or learning hex, the only help I can give you with this is that 0x11 in hex is equal to 17 in decimal, which is the number of frames per frame set. As such, frame 0x00 = 0, 0x11 = 17, 0x22 = 34 ... 0xaa = 170, 0xbb = 187, etc...

Quote from HailFire

However, the trooper does 30 damage, while claiming on it's weapon icon to do 60. I suspect this is a .dat issue, though.

There's a value in weapons.dat for changing the factor which changes the damage displayed. If your iscript only uses one weapon, you may want to change this to 1.

Quote from HailFire

Also, does anyone know where I can get a Shock Trooper .grp that doesn't crash?

This might be because the iscript is calling framesets that don't exist. You should probably check if the iscript is calling any frames that don't exist. Unfortunately for you, IceDC decompiles into hexadecimal format, wheras most GRP editors use decimal. Besides finding a program that convert from one to the other, or learning hex, the only help I can give you with this is that 0x11 in hex is equal to 17 in decimal, which is the number of frames per frame set. As such, frame 0x00 = 0, 0x11 = 17, 0x22 = 34 ... 0xaa = 170, 0xbb = 187, etc...

Grr, those two commands drive me crazy, not only because I think at least some part of them both isn't fully understood, they do very weird things when put into the scripts. Of course I forgot about that fact... Also, if the .dat change doesn't work, it's hardcoded. There's a few units that have hardcoded multipliers for their displayed damage value. I know the Zealot is for sure, but I can't remember without looking in the code if the firebat is too.

Grr, those two commands drive me crazy, not only because I think at least some part of them both isn't fully understood, they do very weird things when put into the scripts. Of course I forgot about that fact...

Also, if the .dat change doesn't work, it's hardcoded. There's a few units that have hardcoded multipliers for their displayed damage value. I know the Zealot is for sure, but I can't remember without looking in the code if the firebat is too.

[quote=name:DiscipleOfAdun]Grr, those two commands drive me crazy, not only because I think at least some part of them both isn't fully understood, they do very weird things when put into the scripts. Of course I forgot about that fact...[/quote] Using [font=monospace]gotorepeatattk[/font] simply tells the engine that the repeat attack script can be called when the cooldown runs out. In the mean time, it continues to execute the iscript, allowing modders to put cool effects in there. The [font=monospace]goto [idle section][/font] is just somewhere for the script to wait while the cooldown runs out. It would also allow modders to add in cool effects to the cooldown (like overheating smoke!). Using ignorerest seems equivelant to using [font=monospace]wait ∞[/font]. What weird behaviours are you thinking of? They've always seemed to behave in that manner for me... I doubt it would be hardcoded, mainly because there's an actual value in DatEdit for it, which we know performs the exact same task. Also, to the OP, you used the [font=monospace]attackshiftproj[/font] opcode for your attack (like the Firebat does...), I'm thinking perhaps what you needed would be [font=monospace]attack[/font], for your missiles, although, not being sure what [font=monospace]attackshiftproj[/font] actually does with ranged weapons (I know it fires melee weapons at the specific distance in front of the unit...). Perhaps it tells the missile to appear in front of the unit?

Quote from DiscipleOfAdun

Grr, those two commands drive me crazy, not only because I think at least some part of them both isn't fully understood, they do very weird things when put into the scripts. Of course I forgot about that fact...

Using gotorepeatattk simply tells the engine that the repeat attack script can be called when the cooldown runs out. In the mean time, it continues to execute the iscript, allowing modders to put cool effects in there. The goto [idle section] is just somewhere for the script to wait while the cooldown runs out. It would also allow modders to add in cool effects to the cooldown (like overheating smoke!).

Using ignorerest seems equivelant to using wait ∞.

What weird behaviours are you thinking of? They've always seemed to behave in that manner for me...

I doubt it would be hardcoded, mainly because there's an actual value in DatEdit for it, which we know performs the exact same task.

Also, to the OP, you used the attackshiftproj opcode for your attack (like the Firebat does...), I'm thinking perhaps what you needed would be attack, for your missiles, although, not being sure what attackshiftproj actually does with ranged weapons (I know it fires melee weapons at the specific distance in front of the unit...). Perhaps it tells the missile to appear in front of the unit?

I replaced attackshiftproj with attackwith at the same time I replaced goto FirebatGndAttkRpt with gotorepeatattk. ^^

I replaced attackshiftproj with attackwith at the same time I replaced goto FirebatGndAttkRpt with gotorepeatattk.

[quote=name:Laser Dude] I doubt it would be hardcoded, mainly because there's an actual value in DatEdit for it, which we know performs the exact same task.?[/quote] You're doubting me?!? You should know better than that by now...especially with hardcoded items.

Quote from Laser Dude

I doubt it would be hardcoded, mainly because there's an actual value in DatEdit for it, which we know performs the exact same task.?

You're doubting me?!? You should know better than that by now...especially with hardcoded items.

New question, since I don't feel like spamming up the forum with a new thread for every question. I'm working on a modding project, and recently got a new .grp for the command center. Edited out the shadow in the iscript (due to laziness), edited the .grp itself a bit, edited out the lift/land commands via firegraft, etc. Thus, the questions are (since the new .grp is smaller than the old one): -How do I modify the building's selection circle? -How do I modify the building's footprint?

New question, since I don't feel like spamming up the forum with a new thread for every question.

I'm working on a modding project, and recently got a new .grp for the command center. Edited out the shadow in the iscript (due to laziness), edited the .grp itself a bit, edited out the lift/land commands via firegraft, etc.

Thus, the questions are (since the new .grp is smaller than the old one):

-How do I modify the building's selection circle?
-How do I modify the building's footprint?

The selection circle is set in sprites.dat. The 'footprint' is a combination of the staredit boxed size and the bounding box, both of which can be set by editing units.dat.

The selection circle is set in sprites.dat.

The 'footprint' is a combination of the staredit boxed size and the bounding box, both of which can be set by editing units.dat.

[quote=name:DiscipleOfAdun]You're doubting me?!? You should know better than that by now...especially with hardcoded items.[/quote] It sounded like you hadn't actually checked whether the value in weapons.dat caused it. Although, to be honest, I think you usually jump to the conclusion of .exe editing and hardcoded values far too fast. I would think that checking for hardcoded values would be the last thing you do when you try to find a problem. That's not to say that you aren't skilled at dealing with the .exe when you do, it's just that I think you often jump to the inappropriate conclusion.

Quote from DiscipleOfAdun

You're doubting me?!? You should know better than that by now...especially with hardcoded items.

It sounded like you hadn't actually checked whether the value in weapons.dat caused it. Although, to be honest, I think you usually jump to the conclusion of .exe editing and hardcoded values far too fast. I would think that checking for hardcoded values would be the last thing you do when you try to find a problem. That's not to say that you aren't skilled at dealing with the .exe when you do, it's just that I think you often jump to the inappropriate conclusion.

Got another problem, that's actually related to iscript this time. :lol: I'm trying to give the Command Center a weapon. I specified the weapon in DatEdit, FireGrafted in an attack button (That works!), and edited the iscript. The potential problem areas: iscripting: [quote]# ----------------------------------------------------------------------------- # # This header is used by images.dat entries: # 275 CommandCenter (terran\control.grp) .headerstart IsId 102 Type 20 Init CommandCenterInit Death CommandCenterDeath GndAttkInit CommandCenterGndAttkInit AirAttkInit CommandCenterGndAttkInit Unused1 [NONE] GndAttkRpt CommandCenterGndAttkInit AirAttkRpt CommandCenterGndAttkInit CastSpell [NONE] GndAttkToIdle CommandCenterWalking AirAttkToIdle CommandCenterWalking Unused2 [NONE] Walking CommandCenterWalking WalkingToIdle CommandCenterWalking SpecialState1 CommandCenterSpecialState1 SpecialState2 [NONE] AlmostBuilt CommandCenterAlmostBuilt Built CommandCenterBuilt Landing CommandCenterLanding LiftOff CommandCenterLiftOff IsWorking CommandCenterIsWorking WorkingToIdle CommandCenterBuilt WarpIn [NONE] .headerend # [/quote] And the attack script: [quote]CommandCenterGndAttkInit: wait 1 nobrkcodestart attack gotorepeatattk nobrkcodeend goto CommandCenterWalking [/quote] Where did I screw up? Or did I just bugger something in DatEdit?

Got another problem, that's actually related to iscript this time.

I'm trying to give the Command Center a weapon. I specified the weapon in DatEdit, FireGrafted in an attack button (That works!), and edited the iscript.

The potential problem areas:

iscripting:

Quote

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 275 CommandCenter (terran\control.grp)
.headerstart
IsId 102
Type 20
Init CommandCenterInit
Death CommandCenterDeath
GndAttkInit CommandCenterGndAttkInit
AirAttkInit CommandCenterGndAttkInit
Unused1 [NONE]
GndAttkRpt CommandCenterGndAttkInit
AirAttkRpt CommandCenterGndAttkInit
CastSpell [NONE]
GndAttkToIdle CommandCenterWalking
AirAttkToIdle CommandCenterWalking
Unused2 [NONE]
Walking CommandCenterWalking
WalkingToIdle CommandCenterWalking
SpecialState1 CommandCenterSpecialState1
SpecialState2 [NONE]
AlmostBuilt CommandCenterAlmostBuilt
Built CommandCenterBuilt
Landing CommandCenterLanding
LiftOff CommandCenterLiftOff
IsWorking CommandCenterIsWorking
WorkingToIdle CommandCenterBuilt
WarpIn [NONE]
.headerend
#

And the attack script:

Quote

CommandCenterGndAttkInit:
wait 1
nobrkcodestart
attack
gotorepeatattk
nobrkcodeend
goto CommandCenterWalking

Where did I screw up? Or did I just bugger something in DatEdit?

Replace this: [code]CommandCenterGndAttkInit: wait 1 nobrkcodestart attack gotorepeatattk nobrkcodeend goto CommandCenterWalking[/code] With this: [code]CommandCenterGndAttkInit: wait 1 nobrkcodestart attack nobrkcodeend wait 1 gotorepeatattk ignorerest[/code]

Replace this:

Code

With this:

Code

Last time I gave the CC an attack, back in UF, the AI really did not like it.

Last time I gave the CC an attack, back in UF, the AI really did not like it.

O, and remember to do the required dat edits. I've given buildings attacks before, but I've never really cared about the AI, so, idk.

O, and remember to do the required dat edits. I've given buildings attacks before, but I've never really cared about the AI, so, idk.