GDICommand

i think youre confused...thats the only way to do it (minus the setting velocity, using FLY as the special when you create the vehicle takes care of most everything you would want to do , unless youre looking at setting a speed that isnt default, then the rest isnt neccessary)

I tried it, and THEN I went to the api for guidance lol. it turns out you can't use this for vehicles. so the way that we did it before (creating each unit individually, and then placing them in the vehicle) was the correct (and only) way to do it. So fadly1979 was just posting without actually knowing what he was talking about. I just assumed he was speaking from previous knowledge createUnit_array

thats not how you access an element in an array, what you want is this: foglist = ["a","a_1"]; for [{i=0},{i < count foglist},{i = i +1}] do { hint format["value at index %1 of foglist array: %2", i, (foglist select i)]; }; that just prints out the index you are evaluating and the string. i corrected a few things for you. NOTE: i recommend you do some more reading about arrays, and the specific syntax that arma requires. my explanation is just identifying your mistakes, nothing more first off, you were evaluating the for loop over indexes that don't exist inside the array. so, when your loop iterated to i equals 3, then you would get IndexOutOfBoundsException basically, which means, that the index you are trying to access is invalid. so, if you notice in the second set of brackets in the for loop, i set it to iterate only to the number of elements in the array, and then break out of the loop by using count. you should always use things such as count wherever possible. writing anything statically in, is just asking for whatever you wrote to break. imagine a program (an actual program), where you reference a value a couple dozen times, lets just call it 24 times. now imagine that value changes, if you statically write in that variable, now you have to change the 24 occurrences manually, which if you don't remember where they all are, or your program spans across multiple files, then you may forget one or two, and now your program doesnt work, and you could spend days trying to figure out why. if you use count, in this particular case, you could have 24 for loops, and maybe you want to add an index, now nothing breaks, because each for loop will iterate up to the last index of the array, and all you did was add an index secondly, assuming we fix the count issue first, you were only evaluating one index of the array. so I set the initial value for i to equal 0, instead of 2. if you only want one index of the array, and you know the index already, then the for loop becomes unnecessary, and when it breaks down to into machine instructions (if not optimized) then it will actually consume more cpu cycles. if you are only interested in one particular index, then you will do it as such: hint format["value at index %1 of foglist array: %2", 2, (foglist select 2)]; by statically writing in the index you are attempting to access EDIT: { I think you were trying to add an index rather than access existing indexes...in any case, I still think you should do some reading for reasons I wont elaborate on (because I think its beyond the scope of this thread), you should really construct two separate arrays. one which is your original array, and the other which contains all the new values you want to add to the old array. after ALL your values have been added to the new array, then you can join the two together }

lol, i didn't fully read this thread, i just had to quote that...it made me giggle lol, sorry mankyle!

you have to do it statically for every unit im sure there is a script out there that does it, but if not, this is generally speaking, what you would want to do (pseudo): create a function that takes in unit names as a parameter scriptName["unit1", "unit2",..."unitN-1", "unitN"] first, remove all weapons and magazines, etc for the unit you are evaluating evaluate based on which unit you are using (i.e. iterate through, and if unit is unitNumber which is a multiple of say, 4, then give it this loadout) have a switch table which says if unitNumber is equal to unitNumber - (iterationCount * numberOfSwitchTableElements) then, give it the weapons you want. thats literally all you need. if you want it based on certain other criteria, for example what enemy units are in the area, you will have to create rules for that. what i have provided is very simple, saying that you will pass in a list of units, and it will iterate through giving unit1 weaponsA, unit2 weaponsB, unit3 weaponsC, unit4 weaponsA, etc etc, assuming that you only have 3 weapons in the switch table. EDIT: the script above does it already lol, so all you need is to pass in an array of units, and iterate over them instead of passing in what weapon class you want

no, you were calling the script wrong. passing arguments into the script was incorrect. i think you need to spend some time learning what scripts are, and how they work from a top-level view. i dont think you understand how this stuff works. passing arguments into a script is part of calling a script these are some links you might find useful. it is in an actual language instead of whatever substitution script that arma uses. functions and methods (which are just another name for a function) are some sort of function, which has arguments that are passed in. part of calling that function, is that you have to specify the correct arguments, so in this respect, a function is the same as the script you are trying to call (all I want you to really focus on, is the arguments for the functions in the articles following): Java Methods C Functions For everything else, I suggest you find a nice arma tutorial to teach you what you are actually doing. As the saying goes: give a man a fish, feed him for a day. teach a man to fish, feed him for a lifetime. What this thread has done is fed you a fish, but you clearly (no offense) don't know why we told you what we did. This is clear because you still don't understand why you were supposed to pass in the same variable name. I couldn't find a link with variables that might help you, but i did only search for a few seconds (don't look for variables in any actual language, because there are keywords and data types used in their declaration, which is not used in Arma, and it could end up confusing you more than helping). For this particular case, one of the arguments was a string (or more explicitly, an array of strings), that was to represent a variable name. passing in the variable name of the unit that was to receive the added support was part of the scripts parameters, which is why i suggested you posting up your specific lines that you used to call the scripts itself. long story short: you need to do some more learning to understand the inner working of what you are doing instead of just copying and pasting it

well what about that isn't working exactly? does it just not execute? or does it not spawn crew with it? I haven't tested the above code (havent played arma in a week or two) but the reason for specifying a group is to place the created unit inside of the group specified...which you can't do with an empty unit, only living units. So, I don't see why it wouldn't work. if it just doesnt work altogether, then i suggest removing layers of complexity to identify the problem. For example: create a trigger that is supposed to create a unit directly in front of you 3 seconds after the mission starts. if it doesnt spawn your unit, then the command is the problem. A common problem with that is specifying an object that isnt in the game...not saying that youre object you specified isnt correct, but try another unit just to screw around. For example if youre playing vanilla arma2, and youre trying to use a mortar from the expansion, obviously that's not going to work. Another reason it won't work is if you don't specify a group, which isn't the case here since you specified the player's group, but just food for thought in any case, as i said above, it does the same thing regardless, just creating each unit individually is much more explicit (i.e. you can control rank/skill/initial loadout/etc of every unit inside the vehicle). Also, you can place opfor units in blufor vehicles, blufor units in civilian vehilces, etc etc. using the createUnit command as listed above which should create the crew, is if you want just basic options for the crew and what not.

lol, thats what all of us were trying to tell you...it doesnt matter what is inside the script, it matters how you call it

how about you post what youre using to call both scripts. i think youre confused about whats going on. you shouldnt be concerned with whats in the scripts themselves, you should only be concerned with how their called. i dont know how the air support script works, since it doesnt have whats in it readily available (and i dont want to download it), but im thinking that youre just calling it the wrong way. it doesnt matter if inside the script, the unit is called m1, it matters what you named the unit, and what you passed in, nothing else. each script should operate independently of the other, so there shouldnt be a reason for one to work, and one not to so basically, you should be able to pass w1 into both scripts, you shouldnt be changing the name for any reason.

you kind of have to rewrite the ai to do it...with the tools arma provides of course basically, you have to have a ton of triggers that say, if this, then this (i.e. if a unit is friendly, and enters within this much space of an enemy, and is within eyesight, infront of that unit...etc etc, then tell all enemy units on the map to engage the friendly...[radio is the fastest thing] -- and many other triggers which say other conditions you want met). remember, a computer only does exactly what you tell it to do...no more, no less. you basically have to sit down and write down every scenario you want to be covered, and write triggers for them...then test each one individually to make sure they work. so, im not gonna go ahead and write this for you, because it's gonna be a ton of work, and im not interested in using it myself...and im at work lol, but in any case, thats the gist of it as far as i know as far as the waypoint thing goes, all you have to do is make it relative to the units position when you add them, save their location, then you can add the waypoints back if you need to. im not aware of a way to end a script prematurely. the alternative is to create a boolean which is referenced by the script, and set it to true at the start, and set it to false when you are ready for the script to end. run checks against the boolean when needed, and when its false, end the script. as a side note though, its kind of a ridiculous concept to have a group of infantry that have just been engaged, to return to a normal patrol as if nothing happened. i would suggest a patrol with "COMBAT" behavior set around the area that the enemy was last engaged

I feel silly now lol...i was creating air support for a mission and manually created every unit that was supposed to pilot the aircraft and placed them in...lol...i dont know why I skimmed over that when reading createunit, it does the same thing either way, I just did it more explicit

i thought when you added a waypoint to a group, it wouldn't execute unless you assigned it some variable name...for some odd reason, it needs to be stored somewhere, even if you have no intention of using that variable name again. which is irrelevant anyway, as you could get it from the waypoints anyway if you needed it...anyway, just throwing that out there

what they said variable names are just that...names...they don't really have much to do with the object other than to keep track of it. it would be borderline-retarded behavior for the developers of arma to require you to have different variable names for different functions/keywords/etc

trigger with center at the waypoint location, which says remove the waypoint as soon as any unit inside the group (or the group leader) enters the area, automatically making said group advance to the next waypoint

lol, i was just being a smartass because the apple mobile devices are notorious for security issues

lol...dont use the ipod...so insecure wait for android to come to arma :P

the reason why i said it's the proper way, is because if you go past mission creating and go to learn an actual language, 'and' is not a keyword for any language ive encountered. '&&' is what is used (c, c++, Java, c#, etc). so id rather teach how to use booleans, rather than use what arma considers a keyword

not to say the way the above poster says to do it is wrong, but the proper way to 'and' something, and receive a boolean in return, is using: if (_size >= 11 && _size <= 50) then { ... } inversely, the or operation is: if (_size >= 11 || _size <= 50) then { ... } EDIT: actually, here is a link that might help you. specifically for boolean operations, look under the section that starts with '#' Arma2 scripting commands

i always tell people the same thing...use io to your advantage. as shk suggests, use error reporting however, sometimes it's not a runtime error, and its not a compiler error...and when this happens, you get a logic error...which basically means nothing will notify you that it's wrong, because technically, it's doing exactly what it's supposed to: its a user error (i.e. you have a boolean that says if 4+4 < 2, and it never evaluates to true) so in this case, i suggest dumping everything you possibly can to the screen related to the problem (seeing as there is nothing to step through a mission line by line). so, first off, verify that the points are created...put a hint before anything in your trigger gets run...then put a hint after everything that happens to verify it executes properly although in this particular case, error reporting should suffice

i just got a better idea. how about at missions start time, get all the vehicles on the map using the vehicles command, and say if the vehicle is civilian or empty, then add a handler for it. have that trigger run every 120 seconds or so, and have it check if all the civilian vehicles have the handler put on them every time it runs. i would say check to see if the number of vehicles is the same, but it's almost guaranteed to not be, so might as well remove that check

well thats not completely true, but the idea i have in my head is even worse that what i suggested (slightly) if the vehicles are from the module start out initializing a global variable somewhere, call it vehicleArray to 0 then have a trigger that says (note this is psudeo code...so dont take it and copy and paste lol): anyone is present 2 second interval to cut down on cpu cycles used if: count vehicleArray != count vehicles in thisList (notice you're going to have to count vehicles to get this number) then: vehicleArray = vehicles in thisList; *add handler for new vehicle if it's greater, if not, remove handler from vehicle not present, and remove it from the array* also, using nearest object won't work. it doesn't guarentee that it will return a AI controlled object (i.e. walls, houses, the player, etc), it won't return all the objects within a certain radius also, the reason why my method wont work, is because a vehicle will slow down at a certain point...what i suggested was a set velocity...so say a civy parks a car...that car's not gonna stop so long as its in the town lol

create a handler on each vehicle that says if the speed exceeds a certain speed within a certain area, then set the velocity to what you want. the handler will constantly get called, which is bad...very bad (so i suggest finding an alternative route to cap the speed instead of constantly adjusting it...this is just off the top of my head), but when a vehicle leaves a town it wont get called anymore, so it suffers only when a vehicle is in a town like i said...this is very inefficient in itself...i suggest a different means...i just figured this is something, and since nobody else has posted yet, why not...lol:rolleyes:

actually that makes sense. but there is no "anybody" command that I'm aware of. but this is ok, because I believe the OP really wants only a certain subset of units to apply to this rule anyway. So now the problem is, youre seeing if a unit in one list, is not in another...and this is terrible as far as cpu cycles go considering this is a constant process. so it seems as though it would be more efficient to put an event handler on each object, and saying when they get so far away from a point, then kill them the only alternative is creating a trigger for each unit that you're monitoring...but this can get equally costly in cpu time...i definitely suggest something that notifies you also, something you should understand about '!', is that is a boolean operator. which means it applies to other booleans. in some languages you can apply it to objects, or primitive data types that are not booleans, but the point is, it returns a boolean itself, regardless of what it is applied to. so applying !, to in thisList basically doesn't do anything because in needs an object to test against, but if we modified it, we could say if(!(obj in thisList)), and this would return true if the object is not in the list. but it still requires an object and an array to pass into in. point I'm trying to make is that you can't negate an array, and get another array, it doesn't work that way

youve never initialized pork for starters...dont really know what else youre going for...also, coding conventions are such that variables never start with an uppercase letter...makes it harder to read for people looking at your stuff

that wouldnt do anything. not present is the condition, not part of the action statement