Jump to content

dwringer

Member
  • Content Count

    368
  • Joined

  • Last visited

  • Medals

Posts posted by dwringer


  1. 17 minutes ago, sarogahtyp said:

     

    
    ( _previousDamage + ( _newDamage min 2 ) * 0.7 )

     

    with ur solution it is not possible to die with one damage event if u had no damage before.


    I see what you mean but, for that example, what I was saying is that it would be equivalent to
     

    ( _previousDamage + (( _newDamage * 0.7 ) min 1.4 ))

     

    Just two different ways of writing the same thing. But all have their uses, for sure.

    • Like 1

  2. 6 hours ago, sarogahtyp said:

     

    you could also use this to cap those deadly damage to 1 (or whatever u like) and reduce by 30% afterwards:

     

    
    ( _previousDamage + ( _newDamage min 1 ) * 0.7 )

     

    Since you're reducing it anyway there's no real difference between that and (_previousDamage + ((_newDamage * 0.7) min 0.7)), but in the latter case it's more clear at a glance (IMHO) what the final damage cap is.  I suppose it's just a stylistic choice more than anything.


  3. On 4/7/2022 at 12:01 PM, froggyluv said:

     I think to fully demonstrate a superior AI positional fighting script -it needs to show how a 1vs 1  -the newer AI wins out well over 50% of the time.


    Okay, I said I wasn't trying for that, but I couldn't say no to a challenge 😄. Now I can say I have an example mission which (might) satisfy that criterion.  At least in the few tests I've done, the ambushers wins a majority of the time.

     

    I added some improvements to the VehicleTargets class, so now it makes the LOS requirements mandatory before spawning vehicles, and it sorts the positions with a weighted average calculation similar to those used with selectBestPlaces

    The result of those efforts is demonstrated by this mission, in which a convoy of 4 BLUFOR tanks drives along a road and is ambushed by 4 OPFOR tanks which are placed by a genetic algorithm.


    Since Arma's tank AI is insane and will choose to turn its back to enemy tanks in response to a threat, I disabled the OPFOR's ability to move, and used TOV_fnc_SimpleConvoy (from https://forums.bohemia.net/forums/topic/226608-simple-convoy-script-release/) to drive the BLUFOR tanks down the road.

    Here's an example of one of the ambushes it generated during my tests:

    e0m1uHh.jpg

    After a couple of minutes the remaining two red tanks worked up the courage to move forward, did manage to take out the blue tank in the road, but were promptly destroyed.

    Edit: On starting the mission, pull up the map.  It will take a minute or two for the OPFOR to spawn, but you can watch the positions evolve as orange dots on the map.

    You can get the example mission here:

     

    "Tank Trials" Example Mission: (added 9 April 2022)
    https://github.com/dwringer/ANIMA/releases/tag/EXM-220409-A

     

    • Like 2

  4. I have always thought this should be something easily done in the editor, but sadly you're right that the kind of triggers and extra waypoints it takes become very messy.

    I think the best way to do it instead is using a trigger and/or scripts to add a new waypoint (possibly a new seek & destroy waypoint at their current location, or a place nearby from which they'll be able to engage the spotted enemies) immediately before the one they were going to, and set that as their current waypoint.  Check out the documentation for addWaypoint, setCurrentWaypoint, and currentWaypoint.  You can provide an index to addWaypoint that will place it immediately before the waypoint they were already going to, use currentWaypoint to find out what that waypoint's index is. Unfortunately the whole process may require a bit of trial and error as you get used to the scripting side of it.

     

    Also check out the other pages on waypoints at the wiki.

     

    Sorry, I wish I had a simpler answer but maybe someone else has some ideas.

    • Like 1

  5. 13 minutes ago, dreadedentity said:

    The most I ever do in editor is put down soldiers/vehicles

     

    Tbh, the way Arma is, I don't see much value in hand-crafted stuff that only works in literally 1 place, unless executed better-than-perfectly. I much more prefer to create dynamic systems that work anywhere/a variety of situations

    Couldn't agree more with this, to me the challenge of creating something dynamic that can surprise even the creator is an endless pursuit that puts Arma head and shoulders above anything else.


  6. 31 minutes ago, dreadedentity said:

    a scheduled environment can never "turn into" a scheduled environment 

    I believe you meant to say a scheduled environment can never "turn into" an unscheduled environment.

    The way I'd say it is that "call" will always block until a result is returned (and can't sleep/wait), but if you use "spawn" your code will go off into a new thread where you are free to sleep, wait, "call" other things, whatever.

    One is also free to use "spawn" inside of a "call". But the call will return without any guarantee that the spawned code finished.

    At the end of the day, when you use "call" the return value you get will be the result of the called code.  If you use "spawn" then the return value will be immediate, and it will be a script handle identifying the spawned thread which will go on running in parallel with the code in the context that called it.

    • Like 1
    • Thanks 1

  7. I think this is a really interesting question, bound to get all sorts of different answers from different people.

    For me, the editor has both strengths and weaknesses.  Setting up waypoints in the editor has never felt right to me, because units have so much agency of their own and there are so many subtle aspects of waypoint assignment that by the time you get things working the way they should according to common sense (IMO), you've had to add all kinds of extra code and workarounds to triggers, unit init fields, and waypoint On Act fields. What the editor gets very right, IMO, is the trigger system.  These can be used for all kinds of things, from simple mission init scripts and waypoint switching, to marking out areas and gathering units together to send to script functions.

     

    I really try to make full use of unit inits and triggers to do anything they can be made to do. I like putting the code here because it's easy to see in the editor and doesn't require me to Alt-Tab and navigate through labyrinths of folder structure and page through thousands of lines of code.

     

    When it comes to waypoints, I do use them in the editor because it's a lot easier than scripted solutions, but for complicated scenarios I still prefer to script them. Particularly if I want them to be dynamic in some way. I often use Game Logics to represent points in space to feed into my scripts. But, again, I often put extensive scripting inside triggers and init fields, rather than in separate files.

    All that said, I tend to have a huge library of function-defining scripts that I include with every mission, mostly to give me the ability to write code in the way that's most comfortable to me, with abstractions that are familiar to me. I don't like to define functions inside the editor unless it's a one-off.
     


  8. 8 minutes ago, ins3821 said:

    do output by systemChat, but doesnt skip the "if(_filter == "") exitWith {[]};" code.
    so i confuse.

     

    If the systemChat outputs anything at all, that means _filter is provably not empty.  That means there is absolutely no way that "if(_filter == "") exitWith {[]};" isn't skipped.  _filter is provably not equal to "", and since it's private we know it couldn't have changed.

     

    I guarantee if it printed something from the systemChat, it does skip the "if(_filter == "") exitWith {[]};" code.

     

    I can't see what the issue is because I don't know what the rest of your code looks like.

    • Like 2

  9. 43 minutes ago, ins3821 said:

    code "systemChat" receives variables, but code "if(_filter == "") exitWith {[]};" does not receive variables. this is the point.


    If you see something output by systemchat, then the "if(_filter == "") exitWith {[]};" will be skipped, always.  The systemchat confirms if _filter has a value, while the exitWith line only activates if _filter is empty.

    If this is working in some cases and not others, like if it prints "APC" but doesn't do anything else, it's because VVS_pre_APC doesn't work right.

     

    • Like 1

  10. 1 hour ago, froggyluv said:

    Ok so tried out the Demo a few times -it works but basically anyone can spawn 7 AT vehicles against 1 tank and Auto-win. I think to fully demonstrate a superior AI positional fighting script -it needs to show how a 1vs 1  -the newer AI wins out well over 50% of the time.


    Hmm, I should perhaps not have used "artificial intelligence" as a tag for this because it doesn't affect unit AI in any way, but I still think of it as more of a generalized disembodied AI.  Literally the only thing the VehicleTargets example does is pick places to spawn the vehicles.  There are alternative ways of doing this including selectBestPlaces and silola's amazing DAC functions, but this is just a variation on that which uses a genetic algorithm to try to find the positions by evaluation a series of functions.  You're right that if it can't win over 50% of the time in a 1v1, then it's not "superior", but that's not the goal here.  The goal here is to be "better than randomly placing the tank somewhere in the area" or "better than the result you get using selectBestPlaces".  It would be great to have such good positions as to win in a 1v1 fight, but at this time that's not the intention.

     

    1 hour ago, froggyluv said:

    Now sometimes in this script the AI gets some really ideal level looking AI placements, like just below Blufor sightline where with turrets are aimed and ready to go at the Blufor tank's underbelly -an ideal ambush placement. But again, are these Opfor AI basically given forewarning of Blufor's makeup (1 enemy armor)  and intended direction of travel? Will Opfor ideally try to gain a position for a Flanking attack on the Armors weakside? 

     

    The OPFOR are not given any information at all.  The position finding algorithm is given two lists: one list of GameLogics which are placed along the approach BLUFOR will be taking.  Positions are selected to be hidden from these gamelogics if possible.  The second list is a list of GameLogics which are "kill zone" indicators.  Positions are selected to have partial LOS to these logics when possible (and they are turned to face the first one to which they have LOS).

     

    As you say, sometimes the placements are ideal and other times they are imperfect.  One use of this might be to run it a few times, take note of the most effective positions, and then use that knowledge to manually set up mission events.  But I still enjoy the randomness for setting up skirmishes.

    ANIMA is really intended for people to mess around with the genetic algorithm to try creating their own position finding algorithms, or perhaps think up novel uses that I haven't implemented (of which I'm sure there are plenty). Things like the VehicleTargets and Headquarters classes, and other things from the example missions, are just examples of the applications and definitely leave room for improvement.

     

    Final Edit:

    I should say again, though, I appreciate your feedback and taking the time to check it out. You have definitely given me helpful things to think about. The real idea behind the VehicleTargets script was not actually to set up ambushes, but it emerged as a possible use.  As the name hints, it was written to create (empty) vehicles to use as target practice, and I developed it originally on the flat tank ranges of the Hebontes map.

     


  11. Hey all, I'm still far from anything resembling a new release, but I feel the ANIMA engine is in good enough shape where developing applications is an equally worthwhile use of time.

    Here's a new example mission, showing a new application of ANIMA. Instead of creating group waypoints, this time ANIMA's position finding is used to place vehicles in a given trigger area.  The vehicles are placed near cover/concealment, near roads, with LOS to some specified targets, and hidden-from-view with respect to other specified targets.  The file ./classdef/VehicleTargets.hpp contains all the code that implements the new application (relying on the ANIMA system).

    Open the mission in the editor:

    cobzR4d.jpg

    Now launch it, and immediately bring up the map. You'll see some orange dots as the ANIMA algorithm evolves some positions at which to place vehicles:
    kCiqlZD.jpg

    After the evolution process has yielded enough suitable positions, vehicles will be spawned at the found positions.  These vehicles are chosen from those which were placed inside the trigger at mission start.

    Here you can see a few vehicles, all poised for ambush of the position at the intersection just above-right of screen center:
    J30EmtF.jpg

    An example of one such position, with a partially covered LOS to the ambush location:
    Ed1ps1k.jpg

    A BLUFOR tank is approaching, and you should see it enter combat around the time it reaches the targeted intersection.  OPFOR positions are randomized, so it will play out differently each time, but BLUFOR is all but guaranteed to lose due to the ambush (and being significantly outnumbered).

    The example mission can be obtained here:
    https://github.com/dwringer/ANIMA/releases/tag/EXM-220407-A

    EDIT: Last night it was working pretty well, but today when I ran it there always seemed to be a tank that wanted to spontaneously explode itself 200m into the air.  I tried to use BIS_fnc_findSafePosition to avoid this but I'm not sure if it does more good than harm. The algorithm could be tweaked to find better/safer positions but it would get a lot slower.  Anyway, it works a lot better on flatter terrains in that regard.

    • Like 1

  12. 1 hour ago, pierremgi said:

    Stay in 2D 3DEN for that.

    No, I wrote about the volume of your triggers' areas.

    Sorry but I think there's some confusion. I'm not the OP, I was offering the OP a possible explanation for why the last car in his chain isn't being triggered. I should have clarified that's who I was replying to.

    My suggestion is that the second-to-last car is initialized so close to its move waypoint, that as soon as it is ordered to move into its trigger area, the waypoint is marked as complete (before the vehicle enters the trigger area!). Then, the second-to-last car just drives off without ever going into its trigger area to trigger the last car.

     

    I could be wrong, that's just what I would suspect.


  13. Although I can't see the blue/black lines linking the trigger/waypoints of the second to the last car (on the upper side), I assume they are there as you described.  If they are then my thought is that the second to last car is starting so close to its "MOVE" waypoint that as soon as its switched, the "MOVE" is considered complete and thus that car never actually moves through its trigger.  Vehicles don't need to get all the way to their waypoint for it to complete, although they usually will, but if they are close enough when its assigned they never actually move.  In this case I believe the second-to-last car is doing this, just skipping its first MOVE right onto the next one and bypassing the small trigger area.


  14. I'm not certain but I think it might be that your variables _playerJailTimeAdjusted and _playerReleasedEarly are only defined for the first time within the loop.  Outside of the loop they have no meaning, or at least not one that's well-defined. That is, they get set to true but only temporarily, so at the end during the switch they are undefined.

    Try adding:

    private ["_playerJailTimeAdjusted", "_playerReleasedEarly"];

    before the loop, in the outermost script context.  That will declare them in the same context as the switch, so when they get set to true they will stay that way.

    • Like 1

  15. 49 minutes ago, pierremgi said:

    It's interesting that the recommended licenses are a bit more restrictive than the ones a lot of people use.  For example, I release my code under MIT license, which is pretty lenient aside from attribution requirements. I'm not sure if the requirements of the end-user license confer additional restrictions or not, and I'd imagine the specifics are difficult to sort out, differ by country and require a legal expert for real assurances.

    The forum rules here, though, are rather explicit (and really mirror common sense): permission is required to reuse anyone's work for any reason.  This can take the form of a permissive license, or a verbal agreement, or anything else, as long as it would stand up to an independent audit. Without permission, the code should not be used.


  16. Great project here! I have encountered something strange and I wonder if it's a known issue or perhaps I'm missing something.

    EDIT: Sorry, I should have done more testing before posting here: the problem I'm having is not related to this mod. Solved below, I'll leave this here since it's at least tangentially related:

    Spoiler

    When using the FLIR modes from the AC-130 IR Operator's gun sights view, I don't seem to be able to see IR strobes blinking (which I created using createVehicle and the "NVG_TargetC" classname).

    When I leave the gun sights view, and look at the PiP display for the gun sights, I do see the strobes, and they are also visible using the FLIR modes of the Splendid Camera, but no matter what I can't see them using the main gunsight view.

    Any ideas? I would love to get this working even if it is a gimmick from CoD 😄

    EDIT: If anyone comes across this I did find some discussion at https://github.com/acemod/ACE3/issues/3207 about scripting a solution. This is just an issue with how IR beacons in the base game work.

    To save future readers time at that github link, the end result of that discussion turned into:


    I tested using that addon, and it seems to work perfectly.  Instead of using createVehicle to spawn "NVG_TargetC" or one of the other vanilla IR beacon classes, with the addon you can create "MS_Strobe_Ammo_1".

    A function employing that addon to put strobes on units that I wrote (based on code in https://github.com/ussrlongbow/RWT/blob/master/rwt.Altis/RWT/functions/forPlayers/fn_toggleLights.sqf) is:

    
    DWR_fnc_attach_strobe = {
      params ["_unit"];
      private ["_thread"];
      _thread =  _unit spawn {
        private ["_light_obj"];
        sleep (random 2.65);
        while { alive _this } do {
          _light_obj = "MS_Strobe_Ammo_1" createVehicle [0,0,0];
          _light_obj attachTo [_this, [0,-0.03,0.07], "LeftShoulder"];
          sleep 300;
          if (not isNull _light_obj) then { deleteVehicle _light_obj };
        };
     };
    };

    Call it with:  [_unitToAttachTo] call DWR_fnc_attach_strobe;

    I use it in friendly group init fields as:

    
    _thread = (units this) spawn {
      waitUntil { not isNil "DWR_fnc_attach_strobe" };
      { [_x] call DWR_fnc_attach_strobe } forEach _this;
    }

    The sleeps aren't really ideal but I don't know how long the effect of the addon beacons is. The 300 can probably be much longer (author claims 5h).  If you want the beacons to be (slightly) more synchronized just remove the "sleep (random 2.65)".

     


  17. Vybor Airbase: Stop the invasion!
    Y1wCqX6.jpg

    SITUATION
    In a surprise attack, Russian forces from the northeast have captured the Pobeda dam and are expected to launch a combined assault on Vybor airbase imminently.

    What they don't know is that it wasn't actually a surprise, and in preparation we've received a large shipment of AA and AT missiles along with a state-of-the-art backpack-sized UAV control terminal from the CIA (who were also kind enough to grant us the use of an MQ-9 Reaper currently flying in from the south).

    An airborne platoon will also be arriving by Ghost Hawk to reinforce, but they are still a few minutes out.

    MISSION
    It's imperative that we knock out the incoming armor and clear the skies before our reinforcements arrive.

    Your task is to take control of the MQ-9 Reaper and ensure these goals are accomplished.


    EXECUTION

    Activate your UAV terminal and take out the Russian armor ASAP. There are some launchers beside you that can also be used to take out enemy aircraft and vehicles.


    This mission was created with the ANIMA library. I created a development overview guide to go along with an early WIP version of this mission. In it, I've tried to explain every aspect of how the triggers are used along with ANIMA, but it's still intended as a companion to actually looking at the example mission in the editor (which can be found on the ANIMA main thread).


    DOWNLOAD

    The mission itself can be downloaded by subscribing on the Steam workshop:
    https://steamcommunity.com/sharedfiles/filedetails/?id=2785257319

    • Like 1

  18.  

    4 hours ago, pierremgi said:

    You should say what is your final goal. A variable name is not a class (a class of what?) To do what?

     

    38 minutes ago, pierremgi said:

    I don't know if "Assault1" is a workable class (not in vanilla) but perhaps you created it for specific units. (I doubt)



    The OP is using the word "class" in the abstract sense, defining an ad-hoc "unit class" entirely through SQF and then calling the appropriate "methods" based on that.

     

    I wrote an SQF library to do this a few years ago but it's showing its age because SQF didn't have hashmaps back then.  I use the technique in all my scripts, though.

    Sorry I don't have just the class code as an up-to-date release somewhere and it's probably a lot more complicated than this particular scenario, anyway.

    • Like 1

  19. Please take a look at the wiki pages for CfgSounds and CfgSFX that I linked.  The page for CfgSFX clearly answers your question under the heading "Class Structure".  

     

    I'm afraid that you've got sections of one mixed in with sections of another - the syntaxes are different, you can't mix them.

    • Like 1

  20. 1 hour ago, Quack O'Neill said:

    whats the best way to trigger a CfgSfx sound ? cause theres no examples on the wiki

    playSound stEveLoop; 
    playSound3D stEveLoop;
    stEve Say 3D stEveLoop; 

     

    According to the Wiki entry for CfgSFX, these are played "either directly with setSoundEffect command or indirectly with createSoundSource command".

     

    But in your example, stEveLoop is what you defined in CfgSounds, and stEveLoop1 is what you configured with CfgSFX.

     

    I believe as for your CfgSounds entries, these are done with say3D, which has a variety of syntaxes but simplest is

    speakerName say3D stEveLoop;

    EDIT: Sorry I hadn't followed closely enough, so I see that the CfgSounds entries are invalid and this won't work.

    • Like 1

  21. ANIMA - Vybor Airbase example mission
    YT16Cyn.jpg


    SITUATION
    In a surprise attack, Russian forces from the northeast have captured the Pobeda dam and are expected to launch a combined assault on Vybor airbase imminently.

    What they don't know is that it wasn't actually a surprise, and in preparation we've received a large shipment of AA and AT missiles along with a state-of-the-art backpack-sized UAV control terminal from the CIA (who were also kind enough to grant us the use of an MQ-9 Reaper currently flying in from the south).

    An airborne platoon will also be arriving by Ghost Hawk to reinforce, but they are still a few minutes out.

    MISSION
    It's imperative that we knock out the incoming armor and clear the skies before our reinforcements arrive.

    Your task is to take control of the MQ-9 Reaper and ensure these goals are accomplished.


    EXECUTION

    Activate your UAV terminal and take out the Russian armor ASAP. There are some launchers beside you that can also be used to take out enemy aircraft and vehicles.


    I've created a development overview guide to go along with the Vybor Airbase example mission, as well as expanded the mission significantly with more units on both sides and a winnable goal (destroy all the enemy armor). After the armor is destroyed, the player should get an action menu option to end the mission within 5-30s (sorry, there's no real notification).  With the guide I've tried to explain every aspect of how the triggers are used along with ANIMA, but it's still intended as a companion to actually looking at the mission in the editor.


    DOWNLOAD LINKS:

    The mission itself can be downloaded from:
    https://github.com/dwringer/ANIMA/releases/tag/WIP-220322-A

     

    Development overview guide written to accompany the mission:

    https://github.com/dwringer/ANIMA/blob/main/ANIMA%20Guide%20-%20VyborAirbase.pdf

    • Like 1

  22. You're too kind... you may notice that the dates in some of the source code files go back to 2016 or even earlier. That's basically because I had only the most rudimentary grasp of the codebase myself, in spite of having written it. I finally decided that it's at least useful enough for throwing together quick editor skirmishes that it would be worth documenting and releasing.

     

    This is in fact something that originated in 2012 for Arma 2, when I would actually spawn soldiers and check their knowsAbout to judge line-of-sight between positions (checkVisibility didn't exist yet and I wasn't trying to use it dynamically in missions). My primary motivation was to be able to quickly figure out where to place waypoints in the 2D editor where the AI would engage each other from a distance (it was hard for me to tell such things just looking at the topographic map).

     

    The automatic waypoint creation code could definitely be better, I think it's overly complicated in some areas and lacking basic functionality in others. As I wrote the documentation and started working on example missions I encountered many bugs, and I expect there are many more I haven't gotten to yet. 

     

    Also, the actual objective functions that I wrote for the genetic algorithm are pretty basic and often not what I'd really consider ideal. Aside from code optimization, I think this is where most of the potential for improved performance lies. I'd love to write a guide on the process of creating and combining these if I get a chance, but to me at the moment it's more of a black art than science.

     

    I do plan to release an overview guide of how I put together the Winter example mission, how triggers and scripts interact, things to watch out for, etc., hopefully in the next day or two.


  23. 53 minutes ago, ducdragger99 said:

    I put down a flagpole and a player in VR.

    I named the flag pole "USFlag1"

    I put in USFlag1 init: this execVM "savetheflag.sqf"


    Just a couple of things to point out here. Calling 'this execVM "savetheflag.sqf"' does two things of note: it provides "this" as the left side argument to "execVM", and it returns a script handle back to the context in which it was called.

    In the flagpole's "init" context, "this" refers to the flagpole itself.  Thus you are providing the flagpole object directly to the script - there's no need to give it a name at all.

     

    The fact that execVM returns a script handle is a problem - an object's init field CANNOT return a value.  So, your call to execVM ends up return a script handle where NOTHING should be returned.

     

    This is fixed easily, just change it to:

    _handle = this execVM "savetheflag.sqf";

    now _handle is asisgned the return value, and the init field code as a whole returns nothing.
     

     

    53 minutes ago, ducdragger99 said:

    in the sqf i put the following:

     

    [

    _USFlag = ["USFlag1"];

     

    _USFlag setFlagTexture "\A3\Data_F\Flags\flag_us_CO.paa";

    _USFlag setFlagAnimationPhase 1.0;

    ];

     

    Well, for one thing, the [ ]; around the outside are unneccessary and incorrect.  [ <stuff>, <stuff>, <...>] is an array declaration, not an SQF statement.  So get rid of those.  The other point to note here is that since we passed the flagpole object directly to the script (with "this" in our execVM call), we don't need to use its name.

     

    Your line:

    _USFlag = ["USFlag1"];

    Is assigning _USFlag with an array, the first element of which is a string.  What we want to do is assign _USFlag with a single object. If you wanted to continue (redundantly) using the flagpole's name, then you would just write that as:

    _USFlag = USFlag1;

    No quotes are used because it's the proper global name of an object.

     

    However, since we passed the flagpole to the script, you can instead do:

    _USFlag = _this;

    In a script call, _this always refers to the entire left-side argument that was used in the original invocation.  Thus, "_this" in the SQF corresponds directly to "this" in our execVM call.

    • Like 1
    • Thanks 1

  24. 2 hours ago, Rook Mk1 said:

    So say if I spawned an opfor unit, and only wanted to make a script  activate if they had a certain name followed by any number. Say badman_1 or badman_25 etc. How would I check for that?

     

    I tried things like if (vehicleVarName _this == "badman_%1") then {code} but it hasn't worked.

     

    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"

    • Like 1
×