dwringer

EDIT: use foley's solution, not mine as mine is very inefficient. I'm leaving it here just as an example. This should be doable, although not particularly efficient, with a loop from 1 to 25 (or whatever the highest possible number would be) which uses compile on strings created with format. Something like: private ["_i", "_matched"]; _i = 1; _matched = false; while { (_i < 26) and (not _matched) } do { private ["_unit"]; _unit = call compile format ["badman_%1", _i]; if ((not isNil "_unit") and (_this == _unit)) then { _matched = true; }; _i = _i + 1; }; _matched Assuming _this represents the unit as in your example, then at the end _matched will be a boolean true or false, thus the snippet can be used in a trigger condition, or at the end you can do "if (_matched) then {<code>}". You can confirm that the snippet works by creating a mission, dropping in a man named badman_12 as the player, then starting it up and pasting the code in the extended debug console replacing "_this" with "player" followed by changing the last line to hint format ["%1", _matched]; which will report "true"

As far as I'm aware, selectBestPlaces will ALWAYS return a list of places, even if the score for "meadow" is extremely low. So I don't believe the problem is there. Also, above, your createMarker code looks alright. So, could you put a hint statement somewhere in the code right before you create the marker? Something like: hint format ["%1", [positionA, positionBravo]]; Then make sure both positionA and positionBravo are returning [<x>, <y>] pairs. If they are then please paste the entire section of your marker creation code because we must be missing something.

Sorry! I checked it out today and it actually returns something different than I thought. The results are an array like [[[x_0, y_0], score_0], [[x_1, y_1], score_1], [[x_2, y_2], score_2]] ... So, to pull the coordinate you want for setMarkerPos, an [x, y] pair, get it like so: myplaces = selectBestPlaces [positionA, 50, "meadow", 1, 5]; positionBravo = (myplaces select 0) select 0; Sorry about the confusion. Basically just drill down an extra "select 0" to get the position out of the place result. EDIT: Something else occurred to me that you might find useful. A quick way to figure out what the return value of something looks like is to put a brief bit of code in the in-game Extended Debug Console that appears from the pause menu, I tested selectBestPlaces with: myPlaces = selectBestPlaces [position player, 50, "meadow", 1, 5]; hint format ["%1", myPlaces]; I do most of my debugging with hint statements either throughout the code or directly from the console like this.

According to this post: The "Area Clear" happens when a group who was set to "AWARE" mode, then entered "COMBAT" automatically, returns to "AWARE". Thus it can be tested by watching "behavior leader <group>" to see it change back from "COMBAT" to "AWARE". I can't say I've tested it myself so ymmv.

I am not in a position to test it at the moment, but it looks like your call to selectBestPlaces is right. myplace=selectBestPlaces[positionA, 50, "meadow", 1, 5]; Assuming positionA is an [x,y,z] position then this should work. The problem I see is that the return value will be an array of positions. Something like [[x_0, y_0, z_0], [x_1, y_1, z_1], [x_2, y_2, z_2], ...]. The problem is that the return value of selectBestPlaces is actually an array like [[[x_0, y_0], score_0], [[x_1, y_1], score_1], [[x_2, y_2], score_2]] ... Thus in your code thex=myplace select 1; they=myplace select 2; positionBravo=[thex,they]; thex gets assigned with [x_1, y_1, z_1] and they gets assigned [x_2, y_2, z_2]. Thus positionBravo is now a list of two positions, [[x_1, y_1, z_1], [x_2, y_2, z_2]]. Instead, just replace those three lines with: EDIT: Sorry, I was mistaken. In that above snippet, positionBravo would end up with a list of two position, score pairs [[[x_1, y_1], score_1], [[x_2, y_2], score_2]]. You can isolate just the first position like so: // positionBravo = myplace select 0; // This won't work, gets a [[x, y], score] pair. positionBravo = (myplace select 0) select 0; Note that we start array selection indexing with 0, not 1. That should get positionBravo assigned to the best "meadow" position found by selectBestPlaces within 50m. As for how those expressions work, think of it like this: There are ten "keywords": forest, trees, meadow, hills, houses, sea, night, rain, windy and deadBody. selectBestPlaces randomly scatters some test positions throughout its search radius. Then, for each position, it would assign each one a score from 0 to 1. Like Position 1: forest 0.0 trees 0.5 meadow 0.2 hills 0.4 houses 0.2 sea 0.0 night 0.0 rain 0.0 windy 0.1 deadBody 0.0 How you compose the expression determines which scores are evaluated, and how the scores are used. So "3*hills + trees" would evaluate the hills and trees scores of each position, and then weight the hills score 3 times as much when sorting the results. The wiki page has a lot more information, features, and examples. Incidentally this kind of thing is also the purpose of the scripts I recently released here as "ANIMA - AI for advanced position analysis using genetic algorithms". With ANIMA you can work "under the hood", so to speak, and rather than giving it a keyword expression to rank positions chosen at random, the algorithm directly takes a list of functions (of a single "game object") that evaluate to each score, and actively evolves them over a number of generations to improve the results. These functions can be written as anything, so you could for instance count LOS to specific units. Unfortunately there's a performance cost for this, and customizing it is more difficult than with selectBestPlaces. It also currently only works in single player. Still if you're interested in such things you might check it out.

I have issued a new release to commemorate the 1-week mark, move some of the fixes and features from the repo into a release (along with the expanded manual), and package a WIP version of an example mission I'm working on. The example mission requires the CUP addons, but I tried to stay away from any DLC content (please let me know if there's anything I missed!). The example mission, which is a small assault on an airfield (rather one-sided in terms of equipment) is much larger in scope than the previous ones and is, at the moment, not much of a mission (no player character is set). However, it should be playable from the perspective of just about any unit (if you start in a helicopter or plane, you're going to have to wait a few minutes for anything to happen). You may note that all waypoints (except those of the airplanes) are generated exclusively by ANIMA's position finding functionality. Occasionally the assaulting force doesn't move up enough at first (eventually they should get orders that are closer), but other times they move in way too recklessly, so it's a difficult balance. Screenshots of the example mission REL-220316-A: https://github.com/dwringer/ANIMA/releases/download/REL-220316-A/ANIMA-220316-A.zip CHANGELOG: - Added sort behavior to fnc_find_positions which can sort the final results by a given function (by default, uses the average across all objective scores) - Added a setting to allow fnc_find_positions to work faster, but less accurately, by allowing undifferentiated results after the target number of generations (a single bin after the nondominated sort, no dominance ranks in the result set) - The behavior of optional parameters for attack_targets and approach_targets methods of Headquarters was fixed - Fixed behavior of wp_config parameter of internal Headquarters method dispatch_transports - Added an optional start_offset parameter for approach/attack_targets which moves the search start location relative to the targets by [x, y, z] - Revised and expanded user manual with section on fnc_find_positions and some classes

I've created a new release of ANIMA, this time with two example missions (and a few bugfixes/feature additions). The new example mission shows off the algorithm's ability to find multiple positions at a time, landing two helicopters at once and issuing move commands to multiple fireteams on each side. CHANGELOG: - Added two parameters to fnc_find_positions: one is a sort-function (or "false") to sort the resulting positions (default sorts by average score). - There are now two example missions. The first one just follows the basic example in the manual, while the second employs a number of functions.

I've updated the example mission so the OPFOR and BLUFOR units will get new orders when they detect one another, so they'll attempt to find positions relative to the detected units rather than the player. So, the engagement should play out a little better and make more sense. I also fixed a couple of minor bugs in the code. The new release is in the main post above. I'm glad you liked the 80's AI lab aesthetic of the manual, lol. Hopefully the optimization code makes some kind of sense, I know how irritating SQF can be to work with in general. EDIT: I've added some sections to the manual to make the code slightly more approachable

Indeed, my scripts don't actually touch the unit AI in any way, just attempt to find favorable terrain at more of a macro scale. It should work fine with any AI mod that still allows groups to eventually follow their assigned waypoints. I've found it is best to let units in Arma discover each other from a distance, as they really do seem to struggle at close range, running right out in the open and even at times ignoring enemies directly in front of them. That said they do a way better job than original Arma 😅 And thank you for the kind words. Getting helicopters to unload in a hot zone without having to hold their hand is probably the number one reason I wrote this system, hehe

Thanks for taking a look! The position that the infantry moves to is only calculated to be within sight of where the player was when the radio was called. The OPFOR is not taken into account - to be honest the OPFOR was just kind of an afterthought to make things play out a bit differently each time. As for the fact that they ended up so far away, I've seen it myself once or twice and it could have a couple of causes. One is if you pause the game while the algorithm is working - unfortunately this seems to lead to unpredictable behavior. The other cause might be if the waypoint finding algorithm couldn't settle on a position in sight of where you were standing that was even close to the one it ultimately chose in terms of nearby objects and vegetation. Unfortunately they do seem to have a small chance of choosing kind of dumb locations sometimes. In a real mission I would re-issue the order every minute or two, or in response to certain conditions, so they wouldn't get stuck somewhere like that for long. I'll definitely put up a better example mission soon that takes all those things into account. The current mission is little more than following the basic example in the manual. Feel free to move the units around in the editor (along with the triggers next to them) and see how the waypoint finding behaves differently. The ultimate goal is for every playthrough to unfold differently, it is a sad artifact of my imperfect code (and limited processing speed) that every once in a while it acts dumb.

PSEUDO-RETITLE OF POST: "Remove Minigun from AH-9" Hey all, I created a script back when I was playing TKOH: Rearmed that would allow me to loadout the light attack helicopter with various different loadouts. I decided to see if it would work just as well in Arma 3 (with adjusted classnames), but have run into a snag. I cannot figure out how to remove the "default" weapons from the Pawnee. I have not done experiments with other vehicles, but the "removeWeapon '...'" command does not seem to work as it did in TKOH. I have also tried removeAllWeapons to no avail - it does not work to remove weapons I have manually added, either. However, removeWeapon does seem to work on weapons that I have added with addWeapon. Here is the code block I am focusing on: _hel setVehicleAmmo 0; _hel addMagazine "24Rnd_missiles"; _hel addMagazine "1000Rnd_65x39_Belt_Yellow"; _hel addMagazine "200Rnd_127x99_mag_Tracer_Red"; _hel addWeapon "LMG_coax"; _hel removeWeapon "M134_minigun"; _hel addWeapon "HMG_01"; _hel selectWeapon "LMG_coax"; It adds the weapons/ammo with no problem, and selects the LMG at mission start, but the minigun is still there (with no ammo) when I cycle through vehicle weapons. Also, if I don't put the selectWeapon command as the very LAST command, it reselects the minigun by default. Even if i do selectWeapon lmg followed by addweapon HMG, the ammo-less minigun will still be selected on startup. So, any clues as to why these features are changed in Arma 3, and any ideas for a workaround? Not game breaking but it is annoying to have an empty weapon there when it's not needed or wanted. Thanks! ADDED: I have done more digging around on the BIS wiki, and apparently while the class info for the AH-9 indeed lists M134_minigun as one of the weapons on this vehicle, the CfgWeapons pages make absolutely no mention of the weapon. It would seem that the M134_minigun is almost "baked in" to the helicopter. Further testing has revealed that I am able to remove the rocket pods, just not the minigun. So, c'est la vie. Probably nothing we can do - but if anyone can show me to be incorrect, I would be very grateful :)

Intro: Hello all! I have been putting this together over the last few days, and have gotten to a point where my desire to add features outweighs my desire to debug/troubleshoot. So, I am releasing what I have as of now in case others may be interested in using it to make missions, or even just to play around with how to make custom dialogs and onscreen resources. I am a complete novice when it comes to those topics, so it is likely some may find serious inadequacies in my code. Nevertheless, it seems to work pretty smoothly now, and I think I've worked out the major performance/initialization hiccups. Features: **This is a purely text-based interactive conversation system, completely independent of the system built into the game. **In interactive mode, the player can be presented with up to three responses, each of which can lead to a new conversation state for the unit (or unit class, represented by a Game Logic). **The responses can also have associated actions, which are just chunks of code that will be compiled and executed at the time of selection (thus, forks in the mission flow can be set up, tasks can be given, etc.). **The system can also work passively, where NPC's provide non-interactive dialog for a specified number of seconds before the frame disappears. This is mainly for visual consistency, as the game currently allows this type of scripting without any real complications anyway. I have included a demo mission, which for simplicity's sake doesn't quite illustrate the full potential of the system. However, it is a bare minimum display of all the different functions involved. Essential things for a mission are: * A trigger, set to activation by Game Logic, with the condition set to (time > 1), and the On Act: field set to "_nil = execVM "dialogEngineStart.sqf";" * Each unit that can be talked to must be initialized with "_nil = this execVM "enableDialog.sqf"" * initDialogs.sqf must be filled with the correct information to set up the NPC's: ** unit setVariable ["dialogState","<start state>"]; ** unit setVariable ["dialogStart","<start state>"]; ** unit setVariable ["dialogName","<display name>"]; ** unit setVariable ["dialogText<state>","<dialog to be spoken>"]; This is extremely basic and incomplete... Look in initDialogs.sqf for examples of what other possibilities exist - I have provided macros to set the text, as well as to set responses and associated actions, and the best way to figure it out is just to see it. This part could probably use some work but it is relatively straightforward. Until such time as I can put together some kind of real documentation, the example mission will have to suffice. And I probably won't do that until I have improved some things. One thing to note is that in the example mission, arrays instead of units are passed into the dialogEnable script. One game logic will be randomly chosen from the array to initialize the unit. The same principle applies to initDialogs.sqf, where the dialogue is passed as an array of strings instead of a single string. This results in a random string being chosen each time for the conversation. It is really a lot simpler than it sounds in practice, it just takes a little playing around with. It is very, VERY fast to add additional NPC's to or otherwise adjust the system. Sample screens (<100kB!): File link: http://www.filedropper.com/converse Feedback/testing is greatly appreciated! Also, if anyone making a valiant effort to check this out finds themselves struggling, I'll be glad to help. As far as I know, the example mission should work out-of-the-box. If you follow the same patterns, you should be able to set up just about anything - the example is as barebones as it gets, so it would probably be fastest just to use it as a template. Thanks!

You haven't given us all of your code. If _group represents the group of hvt then the code would function as you desire. Since you are spawning a group and _group refers to that, of course the waypoints are added to _group. What you probably want is to run that script with _group assigned to "group hvt" and it will add the waypoints you want. Sorry I can't be more explicit without seeing exactly the code you are running and exactly how you are calling it.

An update on the EDEN GUI errors I've been having with the dev branch: With "Small" Interface size and 4k resolution, none of the pull-down menus are functional. They still can have a set value, but the expanding menu never appears so it is impossible to select different options. Pressing alphabet keys will set some of the values inconsistently based on their first letter (?). With the interface set to "Very Small" or "Normal" the pull-down menus function properly with no problems. I have tried this in 32- and 64-bit, with and without mods.

When you have that array of houses, you need to iterate through it to build an average position as a new array. Each position is a 3-element array, so your new array will also be 3-elements: consider each element as its own unique 1-dimensional position (x, y, and z). private ["_meanPosition", "_length", "_component"]; _meanPosition = []; _length = count _findhouses; for "_i" from 0 to 2 do { _component = 0; for "_j" from 0 to (_length - 1) do { _component = _component + (((position (_findhouses select _j)) select _i) / _length); }; _meanPosition pushBack _component; }; This is the same as adding all the x's and dividing by the total, then adding all the y's and dividing by the total, and finally adding all the z's and dividing the total, to yield three position averages (The average 3D position). In this algorithm division is done at each step instead of at the end to avoid accumulating really large sums that could cause problems. Here is a function I have been using, which you can paste in init.sqf or somewhere like that: fnc_vector_mean = { /* Find the mean vector of a list of vectors */ _vectors = _this; private ["_alen", "_component", "_mean"]; _mean = []; _alen = count _vectors; for "_i" from 0 to 2 do { _component = 0; for "_j" from 0 to (_alen - 1) do { _component = _component + (((_vectors select _j) select _i) / _alen); }; _mean pushBack _component; }; _mean }; That is only for 3D vectors, so the name is not very apt, but it would not be complicated to extend it (but you don't need to in this case).

I haven't done extensive testing because although performance seems better in 64-bit, using the dev branch (32- or 64-bit) caused all pulldown menus in the eden editor to stop functioning. Thus it became impossible to set up trigger activations, etc.

Heh, though I am flattered, that is currently somewhat outside of my intended scope with this project. Since all users of this system have to do is drop the source folders into their mission and add a couple of lines to the init.sqf, it should offer almost as smooth an experience as if it were integrated with an addon. Since much of the system's power derives from creating one's own classes, users are expected to dig into their mission folder somewhat anyway, although typically this need not go much farther than simple drag'n'drop. I've been working with this system for the last several days now and can report there will be at least one significant addition to the next release (it is already available on GitHub from the master branch's root): A version of fnc_tell that uses spawn instead of call to execute methods. This returns a handle to the new execution thread and lets much more complicated methods run asynchronously. The new function is called fnc_tells and otherwise works the same way as fnc_tell. This function was created to aid in a new module with which I've been experimenting as a test of the class system's robustness. That new system, composed primarily of classes, can be found on GitHub in the "opti/" folder and provides a basic framework for running multi-objective optimization algorithms. Don't expect high-performance computation here, as not all the systems are well-optimized (or ever going to be extremely fast, honestly). You can, however, expect usable results. More detailed documentation on this is to come later but it could definitely be worth taking a look at. A quick and dirty example is provided that relies on the mkcivs module (also on GitHub) and optimizes positions around the player's group location for partial LOS and nearby civilians in the global array "civArray". That example is illustrated here: [An example mission and more will be coming soon] EDIT: Ugh... starting to see how ArmA can do "interesting" things with its objects. Fixed the Optimizer example - _this inside the spawn was not behaving the same way as the object it was supposed to represent by the end. Not sure why because it seemed to work for the first loop of calls and then return an old version for the last call. Using the actual object name instead fixed the problem in this case. I regret nothing!

SQF Classes for ArmA 3 Edited - release updated with a couple of bugfixes - if you downloaded prior to 6pm GMT on 29 October then please re-download to get the corrected files. "If . . . [the] fact [that brutes abstract not] be made the distinguishing property of that sort of animal, I fear a great many of those that pass for men must be reckoned into their number." -- George Berkeley Many times when scripting in SQF it may occur that implementing object-oriented techniques can simplify or enhance certain abstractions. The technique of using getVariable/setVariable on a unit or gamelogic to store function code or references specific to that unit's situation is a common pattern found in many missions and modules. Here, that idea is taken one step farther: instead of storing functions on game objects, we store an array of class names (representing a chain of inheritance or a mixture of interfaces). Meanwhile, a master Classes array holds a subarray for each defined class, containing a function definition for each class method. With this arrangement and just a handful of primitive functions, an unlimited variety of classes and methods can be declared on-the-fly while a mission is running. Release (.zip): https://github.com/dwringer/a3system/releases/tag/v1.0 Code: http://github.com/dwringer/a3system/tree/master/ClassDemo.Tanoa This is a selection of modules drawn from a larger repository I keep at http://www.github.com/dwringer/a3system/. There, more recent versions of these modules can often be found. I also placed other modules I created over the years, which are of variable quality and may or may not be worth a look. Class layout Lambda Macros Example overview This will demonstrate how to create abstract instances and send messages (method calls) to them. The included example is a mission with four men (crew_1..crew_4) and two vehicles (car_1, car_2). You may easily duplicate it in a different map if you don't have Tanoa available. There is a single Radio Alpha trigger, upon whose activation the following scripts are executed: CG = ["CrewUnitGroup"] call fnc_new; [CG, "assign", crew_1, "driver"] call fnc_tell; [CG, "assign", crew_2, "gunner"] call fnc_tell; [CG, "assign", crew_3, "driver"] call fnc_tell; [CG, "assign", crew_4, "gunner"] call fnc_tell; [CG, "assign", car_1, "vehicle"] call fnc_tell; [CG, "assign", car_2, "vehicle"] call fnc_tell; [CG, "board_instant"] call fnc_tell; Here, fnc_new is how we create a new instance. It accepts the class name and any init parameters appended to it (here there are none). We could also put a Game Logic in the editor instead of using fnc_new, and in its init use the following: _nil = this spawn { waitUntil {not isNil "ClassesInitialized"}; [_this, "CrewUnitGroup"] call fnc_instance; .. rest of code .. }; The method calls are actually made with fnc_tell, which takes as parameters the class instance, method name, and subsequently each method parameter. Thus, all methods to all classes are defined and called using a standardized syntax and set of functions which have been precompiled. Since fnc_instance makes an instance out of an existing object, we can also use it for creating class inheritance. Consider the following: DEFCLASS("MySubClass") ["_self"] DO { [_self, "SuperClass"] call fnc_instance; .. rest of code .. _self } ENDCLASS; Now, MySubClass inherits all the methods from SuperClass. Each game object keeps an ordered list of its class assignments, so if a method is not found on MySubClass it will be looked up on SuperClass. I have provided the macros SUPER and SUPER_ARGS in include\classes.hpp to facilitate subclassing from within classdef header files. If you want to create a subclass method that implements a superclass method under a different name, that can be done by looking up the class alist in the Classes global alist and using the function contained there as a new method. In classdef files, this has a macro called ALIAS(subclass, subclass_method, superclass, superclass_method). Another example Without further ado, the link to the repository containing the above example mission folder and all required modules is: Release (.zip): https://github.com/dwringer/a3system/releases/tag/v1.0 Code: http://github.com/dwringer/a3system/tree/master/ClassDemo.Tanoa Good luck, and if anyone creates some useful classes or a cool class tree, I'd love to hear about it. Even if this just serves as an example of what can be done to (ab)use SQF, I am satisfied. "No point in mentioning these bats, I thought. Poor bastard will see them soon enough." -- Raoul Duke Edited - release updated with a couple of bugfixes - if you downloaded prior to 6pm GMT on 29 October then please redownload to get the corrected files. There were changes made to fnc_tell and fnc_filter related to nil values being passed as parameters. Edited - added another example section

Typically the worst code in the world, called in a spawn context, will not impact your framerate. The best most optimized loop on earth, if "called" directly from a trigger, init.sqf, or initialization, will happily eat all your frames until the game is frozen for 20-30 seconds at a time. Asynchronous contexts are your friend.

That isn't really a complete answer. In general I think you could loop checking nearObjects and applying/removing the disableCollisionWith effect when things came in and out of range, but it might take some fiddling. Saw the above post, I guess that's true, I had assumed the OP misspoke but I think theend3r is right.

Thank you for the advice, and it is an honor to be recognized by such an illustrious forum member. You make the discord sound just so inviting, heh, but I might stick my head in there as I am sure you're right that there is much to gain. I'm not too confident in any of this stuff yet as I'm the only one to my knowledge to be testing it and I never went past trivialities until after I released v1.0 of this class system. I've been trying to break it, though, for the past few days, and surprisingly it has proven robust and a lot faster than I had expected considering the number of function calls going on at times. I share some cynicism about OO too, and there is something to be said for avoiding it, but it is still the right tool for certain jobs and exactly the tool I was wanting in this case. I had checked out a couple of other OO packages in SQF, but didn't see anything as high-level and dynamic (or, some might say, hackish and horrifically unsafe).... This is pretty much an abomination of an homage to Python, mixed with Lisp, slopped together like Christmas dinner leftovers. But as far as I can tell, it works. Thanks again; I still am not committing to anything more than a low profile and a disclaimer that this might not satisfy every use case for now. But, as time permits, I am working on several systems using this class module, and will be sure to post more information as it is available. I also put everything under the MIT license, and it may be painfully obvious that I did not follow the typical community naming convention of prefixing my initials to any function or variable names. That is to emphasize how this is meant to be low-level, experimental, and open to all to make of it what you will. I must leave it at this for now until I get some non-trivial applications going and test things more thoroughly.

Hello, If anyone would like to see a wide assortment of scripts including some helpful functional programming tools and array manipulation utilities, I have assembled several modules with extremely basic documentation at https://github.com/dwringer/a3system You are pretty much on your own with these, especially some of the less documented stuff, but the stuff in "lambda" and "vectools" is pretty well tested so far and helpful in a lot of situations. I would be interested to hear if anyone makes any use of some of this. Best of luck, and let me know if there are any usage questions or problems identified. EDIT 2: There is now a class system included that is superficially similar to Python classes. These can be defined in header files using syntax macros, or created on-the-fly using the right functions. So far there is an ObjectRoot and Dictionary class, but these are more examples than anything. EDIT: Fixed a couple of functions - in particular, fnc_sorted was destroying the original array passed to it. There was also a problem with using negative indexing in fnc_subseq which should be fixed now.

A Tutorial Walkthrough - The Marker Class: In order to demonstrate the power of this Class system, and hopefully make it seem more approachable, I will walk through creation of a Marker class that adds the much-desired (by me, at least) functionality to instantiate a marker once and then have unlimited freedom to manipulate it, hide it, or show it again. Without using a Marker class, it takes several calls and the managing of complicated data structures to accomplish what is done here in just a couple of short lines. The Marker class will inherit from the ObjectRoot class (classdef\ObjectRoot.hpp) that is provided with the class system files. ObjectRoot gives us the ability to send the messages "_getf" <value> and "_setf" <key> <value> [sent with the fnc_tell function] for conveniently managing local instance variables. This walkthrough guides us through the creation of classdef\Marker.hpp, which can be located at https://github.com/dwringer/a3system/blob/master/classdef/Marker.hpp Initialization: Following the BIS Community Wiki documentation for createMarker, we find that the following minimum information is required to make a new marker: name position shape type (if ICON) size (if RECTANGLE, ELLIPSE) We wish to simplify marker creation as much as possible, so here we will no longer take "marker name" from the user as a creation parameter. Instead, we will keep a global variable called MarkerIndex and increment it for a unique value we can append to the name of each new marker. MarkerIndex = 0; Our initialization method for the new Marker class will take the remaining necessary parameters, and we will allow nil to be used in place of "type" or "size" depending on which kind of marker is being made (area or icon). With this, we can create new Marker instances at will with a call like: //mkr = ["Marker", <position>, <shape>, <type>, <size>] call fnc_new; mkr = ["Marker", position player, "ELLIPSE", nil, [10, 10]] call fnc_new; Methods: This marker will still not be visible - all we have done is configure the new instance. We still need a "show" method to reveal the marker on the map. This could be tacked onto the end of our initializer as well, but it needs to exist as a separate method. You can see our show method reads a lot more variables than what we configured in the initializer. This lets us set more than the minimum required for a marker by setting the appropriate instance variables (with "_setf" calls). More on that in a moment. A call to [mkr, "show"] call fnc_tell; will now reveal the marker instance on the map. In order to hide the marker again, we will use another method: "hide". You may note that reconfiguring the marker instance variables using "_setf" will not have any effect on the existing marker on the map. For that reason, we simply create a "redraw" method to call "hide" and "show" in succession whenever the marker is already visible. Finally, we implement trivial methods to set each configuration variable and then call redraw. Using: Combining all of the above together into classdef\Marker.hpp and adding the line #include <classdef\Marker.hpp> to our init.sqf (after including include\classes.hpp) gives us access to the new object interface, and we can use it as one might expect: // Create and show a new marker: mkr = ["Marker", position player, "RECTANGLE", nil, [5, 5]] call fnc_new; [mkr, "show"] call fnc_tell; // Reorient the marker: [mkr, "set_direction", 45] call fnc_tell; // Change marker color: [mkr, "set_color", "ColorGreen"] call fnc_tell; // Change marker size: [mkr, "set_size", [10, 10]] call fnc_tell; // Hide marker again: [mkr, "hide"] call fnc_tell; This is just one simple example of how to use object orientation with the SQF Classes module to facilitate simpler, more powerful options in the editor and during scenario design. Markers were a prime candidate for this technique because of the overhead involved every time a marker is to be created, altered, or destroyed. That overhead can be wrapped up into the class and its methods, and then ignored even as the class can be reused in different projects or even extended via inheritance and subclassing. I hope this may interest you in trying to create your own classes and sharing them with the community, or at least implementing them in your own scenarios to make things easier on yourself! Edited to fix a bug that shows up in certain cases when using nil as a parameter.

In that case they will engage, but continue making their way along the waypoints. You would need to explicitly give them a seek and destroy waypoint to activate when they detected enemies, and then switch them back to their normal waypoints once the enemies are gone. There are a number of ways to do this, but none are that simple. I would say a solution using "Skip Waypoint" triggers (I think that's what they're called... used to be "SWITCH") is probably the simplest. You may have some luck also if you set them to "Open Fire" instead of the default "Open Fire, Keep Formation" (these used to be called "Open Fire, Engage at Will", and "Open Fire", [reversed] which makes things confusing to say the least). You may need to do some testing to determine under what circumstances the units will abandon waypoints to go after enemies. That may suffice instead of using any seek-and-destroy waypoint switching.

I'm not sure, but I tried using it the other day in response to a question I saw on another forum and found it not to work, also. It seemed like it might have possibly done something, but as soon as the units detected enemies they ignored it. Might have been a coincidence, and it never worked at all, but I did not investigate further.