SweepFire=1;

[smoth]

It ignores script locks(when the barrel is covered in grey it would normaly be locked via it's script), when the script lock does happen it fires off at an odd angle.

see video here: http://cs.selu.edu/~ssmith/spring/Movie_0003.wmv

If you guys could fix this it would be great, otherwise, I will need to remove it from my project. I would just work around it but I am not sure, I thought it was created so the unit would target other enemies and move to the next one when it's current was dead. What is the real usage?

[Peet]

I would just work around it but I am not sure, I thought it was created so the unit would target other enemies and move to the next one when it's current was dead. What is the real usage?

That's what it does for me...

[Zpock]

It could use a lot of improvements of course, like making the laser motion blur.. now it looks really choppy when it's turning the laser around.

[Noruas]

Melee Forced Fire lasers!

[smoth]

So, has anyone looked into this?

[Noruas]

Now imagine if all lasers dragged, and allies were getting hit by your own laser, which it does, you will understand something needs to be done.
http://spring.unknown-files.net/file/30 ... ng_Device/

Sure is a pretty though.

[Peet]

I believe it just causes problems when the firepoint of the weapon is moved by anything other than the aiming function, such as unit movement or other script functions.

[Noruas]

But then why is it aiming at the mountain?

[KDR_11k]

I think air units don't properly tell their weapons how to aim.

[SJ]

It depends on the Z dir of the aimpiece being directed in the guns direction, maybe thats not true for that unit ? I only ever tested it with an annihilator.

[Noruas]

I am not exactly sure what you are asking... find the last beta of xta v8.1 and throw it in the latest svn, type .give ostr and you get that unit with the laser tag already on it.

[KDR_11k]

SJ: So basically it's like emit-sfx'ing the laser?

[SJ]

Sort of I suppose, there is no well defined way for the c++ code to ask the script where the gun is pointing, so the piece rotation dir seemed the most logical thing to use. Emitsfx uses the vector between the two first vertices in the piece though iirc.

[KDR_11k]

Emitsfx uses the vector between the two first vertices in the piece though iirc.

Only for 3dos AFAIK and there may be some special handling for empties. s3os use the piece orientation.

[rattle]

Yeha made some changes to use object rotation now instead which is much more useful.

I'm pretty sure beamlasers need a start and end position (firepoint, target position) to get the direction from. I recommend to temporarily save the last target position and use it instead when there is no target. Or perhaps you can think of something without the need of a target position.

edit: Indeed.

BeamLaser.cpp

Code: Select all

wantedDir=targetPos-weaponPos;
wantedDir.Normalize();

Wouldn't it be possible to override wantedDir by using the piece rotation of the piece the weapon is being fired from? If you still need targetPos then perhaps weaponPos*weaponDef->range could work... or something like that. I know I suck at maths...