Dead Body and object remover (DELETED)

[myke13021]

Retiring all works from public. Has nothing to do with OFPEC nor with any member of OFPEC.

[Mandoble]

At first glance there is a limitation there, as it seems to work only with units already present on the map when the init script is executed. That means that the script will ignore all dynamically created units.

[myke13021]

indeed, it is but i've got already plans to remove this limitation. Thought too late on this issue.
Reworked. Check first post.


Myke out

[Mandoble]

You may create the trigger inside your script this way:

Code: [Select]

   _trigger = createTrigger ["EmptyDetector", _position];
   _trigger setTriggerActivation ["ANY", "PRESENT", false];
   _trigger setTriggerArea [_maxrange, _maxrange, 0, false];
   _trigger setTriggerType "NONE";
   _trigger setTriggerStatements ["this", "", ""];
   _trigger setTriggerTimeout [0, 0, 0, false ];

Then you may check

Code: [Select]

list _trigger every desired time period, the list of the trigger will keep updated all the time until you delete the trigger.

[myke13021]

hmmm...you mean create a trigger that already covers the whole island? Indeed, but i think this way it keeps flexible whenever new Islands come out (whenever BIS releases the tools for) to be used on them also. I don't think to place the trigger/s manually is a great downgrade. But let me reflect on this a while....btw, is there a way of detecting actual map/island size? As you might see, the trigger needs another size on Rahmadi than on Sahrani.

[Mandoble]

How about a trigger with 100Km radious, would that be big enough to cover any future island? 

[myke13021]

How about a trigger with 100Km radious, would that be big enough to cover any future island?

rofl...any future island...let first fill out my lottery as i want to be rich asap. But i guess it will be big enough. But another question: will performance not be affected by the size of a trigger? As it has a bigger area to check for units? Hmmm...probably one single giant trigger wouldn't be noticeable. OMG, already answering my own questions...got to visit my psycho-dad...erm, meant psycho-doc 

I think i'll give it a go...tomorrow

[Mr.Peanut]

It should be possible to get the world size from the config. Perhaps hoz or Planck knows how to do this.

[hoz]

I don't think you can get the exact size from the config, but you can return the lat, long, size of landgrid and maybe do some math to calculate that.

Code: [Select]

_cfg =(configFile >> "cfgWorlds" >> worldName);
_Lat = getNumber (_cfg  >> "latitude");
_Lng = getNumber (_cfg  >> "longitude");
_LandG = getNumber (_cfg  >> "landGrid");


For sara landGrid = 40;

[Mandoble]

You dont need the exact size, you only need a trigger big enough to cover any island. The size of a trigger does not affect the performance.

[Mr.Peanut]

Are latitude and longitude single values i.e. center of grid, or arrays with two values? And what exactly is landGrid?

Approximate formulae:
(lat2-lat1)*111.111 = approx distance between two lats in km.
(lon2-lon1)*111.111*cos((lat2+lat1)/2) = approx distance between two lons in km.

Formula are only accurate for small distances (< 1000 km) and at points away from the poles (70S>lat<70N).

A trigger's size may affect performance depending on the complexity of the trigger condition.

[hoz]

  longitude = -40.02;
  latitude = -39.95;

Not sure what land grid is I through that in there for confusion and see it worked.

[Planck]

landGrid is the smallest terrain cell size for a particular island .wrp file.

For the old OFP islands it was 50, which means the grid was 50m X 50m
Each grid square was occupied by one texture. (OFP only)

As each smallest grid was this size and you needed 256 X 256 of them to cover the whole map, which is of course 65,536 grid squares, giving a map size of 12.8km X 12.8km. (163.84 sq km)

Sara on the other hand has a grid of 40 which means 40m X 40m

Needing 512 X 512 to cover the whole map and giving a map size of 20+km X 20+km. (400+ sq km)

Or so...


Planck

[myke13021]

Indeed, this could really work but at some stage i think it would be too much taken out of the hand of missions creator, even if it's customizable. I don't think it's too much downgrade to ask a missiondesigner to plant one single trigger.

Surplus, i finished a "coop essentials" package which contains the DGC:r, the Body removal system and an ambush/reinforcement system.
Therefor i think the Body & Object remover is good as is.

Tell me if you have a completely another opinion.


Myke out

[Mandoble]

There are several main issues:.
Case 1: You have a "repeatedly" trigger covering an area with a group of units inside and the units get their corresponding event handlers. But the group moves away of the triggers area pursuing some enemies and the trigger deactivates. Then the remaining units return inside trigger's area, the trigger activates again and each unit gain a new added event handler. And so on as long as the group leaves the trigger's area and enters the trigger's area again.

Case 2: You set a trigger (repeatedly or not) covering the desired area without units inside the area. And a group moves inside the trigger's area, but all the units of the group are not teleported inside trigger's area at once. When the very first unit of the group enter's the area, the trigger activates, and the trigger's list contains that single unit (which receives the event handler). The rest of the group doesnt get any event as the trigger will not activate again unless deactivated if not units are present again.

Case 3: You set a trigger covering the desired area without units inside. The trigger is activated by their presence and each unit gets its event handler. Now a second group enters the area, but the triggers has not been deactivated, so the presence condition is still true and the activation action is not executed. As a result, none of the new units gets the corresponding event handler.


In case this remove dead bodies method is used in "coop essentials", the same problems would be present there.