Position of the point shots are created
Moderator: Moderators
Position of the point shots are created
It seems that TA use the position of the vertex 0 of the piece given by QueryX, while Spring use the position of the center of the piece given by QueryX. Someone confirm?
Interesting question. I've always used null points for the firepoint, because I didn't like the way OTA handled it otherwise- hiding/showing the flare is a seperate step.
While I'm randomly muttering... does anybody know how Spring hides flares? Does it just look for anything with "flare" in the name, or does it look for stuff that is hidden/shown during a fire animation?
Why do I wanna know? Because I need to show something during a fire animation, duh...
While I'm randomly muttering... does anybody know how Spring hides flares? Does it just look for anything with "flare" in the name, or does it look for stuff that is hidden/shown during a fire animation?
Why do I wanna know? Because I need to show something during a fire animation, duh...
Code: Select all
Create()
{
hide rfire;
hide lfire;
Code: Select all
FirePrimary()
{
if (gun == 0)
{
show rfire;
sleep 100;
hide rfire;
you can place animations in the fireprimary.. and im almost (never done) you can use the wait-to-turn /move commads there..
that way you can "unhide" things in that part of the scprit, and animate them.
a question related to the scripts:
how you call the equivalent to "Fireprimary" but lets say for weapon 4?
its fireweapon4?
About what zwzsg is asking, just by looking how the game works i would say he is rigth, but cant tell for sure.
btw, didnt know vertex0 became the firepoint when a part was taken as the fire origin...
nonono... what I am wondering is how flares are being replaced with the fire/explosion animation, which looks kewl but is a very poor fit for certain things.
For example, I am going to make a flamethrower that is semi random and "persistant" for a moment, through scripting tricks, that will look cooler than the OpenGL colored alphamap technique being used now.
Short of having some sort of way to ... hmm... new topic... <goes off to write new topic>
For example, I am going to make a flamethrower that is semi random and "persistant" for a moment, through scripting tricks, that will look cooler than the OpenGL colored alphamap technique being used now.
Short of having some sort of way to ... hmm... new topic... <goes off to write new topic>
yah, ive always wondered how, and what is possible, in the weapong making side of spring.
For instance, the very cool effect that happens around forcefields (plasma repulser) weapon.
Is that just inherithed from TA? or is new and how to take adv of it..?
But back on topic... no i dont know what zwzsg was questioning.. :D
For instance, the very cool effect that happens around forcefields (plasma repulser) weapon.
Is that just inherithed from TA? or is new and how to take adv of it..?
But back on topic... no i dont know what zwzsg was questioning.. :D
-
- Posts: 854
- Joined: 28 Jan 2005, 18:15
Argh: What I heard is it just looks for a hide piece; wait X; show piece; to determine where to do its flare stuff. Not sure it looks anywhere but in the fireweaponX() function though.
Yes. And it is also strongly suggested by the SY to change Fire/Query/Aim/Aimfrom-Primary/Secondary/Tertiary to Weapon1/2/3 (respectively) as well if your going over 3 weapons. Its a "just don't test it" thing. Also, as it is becoming more and more that Spring units are less compatible with OTA (good thing, it means more power to the modder), at least some of the scripters (such as me) has taken to doing those replacements whenever we change a script.mongus wrote: a question related to the scripts:
how you call the equivalent to "Fireprimary" but lets say for weapon 4?
its fireweapon4?
put in more words, its
FirePrimary=>FireWeapon1
QueryPrimary=>QueryWeapon1
AimPrimary=>AimWeapon1
AimfromPrimary=>AimfromWeapon1
and so son for weapon2 +
Just as a random note, it seems the flares controll, in some way, the ammount of smoke the shot generates.
(this was told to me by a moder, no first hand exp).
Also, argh was thinking more of what does spring "internally", to transform the flares (flare named parts in the object?) into smoke clouds,the timing of the clouds...
(well that is my guess).
See his post about that here.
FirePrimary=>FireWeapon1
QueryPrimary=>QueryWeapon1
AimPrimary=>AimWeapon1
AimfromPrimary=>AimfromWeapon1
and so son for weapon2 +
Im gessing that means, "just do it" :)Its a "just don't test it" thing
Just as a random note, it seems the flares controll, in some way, the ammount of smoke the shot generates.
(this was told to me by a moder, no first hand exp).
Also, argh was thinking more of what does spring "internally", to transform the flares (flare named parts in the object?) into smoke clouds,the timing of the clouds...
(well that is my guess).
See his post about that here.
The flare code checks if show-piece is called from a Fire* function. If so, it doesn't show the piece but instead creates our own muzzleflare effect.
This works fine for ota/xta stuff, so I guess it will probably stay that way. So right now if you want to avoid it, you could do something like this:
Also, you can mix FirePrimary and FireWeapon4 etc.. But if both FireSecondary and FireWeapon2 are present for example, FireWeapon2 will be used.
This works fine for ota/xta stuff, so I guess it will probably stay that way. So right now if you want to avoid it, you could do something like this:
Code: Select all
ShowPrimaryPiece()
{
show myotherpiece;
}
FirePrimary()
{
show flare;
call-script ShowPrimaryPiece();
sleep 150;
hide flare;
}
I wasn't joking. I really thought there was a DISAPPEAR case.
Soo... how's about this:
That might do it... or close enough...

Soo... how's about this:
Code: Select all
explode BulletCasing type FALL;
sleep 250;
hide BulletCasing;
Get a clue!
What I was saying if that, unlike TA, there is an explosion even when no explosion GFX is specified.
In case you don't know, when you "explode" a piece, you lose all script control over the bit that is sent flying, and the piece that is "exploded" is hidden as well (save a few special cases in TA where it gets hidden as soon as the model refresh).
So that "hide BulletCasing;"
- Does not hide the explosion.
- Does not hide the BulletCasing sent flying.
- Does not hide the BulletCasing piece on the unit model because that one is already hidden.
What I was saying if that, unlike TA, there is an explosion even when no explosion GFX is specified.
In case you don't know, when you "explode" a piece, you lose all script control over the bit that is sent flying, and the piece that is "exploded" is hidden as well (save a few special cases in TA where it gets hidden as soon as the model refresh).
So that "hide BulletCasing;"
- Does not hide the explosion.
- Does not hide the BulletCasing sent flying.
- Does not hide the BulletCasing piece on the unit model because that one is already hidden.