Need Help With Proximity

[PatrickAWlson]

I am trying to get a proximity to trigger with planes and not coalitions.  Doesn't work.  The planes fly right by and the proximity does not trigger.  Same mission, triggering by coalition, does work.  Posting zips with both.  They are small missions that take less than a minute to run.

 

The documentation (page 87) seems to clearly state that you can trigger by proximity to a plane or vehicle by object linking the proximity to the plane/vehicle.  

 

Hope I'm just making a stupid mistake.

Ground Free Hunt Spawn Test Works With Coalition.zip Ground Free Hunt Spawn Test Does Not Work With Planes.zip

[JimTM]

In addition to the object link to the German plane, you need an object link to the Russian lead vehicle.

Edited June 26, 2021 by JimTM

[PatrickAWlson]

Thanks for taking a look, but still not working.  Or more like working entirely too well now.

 

With an OL to the lead truck and the lead plane, the proximity triggers immediately (Ground Free Hunt Spawn Test Triggers prematurely).  Closer = 1.  The trigger distance is 2000 and the actual distance is 13000, so there should be no trigger.

 

As an experiment I tried switching the proximity MCU from closer to further (Closer = 0).  That does not trigger at all (Ground Free Hunt Spawn Test No trigger). 

 

Ground Free Hunt Spawn Test Triggers prematurely.zip Ground Free Hunt Spawn Test No trigger.zip

[JimTM]

It appears that the spawner feature affects the behaviour of the proximity trigger. If you set up the vehicles without spawning them, the proximity trigger works as expected, as shown in this mission:

 JimTM - Test Proximity Trigger 3.zip

 

Note that all the vehicles you spawned in your test mission had Enabled selected so the spawn was redundant. However, it appears that the spawn still affects the proximity trigger behaviour even if the vehicles are already there. I tried adjusting the timers in your mission to wait for a longer time for the spawn and then trigger proximity, but it made no difference.

Edited June 27, 2021 by JimTM

[PatrickAWlson]

That does work.  Rewriting the code to make potential victims enabled from mission start.

[IckyATLAS]

Sometimes it ca work better when activating and deactivating the entities instead of deleting and spawning. But all depends on the scenario.

 

[Jaegermeister]

On 6/27/2021 at 9:54 PM, PatrickAWlson said:

That does work.  Rewriting the code to make potential victims enabled from mission start.

 

Wouldn't it be preferable to have potential enemies activated by a proximity, checkzone, waypoint or timer, but not enabled from the start to save resources? I don't know if that is an option with your programming but it helps frame rates for scripted missions.

[JG4_Deciman]

6 hours ago, Jaegermeister said:

 

Wouldn't it be preferable to have potential enemies activated by a proximity, checkzone, waypoint or timer, but not enabled from the start to save resources? I don't know if that is an option with your programming but it helps frame rates for scripted missions.

 

Recources are used when a unit is active.

 

Difference between

'active on mission start -> disabled directly afterwards -> enabled/spawned when needed'

and

'disabled on mission start -> spawned when needed'

is absolutely ZERO after the initial 'disable all unused units'

 

And the mission size will be nearly the same, because in both cases all units have to be present in the mission...

 

Deci

[AEthelraedUnraed]

5 minutes ago, JG4_Deciman said:

Difference between [...] is absolutely ZERO after the initial 'disable all unused units'

I think disabled units still use RAM if they were enabled before, as the game needs to track their state?

[JG4_Deciman]

30 minutes ago, AEthelraedUnraed said:

I think disabled units still use RAM if they were enabled before, as the game needs to track their state?

 

That can be answered by the devs only.

But if units need still ram in case they were enabled and are disabled now

they would also need ram in case they could be enabled

and every despawned (so disabled) unit would need the same ram...

So finally every unit in mission needs ram, as it is monitored (enabled/disabled)

and maybe enabled/spawned units need more ram as the complete monitoring is used

 

But in that case it also makes no difference

if a unit is disabled by default

or enabled by default and then disabled...

 

I don't know if the devs have implemented it that way

but the difference between 'disabled and later enabled/spawned' and 'enabled and directly despawned/disabled' units

that caused the problems seems to proof they used a different way...

 

Deci

[Gambit21]

There should not be a difference between disabled and later spawned, and disabled and later activated. I’ve told that there is however (with the second option being more expensive) and this makes no sense to me at all.

[AEthelraedUnraed]

4 hours ago, JG4_Deciman said:

But if units need still ram in case they were enabled and are disabled now

they would also need ram in case they could be enabled

and every despawned (so disabled) unit would need the same ram...

Not necessarily... if they're disabled after being active, the game needs to store their state in case they get activated again (health, hitbox status, position, orientation, ...). If they're disabled from the start and get activated afterwards, the game knows the state so it doesn't need to store anything.

 

But yeah, you're right in that the Devs are the only ones who know the answer.

 

40 minutes ago, Gambit21 said:

There should not be a difference between disabled and later spawned, and disabled and later activated. I’ve told that there is however (with the second option being more expensive) and this makes no sense to me at all.

I agree with you that this wouldn't make any sense. If anything, I'd expect spawning to be more expensive because of the more complicated spawner MCU. But again, only the Devs know the answer. 

[JG4_Deciman]

9 minutes ago, AEthelraedUnraed said:

Not necessarily... if they're disabled after being active, the game needs to store their state in case they get activated again (health, hitbox status, position, orientation, ...). If they're disabled from the start and get activated afterwards, the game knows the state so it doesn't need to store anything.

 

Are you sure about the state is being stored for re-enable (respawn)?

I was always thinking that a deleted unit is replaced by a fresh one when enable/spawn.

And the server logs also show a new unit-id every time you respawn a deleted unit...

 

Deci

[AEthelraedUnraed]

1 minute ago, JG4_Deciman said:

Are you sure about the state is being stored for re-enable (respawn)?

I was always thinking that a deleted unit is replaced by a fresh one when enable/spawn.

And the server logs also show a new unit-id every time you respawn a deleted unit...

Respawn, yes, but I thought re-activating a unit will just continue with the old one. I may be mistaken though.

[PatrickAWlson]

12 hours ago, Jaegermeister said:

 

Wouldn't it be preferable to have potential enemies activated by a proximity, checkzone, waypoint or timer, but not enabled from the start to save resources? I don't know if that is an option with your programming but it helps frame rates for scripted missions.

 

That is how I do almost everything.  In this case I want them moving from the start of the mission to make the player hunt for them.

[Jaegermeister]

7 hours ago, PatrickAWlson said:

 

That is how I do almost everything.  In this case I want them moving from the start of the mission to make the player hunt for them.

Makes Sense

 

I don't know about the difference in resources between spawned and deleted or activated and deactivated, but the state of a deactivated vehicle is saved in terms of location. I am not sure about damage.

 

An active vehicle definitely uses more memory than a deactivated one.

[PatrickAWlson]

3 hours ago, Jaegermeister said:

Makes Sense

 

I don't know about the difference in resources between spawned and deleted or activated and deactivated, but the state of a deactivated vehicle is saved in terms of location. I am not sure about damage.

 

An active vehicle definitely uses more memory than a deactivated one.

 

It does, but so far performance seems to be acceptable.  At the moment I wanted to see how the missions played out, and I like them.  Much prefer them to go to a point and the 

[IckyATLAS]

The way I have used these choices to improve and avoid time dilation:

 

1) I spawn/delete "static" (that will not move) entities for which block version do not exist and this is typically ships and a certain number of plane models like the B25, C47 and some others, or that the static block version does not have the right skin typically US, RAF instead of USSR. It is unfortunate that this does not apply to block and ground objects because it would help a lot to reduce the quantity of items in memory at one given time for large maps like Kuban (The best map so far on my humble and personal opinion). 

 

2) For dynamic objects I use activate and deactivate. It is important because to avoid time dilation (due to the use of too much CPU resources) you need to keep visible and active what is in sphere of influence of the player. He may leave things out of his  zone of influence which then become deactivated, that means their data is not lost, and if the player comes back all can continue again as if it did not leave. And this works well for planes, ships, trains and vehicles (all including artillery). Sometimes depending on the scenario you may have to keep active distant entities but still it is very limited cases and in general good design and use of the editor can allow us to simulate the activity and avoid it to the maximum, but as usual they may be exceptions.

 

3) I use the Proximity Trigger when the two objects are dynamic and moving. But when one object is fixed then usually Check Zone (which uses less resources) centered on the static object is the best way to go, and do not forget to use the right shape Sphere or Cylinder and also that the center of the sphere in space or the bottom of the cylinder can be set at a given height. This gives you a lot of flexibility. There are exceptions again where Proximity has to be used if you really need to have a precise straight line distance between a static and one dynamic object. The Proximity trigger with multiple dynamic objects is not easy to apprehend and I am not sure it works properly.

[AEthelraedUnraed]

13 minutes ago, IckyATLAS said:

The way I have used these choices to improve and avoid time dilation:

 

1) I spawn/delete "static" (that will not move) entities for which block version do not exist and this is typically ships and a certain number of plane models like the B25, C47 and some others, or that the static block version does not have the right skin typically US, RAF instead of USSR. It is unfortunate that this does not apply to block and ground objects because it would help a lot to reduce the quantity of items in memory at one given time for large maps like Kuban (The best map so far on my humble and personal opinion). 

 

2) For dynamic objects I use activate and deactivate. It is important because to avoid time dilation (due to the use of too much CPU resources) you need to keep visible and active what is in sphere of influence of the player. He may leave things out of his  zone of influence which then become deactivated, that means their data is not lost, and if the player comes back all can continue again as if it did not leave. And this works well for planes, ships, trains and vehicles (all including artillery). Sometimes depending on the scenario you may have to keep active distant entities but still it is very limited cases and in general good design and use of the editor can allow us to simulate the activity and avoid it to the maximum, but as usual they may be exceptions.

 

3) I use the Proximity Trigger when the two objects are dynamic and moving. But when one object is fixed then usually Check Zone (which uses less resources) centered on the static object is the best way to go, and do not forget to use the right shape Sphere or Cylinder and also that the center of the sphere in space or the bottom of the cylinder can be set at a given height. This gives you a lot of flexibility. There are exceptions again where Proximity has to be used if you really need to have a precise straight line distance between a static and one dynamic object. The Proximity trigger with multiple dynamic objects is not easy to apprehend and I am not sure it works properly.

About each of your points I've got a small question that I hope you can clarify

 

1) Any particular reason why you use spawn/delete instead of activate/deactivate?

 

2) Do you happen to know if the current action is stored as well when (de)activating objects? Meaning if I trigger e.g. an Attack Ground MCU object-linked to artillery and I deactivate and activate the artillery, will it still fire? Or do I need to re-trigger the command?

 

3) "the bottom of the cylinder can be set at a given height" - wait, do I understand it correctly and will a Check Zone in cylinder mode not trigger if you enter the cylinder below this height? That would be great, I now use very large spheres if I want to check the altitude of an aircraft.

[Jaegermeister]

2 hours ago, AEthelraedUnraed said:

About each of your points I've got a small question that I hope you can clarify

 

1) Any particular reason why you use spawn/delete instead of activate/deactivate?

 

2) Do you happen to know if the current action is stored as well when (de)activating objects? Meaning if I trigger e.g. an Attack Ground MCU object-linked to artillery and I deactivate and activate the artillery, will it still fire? Or do I need to re-trigger the command?

 

3) "the bottom of the cylinder can be set at a given height" - wait, do I understand it correctly and will a Check Zone in cylinder mode not trigger if you enter the cylinder below this height? That would be great, I now use very large spheres if I want to check the altitude of an aircraft.

 

I'm not IckyAtlas, but I can clarify those points from my perspective, as I have come to almost the same conclusions independently.

 

1) It was discussed above that spawning instead of activating/deactivating with all else equal saves resources, as you delete the entity instead of saving its current state.

 

2) If your reactivation logic includes triggering a force complete and an attack area MCU, that's not a concern. It should all be the same every time it activates.

 

3) That is not correct. You cannot fly under a cylinder zone that I am aware of. It extends from ground level up no matter what level you place it at, unless there is a setting I am not aware of.

 

 

Edited July 19, 2021 by Jaegermeister

[AEthelraedUnraed]

25 minutes ago, Jaegermeister said:

I'm not IckyAtlas, but I can clarify those points from my perspective, as I have come to almost the same conclusions independently.

 

1) It was discussed above that spawning instead of activating/deactivating with all else equal saves resources, as you delete the entity instead of saving its current state.

 

2) If your reactivation logic includes triggering a force complete and an attack area MCU, that's not a concern. It should all be the same every time it activates.

 

3) That is not correct. You cannot fly under a cylinder zone that I am aware of. It extends from ground level up no matter what level you place it at, unless there is a setting I am not aware of.

1) Yes, I know, I was part of that discussion It was still somewhat unclear though if and how large a difference there really is so I thought IckyAtlas might shed some additional light on it.

2) I know it'll definitely work with more complicated reactivation logic, but I was wondering if a simple activate/deactivate would be enough, rather than additional logic to determine which additional MCU(s) to trigger.

3) That's what I thought. It is what IckyAtlas seems to imply however.

[Jaegermeister]

1 hour ago, AEthelraedUnraed said:

2) I know it'll definitely work with more complicated reactivation logic, but I was wondering if a simple activate/deactivate would be enough, rather than additional logic to determine which additional MCU(s) to trigger.

 

Gotcha. Check your PMs

[IckyATLAS]

This is what stands in Jim's manual:

 

Zone Type
The shape of the trigger zone
The bottom of the cylinder shape and the center of the sphere shape are located
at the altitude and position of the check zone icon. For example, for an icon at
ground level, the cylinder extends upwards only and the sphere is half under
ground and half above ground.

 

This implies as I mentioned that you can fly under the cylinder but not above.

For the sphere you can fly all around it.

 

I have tested the sphere but not the cylinder. I suppose it works.

I just tested the Cylinder and it does not seem to work. I put the Icon at 2000 mt and flew under it at 500mt and the trigger fires.

It seems the manual is not correct or I am missing something.

[Jaegermeister]

31 minutes ago, IckyATLAS said:

This is what stands in Jim's manual:

 

Zone Type
The shape of the trigger zone
The bottom of the cylinder shape and the center of the sphere shape are located
at the altitude and position of the check zone icon. For example, for an icon at
ground level, the cylinder extends upwards only and the sphere is half under
ground and half above ground.

 

This implies as I mentioned that you can fly under the cylinder but not above.

For the sphere you can fly all around it.

 

I have tested the sphere but not the cylinder. I suppose it works.

I just tested the Cylinder and it does not seem to work. I put the Icon at 2000 mt and flew under it at 500mt and the trigger fires.

It seems the manual is not correct or I am missing something.

 

@JimTM, I have also tested the cylinder zone, and the zone in meters setting appears to only affect the radius of the trigger. It starts at ground level and extends upwards indefinitely as far as I can tell. Also as you have mentioned, once a vehicle is activated and then deactivated once, the activation radius appears to change and coincide with the deactivation radius. I might test that some more to confirm.

[JimTM]

46 minutes ago, Jaegermeister said:

 

@JimTM, I have also tested the cylinder zone, and the zone in meters setting appears to only affect the radius of the trigger. It starts at ground level and extends upwards indefinitely as far as I can tell. Also as you have mentioned, once a vehicle is activated and then deactivated once, the activation radius appears to change and coincide with the deactivation radius. I might test that some more to confirm.

 

There are features described in the manual that have either been changed or have stopped working as intended (or perhaps never worked that way to begin with). Sorry, I'm not actively maintaining the manual for various real-life reasons. I'll try to help where I can, but I'm not current on the detailed behaviors of all mission elements.

[IckyATLAS]

It would have been a very cool feature because you could organize the airspace in layers and detect when planes are in certain layers.

Doing it with spheres is too cumbersome. Definitively devs should arrange that. I will post it as a bug.

[Gambit21]

Just now, IckyATLAS said:

It would have been a very cool feature because you could organize the airspace in layers and detect when planes are in certain layers.

Doing it with spheres is too cumbersome. Definitively devs should arrange that. I will post it as a bug.

 

It’s not a bug, it’s just how the cylinders work.

 

DCS zones operate the same way - the difference is we have altitude trigger conditions to work with if we choose, thus adding that functionality to said zone. Also polygon/square/rectangle zones - can you imagine?  

 

 

 

Sphere’s are a huge limitation no doubt.

[IckyATLAS]

1 minute ago, Gambit21 said:

 

It’s not a bug, it’s just how the cylinders work.

 

DCS zones operate the same way - the difference is we have altitude trigger conditions to work with if we choose, thus adding that functionality to said zone. Also polygon/square/rectangle zones - can you imagine?  

 

 

You mean that you have altitude triggers in DCS. We don't have that in IL2 right?

[Gambit21]

7 minutes ago, IckyATLAS said:

You mean that you have altitude triggers in DCS. We don't have that in IL2 right?

 

Yes...and no.

 

[Jaegermeister]

52 minutes ago, JimTM said:

 

There are features described in the manual that have either been changed or have stopped working as intended (or perhaps never worked that way to begin with). Sorry, I'm not actively maintaining the manual for various real-life reasons. I'll try to help where I can, but I'm not current on the detailed behaviors of all mission elements.

 

Yes, many things continue to change. Posting those things may help others down the road, but I can relate to having other priorities.

[IckyATLAS]

16 hours ago, Gambit21 said:

 

Yes...and no.

 

You have excited my interest here. How would you do the altitude trigger in IL2. I hope it is not a trade secret ? 

I need this in one of my missions and did not find yet a proper solution. ?

 

[Gambit21]

2 minutes ago, IckyATLAS said:

You have excited my interest here. How would you do the altitude trigger in IL2. I hope it is not a trade secret ? 

I need this in one of my missions and did not find yet a proper solution. ?

 

 

Look at your 2,questions and my 2 answers again.

 

No alt trigger in IL2.

 

[IckyATLAS]

3 minutes ago, Gambit21 said:

 

Look at your 2,questions and my 2 answers again.

 

No alt trigger in IL2.

 

My error, I took the yes and no as a expression and not as two answers in order. 

Okay I need to find a way to simulate the same effect. ?

[Gambit21]

I used overlapping spheres, very large ones to create the German radar...above 500’ you run the risk of being detected. 

 

It’s not perfect because the bottom of the spheres of course, but close enough. There is no way to get exactly the same effect of the alt triggers in DCS unfortunately.