dwringer

What? The editor won't even allow you to write "this spawn {}" in a trigger activation or init field. You HAVE to assign it to something, '_nil' is a convention because the results are not used in this case. _nil = this spawn {}; is fine, but this spawn {}; won't even let you close the dialog window. EDIT: specifically, the error message is: What I meant was, the game will not allow you to return a variable from whatever you insert into Init. It expects "Nothing" [which is precisely what an assignment (to _nil or anything else) returns] EDIT 2: I can see how in some contexts it may be desirable to wait for the script to finish (or check its value) during init. In that case, you're right, assignment to _nil is the wrong pattern. It is perfectly fine in most cases, though, and certainly better than "nil =" or "0 =" which are plainly invalid. EDIT 3: Perhaps what we should start doing is "_dontCare =" or "_handle ="... I did that for a while, but honestly, "_nil =" is just a lot shorter, clearer than "_dc =", and works just as well for something that's never going to be seen again.

In that case you can just try: _nil = [ [GKB_aa1, GKB_aa2, GKB_aa3], [[0, 4500], [7000, 8000], [1000, 500]], 20 + random 100, 0.1, {alive GKB_radar}] spawn GKB_fnc_randomAAFire; If you add "_nil =" at the beginning it won't be trying to return anything to the game where it isn't supposed to. (of course, you will need to replace the parameters with things that make sense in your case... I presume you don't have any of the units GKB_aa1.. or GKB_radar unless you named them that to work with this specifically)

You may be right... since this is a function it must be compiled before you can say "spawn GKB_fnc_randomAAFire" as in the example. <EDIT: try it with no ".sqf" here> Assuming that example syntax is correct, try adding this to the file "init.sqf" in your mission directory: GKB_fnc_randomAAFire = compile preprocessfile "path\to\the\script.sqf"; Where, of course, you insert the actual relative path from your mission directory. I.e if it isn't in a subfolder, just write "scriptname.sqf" (whatever the filename is). EDIT: I'm not sure that example syntax IS correct; try dropping the ".sqf" when you actually spawn it. EDIT 2: backslashes

I'm afraid I don't fully understand the reference, although looking through the functions I have found a couple that would have made string manipulation slightly simpler and probably more efficient. I must caution that this system is not designed for speed, but simply for power of abstraction. The chaining of functions can get very deep and is bound to cause problems if abused or used heavily. I noted that there is a way to register functions in the game's function library, which I have not done as it is all new to me (I have not been active in the community for a while). I welcome any specific suggestions on how to handle improvements and optimizations like that, but I am out-of-touch when it comes to standard practices with sqf. This is also designed and tested only for single-player; if anyone with multiplayer coding experience has advice or concerns I'd be grateful. I'm not entirely sure how the scripts would interact in such an environment. Finally, I have added to the class hierarchy including a unit group abstraction that offers a center_pos method (giving the mean position of all units in the group instance). I will be continuing to work on fleshing out classes but the things in the repository are bound to fluctuate wildly in quality as I continue updating and moving things around. [Edited for clarity] If you are wondering why fnc_sorted would be more useful than the BI sort functions, it is because you can use fnc_lambda inline to create a custom comparison function and pass it , and an array of any supporting variables, to the sort and get any ordering you can define. In any case, I have just finished a couple of methods on a CrewUnitGroup class. This class keeps unit arrays for various roles (driver, gunner, cargo), and vehicles themselves. There is a simple "assign" method (remove has not been properly overloaded yet so that functionality is not present) which takes a unit and role and adds it to the corresponding array. The other method is "board_instant", which loops through vehicles dynamically assigning drivers and gunners, then filling in cargo as space allows. Hopefully this is a better example of what is possible, and maybe even conceivably useful. [Edited again for update]

I have always wondered why they didn't add these features to SQF, and presumed it is because if they are used excessively it can be grossly inefficient. I remember hearing that they were looking into Java or something, but that somehow doesn't sound very appealing. I haven't implemented any complex systems with these classes yet, but the functional tools are already proving their worth in my missions and experiments. The class system will surely prove invaluable (and has already been helpful) in organizing mission components, inheritance trees among abstract concepts, etc. Anyway, just wanted to let everyone know I have massively upgraded the documentations (trying to find errors - especially in the dependency listings - is something I don't find to be a very rewarding use of time). They should be usable, which is all that I want from them, but if you have trouble getting a module to work from the docs just try adding the whole repo to your mission first. That way you can make sure to have any unlisted dependencies. The class system has been tested and proven effective with the ObjectRoot and Dictionary classes, which show off the abstraction and inheritance capabilities avaialble. Some other test/example classes of low quality are also included (these are in the classdef/ folder).

I am probably going to work some parts of this into their own independent modules (they can already be used that way but perhaps the codebase isn't too approachable). But, I wanted to announce a couple of things here: If anyone checked out this code after my first post you may have found some show stopping bugs. I have been working extensively on this and everything should be working as intended as of now. Most importantly: dynamic classes! I've seen a few other class implementations in sqf out there, but none of them were much like this - although I'm sure it is out there somewhere :). I urge you all to check out the idea and share what you think. Here's an example class definition file to hack into objects' native dictionary capabilities: https://github.com/dwringer/a3system/blob/master/classdef/Dictionary.hpp

Hello everyone. I am hoping someone around here with some experience might have some insights into the following problem: If I create a preprocessor macro in a script to be executed like: "call compile preprocessfile 'myscript.sqf';" as follows: #define MACRONAME(ARG1,ARG2,ARG3) setVariable [format ["foo%1%2", ARG1, ARG2], ARG3]; Then call it with: dude MACRONAME("Bar","Baz","SomeString") It works more or less okay, translating (after preprocessing and the "format" call) into: dude setVariable ["fooBarBaz", "SomeString"]; BUT: The "SomeString" has had all commas removed from it, i.e.: dude MACRONAME("Bar","Baz","SomeString, WithCommas") -> dude setVariable ["fooBarBaz", "SomeString WithCommas"]; The macro breaks completely if I try something like this: dude MACRONAME("Bar","Baz",["AnArray","OfStuff"]) Clearly, from the errors (and the error messages which I cannot at the moment reproduce) the macros fail to support arguments containing commas. So my question is this: Is there a way around this, so we CAN use commas inside data representing macro arguments?

Although that does answer a question I had, I think he was referring to the fact that your video is private, and thus we are not able to view it at all :)

Sorry, yeah; that I can definitely agree with.. but I can also guarantee they do use the stances now and then. I have a half-assed script that positions units in "advantageous" overwatch positions and from there, occasionally I have seen them use the animations. But, these are locations that were tailored to their AI already, so the results don't replicate well on random positions they tend to end up in :(

The way I think of it with imaging technology is, look at the newest version of Adobe Photoshop, then apply a little imagination. Remember, a computer beat the crap out of humans on Jeopardy , years ago. :P

The AI has been able to effectively use and shoot from cover since Arma 2, it doesn't require any special scripting; just for their behavior to be set to "Combat" (which happens automatically even when they're in "Aware" when they come under effective fire)

Oh man, freaking sweet. Finally we are starting to realize new paradigms thanks to A3 and awesome stuff like this!

Sounds to me like "ff1grp" is not defined. Check your .rpt file and see if you are getting any specific error messages. I would find the leader of your ff1grp, if its in the editor, and make sure his init says "ff1grp = group this", and then (as Na_Palm suggests) put a waituntil{time>0} or something into the above script to make sure the group has initialized before this script gets called. If this is running inside a trigger you can just make time>0 part of its condition. Forgive me if time>0 isn't the best way (or 100% correct way) to do this ... hopefully this might help

I am wondering if you could use a combination of doStop, setBehaviour, and setUnitPos to get them to stay grouped and stand apart from one another (adjusting setUnitPos with a trigger for once they come into contact with an enemy)? I will check it out today if I get a chance and get back to you.

Then instead of defining the stuff as a dialog, it needs to be defined as a display under the RscTitles class. I have only played around a little bit with it, but I'll paste the relevant sections of my definitions below that hopefully illustrate the differences. That was how to define a display resource, such as a HUD. Below is a dialog with essentially the same elements in it: There's actually a much more detailed post on these forums about how to use #ifdef and some other things to use the same source files to define something as both a dialog and a display, but it's beyond the scope of this thread and I don't remember where it is. :) Anyway, where you pull up a dialog with: _handle = createDialog "dialogName"; and end it with closeDialog 0; you would pull up the display resource with: _handle = 0 cutRsc ["dialogName","PLAIN"]; and end it with 0 cutRsc ["Default","PLAIN"]; (assuming you created a default display as seen above)

For sure I have voted this up, and hopefully this gets some more attention ;) TBH this would open up so many possibilities - imagine a multiplayer game mode based on the movie Predator :D But.. considering how many Sam Fisher type missions Arma games have always had, it would be nice to have at least SOME of the same equipment he has, and not just feel like I am just waiting to get lucky with the timing and my choice of Save Games ;)

Well, the condition to change it from green to red was, I thought, for any OPFOR at all to be present, regardless of BLUFOR, so that condition would need slightly adjusted ;) Anyway, the thing you said about making one trigger reset another is exactly why I was suggesting to check if the marker had already changed color in the trigger conditions. Basically triggers are either one-off, or infinitely repeatable (according to their standard behavior, anyway). Thus we would use infinitely repeatable triggers, but be more selective about what it takes to trigger them :) Sorry it's really late and I don't have much time to look over this but if I get a chance tomorrow I will return.

In general terms, the solution would be to add a second trigger. Looking at the one there, it is set to fire when there are no "resistance" troops (independent, not opfor), and at least one "west" troop (now also known as blufor for consistency, so i recommend changing that too). What you need is a trigger to fire when there are 1 or more "opfor" troops that changes the thing red. Then, another trigger, which fires when there are 0 opfor troops, to change the marker green. The trigger to turn the marker red must only do so when the marker is not already red, so I would add global variables or find a way to otherwise check the marker color for each trigger. And, of course, the green trigger should only fire when the marker IS red. In the syntax you provided, {(side _x) == resistance} count thisList == 0 AND {(side _x) == west } count thisList >= 1 represents the "conditions" of the trigger - what circumstances under which it will fire, so you want to formulate these sections based on the above constraints. format["""%1"" setMarkerColor ""ColorGreen"";",_x] defines a string of code that executes when the trigger is executed, with the _x going into the place marked %1 and being part of the "foreach" statement enclosing the whole block. (_x represents the current iteration's corresponding array element) I realize this is a lot to take on, but you will learn so much by working this out yourself that I hesitate to try and solve it myself. :cool:

I'm afraid this is untrue, and the original objection is valid. _selection = _array select floor random count _array; would be the correct syntax; "random" always returns a floating point value between 0 (inclusive) and the value passed to it (non-inclusive). Thus, if an array has 4 elements, _array select random count _array would end up as _array select random 4; which then translates to something like: _array select 0; //or _array select 0.4; //or _array select 3.3; floor and ceiling commands serve to round down, or up, respectively, to the nearest integer. Thus, in the case of using "count <array>" you should use "floor", so you now get an integer 0,1,2, or 3 (assuming the above example of the array having four elements). Hopefully this helps somebody at least!

Hmm, very cool; I had a suspicion there was something like that. However I'm afraid it isn't quite the solution I was looking for. I actually want the rockets still there, and I want the hardpoints visible. Because I am still adding weapons to the helicopter, and when I fire they animate coming from those positions. I just don't want the minigun showing up in the list of weapons when i cycle through them, and afaik that still is not possible without removing the gun holders, as you said. But I appreciate the info; A3 has been out for months and I still keep finding commands from A2 I never really knew about, I am screwed when it comes to keeping up with this series :)

Heh no need to credit my suggestion, I didn't plagiarize anybody but I basically copied others when figuring out how to access the configs :) Anyway, to keep this post on topic, I want to point out that my technique will actually not fill the player's inventory with magazines (if the capacity WOULD fill the player's inventory). For example, if the player has room for 9 magazines plus one in the gun, the player will only get 9 magazines. Instead, add just ONE magazine, then add the weapon, then add the remaining magazines - that way you get all 10. This is a minor issue and not really worth coding a solution IMHO. But it is an issue nonetheless ;)

Gah, sorry man! Try this _units = []; _backpackarr = ["B_FieldPack_cbr","B_OutdoorPack_tan"]; _weaponarr = ["LMG_Zafir_F","arifle_Mk20_F"]; _uniformarr = ["U_IG_Guerilla3_1","U_IG_Guerilla3_2","U_IG_Guerilla1_1","U_IG_Guerilla2_1","U_IG_Guerilla2_2","U_IG_Guerilla2_3","U_IG_leader"]; _headarr = ["H_Shemag_olive","H_ShemagOpen_khk","H_ShemagOpen_tan"]; { if (typeOf _x == "C_man_1") then { _units set [count _units, _x]; }; } foreach allunits; if (isServer) then { { _backpack = _backpackarr call BIS_fnc_selectRandom; _uniform = _uniformarr call BIS_fnc_selectRandom; _head = _headarr call BIS_fnc_selectRandom; _weapon = _weaponarr call BIS_fnc_selectRandom; _muzzles = getArray(configfile >> "cfgWeapons" >> (_weapon) >> "muzzles"); _unit = _x; // _x will be superceded, below, so rename it so we can still access it clearItemCargo _x; clearWeaponCargo _x; clearMagazineCargo _x; removeallWeapons _x; removeAllHandgunItems _x; removeHeadgear _x; removeGoggles _x; removeUniform _x; removeBackpack _x; _x addBackpack _backpack; _x addHeadgear _head; _x addUniform _uniform; { if (_x=="this") then { // no longer does _x refer to the unit _mags = getArray(configfile >> "cfgWeapons" >> (_weapon) >> "magazines"); { _unit addMagazines [_x, 10]; } forEach [_mags select 0]; } else { _mags = getArray(configfile >> "cfgWeapons" >> (_weapon) >> _x >> "magazines"); { _unit addMagazines [_x, 10]; } forEach [_mags select 0]; }; } forEach _muzzles; _x addWeapon _weapon; } foreach _units; }; Haven't actually tried this but hopefully you can glean the solution if it doesn't work precisely that way. The problem is, my script only gave it to the player, and I think addMagazines only works on units (not unitArrays)

Hmm, the way I have approached that one is as follows: private ["_muzzles", "_mags"]; //<...> _muzzles = getArray(configfile >> "cfgWeapons" >> (_w select 0) >> "muzzles"); { if (_x=="this") then { _mags = getArray(configfile >> "cfgWeapons" >> (_w select 0) >> "magazines"); { player addMagazines [_x, 1]; }forEach [_mags select 0]; } else { _mags = getArray(configfile >> "cfgWeapons" >> (_w select 0) >> _x >> "magazines"); { player addMagazines [_x, 1]; }forEach [_mags select 0]; }; }forEach _muzzles; In the above, "(_w select 0)" is actually just the classname of the weapon, as a string. "[_mags select 0]" actually only resolves to one magazine, so you only get one added. Just change the quantity used in the "addMagazines" call if you want to add more than 1. The reason for the "foreach" statements is that if you change "[_mags select 0]" to "_mags" it will add one of each type of usable magazine (rather than just the first one found)... although the unit needs carrying capacity or they will not all be added. Hope that's not too confusing, but I'll be glad to clarify anything if you have specific questions. Sorry about the "_w select 0" thing, as I said, just replace that with the weapon classname obtained from your random selection. So if you do _weap = <whatever code gets a random weapon classname>; then replace every instance of (_w select 0) with (_weap). That SHOULD cover it but it only takes the first magazine type found, so if the person who coded the muzzle listed supported magazines out of order, you might get tracers instead of normal rounds (or some such).

I'm afraid I haven't looked over this much at all, but hopefully there is a command that might be of at least some help. If you use "setVectorUp" you can basically align an object's vertical orientation so it is upright (or not). The way to get a piece to be perfectly upright is: object setVectorUp [0,0,1]; This makes the model's "UP" vector correspond to the positive z-axis of the world's coordinates. Essential with static weapons and putting things on roofs, etc.

I am only basing this on the reply that says "you shouldn't use loops that run without any delay in them", with the techniques that I myself use for this issue: if (!isServer) exitWith {}; private ["_veh","_targets","_shoot","_count"]; _veh = _this select 0; _veh setVehicleAmmo 1; _targets = [t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11,t12,t13]; _shoot = true; _count = 0; _target = _targets select floor(random(count _targets)); sleep (0.2 + random 0.2); // Multiple scripts now much less likely to compete in the same frame while {(_shoot) and (alive _veh)} do { _count = _count + 1; if (_count == 15000) then { _shoot = false; doStop _veh;}; _veh doWatch _target; _veh action ["useWeapon", _veh, gunner _veh, 0]; sleep 0.05; // assuming the user gets at least 20fps, this almost as fast as visually perceptible. much longer sleep is usually ok. }; EDIT: sorry, i see now after actually reading the code that the firing occurs every cycle of the loop (if possible). Thus the sleep duration I put as 0.05 will give you a firing rate of 20 rounds a second, or 1200 rounds per minute - probably still much higher than the actual rate of fire. Just find what your weapon's intended firing rate is, and use the appropriate sleep value (60/rds per min). There are also commands to order a unit to fire at a target, or to use suppressive fire at a target, but I'm not familiar enough with how they work to see how they may or may not be more suitable here.