my suppress script dosent work

[penguinman]

hey

i made this script and it dosent show any error messages when i run it, but it also dosent work, anybody know why not

Code: [Select]

 _unit = _this select 0
_bullets = ["bulletsinglew","bulletburstw","bulletfullautow","bulletsinglee","bulletburste","bulletfullautoe","bullet7_6","bullet12_7"]


#loop

_round = nearestObject[_unit,"_bullets"]

?speed _round > 1 and _unit distance _round < 3   : goto "update"
 ~.001
goto "loop"

#update
_unit setunitpos"UP"
_unit setbehavior"combat"
_unit switchmove"combattocrouch"
_unit setcombatmode"NEVER FIRE"
~3
_unit setcombatmode"Open Fire"
goto "loop"
exit
thanks

[h-]

You have this one line which is wrong:

Code: [Select]

_round = nearestObject[_unit,"_bullets"]You can't use an array 'in' the nearestObject...

You will need to search for each of those bullet types in the _bullets array separately...

Something like:

Code: [Select]

_i=0
_cnt = (count _bullets)-1
#loop
_proj = _bullets select _i
_round = nearestObject[_unit,_proj]

? _round in _bullets && speed _round > 1 && _unit distance _round < 3: goto "update"
~.001
_i=_i+1
? _i < _cnt: goto "loop"
exit
But, I will guarantee you that you will not detect any bullets with this...
Bullets are way too fast for sqs loops...

[General Barron]

Try this function here. It does exactly what you want.

http://ofpec.com/editors/funcref.php?filter_func=43

However, I don't think this script is going to work out. NearestObject is a very CPU-intensive call, and if you are going to make (8 types x 1000 calls/second) 8000 calls per second, you are in for one heck of a lag (or crash) fest. Nevermind if this script is running for more than one unit, and never mind if it is in an actual mission (not on desert island).

It is possible to detect some bullets with a nearestobject loop (slower ones), but it is very cpu intesive. Check this out here:

http://www.ofpec.com/yabbse/attachments/max_payne.zip

[penguinman]

oh, well if it is that cpu intesive, thanks anyways :-\

but then how does ofp do it, like with the little cloud of dust where a bullet hits?

[penguinman]

oh wait,

all bullets derive from the bulletsingle class right?

so couldnt i just put bulletsingle in the nearest obj and have it work

and also
nearest object can detect bullets

ive made a script that uses nearest object to find a bullet the player fired and setpos a bycycle on it, and then give the bicycle the same velocity as the bullet, im positive because i saw it work, i did that when I made a gun that can shoot bicycles for this one mission i made.

and it wouldnt be that cpu intensive because im only using it for one person.

[Planck]

couldnt i just put bulletsingle in the nearest obj and have it work

Whilst it is correct that most bullets are derived from bulletsingle, they all have different class names, so, if you just look for "BulletSingle" that is all you will be looking for.

If the enemy is shooting "BulletSingleW", then you won't detect them because they are a different classname.


Planck

[Fragorl]

oh, well if it is that cpu intesive, thanks anyways :-\

but then how does ofp do it, like with the little cloud of dust where a bullet hits?

In the ofp core, an instance of 'bulletsingle' is created. When the bulletsingle collides with something, the collision checking process returns the exact location, and bullet destroys itself and produces a 'smokepuff'. Or something along those lines. Basically, the game can do whatever it likes to the bullet at the exact instant of its death, because it contains the code that decides when the bullet dies in the first place.

This is an example of event-driven code; the game does not have to run a background check on all it's bullets, because they notify it of their own deaths, and it responds accordingly. So for example when the bullet hits a player, it retreives to mesh of whatever it collides with, tells the game that it collided with it. The game checks the owner of the mesh and sends a damage call. That object then decides if it wants to take damage from that type of ammunition (eg yes if player, no if tank). Each bullet flying around has it's own thread executing simultaneously with all the other bullets, and tanks, and men. The bullet may refer back to the game for lists of objects to check, but fundamentally it is independent and manages it's own affairs.

Hopefully that has shed some light on the situation, unless of course i have spent the last 5 minutes telling you something you already knew... Anyhow, that is approximately the way object-oriented programming works in these situations. It is different to the way we write scripts in ofp. We are forced to retrieve what meagre scraps of information we can at, relative to the game's workings, extremely large intervals. This is why we are quite dependent on event-handlers- they are things that the objects themselves call at specific times in their life. You can be assured that a Killed eventhandler has executed just before (or just after) an object dies, as opposed to anywhere between 0.001 and 0.1 seconds after it's died.

Access to some of the ofp source code would really be nice. Something similar to the way the Unreal series gives you access to a large portion of their game code, plus a compiler, and you can edit the games at the source level.