dwringer

Instead of blowing them up,you can deleteVehicle them from a position out of sight of the player, to avoid needless exploding harriers in the sky. Also once your airstrike targets are destroyed, you could (in addition to "setCaptive true") do a "disableAI 'TARGET'" or something like that, there's also one for firing I think but I don't really remember how exactly to use these commands. Doing a search for "disableAI" and experimenting with the available commands should be more than enough to stop the planes from attacking things. There's a thread around here somewhere about being a player gunner in an AI controlled UAV which discusses the issue, though I'm afraid all that was discovered is that the game's default behaviour is quite screwy.

Er, well, yeah, I guess you have a point; I kinda confused myself trying to figure out the discussion prior to my post, haha

Yeah, as far as I understand it, if you want a particular condition for a trigger beyond the trigger's inherent Activation Type, you set the trigger's conditions to be something like (this && (your own conditions)); the "this" refers to the default Activation. Setting it to "true" instead would bypass the builtin Activation mechanism and ONLY activate the trigger when your own conditions become true. Depending on what the trigger's Activation Type was, you could probably convert it into a condition statement, then just make your trigger with the 0 area and set its conditions to be (true && (whatever its activation condition would have been)). Not sure what your specific Activation Type was or whether it would actually be possible to do the above, but you haven't really told us what you're trying to do yet. At least in a way that I can discern the facts regarding the issue ;)

I guess it's a lot easier to get certain aspects of mission design working that require a particular loadout without going through all the semantics of defining a "proper" loadout first. Then once things are in place, before you .pbo it you take care of that as one of the finishing touches. I guess. I agree that the editor probably could do a little more when it comes to loadouts. To say the very least.

Hm all very good suggestions, and I am sorry about the performance issues. After the first 30-40 seconds once DAC initialization is complete some of the choppiness should let up, but I realize there are a LOT of groups on the map at one time (over fifty hostages and about forty militia groups, NOT counting what DAC generates (another 50-60 groups over the course of the game). I am sure this could be optimized; but my main focus was just implementing the idea of the mission and not making it "the way it should be done". Now I will certainly try and keep coming back to it to try and fix things up. Gunner AI might be helped if your CPU isn't working as hard (but probably not, I guess, haha). The only way around that is to switch to manual fire or just use your Hydra rockets to blow away anybody your gunner seems to be ignoring. After the second or third pickup your best option is usually to avoid extended combat anyway, because you're going to be outgunned. I was thinking about a medic or engineer, or even just a way to give you more "lives" (like the way Choplifter used to be), but nothing has really grabbed me yet on how to do it. Finally, the dropoff point is so tight because 1) I remember having a lot of problems at first in the original choplifter with trying to land the dang thing, and 2) the challenge! (maybe not everyone's cup of tea I guess ;)) (And thank you for your kind words. There is a ways to go before I feel like there's anything in the mission to justify them, but it is appreciated :))

Hey everyone. I have always wanted to contribute a mission to the community, and unfortunately this barely qualifies at the moment. Nevertheless I've had some fun playing it, and thought maybe others could as well. It's at least something a little different from the norm. readme: If somebody tries this and can't get it to work, let me know (and include the versions of any addons you're using, just so I can make sure that's not an issue on my end). Requirements: - ArmA 2 - Isla Duala - Dynamic-AI-Creator (DAC) Here is the file, just extract this to your [:\Arma 2 Operation Arrowhead]\Missions\ directory (wherever that happens to be): http://www.megaupload.com/?d=3X4ZW0KP Armaholic mirror: - Choplifter (@)

Zora is the Zone Restriction Module. Which from what I have been able to dig up is rather poorly documented and might not have the functionality you're looking for (much as custom factions, or even expansion factions, cannot be used with the ambient combat module).

Well I don't think they begin spawning civilians until a player gets near them. Barring that being your issue, I don't know enough about programming the module to tell you I'm afraid.

Yeah, the PRNG (pseudo-random number generator) of Arma 2 is pretty terrible sometimes. There's certainly no way to predict what is coming next, and given enough trials you might notice a pretty even distribution, but it likes to keep picking numbers around the same value when it gets into certain moods . . . if you google random number generators you're sure to find pictures which show this kind of distribution, where certain ordered patterns appear as artifacts of whatever algorithm they use to come up with the numbers.

You'd have to create each projectile and script its position/velocity relative to the bomb. Not a ton of code depending on the solution you use. In the thread marked "Road Side IED" I posted the code for a road bomb which uses an abrams' sabot round fired straight up to take out vehicles, and fires high caliber armor piercing rounds out in somehwhat of a cone shape around the bomb position. You could, instead of a cone, script something like a back and forth traversal of a specific arc (hope you remember at least something from trigonometry though) ;p

A "CYCLE" waypoint causes the unit to go next to its other waypoint nearest the "cycle" waypoint. Thus if you make a circle as you describe, placing a "CYCLE" waypoint as the last waypoint, right next to a waypoint at the beginning of the circle, the unit will go from one to the next and continue looping.

Well I have yet to beat even the first mission, and I certainly didn't understand a word of the cinematics. Basically I haven't got any right to really review this campaign. That said, from what I have played of it so far it is fantastic :) The way the copilot complains when the systems begin taking too much damage adds a ton to the atmosphere. One of the cinematics where there are two men launching a shoulder fired AA missile reminds me of something very similar I saw on liveleak one time. I have never been to Russia, nor have I ever been in a helicopter, but as far as my imagination goes this campaign really captures it. Being shot down and running from cover to cover while being shelled by apc's while you wait for another chopper to pick you up is great, also. This resulted in slightly less reliable behaviour from the AI, but for a situation which basically spells "game over" in any other sim this was handled really well. Being thrust from a helicopter sim into a "run away from the tanks" sim so quickly has to be one of the coolest things I have seen in a game in a while, and is a great example of the kind of awesome experience possible in ArmA.

That's not what it seemed like, since that would mean we are in agreement. The floor is both clearer and more logically correct. I certainly feel bad for arguing a point like this when it's something merely stylistic, but the more I think about it the logic is simply flawed without using the "floor" statement. Ex. We have an array of length 10, with indices 0 thru 9. Selecting (random (count - 1)) would give us a number between 0 and 8.9999 (dunno how many significant places are used here by the engine). Rounding that would mean any number between 0 and 0.49 gives us 0, anything between 0.5 and 1.49 gives us 1, and so on, to where a number between 7.5 and 8.49 gives 8 and only 8.5 thru 8.99 yields 9. That means the chances of getting a 0 or a 9 COMBINED only equal the chance of getting any other specific number; thus the "random" index is twice as likely not to be the first or last element of the array. Using the floor method (while not "clearer" to some, apparently) circumvents this problem, simply truncates the number past the decimal place returned by random, and consequently just gives us a random integer corresponding to one (any) of the array indices.

Well count _array will return the length of the array, so generating a random with (count _array) - 1 as the argument will generate a random number from 0 to the last index of the array, non inclusive. The round will round some values (but not quite half of an integer's worth) up to the last index. Since the random number generator in ArmA2 is dubious at best this is acceptable, but it is not more logically sound.

If you sync them with an ARTY battery and then supply them with a fire mission template they should be able to execute it. Take a look at the Bohemia Interactive Community Wiki pages for Arma 2: Editor Modules (more specifically, the one for Artillery). EDIT: Guess I'm wrong about the scuds, but I think this works with any other indirect fire weapons.

I think it has to do with a few things, such as combat mode, altitude, and skill. A smart pilot flying high enough in "Aware" combat mode will stay pretty far back from a waypoint, the idea being he is "close enough" to engage any targets in the area, he can see the waypoint itself, and if absolutely necessary he could fly to it, but otherwise the chopper considers looking at the target enough. Pretty sure there are more detailed discussions of what exactly happens in these situations elsewhere on the forum. I also confess to being hopelessly confused about the way units execute their waypoint orders sometimes, even ones assigned from the editor.

That will unfortunately give your fuel consumption a curvature, which, although I'm sure it's not really supposed to be linear, is also nowhere near the curve you will get with that. Instead perhaps you should set a reference variable for however much 0.01 * fuel _vehicle would be, and iterate while the engine is on until the fuel is empty subtracting that amount from whatever _curFuel is.

As long as you have each group leader named, you can put something into your init sqf such as _myGroupLdrs = [ldrGrp, ldrGrp_1, ldrGrp_2, . . . , ldrGrp_n]; {{_x setSkill (0.3 + random 0.5);} forEach units group _x} forEach _myGroupLdrs; There are also commands to return all groups on a given side if you look into it, I don't really know offhand but I'm sure you could use some neat tricks with that to automate a lot of things like you describe.

You can, instead of just creating a biga** bomb, create a simulated EFP [explosively formed penetrator] along with some high explosives. This only works if you set the bomb up to be a kind of mine, or road bomb that is actually buried in the road itself. The script here basically just assumes you have a position stored in _bombPos which will ideally be underneath the target vehicle. The details of that are up to you, but here is a method of making the bomb I've been having some success with: (of course there would also be an array _bombIntvls, in mine I have only a single number in there to determine how long to wait before detonating the bomb, in seconds.) The SABOT round fires up at some ridiculous mach 5 speed (from my quick estimate, idk), so if it directly hits the target vehicle, the vehicle is instantly destroyed. If it is a near miss, the SABOT round ends up somewhere in orbit and is never heard from again, while the M_Stinger_AA takes care of disabling the wheels and/or turret of hum-vees, and killing any infantry in the area. EDIT: After the above code, you can add the following to put in armor piercing projectiles angled upward in a cone around the detonation position. That code actually created a bomb that, when detonated right in front of an uparmored hmmwv, took out the wheels and killed one of the passengers (in the back seat). The rest of the passengers disembarked. You may wish to edit the code, as I have not really tested it further. I was just happy to finally find something that could kill passengers without killing everyone inside. This is WITHOUT ACE, mind you :P EDIT 2: Here is a demonstration of what this bomb is like, with slight alterations. Here is the code (_timerBomb was set to about 3 seconds and you would need to do something like that in your own script if you used this): _bombIntvls = [_timerBomb]; {sleep _x; _EFP = "Sh_120_SABOT" createVehicle _bombPos; _EFP setVelocity [velocity _EFP select 0, velocity _EFP select 1, 2000]; "M_Stinger_AA" createVehicle _bombPos;} forEach _bombIntvls; _bvels = []; _vel = 1250; _countBullets = 80; _angles = []; _i = 0; _iIncVal = 360 / _countBullets; while {(_i < 360)} do { _angles = _angles + [_i]; _i = _i + _iIncVal;}; {_bvels = _bvels + [[(_vel * (cos _x)),(_vel * (sin _x)),(_vel * (sin (15 + (random 45))))]];} forEach _angles; {_bulX = "B_145x115_AP" createVehicle _bombPos; _bulX setVelocity _x;} forEach _bvels; Video: (and I realize that the velocity is not properly calculated in 3 dimensions. This is just something that worked. :P)

Hrm. Transport Unload waypoints also need to be synchronized to a "GET OUT" waypoint of the group they are unloading. Usually this waypoint would be placed right next to the invisible H, with the Transport Unload being placed directly on it. There could be a bug you found of which I am not aware, however. I haven't done a lot of helo insertions since ArmA 1 ;p

http://community.bistudio.com/wiki/terminate

derp :P I've been doing everything in emacs lately so its paren-matching has gotten me into some pretty horrible coding practices, although I need to look into whatever editor that is where there's a color coding configuration based around .sqf syntax, can't remember off the top of my head... But thank you, I had never really gotten around to figuring out how exactly things get evaluated. Guessing a list of function names just gets evaluated right to left then. haha.

fatty86's advice was helpful for the question asked, just because you don't agree with the OP's algorithm doesn't mean you should criticize those who help him implement it. Just because something isn't, in your opinion, the "best" way to code something, doesn't mean it wouldn't be extremely beneficial for a novice scripter (like most of us here) to learn how to do it anyway, to understand the technique, its advantages and limitations. Of course you are welcome to criticize, but it would be nice if you went into detail about what those limitations are without casting a blanket judgment upon them. That said, I do think Celery's implementation of said "bad" algorithm is slightly more elegant ;p Oh, and doing a select (round (random ((count _arr) - 1)) seems like it might make more sense as select (floor (random (count _arr))). Just to save on parentheses and math, two of my least favorite subjects.

Well my entire goal was to simulate the IED without manually placing an object at a specific location in the editor. Set up a somewhat variable condition for the trigger, and you will never know when or where the bomb is going to be. For the most part, the bomb will be in the road or just off the shoulder. If you charge into a corner at high speed. you could get the bomb to appear pretty far off into a field or house or something (up to 20 yards from the center of a road segment), but if its too far the script tries to find a road within an additional 10 yards and places the bomb there. IF that still fails, then the bomb won't happen, but I have only seen that once so far. If you have lots of little triggers that each call the ambush script with a relatively low chance of actually happening, or a wide area trigger with a randomized timeout on it, you can have a very dynamic ambush situation. EDIT: but I have not checked out fully the other scripting options available for such things. It has taken me a very long time to start to understand how to do a lot of what's possible in scripting, lol.

Hrm, I guess sometimes civilians are just stupid, haha. One thing I was having problems with at first was that as soon as some civilians would arm themselves and become opfor, those that had not yet switched would become afraid of them and refuse to do anything else. Make sure civs are friendly to opfor, or everyone. I think they still have a tendency to go brain dead, though, for sure. The mission I've been playing around with now does seem to have all of them following the script MOST of the time. I hesitate to say almost all the time, because the times in the past I've been trying to debug this they have been extremely frustrating to understand. I cannot tell how to reproduce the anomaly very well, and every time I find a good way, and fix it, I just find them do something else stupid and unpredictable. Lol.