TAKE COVER script

[General Barron]

This script makes a group take cover behind the nearest bush/tree/rock/object. The script uses a 'nearestCover' function I wrote based on the work of Komuna and Spinor. You can choose one of the following conditions that the group will take cover under:

1) Take cover immediately when the script is called. Basically for "manual" use by mission designers.
2) Take cover if the group is attacked but doesn't know where the enemy is, or if they see the enemy but he is too far away to engage (I'm saying beyond 500 meters is too far, but it could be changed)
3) Always take cover if the group is attacked or spots the enemy

Sounds great right? Well... there's a little problem. On my computer, the damn thing crashes! But my comp has crashed before on some OFP things that don't crash other's computers, so I'm hoping you guys can try it out and see if it works for you. But let me be more specific:

On my computer, I can run the script just fine if there are no enemies around. I'll run the script using the first method, and the squad will all run and take cover perfectly, just like they are supposed to. However, when I try running the script (using any of the methods) with an enemy shooting at the group, suddenly I crash 100% of the time. It seems to always crash right as someone dies or gets hit by a bullet, so I suspect that has something to do with it.

Here is what I'd like from you guys:
Open up the demo mission. In it, there is a friendly AI squad, a radio trigger, and one enemy next to another trigger. The radio trigger will execute the script using the 1st method above. The other trigger will execute the script using the 3rd method right at the start of the mission.

Delete the enemy and the trigger next to it. Now run the mission, and use your radio to execute the script. The squad should run to the bushes and lay down. Yay, ok the script works in theory. Now, exit and reload the mission. This time, run it with the enemy there. Now the enemy should start firing on the squad, which should then try to take cover. This is the part that crashes on my computer. Usually it will crash right when like the 2nd or 3rd guy is killed (right when the script starts telling people to take cover).

If your computer doesn't crash, then horray! It means this script can be used by someone. If your computers all crash, then I guess its back to the drawing board....

[Gooner861]

Hello there,

I'll give this a quick try before i go to bed.

[Planck]

Hello GB

Tried your script.

It works perfectly without the enemy and trigger.

Unfortunately reloading and trying with them also causes a CTD on my system.

Nice script, hope you can get it working right.

EDIT:  Tried it a second time..........same thing


Planck

[Gooner861]

Ok just tried it and it worked for me, didnt crash at all. I waited for about 4 of my squad to get killed but it didnt crash. Dunno why urs and Plancks did though.  :-\  

Nice script by the way  ;D

Gooner

[General Barron]

Ok just tried it and it worked for me, didnt crash at all. I waited for about 4 of my squad to get killed but it didnt crash.

Great! Now, would you consider your system to be low, medium, or high power? What about you Planck? I would consider mine to be low power, and like I said, I have crashed before playing OFP, but usually that is when I am at like 4x acceleration, and running a heavily scripted mission.

[Planck]

My  system is a few years old now......I built it myself I should know.

It is fairly low power by todays standards.

Amd Athlon 900 Mhz
Geforce 2 GTS 64Mb
256Mb System memory

OFP very seldom CTD's when I am playing, just the odd occasion.


Planck

[Mud_Spike]

Crashes here to, an exeception in ddhelp, on my 1.4Mhz or whatever it is.

The script is recursive, could it be that a small bug makes it spin out of control, calling itself over and over, increasing the number of script instances logarithmically (sp?) until we run out of stack/script-slots.

Havent got time to try to debug it now though. If you havent cracked this by tonight I'll give it a go.

[Gooner861]

Mines probably just abit more powerful than Plancks. Same processor speed, Geforce 4, 256mb memory.

I'll try the script again just to make sure it wasn't a one off.

Gooner

[Gooner861]

It worked again  ;D !!! I waited and waited and waited but it never crashed, got abit laggy but never crashed. Dunno wots so different to my computer to all yours.

Gooner

[Manitou]

Tried it, the Russian fellow started firing on the US blokes. One of them got shot and then CTD.

900Mhz
320Mb SD-RAM
GF4 MMX 440 64Mb DDR

[Mud_Spike]

FYI:
It's a problem with the dir-loop in nearestCover.sqf (while { _dir < 5 })
I tried cutting it down to 4 dir-iterations per outer-loop iteration, and that keeps it from crashing, so I'll continue debugging it from there.

Looks as if it is an execution-time issue though, the function runs for too long and OPF happily kills itself.
I guess you could keep the outer loop in your .sqs.

Edit:
With a benchmark of 3050; setting the resolution(_res) to 45 (as opposed to the default 5) prevents the game from crashing.
44 also seems to work, while 43 crashes every other time.

Why it works when manually triggered is probably because OPF is too busy computing the threat of being attacked for 10 units, along with targetting for the russian, bla bla bla,
and hence more aggressive when it comes to CPU-hoggers.

All that aside, it's a very nice script when it works.

[General Barron]

It's a problem with the dir-loop in nearestCover.sqf (while { _dir < 5 })
I tried cutting it down to 4 dir-iterations per outer-loop iteration, and that keeps it from crashing, so I'll continue debugging it from there.

Logically, the function works exactly like it should. It makes a nearestObject call every _res meters along the perimeter of a square, then it checks to see which of the valid "covers" that were found is closest to the center. If no cover was found, it will search along the perimeter of a bigger square, and so on and so on. If nothing is found by the time the search distance limit is hit, the function exits.

The resulting pattern is a bunch of concentric squares, or a grid pattern. I've visually verified that the looping works exactly as it should by having it place objects at each place it would call nearestObject.

I tried cutting it down to 4 dir-iterations per outer-loop iteration, and that keeps it from crashing, so I'll continue debugging it from there.

Actually, it currently does 4 dir iterations--one for each side of the square that it is searching along. If you cut it down by one, that means the search pattern is going to look like a square "c".

setting the resolution(_res) to 45 (as opposed to the default 5) prevents the game from crashing.

I wouldn't reccomend setting the resolution beyond 20 meters at the most, because doing a search every 45 meters is unlikely to return the nearest cover, if it even finds any cover at all (keep in mind the nearestObject at the search point could be a road or some other non-cover type object).

Looks as if it is an execution-time issue though, the function runs for too long and OPF happily kills itself.

I don't think so, because it only crashes when somebody is dying. My guess is that there is just too much for OFP to handle when somebody is killed, and so if you try to make it do like 40+ nearestObject calls at the same time, it crashes.

Since this is crashing so many people's computers, I am going to go to plan B: instead of putting the nearestCover routine in a function (which OFP tries to resolve the entire thing in like 1 game clock "tick"), I'll work it directly into the sqs file, with a very slight delay between each iteration. When I get a stable version of this "function" working, I'm going to post it on OFPEC so that all those AI scripters out there (like 2 or sumthin) can use it in their own scripts.

Thanks people, I'll post a new version of the script in a little bit.

[Planck]

I did try playing a bit more with this.

I found, as you stated that it seems to CTD when someone is dying, but, not every time someone is dying.

Sometimes nearly everyone is dead and it is still ok.
Sometimes, it CTD's when the first person is killed.
Sometimes after 2 people die.

It 'appears' to be random, but it might be tied to sound.  It is only an impression I get, but it appears to CTD when someone cries out after getting hit, and then not every sample, but maybe only certain ones.

But, as I said, it is only an impression.

I may do further testing yet.


Planck

[General Barron]

It 'appears' to be random,

Note that the nearestCover function is called once per unit, with a slight delay between each unit in the group (a second or less). So it could just be that the nearestCover function isn't being called when somebody is dying, at times.

[Zayfod]

Hmmm.

I dont believe nearestobject command or resources is the issue.

I encountered a similar issue when I was working on creating special FX at bullet impact "crater" holes in the ground (Dirt and pebbles flying up). Now--I had no issue finding the crater and when the bullet holes were all in the ground it always worked perfect but as soon as the bullets started hitting objects it would CTD 100% of the time.

What is important to note is that I was always looking specifically for "crater"s.I discovered that something weird takes place with bullet "crater"s when they hit objects.

When bullets hit objects my function still found a crater even tho there was none to be seen. So I added an "isnull" check for safety and my function still found that the crater did indeed exist--you can imagine how puzzled I was? So i went through my code line by line and discovered the culprit for the CTD--it was "Getpos"

If I tried to "Getpos" on a crater (made after striking an object) that was found using Nearestobject (checked with isnull) I would get 100% CTD. When I simply commented out the getpos the code was fine--although usless now as I needed getpos.
 
However--you dont want craters

So try this,

Code: [Select]

_obj = nearestObject [_x,_y,0];

if ("All" countType [_obj] == 1 && "crater" counttype [_obj] == 0) then
Might just do the trick.

Zay
      

[General Barron]

I dont believe nearestobject command or resources is the issue.

Seeing how the script works on some computers but crashes slower ones, that would seem to be the case. However, I tried commenting out all the evaluation part of the function (where it determines what do do with the object found via nearestobject), and it didn't crash my computer at all. So I think you may be right about that.

Now, I tried your suggestion, and.... it crashed still. However, it didn't seem to crash as quickly as usual, so at least that is encouraging . Interesting thing though, is that I tried putting this in instead:

if ("All" countType [_obj] == 1 && typeof _obj == "crater") then

And I got a different result: instead of the game crashing, it froze. Not a more desirable result, but a different one nonetheless...

A sneaking suspicion I've had is that perhaps the nearestObject is returning something weird, like the blood particle that appears when a unit is hit. But the thing that confuses me, is why would the script crash some computers but not others, if it is making a bad call (like a getpos to an object that doesn't exist)?

[Zayfod]

Did you try

Code: [Select]

if ("All" countType [_obj] == 1 && typeof _obj != "crater") ??

And perhaps switch off blood for testing purposes.

[General Barron]

Whoops! I meant !=.... I'll try turning off blood though.

[Manitou]

I'm totaly in the dark to all this clever scripting but I noticed in the last post, a comment about a "blood" object and confusion over why one PC crashes and another doesn't. I forgot to mention in my last post that I use ECP and I know that it has custom blood particles, which were on at the time of my testing. I'm in work at the moment so I can't test the script with and without ECP blood running but I thought I'd mention it.

Good luck, code boffins. ;D

[Blanco]

Just for the record :

My PC crashed too to desktop, once the battle begins.
No mods like ECP were installed,
I have a AMD 2000+ with 1024 Mb RAM.
So plenty of RAM and it still crashes.
Very nice script when it works, I really hope it will someday.

**edit**
Correction : I forgot dxdll was installed

[Gooner861]

How come my computer is the only one not to crash? Im feeling left out  :'( .

[General Barron]

How come my computer is the only one not to crash? Im feeling left out  :'( .

What are your computer specs? I'm just as confused as you are on that one Gooner. Try running the script on a few groups at one time, and have them fight more enemies. Maybe you can get a CTD then.  

[Gooner861]

900mhz, 256 mb Ram, Geforce 4 graphics card so pretty poor really.

I have ECP installed when running it. I think you have enough people anyway with crashes to show the script needs fixing, maybe my computers just invincible  ;D   .

Nice script though  ;D

Gooner

[Northener-PNE]

I also tried your script and it CTD in about 10secs. Shame as it sounds like a cool script. I hope you can figure it out.

My specs
Amd 3200XP
1Gig Ram
XFX 6800GT
XP Pro SP2
Bla Bla Bla

 

[penguinman]

MIne worked fine on first part crashed on second part I didnt get to try it 2 times though it looks promising. its funny seeing all there heads sticking out of the bushes

[Garcia]

So what's happening to this script? You abandoned it? Or are you still working on it?

[Fragorl]

Wow, I never saw this before.

What Zayfod says about craters etc has cleared up a minor issue for me, too- namely that when I was running a nearestobject loop and constantly (accidentally) picking up the player's footprints (called 'mark'), I was often getting crashes to desktop as well, but only rarely. Still, it puzzled me since ofp almost never does that to me, certainly not with the kind of frequency that was occuring in this script. Well, now I know why

And, even though I'll only be about the 59 billionth person to test this, I must see it. I tried to make something similar to this a while back (all that raytracing with smokeshells business ), by testing the environment around the unit in question for line of sight to the thing they were taking cover from. However my method often failed due to incorrect positions being returned from the raytraces. If I'd have known the problem had already been solved...

[Nemesis6]

Back to the drawing board.