xPaveway

Please wrap your code in tags.As far as rearming goes, if you're looking for something like in domination, you'd need to write a script of find one. I assume it would be something like having a trigger that would be activated by a vehicle entering it. Upon entering it it would remove all the fuel, repair everything, rearm everything, and refuel the vehicle. AFAIK hints are dependent upon who you run the script on. Basically the script would have to be executed only by the player who is attempting to run the course. If you execute all scripts for all players connected, you'll probably get a lot of hints piling up.

I made a script where you throw a green smoke and a c130 flies over the smoke position. In order to get the smoke grenade's position I had to call a script whenever the player (or whatever unit) throws a SmokeShellGreen or whatever. I used the http://community.bistudio.com/wiki/addEventHandler http://community.bistudio.com/wiki/ArmA_2:_Event_Handlers object addEventHandler [type, command] method to look for the "Fired" event. In the fired event, you can get what type of ammo was fired. If you check that it was a smokeshell or whatever, you can run a script that has _smokeShell = getPos _unit nearestObject "SmokeShellGreen"; sleep 15; _smokeShellPos = getPos _smokeShell; Or something similar to get the position of the smoke shell 15 seconds after the player throws it. From there you could do createVehicle with an invisible H or whatever on that position. With regards to checking if someone gets into the vehicle, that would also be accomplished with an event handler on the vehicle. http://community.bistudio.com/wiki/ArmA_2:_Event_Handlers#GetIn

You might try using knowsAbout with the findNearestEnemy statements

http://www.arma2.com/comref/full.html#ObjectaddActionArray The unit name goes before addAction

http://www.arma2.com/comref/full.html#ArraysetWaypointTypeString

http://www.armaholic.com/page.php?id=6057

I'm not sure what HerculesPilot = name Hercules; is for. Did you mean to put HerculesPilot = driver Hercules; http://community.bistudio.com/wiki/driver

Try the land command. I don't see why you would need to script the helo moving down.... http://community.bistudio.com/wiki/land Also, there seems to be a lot of redundant or unnecessary things in your script. Maybe I'm just not understanding though. For example: private ["_outboundpos", "_inboundpos", "_uhlz1", "_approach", "_pos", "_posx", "_posy", "_posz", "_ang1", "_ang2", "_ang3", "_avgang"]; From what I understand about private, the way you have used it doesn't really have any effect. http://community.bistudio.com/wiki/private // set H (invisible) objects in Y formation _pos = position UHLZ1; _posx = _pos select 0; _posy = _pos select 1; _posz = _pos select 2; _ang1 = -((wind select 0) atan2 (wind select 1)); Sleep 0.01; _ang2 = -((wind select 0) atan2 (wind select 1)); Sleep 0.01; _ang3 = -((wind select 0) atan2 (wind select 1)); Sleep 0.01; _avgang = (_ang1 + _ang2 + _ang3) / 3; // Having objects face direction of wind (_avgang) UHLZ1 setDir _avgang; UHAPPROACH setPosATL [_posx + sin(_avgang)* 0,_posy + cos(_avgang)* - 500,0]; UHAPPROACH setDir _avgang; I don't understand why you're needing H objects to face the wind. It seems like a lot of unnecessary code, it could make for easier debugging if you didn't have to do this. You have a lot of sleep statements. Do you really need the Sleep 0.125; After each waypoint? Also your waypoints have waitUntil statements between them. Why do you need this? You should be able to just add all the waypoints. If you are waiting for waypoints to complete before adding new ones, it has the potention to make your script more intensive, since it has to sit in the waitUntil loops for a long time. http://community.bistudio.com/wiki/setWaypointStatements You might consider using waypoint statements (just like adding conditions / onActivation stuff in the editor) It's hard to tell exactly what is going wrong in your script. That's why I pointed out some things that I think may be contributing to the odd behavior. I think you should try using set waypoint statements to tell the helicopter to land once it reaches a move waypoint close to the H's. Once it's landed and all units are inside, then you can tell it to move somewhere else, it should automatically do a lot of these things. If you have an example mission I could try playing around with it, cause honestly this is something I've been wanting to make too.

What you wrote.

What happens if you don't check that it's loaded? Is it necessary?

Use single quote marks inside of the double quotes. It's kinda ridiculous having four double quotation marks in a row, it will be impossible to debug a beast such as that.

Dunno, have you tried it? Did it have an effect?

Splicer, The error message is as simple as it says: You simply cannot use waitUntil in an init line. waitUntil is only valid in scripts. This is at least what I can tell from personal experience. Trying to use waitUntil in the init line appears to throw this error message. Also: why are you using spawn? and why do you need to waitUntil PatrolScript is not null? Does the script not work if you just use execVM?

Will there be documentation for everything? More specifically, I'm wondering how we can get AI to utilize things in ACE like gasmasks, "JUMP OUT" actions, "Pull ripcord" actions etc. I've looked on the wiki but haven't found a list of actions and stuff. I did find the classnames though, which is nice. As long as things are documented well, mission makers won't have too much of a headache :D

That thread has 4 pages of people talking about trying to get suppressive fire to work. Come on man: Taken from the thread:

Has way more atmosphere, I loved the feeling of being stranded on my own, having to find dropped weapons, having to hide the forrests for fear of being discovered by enemy patrols. Great stuff.

Ok, because clearly if ArmA doesn't do it like other games, it's worse.

Yeah I know ACE did this, but ArmA and ACE are different you know. Not picking on you specifically, but I dislike how there seems to be this tendency to answer any problem with ArmA with "just play ACE, it's amazing and it fixes everything and it's the answer to all our prayers." ACE definitely has its own problems. Don't forget that BIS are still working on ArmA :) and as a side note this is the ArmA 2 suggestion forum.

The thing about simulating fear response and suppression etc in games is that it can make it unrealistic. Yes in reality your adrenaline will probably start flowing pretty damn good when you're in the middle of a firefight, but what if your response was beneficial? I.e. you react well under the pressure. These kinds of things need to be left to the actual person playing the game, not the game itself. Maybe my soldier in the game can't handle it, but in real life I could. It's just penalizing the player. Now I realize you're talking about the AI, but I think the same thing applies to both them and us. I don't think it's fair to FORCE the AI (or players) to totally panic in a firefight. Sorry, this is just one of my pet peeves about "realism". While the idea is interesting, I think this could be achieved with perhaps just fleeing and the skill level (i.e. they don't aim very well, but it's not due to them "panicking"), which is up to the mission maker if they want to make the enemies a bunch of dolts.

Come on man, you can't make polls that are basically: Should BIS improve <x> aspect of Arma? 1. Yes 2. No 3. Fine as is Of course everyone will vote for an improvement. If you made a poll that had specifics it would be way more useful. As far as tanks go though, what specifically could be improved? The way I see it, ArmA 2 so far has kind of a jack of all trades, master of none thing going for it. There's every aspect of the military in the game, but things like planes, helicopters, and tanks are not to 100% simulation as you would get from playing a game solely dedicated to one aspect. (IL-2 for example) Sure tanks could be improved, but so could planes and helicopters. Perhaps we could focus more on specific aspects that could be tweaked. For example: tanks seem to become useless after being hit once. I mean if I'm engaging a T-90 in my M1A1, after the first hit or so I seem to lose turret control and my tracks. Makes tank battles kind of short and uninteresting. Perhaps boosting HP for the tanks would help. I heard that in reality the M1A1 barely flinches when being hit by an RPG-7.

I was able to verify this. The "Off-Road" vehicle appears to have no engine running noise, the start up, shut down, accelerate and decelerate noises play but there is no idle running noise.

Try: enableSentences false I havent used it yet, but it might be what you're looking for.

Nah there is nothing specially set up for reinforcements. I was simply saying that you could have your group start out far away from the objective, but give them a set of move waypoints and stuff into the objective. If you sync the trigger to one of the waypoints outside of your objective, they will not go past that waypoint until the trigger activates. This would simulate not having them come into the area until trigger conditions were satisfied. On that trigger, just make sure it's set to "ONCE" and I believe you don't need to worry about deleting it. Why are you using two triggers? I think you can accomplish what you are trying to do by only using one. Here's a rough example: Create your objective area (for example a town). Place your normal guys you want stationed there etc. Add a trigger in the center of town. Make the trigger type a "detected by opfor" with the activator being "blufor" or whatever sides you are using. (I dont know the details about using detected by triggers, haven't used many of them, you probably want to test it separately first) In the detected by trigger, have the condition field as this && alive nearestObject [bridgeMonitor, "House"] && alive nearestObject [bridgeMonitor_1, "House"]; (By having "this" in there, it means it will also check the built in 'detected by' conditions notice I removed checking for if the building is dead, in the case you'd want to check if it's alive) Sync that trigger to your reinforcement group's waypoints. And there you go. The trigger will not fire (reinforcements wont come in) unless you have satisfied: 1. You were detected by the opfor. 2. The radio tower at bridgeMonitor is alive. 3. The radio tower at bridgeMonitor_1 is alive. Otherwise the trigger's conditions will not be true and it will not trigger your reinforcements.

Use the "condition" field in a trigger.