Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

10 Good

About GDICommand

  • Rank
  1. GDICommand

    Spawn vehicle mid air.

    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)
  2. GDICommand

    Spawn vehicle mid air.

    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
  3. 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 }
  4. lol, i didn't fully read this thread, i just had to quote that...it made me giggle lol, sorry mankyle!
  5. 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
  6. 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
  7. GDICommand

    Spawn vehicle mid air.

    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.
  8. 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
  9. 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.
  10. 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
  11. GDICommand

    Spawn vehicle mid air.

    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
  12. 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
  13. 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
  14. 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
  15. GDICommand

    PMC ipod GPS

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