RicHornet

First of all, thanks for your reply and heads up! Ok, so the "this" in the condition is redundant, I see. Thanks again for the heads up. That's why I use the {_x isKindOf "plane"} before count thisList >0, so that only aircraft gets into the list that is passed as a parameter to the script. What I want with my example is to create "air exclusion zone" (for aircraft only) if you will. And yes, I tested it and it works just like I want. For instance I tested by sending an enemy wheeled armored vehicle (APC) into the trigger area and just like intended the enemy vehicle wasn't counted/considered and therefore it didn't turn away. But if I change to {_x isKindOf "car"} before count thisList >0 then it gets counted and the vehicle will turn away from the trigger area. For my current situation/scenario, I only expect that a single group of planes (all from the same group) will ever enter the trigger area at one given time. For instance, I don't expect that two (2) different groups of planes will even enter the trigger area at the same or given time for my scenario. However your example made me think about the possibility of multiple groups of enemy aircraft entering the trigger area at the same time and I'll definitely take a look at your examples!

Well, in the meanwhile I found a better solution via a small modification of what I previously did and posted above and which is actually the solution which I was trying to and going after! Basically, this new version doesn't require the Marker at all and works even better since in this example when a group of OPFOR aircraft reaches the "no-go" trigger area then these aircraft will turn 180 degrees away from the trigger area and this relative to the aircraft's approach angle. This brings a huge advantage since the aircraft will always turn 180 degree away from the trigger area independently from where they approach the same area, where in the previous version they didn't (previously, it basically only covered a "one side" approach regarding the trigger area). Anyway, here's the example: Trigger: Define desired area (for example: A: 8000, B: 8000 and Ellipse) Activation: OPFOR Activation Type: Present Repeatable (option ticked) Condition: this and ({_x isKindOf "plane"} count thisList >0) On Activation: nul = [thisList] spawn {_thisList = _this select 0; _eplane = _thisList select 0; _epgrp = group _eplane; lepgrp = leader _epgrp; { _rallyp = _x getPos [2000, (getDir _x)-180]; _x doMove (_rallyp); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _thisList;}; On Deactivation: lepgrp setBehaviourStrong "COMBAT";

Ok, I found a way to implement what I wanted. Probably this isn't the most "elegant" solution but I believe it's quite simple to implement in a mission since it "only" requires one (1) Trigger and one (1) Marker. Basically the Trigger acts both as defining the no-go area and defines the code that forces some type of AIs to avoid the Trigger area. And the Marker serves as a "rallypoint" to where the AIs that shouldn't be allowed to enter the Trigger area will go after entering the same Trigger area. The example below prevents a group of OPFOR fixed-wing aircraft (planes) from entering the trigger area. I implemented this on a mission where I have a BLUFOR Carrier group with ships armed with SAM launchers and whose objective is to prevent the REDFOR from flying near or around the BLUFOR Carrier group ships and therefore ending up being shot down "like flies" (in this case the Trigger area will cover the areas around the Carrier group). Trigger: Define desired area (for example: A: 8000, B: 8000 and Ellipse) Activation: OPFOR Activation Type: Present Repeatable (option ticked) Condition: this and ({_x isKindOf "plane"} count thisList >0) On Activation: nul = [thisList] spawn {_thisList = _this select 0; _eplane = _thisList select 0; _epgrp = group _eplane; lepgrp = leader _epgrp; { _x doMove (getMarkerPos "rpredair"); _x setBehaviourStrong "CARELESS"; _x flyInHeight 50; sleep 1; } forEach _thisList;}; On Deactivation: lepgrp setBehaviourStrong "COMBAT"; Marker: Choose pretended type of marker (for example: "Empty" marker) Give it the variable name of: rpredair And place it in any desired location but of course outside and at least a little bit away from the Trigger area.

First of all thanks for the reply redarmy! Well, the trigger and script that I had in the past didn't envolve any "teleport" and that would be a solution which I would like to avoid. Basically what happened in the trigger and script that I had in the past was that if a certain plane type, let's say for example a "O_Plane_Fighter_02_Stealth_F" (which is the Stealth version of the To-210 Shikra) entered in the trigger area then it would turn back (was forced to do it) in a direction for example 180 degree or so from where it came from when it entered the trigger area. And I remember this was all done and happened naturally, with "naturally" I mean that the aircraft simply turned away and when or if it entered the trigger area again then the same thing would happen. I hope that I've explained myself better this time?

In the past I found a script that forced certain types of AI units to stay away from a trigger area which I implemented in a mission. Unfortunately I lost that mission files (including the script files) and despite my best search attempts, I wasn't able to find that same trigger and script. To be more precise what I would like is to have a trigger area in the map/mission where for example when any Red side aircraft or a certain model/type of aircraft enters this trigger area it is forced to turn away (like 180 degrees or so) and this way such units would avoid the same trigger area. Thanks in advance for any replies.

Thanks for the reply Harzach 👍

Thank you, very, very much! I can't understand why BIS never fixed this bug but at least with your solution I was finally able to watch the "Ensemble's end" and gain the achievement after all these years trying to do it so! Just a small note, the: player setPos[5490,14610]; which gets you close to the meeting point with Keystone sometimes doesn't work. In my case what I did was to jump to the next point (Georgetown - player setPos[5800,10300];) get a boat, meet with Keystone and do what it needs to be done. And then jump back again to: player setPos[5800,10300]; and complete the "mission"

Actually I have the exact same question! For instance, I can't even find the wall gun rack in the editor.

I will definitely take a look at your hint/help. Thanks for your reply NightIntruder.

First of all, thanks for the reply NightIntruder. However, I can't find the cfgActions section in the config.cpp file (and neither in the model.cfg file). Sorry for looking to be such a 'noob' but this is my first real attempt at modeling in ArmA 3 and I'm modeling an aircraft which someone else did/created (with the author's permission of course!) so basically what I'm doing is to improve the model/aircraft and fix existing issues. As such I would ask you if you could help me how or where I should implement that cfgActions section that you mentioned?

Currently I'm modding a plane (F-35C) which basically has a main display (which is basically divided in two "MFD" displays) and a secondary display which is a "MFD" that shows artificial horizon, airspeed and altitude information and everytime the aircraft suffers considerable or severe instrument damage both the primary and secondary displays either "go off" or start flickering. This is OK for the primary display but I would like that the secondary either can't be damaged or at least that would be much more resistant to damage than the primary display. The reason is that the secondary display like in the real aircraft is actually a backup display which should continue to be functional even and after the primary display fails. However I don't have a clue how to do this and again I've been looking at several sources in order to learn how to do this but unfortunately I couldn't find a solution for my 'problem'. As such, I'm asking here for help in order to solve this 'issue'. I would really appreciate any replies and help regarding this. Thanks in advance.

nkenny, First of all thanks for the reply. I'm actually modeling the aircraft (F-35C) which of course is a mod. I mentioned the script example as how I implemented auto-flaps. However and since I'm modeling the aircraft and according to your reply I could implement something thru the mod in order to remove the manual flaps from the Action Menu. But the problem is that I don't have a clue how to do this and therefore I ask you or someone else for help.

Don't get me wrong but what does someone has to do in order to get a reply here? P.S. - I'm posting the above because it's not the first time that I open a thread in this forum and unfortunately don't get any reply here.

Could someone help me on this one, please?

Greetings, Currently I'm modding a plane (F-35C) and recently I implemented (via script) an automatic flaps feature (like in the real aircraft) which automatically sets the flaps depending on the aircraft's speed and whether the engine is on or off, something which seems to be fully functional. This means that the manual 'Flaps Up' and 'Flaps Down' actions are now redundant (and if someone tries to use any of these actions my automatic flaps script will always override) and so and like the subject says, I would like to hide these manual 'Flaps Up' and 'Flaps Down' actions from the action menu. I've been looking at several sources in order to learn how to do this but unfortunately I haven't find a solution for my 'problem'. As such, I'm asking here for help in order to solve this 'issue'. I would really appreciate any replies and help regarding this. Thanks in advance.