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!

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.

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?

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.

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.

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

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.

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?

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, Lately I've been trying to implement a script to model an Afterburner effect (nothing too fancy) to an aircraft but unfortunately I've been unsuccessful. I tried to search everywhere and I found the following couple pages/scripts: https://forums.bohemia.net/forums/topic/156568-afterburner-particle-flame/?tab=comments#comment-3426005 https://www.armaholic.com/page.php?id=974 But I couldn't make them work. As such, I'm asking here for help. Thanks in advance.

I tried your script (placed the init.sqf and Afterburner.sqf) as you have above but nothing happens (when pressing the LShift key). If you could provide assistance I would appreciate.

Nevermind, I figured out how to solve this.

Greetings, First of all, I want to say that I'm a 'noob' when it comes to modeling objects such as aircraft in ArmA 3 (or any other game for that matter) but recently I decided to learn more about the subject, namely to improve/fix a F-35C model which I enjoy very much (this one: https://steamcommunity.com/workshop/filedetails/?id=1663110214) whose development has been stopped (BTW, I have the permission from the author to continue improving it). So far things have gone much better than I initially hoped for (given my limited experience and knowledge) and so far I managed to solve a considerable number of issues with the mod. And one of the things that I'm working right now is to implement a HSI (Horizontal Situational Indicator) display. For the most part, I successfully implemented it (using the config.cpp code from BIS F/A-181 Black Wasp II) and now I have a working HSI. However this indicator didn't have the 'background' texture (showing the horizon with ground below and sky above) like in the original F/A-181 and so I decided to implement a background texture of my own. Afterwards I did implement one of such texture but this texture doesn't 'move' with the Horizontal Indicator - the texture doesn't bank or pitch like happens with BIS (and other mod) aircraft and now I 'stuck' or more precisely I can't find a way to make my texture move with the Horizontal Indicator and as such I'm here to request help from anyone here. Thanks in advance for any replies. BTW, here are a couple of screenshots showing my currently implemented HSI where you can see that the background texture of my HSI doesn't move with the horizontal indicator like it should: https://drive.google.com/file/d/1k-XjTC8ql1-O1MPPDisXQy5XTybHPz_i/view?usp=sharing https://drive.google.com/file/d/1KQ5XzBJGeLleFg53OhO9JLoqP_1m3QEJ/view?usp=sharing

Greetings, I developed a script which can be called thru the action menu (Addaction command, defined for example in the unit's init field). All of this works perfectly when the script (.sqf file) is located inside the mission folder and called from there. But I would like to be able to call the same script/.sqf file if and when this one is located outside the mission folder, for instance located in or called from the "e:\myarma3scripts\" folder/location or from any other location outside the mission folder for that matter. The purpose/objective for this would be to be able to call the script from a mission being developed in the editor before or without being saved and also (and personally, my main objective/purpose) to be able to add via console a unit that can use my script in any mission where the console is enabled. However, I tried to look everywhere but I couldn't find an answer to my question hence why I decided to ask here. Thanks in advance for any replies.

Ok, I can confirm that it worked perfectly! Thanks again for the help, target_practice! And I also want to thank phronk for his tip about the filePatching parameter which was crucial to solve my problem!

Thanks for the reply target_practice! I will definitely try that.

So this means that if I put the script files inside the ArmA3 folder then it should work?

First of all thanks for the reply (and I also thank Erwin23p's reply). I tried the following: I put my scripts inside a folder called "p_gps" (without the quotes) and this same folder is located inside a folder called "Armascripts" in disk "E:". So I started the game with the filePatching parameter enabled and in my mission and in the unit's init field I placed the following line: contents = loadFile "E:\Armascripts\p_gps\gps.sqf"; but when I load the missions, I get the following error: Script E:\Armascripts\p_gps\gps.sqf not found

I guess you missed the purpose of the discussion above (about HMD aiming the gun). It wasn't actually a request "per se" since someone already asked for this a few days ago, here: http://feedback.rhsmods.org/view.php?id=4479 What was being discussed was the difficulties of accomplishing what was asked above and as such I posted a suggestion that could somehow help modeling/implementing this - by looking at a mod that already implements this.