Drop

[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.