iskindof [SOLVED] How to know if the object is a trigger or a visible object that can be destroyed?

[thy_ 164]

Are there smarter ways to know if my object is a trigger OR a visible object that can be killed/destroyed? 

 

My current solution looks not fancy at all, but works:

// If the object is a trigger, when triggerActivation command is used, it returns this array: [by, type, repeating]

if ( count (triggerActivation _myObject) == 3 ) then {
	
    systemChat "The obj is a trigger!";

} else {
    
    // If the object is a unit or a building or vehicle, triggerActivation command will return an empty array: []
    systemChat "The obj is a visible object that can be destroyed or killed!";
  
};

 

Wiki of triggerActivation.

Wiki of count.

[Harzach 2517]

if (typeOf _myObject == "EmptyDetector) then { <code> };

Though I'm not sure either method will sufficiently determine if the object is destroyable.

[thy_ 164]

Hey, @Harzach

 

// Context _myObject is a trigger dropped on Eden:

systemChat str (typeOf _myObject); // returns "EmptyDetectorAreaR50"

 

Will triggers be always "EmptyDetectorAreaR50" or are there other classname variations for triggers (different shapes, sizes, settings...)?

 

(I'm testing right now...)

[Harzach 2517]

Pretty sure a trigger will always return as an "empty detector" - I guess it also returns basic area info too? I don't remember that being a thing, but as always, see my signature.

 

There is also BIS_fnc_objectType which will specifically return "Trigger."

 

I need to play around with these later tonight.

 

*edit* - yeah, editor-placed triggers come in four classes as seen in the trigger menu:

//Trigger
"EmptyDetector"

//Trigger ( ⌀ 100 m )
"EmptyDetectorAreaR50"

//Trigger ( ⌀ 500 m )
"EmptyDetectorAreaR250"

//Trigger ( 10x10x10 m )
"EmptyDetectorArea10x10"

 

 

 

[pierremgi 4886]

7 hours ago, thy_ said:

Are there smarter ways to know if my object is a trigger OR a visible object that can be killed/destroyed? 

 

 

Yes, "emptyDetector" is the kind of all triggers, and triggers only...  and it's used in  allMissionObjects for example. See also allObjects as reminder for a recent command.

But the question is: why do you need to know if _myObject is a trigger?   It comes from your code, no? which context?

 

[thy_ 164]

@Harzach and @pierremgi

 

My go with BIS_fnc_objectType didn't work well:

_triggers = [trg_1, trg_2, ...];  // it's composed ONLY by varnamed triggers on the map.
_targets = [tgt_1, tgt_2, ...];  // it's composed by many varnamed objects on the map that can be killed or destroyed.

// selecting just trigger_1:
if ( ((_triggers # 0) call BIS_fnc_objectType # 1) == "Trigger" ) then {  // <<----- Unfortunately, it returns "UnknownObject" 

    systemChat "It's a trigger for sure!";
    //<Code for New AI Spawn by Trigger Activation Method>

} else {
  
	systemChat "It's a soldier or building, basically!";
    //<Code for New AI Spawn by Target Elimination Method>

};

 

 

For now, I am using this format ( it's working)

// <code>

// Selecting just trigger_1:
if ( typeOf (_spawnDelayCond # 0) in ["EmptyDetector", "EmptyDetectorAreaR50", "EmptyDetectorAreaR250", "EmptyDetectorArea10x10"] ) then { 
  
    // <code>
  
} else {

    // <code>
  
};

 

[mrcurry 505]

Editor placed triggers inherit from EmptyDetector. Ofc this assumes _trigger is an object, passing something else will throw an error

Use isKindOf:

 

if ( _trigger isKindOf "EmptyDetector" ) then

{

    //trigger-Stuff

}

else

{

    // not-trigger-Stuff

}

[thy_ 164]

6 minutes ago, mrcurry said:

Editor placed triggers inherit from EmptyDetector.

Use isKindOf:

 

i swear, I was coming here to say the same! hahaha! Thanks, ma man!

[Harzach 2517]

As @pierremgi suggests, telling us what the point of this is might help us to help you.

[thy_ 164]

13 hours ago, pierremgi said:

But the question is: why do you need to know if _myObject is a trigger?   It comes from your code, no? which context?

 

@Harzach I am developing a new feature for the CSWR Script where it will be possible to SPAWN new AIs when one or more triggers are activated in-game. Also, the feature will bring another method to SPAWN new AIs through target elimination. That's why I need that snippet.

[pierremgi 4886]

Not sure I understand.  I think the scenarios have triggers (all of them "emptyDetector", even if zeroed area) but some of them are made for spawning, other ones for setting tasks, or triggering codes (non spawning AIs)... So,... ? I'm afraid I'm still wondering why you need to sort triggers and objects.

[mrcurry 505]

1 hour ago, pierremgi said:

Not sure I understand.  I think the scenarios have triggers (all of them "emptyDetector", even if zeroed area) but some of them are made for spawning, other ones for setting tasks, or triggering codes (non spawning AIs)... So,... ? I'm afraid I'm still wondering why you need to sort triggers and objects.

 

Just off the top of my head: 

• If you're working off an existing script (that you don't want to change) and a combined list is all you have access to.
• If you using something like nearObjects to fetch and want to do different operations on triggers and other objects.

 

If all you are doing is both combining and filtering then maybe rethinking the design could be beneficial to save on perf, but sometimes you just gotta work with what you got.