Drop

[icarus_uk]

This is infuriating.  I cant find a tutorial, or even a snippet that contains the drop command.

Is there one out there and Ive missed it?  I searched the editors depot, the forums and the officials forums.  Is there one around?

[Gameer_77]

Its a good idea. Is there anything in particular you are looking for? Theres some stuff about it in the comfref, albiet pretty messy.

Someone should make a tute on this. (maybe they have  )

 8)PEACE

[icarus_uk]

Im looking for a way of using the command.  An extensive one that I can tinker with.  It makes particles right, well i want to make fire, fake tracers, smoke maybe...  I want a comprehesive tutorial.

[Gameer_77]

Damn sorry man, i don't where one is. My advice is to just play around with some of the options. I made a little script where a guy smokes a ciggy then a puff of smoke comes out.  

 8)PEACE

[icarus_uk]

If all the variables in the array were numbers then playing around would be fine. The array format is thus;

[ ShapeName, AnimationName, Type, TimerPeriod, LifeTime, Position, MoveVelocity, RotationVelocity, Weight, Volume, Rubbing, Size, Color, AnimationPhase, RandomDirectionPeriod, RandomDirectionIntensity, OnTimer, BeforeDestroy,Object ]

As I see it, some of them are numbers some arent.  The number ones are fine, I can just tinker.  But, for example, how would one find out the possible shape names, and animation names without a tutorial or an example or two.

Can someone post any example of drop that you have, or have made, or know where they are, so I can see?

[Gameer_77]

If you want the shapenames the de-pbo the data3D file in the res directory.

Cl_fire, Cl_basic and CL_water are the only ones which look normal.

8)PEACE

[icarus_uk]

I can see this thread isnt going to garner any results.  I'll leave it open in case a miracle happens though.

[Gameer_77]

Cause its only you and me (I?) on. Yoohooo! Wake up everyone! ICARUS HAS A QUESTION!  

Im sure you'll get some help. Check back tommorow.  

 8)PEACE

[Tomb]

[attachment deleted by admin]

[icarus_uk]

Im doing good Tomboy.  Im a little tired but Im about to go to bed to fix that. :afro:

[/b]

Now that I can work with.  Change a couple of the numbers around and see what happens  It was very lucky you found the thread Tomboy.  You must have some kind of 6th sense or such.

[Tomb]

yesss, amazzzinnn' ain't  I ?!   :beat:

[icarus_uk]

You know tomboy.  The glamerous way of scritping is to get you to make my fave tracers script for me

Oh and how do I change the size of the fire?  Its a big ball of flame, I want something small and car engine shaped.

[icarus_uk]

Cmon people.  How can I make a fake tracers effect with the drop command!

[KTottE]

Change a couple of the numbers around and see what happens

See above statement ;D

How many tracers, just one?

Then you should probably decrease rate, spread and some other things. A shame that Vektorboson isn't around, he has documentation on this stuff.

[Sui]

I was having a muck around last night... I can't seem to get the particle to look like tracers though

I can't change the size in only one dimension. I'm sure there will be a way, I just haven't found it yet

drop ["Jeep","","Billboard"... etc gives you a square, which you can make any colour you like to look like a tracer...
I'm working on sheer guessing here though

[icarus_uk]

Woohoo at least someone is looking into it.  I tried messing with the numbers of the fire scripts, giving them a large velocity by changing some numbers.  It all got messy and didnt work at all.

[Gameer_77]

I can't work out to make the drop go at a vertical angle. Damn!

 8)PEACE

[vektorboson]

[attachment deleted by admin]

[icarus_uk]

Doesnt work for me.  I put in a gamelogic and execed the script but I got no tracers out of anywhere.

[edit]
The top line in teh script said

 _obj = _this

I changed it to _this select 0, and put the game logic in brackets and it worked...  Meh!

Very nice indeed.  I sped up the velocity to 1000, more of a bullet velocity, and decreased the interval time.  You are right in that the game slows down a bit.  Finding a balance is whats needed now.

[Gameer_77]

Doesnt work for me.  I put in a gamelogic and execed the script but I got no tracers out of anywhere.

Cause you need to do : this exec "faketracer.sqs" - not : [this] exec "faketracer.sqs"

 8)PEACE

[icarus_uk]

I did and it didnt work.  I said that I added the [] and select 0 part AFTER it didnt work.

[Gameer_77]

oops, sorry mate.  

[icarus_uk]

Second time in two threads Ive been misquoted.  Not my day today.

[jostapo]

For the record, i'm struggling with drop as well.

I'm trying to create an 'accurate' claymore.   Rather than calculate kill chances for the effective blast cone, I'd much rather create a spray of horizonatally fired projectiles.

the usual dotarget fire[ ] tricks won't work either because a claymore is going to have to fire off 100 or so projectiles, and do it in such a fashion as to not bring the gameserver to it's knees.

Anyone know if drop[]'d objects have any lethal effects?

[jostapo]

Noting like replying to yourself.

Messing aroudn with drop tonight has plainly shown drop uses the ballistics algorithms inside ofp but not the object logic.

Ie, you can create a fountain that sprays m1abrams out in beautiful, non cpu sapping, arcs.  Unfortunately, when those tanks hit a player you get a bit of 3d clipping and that is it.

So for my application it's almost useless.  For that matter, i don't think it full answers icarus's tracer spam problem.  I mean, if you were walking along and green lights flicked across your line of site without the usual swish and thwack of bullets passing and hitting, would you duck?  Might be useful for cutscenes however.

What I really want to know is, is it possible to quickly and effeciently create a virtual muzzle, and fire rounds from it in very fast succession?  Furthermore, can the muzzle be targeted using ONLY x,y,z coords for position, and a compass heading, and 0-180 barrel elevation heading.

Someting along the lines

_mymuzzle = CreateMuzzle "Bullet12_7"
_mymuzzle SetPos [x,y,z]
_mymuzzle SetHeading 185
_mymuzzle SetElevation 45
MuzzleFire _myMuzzle

BIS is already doing it... and given new ammunitions and fire modes are possible for addon makers, there have to be a set of commands for executing this sort of thing.

Hoping.

[BitFlix]

I found a very cool way to quickly move a bunch of objects (bullets, shrapnel, etc) in a circular fashion, i.e. starting from one point and moving in all directions from there.

The trick is to use the "foreach" command and an array filled with objects that are camcreated before the loop starts. "foreach" has almost zero latency, and I can move up to 100 bullets in reasonable time.

I use a parametric line equation with normalized direction vectors. Each object is assigned a vector and stored in an array. Then from the "foreach" loop I pick the object like this:

(_x select 0)

and the vector's x and y components with

(_x select 1)
and
(_x select 2)

I've finished a nice shrapnel script with drop effects and all, but its in its early stage and still has some bugs. One problem is that "foreach" works with global vars only, so there can't be more than one script running at a time (unless you do something very clever).

I'll post it here when its finished.

Oh, one more thing: The direction vectors can be precomputed and stored in a global array. You can simply use the [1,0] vector (east direction) and rotate it with sine and cosine for 0..360°, then store in an array and use it for all your shrapnels.

[jostapo]

Actually  Dinger and I have been working on this problem and have done an end around on the entire drop/setpos/foreach bit.

Digger came up with teh notion of attaching a shell to the missile simulation.  It works out exceptionally well.

Simply camcrate the 'shrapnel' addon, setdir, and off it goes without the usual drop.  It's a pity the shotbullet simulation doesn't work in the same fashion.

With this setup, we're able to spawn a spread of 120-200 bits of shrapnel inside .2 seconds.   This is without reliance upon setpos, foreach, or any global variables.

About the only down side is, shotmissile ends the simulation with a small explosion at the impact point.  It probably won't bother most people, but bothers me a bit.

I can't speak for Dinger, but think he feels the same as me.  Whatever solutions that can be found have to try as they may to avoid:

1) Long executon times.  As the shrapnel based scripts will more often than not, be called 2 or 3 times all at once (or in the case or artillery deployed mines, a dozen times).  Locking folks machines up for 3 seconds while shrapnel is spawned just isn't going to fly (and will pose real problems in MP).

2) It has to be easy to use.  Dependence on a raft of global variables or a complex set of triggers isn't all that great.  The working claymore and bouncing betty scripts I've worked up are exceedingly easy to call with , [this] exec "fireclaymore.sqs" where this is the name of a gamelogic object who's facing is the direction the claymore is to detonate.

3) And this is the kicer, the shrapnel sim has to take into account lateral travel of the shrapnel over the battlefield.  I was using Drop in the early versoin of the claymore, but the problem was I had to simulate each projectile one at a time because the drop command's timerevent only passes x,y,z in.  If it were to pass the boundobject parameter as well, then this would have been the wya to go, as you could track the flight of all the objects and constantly check for cohabitation of shrapnel in the same space as other objects (aka hit detection).   Without proper hit detection, the simulation just doesn't hold true.   If a tree is in the way, the simulation needs to give the target cover.  Something my early tests showed would be expensive and wordy to accomplish.

If you'd like to confabulate on this, pop in on #ofpec.  I'm usually there and will gladly swap ideas/scripts.

Joel

[BitFlix]

You wont be able to do proper collision detection in OFP so forget that. It *might* work for AI units, like soldiers, maybe even small vehicles, but not for buildings.

Actually I was thinking about using just the line equation and moving a small "drop" particle along its way until it hits something, then see if its a soldier and kill him. I can do that using a small bounding box with 4 planes, but I failed to do col.det for buildings. Any AI unit around the claymore mine can be grabbed using a trigger, but I have no clue how to get hold of building/tree IDs.

And even if it would work it'd still be an insane thing to do. Just imagine we're basically re-producing OFP's colision detection with the crappy script language - that's totally braindead, coz its all there already, we only need a way to fire the shells/bullets.


Anyways, some thoughts. If we're gonna resort to the traditional way and move small objects along lines or parabolic arcs, then we should definetely use my "foreach" trick, coz its at least 10 times faster than a loop which needs to update each friggin particle once per cycle.

Also I recommend precomputing as much as possible - angles, trigonometry, vectors etc pp. and store everything in a global array for all scripts to use.

I wonder if you can get rid of the small explosion you mentioned by using a non-explosive shell, like those API shells fired from the Bradley's 30mm.

[jostapo]

The way we are moving the shrapnel isn't the tradional way.  Or rather, it's not the conventional way.  We are simply camcreating them, setting their direction, and letting the game engine take care of the rest of the stuff.  By tweaking down the thrust and burn time for the shotmissile simulation, you end up getting a missile that looks and behaves pretty close to what you'd expect a slow bullet to.

Digger's first example script used just the sort of 'build array with coords, build array of camcreated stuff, and then setpos the lot in a foreaech loop' approach you are talking about.

I sat down and actually profiled the code using the _time variable to measure exection times.   I have _no_ doubt that foreach inlines the code and executes it much faster than standard ?x>y:goto loop.  It is.  Unfortunately, you have to mess around so much to get the variables in place to actually use the foreach loop that you've actually set the execution back.  I benchmarked this specifically.  The script executes in .4 seconds or so when using the foreach loop.  Without it, and a raw loop camcreating it executes in .2 seconds.

About the only worthwhile optimization was inlining the trig functions with the actual camcreate calls.  That cut the original .3 second execution down to the final and current .2 seconds execution.


As for getting rid of the explosions, I just don't know.  I've messed with the cpp file a whole bunch, setting explosive to false, toning down the damage to next to nothing (think 1mm round moving at 2feet per second .P, with no luck whatsoever.

Your point about the 30mm ap round does bring to mind I never checked that definition's class.  I'll take a closer look at it to see if there's something in their I missed.

Otherwise, I'm all ears about ways of getting rid of the flames.  That'd sinch this thing right up.

Thanks,
Joel

[Schoeler]

Have you messed with the new setVelocity command on your claymore script?  Since it involves a speed AND direction, I thought it might be a useful command for this purpose.  Also, what about using drop to create multiple tracer like objects shooting up and outward from an explosion and combining it with multiple camcreated smoke grenades trailing them to simulate a white phosphorous round going off.

[MI_Fred]

Using the Drop:

So far I've managed to create a 'whip' of those 'nades bursting out of 1 spot into a random direction (18th & 19th arguments) for 360 degrees. Also the Velocity is in the drop command, it's the easiest thing to make this 'whip' but when I wan't the shrapnel to burst out at the same time, I just am loosing hair. ;D

_obj = _this select 0
_head = getdir _obj
_posDrop = getpos _obj
_velocity = [0,0,0]

_distance = 0
#Begin
_head = _head + 1

drop ["granat", "", "SpaceObject", 1, 0.75, _posDrop, [25 * sin _head,25 * cos _head, 0.2 + random 1], 1, 0.0045, 0.0042, 0, [0.8,0.8], [[1,1,1,1], [1,1,1,1], [1,1,1,1], [1,1,1,1]], [0,1,0,1,0,1], 0.000001, 5, "", "", ""]

~1/10000000000000
? _head >= (getdir _obj *3.5) : exit
goto "Begin"

The velocity is the 7th argument(the array) in that drop array. I could possibly drop it at a different position(6th argument) on every time but that'll also be demanding on my hair.

When it comes to determining impact points with dropped particles, I wouldn't go there  ;D should I? I think not. There's a possibility to run a script just before a particle is destroyed, into it is passed the position of the particle. But that won't do if it impacts anything before the death of itself.

Well I hope some1 got kicks out of this. For me, well, plain fun  

[Aeon]

"granat"  
What's that things ? where did you find it ? Do you discover other new things? tell us all you know  ;D

[jostapo]

We did end up using set velocity instead of drop.

Worked up a 4 poly shrapnel model as well to to reduce the impact on the frame rate when a claymore is detonated (could have gotten away with nothing, but we wanted something to be visible... if just barely).

Look for a release soon.

[MI_Fred]

Aeon, how do you usually discover new things? by mistake!  

First I entered  hogus bogus things into it like "grenade", gave me an error: it couldn't be found from data3d.pbo, so I dePBO'ed it and had a look what's in it. Everything! hehe.

There you will find your cl_basic, cl_fireD etc. Also abrams, law missiles, law proxies, lightsources... and that granat (from a GLaucher). You just have to use the "SpaceObject" as the particle type for some and "Billboard" for others. So dePBO data3d.pbo (from DTA folder), insert the name of the object u wan't into a drop, fiddle with the particle type... there's 859 p3d's in there so... happy hunting.

[Rubble_Maker]

When ya drop grenades or missiles, do they explode upon impact?

That'd be AWESOME...

[MI_Fred]

When it comes to determining impact points with dropped particles, I wouldn't go there  ;D should I? I think not. There's a possibility to run a script just before a particle is destroyed, into it is passed the position of the particle. But that won't do if it impacts anything before the death of itself.

Nothing like quoting myself.  
I'd wish RM, but drop creates just nice good-for-almost-nothing-gfx. They pass through units. Only collisions happen hitting the ground...  and in the end of a particles lifetime that script could contain an explosive, other than that, what is drop good for I would like to know too.

The last argument in the drop array is "object" to which the particle can be binded to. If I'd know how this works, You could run continuous queries if that "object" is in the same pos of any list of objects in the editor. As in putting a whole map covering trigger and naming all in it as ALLLIST for example. Then running ? "getpos _x == getpos _objectbindedtoparticle" count ALLLIST > 0 : _boom = "shell125" camcreate getpos _objectbindedtoparticle  ;D
Way theoritical still.

Jesus,

That's obsolete. Sorry, didn't look into it hard enough. There's the 3rd last argument: OnTimer - Name of the script to run every period determined by TimerPeriod property argument (4th). The position is passed into it. That is all you need them. ëhkey?  ;D