Ahem...


I did include it.

And #... is just my little comment that you can add whatever you want in between the two commands.

Waaaaiiiiit a second, I think I might know what the problem is.



If I'm not mistaken, this block tells it to check for AttackStyle0, with 51/255 chance of using AttackStyle0. If no, it checks for AttackStyle1 and so forth. If yes at any point along the way, it immediately jumps to that attack's header, firing its one attack and going to endofattacksequence, where it wraps up the attack animation and signals for gotorepeatattk.

Which is why it's only firing one missile.

Amirite?

Yes... My version only fires one missile. That's why I gave you the .js source code so you can edit it to your own liking.

However, there is a cool idea you can do:

Have each attack loop back to the main attack loop and have a random jump in the attack loop that goes to the cool down. That way it will fire a random amount of shots. However, the unit CAN fire infinitely (theoritically).

But if I can just stick additional attack commands in, doesn't it make the whole huge attack loop rather pointless?

Also, do the turn commands cause the missiles to veer off target? That was basically the whole point of this exercise: A short (but rapid) spray of missiles affecting an area around the selected target (in this case, anti-air only).

My brain hurts.

Yes, the turn causes the attack to veer off. It works with halo or go to max range behavior.

Goto my .js code and just plop in another attack 1 line... its quite simple.

If you want them to go in sequence, but randomly skip each one, you could do something like this partial example:



I don't really know if those are good numbers or not, I just reversed the ones above.

For some odd reason, I've never thought of doing that for attacks . Only for skipping certain animations. Nice idea.

Finally got back to working on this (no way in hell's it going to make M3): Decided I was fed up with problems I was having with dragoon .grp bugs encountered while working on the iscripting, thus undid the units.dat and iscript changes and turned my attention towards the goliath.

I then spent two minutes giving it a working spread attack.

I actually drew the technique from A_of-s_t's first post after my initial request: Before you people started burying me under mountains of (apparently unnecessary) iscript.

Apparently, half the problem was that I forgot to turn on "Attack 3x3 Area" in weapons.dat.

EDIT: Almost forgot, just one small obsticle before I can finish this unit: No matter how many missiles it spews, they only affect the selected target in the 3x3 area. Just create an iscript entry for the goliath missiles and copy/paste in the halo rocket properties?

Is the weapon using the halo behavior?

DatEdit -> weapons.dat -> (8) Hellfire Missile Pack (Normal) -> Graphical Properties -> Behaviour -> Attack Target 3x3 Area

If that's what you mean, then yes.

I haven't seen the new dat edit, but Im pretty sure there a weapon behavior that is "halo." Then change the flingy turn radius to a really small number.

The problem isn't that the missiles aren't spreading; they're doing that just fine. Similarly, all of the missiles that hit the target are doing damage.

The problem is that the missiles are only affecting the selected target, and don't damage other enemy air units within the 3x3 target grid, no matter how many missiles should be damaging them.

Retroedit: The DatEdit weapon behaviour list is as follows:

-Fly and Don't Follow Target
-Fly and Follow Target
-Appear on Target Unit
-Psionic Storm
-Appear on Target Site
-Appear on Attacker
-Attack & Self Destruct
-Bounce
-Attack Target 3x3 Area
-Go to Max. Range

EDITTED:

Effect: Splash Radial

It's working good now, thanks for the help.

NEW QUESTION: I'm trying to make two goliath type units, but they have different turret graphics/attacks. Since both default goliaths use the same iscript entry, I trekked forth to duplicate the goliath and turret onto unused units in order to make a pseudo-clone of the unit for my purposes. I copy/pasted the Goliath Base's iscript over the Ultralisk and the Goliath Turret's iscript over the Corsair, edited the headers where needed in order to avoid errors (including telling the ultralisk to summon a corsair.grp overlay during init), set the corsair to be a subunit, and the ultralisk to have the corsair as a subunit in units.dat, and poked firegraft into letting me build the abomination for testing.

The game crashes when I click the 'build' button. I'm pretty sure that it has something to do with me not applying a .lo file for the unit/subunit relation, but I have NO FUCKING IDEA how to use loedit because the bare-bones readme and super-efficient design give no clue as to how to actually use the fucking program.

Also, FireGraft won't let me delete entries while modifying .dat requirements, WHAT THE SHIT.

Deleting entries isn't needed for Dat Requirements. if you don't need the entry, uncheck the used checkbox. Although this does bring up a good possible feature, deleting all items at once. I'll consider it for the next version.

If you mean each individual requirement(which is an item to me), then just click open the button tab and then go back to the requirements tab and then you can magically delete them. A little unintentional bug I put in trying to make it idiot safe.

This. Thanks for the protip.

Try editing the Ultralisk in images.dat to use the same .lol file as the Goliath base...

Told you I didn't know what the fuck I was doing.

The ultra no longer crashes when I click the button: It now crashes on init. I'm pretty sure I can puzzle tis one out, though.

EDIT: Found one of the other reasons it was crashing (it's still crashing, though):



Durr hurr hurr.

EDIT 2: Winrar is me! Found the other reason it crashed: I forgot to edit corsair's init, wherein it was trying to call on (the non-existant) frameset 7.

However, even though it works now, the unit still behaves somewhat oddly: When newly constructed, the turret doesn't orient correctly with the base for a short while, and the unit will fire while moving (although I personally find this rather righteous, and may not attempt to remove this feature).

Post has been edited 4 time(s), last time on Jun 25 2008, 10:42 pm by HailFire.

Yeah, I made it fire while moving too with CU's bulldog. Pretty neat. You just need a nobrkcode in the attack for the turret. Thus, while the legs move, the turret will not stop shooting.