Jump to content
Sign in to follow this  
Macser

Help needed with "tracer" object.

Recommended Posts

Ok.Straight to the point.

This relates to a sci-fi type addon.Specifically the snowspeeder from the Star Wars series.

I'm trying to find a decent method of emulating the twin energy bolts the craft fires.

Tagging a 3d object or dropped particles and making them follow a round is fine.I can do

that.And even have the object move in the correct direction.

The main issue stems from the fact the twin energy bolts are fired from fixed weapons.

So the attached object must match the roll/pitch/bank of the craft,as well as following

the round.

As I've mentioned before in other posts,I'm not a great scripter.And functions I know very

little about.So I need some help setting this up.Here's some pics of the issues as reference:

chdvpWsr.jpg

CxNWy7po.jpg

1WXhe7SX.jpg

i9mLKK8z.jpg

My simple script,so far:

_Veh= _this select 0

_Bullet= nearestobject [_Veh,"MCSR_RblHbChrg"]

_NrgBolt = "MCSR_HbChrg" createvehicle [0,0,0]

#loop

_pos1 =(getpos _Bullet) select 0
_pos2 =(getpos _Bullet) select 1
_pos3 =(getpos _Bullet) select 2

_Vel= velocity _Bullet
_dir = direction  _Bullet

_NrgBolt SetDir _dir
_NrgBolt SetPos [_pos1,_pos2,_pos3]

~0.001

?(alive _Bullet) : goto "loop"

deletevehicle _NrgBolt

exit

Edited by Maczer

Share this post


Link to post
Share on other sites

It might not be possible due to engine limitations. The scripting commands to set/return a vehicle's axes were only introduced in Arma. It could probably be solved with the help of Fwatch, but you'll have to ask Faguss about that.

An alternative method would be to make the tracers part of the vehicle's model. It might even be possible to animate them with clever use of setObjectTexture command so it doesn't look too fake.

Share this post


Link to post
Share on other sites

Hey Rellikki.

I do know Bn880's tracer rounds have their orientation changed when they're fired.

Although it doesn't account for roll.Only the angle of dive/climb(Pitch?).

Making them part of the vehicle might be a work-around for a "beam" type effect.

But on this occasion the tracer look is the one I'm after.

Share this post


Link to post
Share on other sites

I took a look at Bn880's tracers. It appears that the tracers' pitch is set with the use of the animate command by using the bullet's velocity as sort of a factor. It's not possible to return a vehicle's roll from the velocity of the bullet though, so it's useless in that regard.

I haven't tested this but you might be able to figure out the vehicle's roll by comparing the vehicle's position with the initial position of the fired round. Unfortunately I don't really know how to make practical use of that idea, but it might be a good start. Otherwise your best bet would be Fwatch if Faguss comes through.

Share this post


Link to post
Share on other sites

This is going to take more brainpower and sobriety than I have to spare at the moment, but I think it should be possible.

Commands in OFP should tell you the positions and velocities (in 3 dimensions) of the vehicle and fired bullet. This gives you two lines in space (that ought to be parallel at the moment of firing). You should know the relative coordinates of the gun muzzle to the centre of the model. Apply that to the other side, relative to the model's line, and you have the trajectory of the second beam.

(This assumes that one of the guns on the model fires actual bullets, because how else are you going to inflict damage on anything?) ((Though I suppose you could spawn rockets that look like energy beams.)) (((But then again, you couldn't set them to point in the correct 3d direction.)))

Regarding your script:

there's no point defining _pos1, _pos2 & _pos3 if you're not going to use them with setPos

you don't need to loop it: once created in the correct place and given the correct velocity, it should be able to take care of itself.

Actually, I'd probably scrub all that, apart from the bit about me needing more brainpower and sobriety. Since this is an aircraft, configure them as FFAR rocket pods where one side fires then the other. Then it's a matter for the config: it may be possible that one trigger pull could cause two rockets to be fired (hopefully one would emerge on each side) OR ELSE put in an eventHandler so that when the weapon is fired it automatically triggers a second time.

Share this post


Link to post
Share on other sites

Yeah you're right.I must've been experimenting and didn't bother putting the variables it into the SetPos array.And to be honest I don't really need setvelocity in that script either.I seem to

recall setvelocity not working on building type classes.Which is why I assume Bn880 went with

the car class for his tracer. :)

As for the missile idea.I already tried it.It has it's own limitations.One of which seems to be particular

to the plane class.

Edited by Maczer

Share this post


Link to post
Share on other sites
The scripting commands to set/return a vehicle's axes were only introduced in Arma. It could probably be solved with the help of Fwatch

No. I'm not skilled enough in reverse engineering to do that.

I do know Bn880's tracer rounds have their orientation changed when they're fired.

Bn880 calculates angle of the real bullet based on its velocity and then rotates the tracer so it matches the real bullet. You could do the same.

_b = nearestObject [_u,_a]
_v = velocity _b
_s = sqrt ((_v select 0)^2 + (_v select 1)^2 + (_v select 2)^2)
_r = acos ((_v select 2) / _s)
_n = _BNTRACERRED_MODEL camCreate (getPos _b)
_n animate ["tracer_swing", _r/180]

Forget about tracer roll. These are symmetrical tubes so you can treat them separately (aka create two objects instead of one). Obtain roll of the vehicle, use

to calculate the offset so that one tracer is placed higher and the other lower.

Share this post


Link to post
Share on other sites

Thanks for the reply Faguss.

Unfortunately my strongest skills are modelling,unwrapping,sculpting,texturing etc. :)

I can see why it won't work trying to adjust the roll of the tracer object in

it's current form.Not using "animate" at least.As you can't have more than one

animation per selection.

Creating two separate objects makes sense with that in mind.

So I would assign a variable to the output of the GetBank function.Which is called by the craft.

The output of this gives me a value which is then used to find the position for the created objects.

c1g3S6Lk.jpg

Correct?

Edited by Maczer

Share this post


Link to post
Share on other sites
As you can't have more than one animation per selection.

Wait, you sure you can't have two rotations? Because then there wouldn't be need for complicated math. Just GetBank and Animate.

Correct?

Yes.

Edited by Faguss

Share this post


Link to post
Share on other sites

Sadly.Yes.Only one config based animation per selection.At least that's what I've observed.

Otherwise it would be possible to animate complex objects from the config.And run them via

script.For example the joints of some kind of mechanical biped.

I can't for instance rotate a limb forward and back and up or down like a hip would move.

It's either rotate forward and back,or,rotate up and down.

Which is why those kinds of animations always look so strange.You can't add

any kind of dynamics.

Edited by Maczer

Share this post


Link to post
Share on other sites

To avoid issues with the sideways roll and placing the laser objects at the two cannon positions it might be easier to go for single fire and use rockets (with a setVelocity loop to keep it consistent without slowdown) with two memory points. I think that's what I did with a TIE Interceptor once, still has a few issues, though - like lots of small scripts running at once causing lag if there's masses of vehicles like that flying around.

Share this post


Link to post
Share on other sites

Hey Lenyoga.

I tried missiles in this context.class zuni.

From what I've observed,getting rid of the smoke trail makes the rockets invisible

unless you're the pilot of the craft.This seems to affect planes only.

Acacyn's old Star wars addons exhibit the same behaviour.

Share this post


Link to post
Share on other sites
From what I've observed,getting rid of the smoke trail makes the rockets invisible

unless you're the pilot of the craft.This seems to affect planes only.

Strange ... I think all "shining" parts of a missile 3d object are treated as rocket exhaust, so they only show when the missile thrust is active, that might be the problem. I just remembered I completely disabled the missile smoke effects in the main config to work around that problem and go for custom ones instead.

Share this post


Link to post
Share on other sites

You mean CloudletsMissile?

Although I'd prefer to keep it as self-contained as possible,I'll certainly keep that in mind.

Share this post


Link to post
Share on other sites
You mean CloudletsMissile?

Although I'd prefer to keep it as self-contained as possible,I'll certainly keep that in mind.

I just took a look and noticed the TIEs also work as a standalone, without the changed config - I'm not too sure how I did it, to be honest. CfgAmmo (dual lasers based on class AA) has one parameter that might be responsible: lightColor[] = {0, 1, 0, 0}; but neither the CfgWeapons (lasers - class mavericklauncher), CfgVehicles (fighers - class cobra) or any other part of the config have anything which might have caused this unlikely success.

Share this post


Link to post
Share on other sites

The CfgVehicles section likely did it.Specifically the Cobra class.Missiles as energy "bolts" works well

with the helicopter classes.There's no visual oddities.

But planes are a different situation.If you observe the craft as a spectator the missiles disappear

even though the ammo and weapons would be the same as on the helicopter variant.This is from

my own observations.

I had considered basing the craft off of a helicopter class.But I didn't think the handling would suit it.

Simulating a plane might be possible with scripting.But that would be something constant,rather

than being tied to the life-time of a bullet.Which as you know is short-lived.

Still.It's an option. :)

Share this post


Link to post
Share on other sites
But I didn't think the handling would suit it.

- that's what all those dead TIE Fighter pilots said, too. I used some sort of forward thrust script which is activated via the action menu, it makes it all less stable and a bit more complicated to steer... but hey - no risk, no fun.

Share this post


Link to post
Share on other sites

Exactly,yes.That's the kind of thing I've tried myself.Although only in short bursts.As a boost.

It's pretty effective too,in the hands of a player.The problem is the AI.They just aren't built to

handle that kind of flight.

The best they can manage is to fly around in circles in a vane attempt to stay in formation.

Or until they crash.Which is not surprising as they can't switch the script off as and when needed.

If I can get something working with getbankpitch,I'll be trying to keep the fire rate

as low as possible without making the weapons ineffective.That should at least help

to offset any looping.

I know I might sound very negative.But honestly,I appreciate any input.Cheers. :)

Share this post


Link to post
Share on other sites

I think I might have the solution for dual lasers (quads are another story for planes, so far those only work on helicopters). Better late than never. I've tried the rocket method on plane-based beta-TIE Fighters now and it looks promising.

 

A weapon based on ZuniLauncher38 with an initSpeed of around 380 (higher goes invisible) and ammo based on Zuni (although it doesn't really matter if it's shotRocket or shotMissile due to the way other values factor into the calculation) with maneuvrability and maxcontrolrange of 0 and a high as possible initTime (thrustTime should have a positive value too, otherwise shining p3d parts are rendered invisible) and a sideairfriction of 0. If you set the weight of the laser's geo LOD to 0, it works pretty well when fired from l raketa and p raketa without being affected by gravity or air friction. Now the only problem is that the AI doesn't really bother to aim well, because if the thrust time has a positive value, the reticule displays ready for a really wide area in front of the vehicle, which just makes them fire whenever they feel like it. A swarm of TIEs still manages to take out a few A-10s though...

I think I'll have to go official with that soon and upload a demo video demonstrating the dual lasers once I get a better idea on how to make the AI use them more effectively.

 

Edit: the above mentioned problem is specific to plane simulation vehicles, it seems to work on helicopters. I couldn't find any values influencing this behavior, but I might try parenting around a bit later (not in the reproductive kind of way.)

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×