nominesine

Place it in the editor and you will be able to select NATO-style military symbols as markers, besides the usual X's and circles.

Thanks. I intend to attack the ca folder wioth a can opener asap.

You are of course aware that to increse zoom you must lower the FOV setting, as opposed to raising it to a higher numerical value? And if you do zoom in by changing the FOV this way you will of course have a smaller field of view, as if you were looking through a lens. That's the whole point of it, isn't it? The game behaves exactly as any camera/binocular/telescopic sight/etc in the real world.

Morale is indeed implemented in the game and has been since the days of Operation Flashpoint. It's controlled by the command allowFleeing where: this allowFleeing 0 means that the unit/group will never break whereas this allowFleeing 1 make them run away as sonn as they start to suffer casualties. It's a sliding scale from 0 to 1, and i believe 0.5 is default value. Changes to the command can be made in the init line, from a trigger or a script. Morale and AI behaviour can also be simulated easily with the use of a Captured-By-Side type trigger (they are found in the editor). You only need to set three values, and they are fully documented in the BI Wiki. The surrender module (F7) is another way to simulate morale. All three methods can be used simultaneously to produce a large range of effects in the same mission. ArmA2 is a sandbox game, meaning that you have to add these effects yourself, if you want to see it in action. A lot of players like it, and they implement it in their missions. Other people don't care about morale, and leave morale out of their games. That's the beauty of it. It's your choice.

I've also heard that you may call different clods and fog using the weather module, but I've not yet seen it done anywhere. White fluffy things would be even better than the thin whisps of smoke currently present. What commands did you try and where did you find them? If you care to share your findings I'll gladly try to solve this issue, since I would like to use the weather module myself, albeit for different reasons.

Your question is impossible to answer without knowing the ending conditions. I've never tried the aforementioned mission. What does the endtrigger look like? Did you test it in true MP mode with more than one player, or did you just test it on a MP server with only one human player? All missions will be terminared automatically when all human players are dead. Maybe that's what is happening.

is there any chance you might actually let us in on what the problem is? ;) The weather modules should produce thin whisps of moving 3d clouds in the sky if you place it in the editor. It works for me and it looks nice.

Let's leave the objNull end execVM part of your command line for a while, ok? Here's a straight forward (and working) example based on what you want to achieve. Assumption: Player must capture helicopter1 and destroy helicopter2. It's a MP COOP game and any player may complete the task. Mission Designers Problem: You must fins a MP-safe way to decide when the first helicopter is captured and the second one is destroyed. Solution: If a player is piloting helicopter1 it's only fair to say that he has indeed captured it. Make a trigger: CONDITION: driver helicopter1 == player ACTIVATION: heloCaptured = true; publicVariable "heloCaptured" player is a handle that refers to any unit played by a human. As you might have guessed the above trigger will therefore only fire on one machine (I have fiddled with the condition line and replaced this). But since I use a publicVariable heloCaptured will nevertheless be true on all machines. Now make a second trigger, to check if the second helo is detroyed. CONDITION: !(alive helicopter2) ACTIVATION: heloDestroyed = true A unit that is killed will be registered as dead by all machines in the network. Hence no need to broadcast a public variable this time. Now it's time to tick off the task objective in the briefing. make a thrid trigger: CONDITION: heloCaptured AND heloDestroyed ACTIVATION: tskobj1 setTaskState "SUCCEEDED"; Since this trigger will now fire on all clients the task will be ticket off on all machines more or less simultaneously. You may face a discrepancy of up to three seconds between server and client, but that is a game engine limitation. It cannot be affected.

[soldier1, soldier2] join player

The elitist aproach to BI games sometimes seen on these forums is indeed annoying, as well as extremely childish. But I doubt that it has affected sales or the size of the community that much. The fact that Codemasters (being a multinational worldwide corporation) gets more attention when they promote an upcomming release, than a smallish and independent czech company with limited budget do, isn't really suprising in my opinion. If I google my own name I get 745 hits. If I google Brad Pitt I get 23 900 000. Admittedly I don't have the nicest personality in the world, but I'm quite sure that Mr. Pitts status as a world famous actor is the explaining factor here. Not my own shortcomings when it comes to social skills. :)

I'm afraid not. The missions remain the same. If you link a SecOps Module to an unarmed civilian riding a bicycle, he/she will still recieve requests to take out enemy camps and escort friendly squads through hostile territory. The Secops Module is a great addition to the game, but it's not that great ;) EDIT: It's possible to control what type of missions will be spawned. You may find a post explaining how to do that here.

I'm not sure I understand your problem correctly, but this is how it works. Forgive me if my answer seems obvious. I'm not trying to lecture you, just trying to keep it on a basic level: Problem: When you change a variable, the change is sometimes just recognized on the client where the change takes place. This can be a problem in MP games. Example 1: If you change a variable in the activating line of a waypoint, the change will only be registered by players/client in the group that triggered the waypoint. If the unit is completely AI controlled the change will only happen on the server. Example 2: Lets say that you have started a script using the addAction command. This script will only run on the client where the player who triggered the action is playing. Any variables changed in the script will then register on his machine only. The server and the other players won't know what is happening. The publicVariable command is the solution to the above problem. It can be used to broadcast the variable to all clients in the network. Example 3: myVariable = true; publicVariable "myVariable" This will be recognized on all machines. Example 4: myVariable = true; This may only be recognized on the machine where the command was given. Generally speaking variables and commands behaves like this: Triggers: An editor placed trigger usually fires simultaneously on all machines. Hence varaibles changed in a triggers on activation line will be recognized by all clients in the network. Including the server. Scripts started from triggers will run on all machines. The only exception to this rule is if you fiddle with the condition line of the trigger. As long the condition is left on it's default this, all triggers can be regarded as a MP safe. Waypoints: Changes made in the activation line of waypoints are local. Scripts started from waypoints may not run on all computers. Some clients will miss varable changes issued here. Hence waypoints are not MP-safe. Use publicVariable. Scripts: The init.sqs or init.sqf is run on all clients including the server upon mission start. It can therefore be used to change variables for all players simultaneously. It is MP-safe. Scripts started within missions are not MP-safe, unless you start them from a trigger (see above). Happy editing :) EDIT: OFPEC Forum has an entire board dedicated to resolving Multiplayer Issues. It's a very good place to ask for help with all MP questions, basic as well as advanced. Just follow this link.

Sorry for my ignorance, but if I understand you correctly these cruise missiles are already available in ArmA2? They're just hidden and you've found a script that enables them. Am I assuming correctly? I have no testing opportunities at the moment.

If you make a custom weapon addon you can set the zoom value for the optic sight of that particular weapon though. Apart from that: only a FOV change in the user profile can help you (as suggested above). Other zoom methods: Hold right mouse button (gives you weapons view zooming and hold breath) Numerical + (allows you to zoom in/out without holding your breath, can also be used even if you aren't looking through a scope) Double tap numerical + (locks your view in maximum zoom)

If you synchronize a load waypoint with a get in waypoint it should happen automatically.

Or place an empty marker and give it the correct shape/color/etc with the commands: setMarkerType setmarkerColor setMarkerText You can read more about the commands in Ofpec's comreh here: http://www.ofpec.com/COMREF/

This is not the correct way to use publicVariable. This is: 1) Change the variable on one computer first 2) Broadcast the change to the clients afterwards Assuming that kolmas was false to begin with, the above code will only ensure that every client in the game continues to regard kolmas as being false, and then you change it to true on one computer only. The correct syntax would be: Kolmas = true; publicVariable "Kolmas"

Join the other side and play as a russian. Maybe that helps? :)

It's one of the standard random missions that comes from the Second Operations manager (found under F7 in the editor). The SOM should be disabled in Manhattan, and isn't supposed to hand out side missions. It's only there to give you access to Starforce21 and the artillery. But there's a glitch in the game engine, that sometimes let's the sidemissions slip through, even if they were disabled by the mission designer. I suspect that what's happened. Or maybe the SOM is switched on from time to time via one of the scripts running in the background. I haven't searched all of them for SOM references.

Personally I don't enjoy being shot at all, regardles of the other circumstances involved.

I liked Operation Underdog a lot and I gladly help you fine tune your next mission before it's released. Another idea that I like is a story driven death match, where the opposing players have separate agendas, but the mission doesen't require them to confront each other. Albeit if one player fulfills his main objective, the other player should fail a minor objective. Thus giving the players an incitament to hazzle each other during game play, but not necessarily exterminate one another. With multiple slots on both sides you can then have two Coop missions running at the same time on the same map. Or you can play it as a randomized SP or MPcoop mission, if you lack others to play with. Very good for replayability. EDIT: I voted yes, BTW ;) EDIT 2: Grow up and get some manners, will you? If you don't want to watch the intro you can always disable it at MP setup. JIP or not. There's no need to be rude because some people likes to spend time pleasing other people with top notch missions, that they hand out for free for you to enjoy.

The Guarded by trigger behaves more like a marker than a trigger, unfortunately. It would be nice if they could be activated at certain times within the mission and then unactivated again. Unfortunately you still cannot do that without doMoves and markers. Plan carefully before you place any guarded by triggers on the map. The AI will protect the trigger you placed first more fiercly than the second and third. They consider the first placed guard trigger to be of higher priority.

You are dead wrong. When a mission is exported every file in the mission folder is copied to a single pbo. You may even include files that are of no use to the game engine, such as readme files. It's been that way since OFP. Armed Assault and ArmA2 uses the exact same method. EDIT: Kegetys Tools are useful, but you don't need them to export missions from the editor. You need them when you want to move a pboéd mission into the editor.

Not completely true. You may deleteVehicle any unit manually, as long as a human player is not playing the unit in question. If a human controls the unit, deleteVehicle will do nothing.

Harryohh is just trying to be funny by spaming the forums. There is no such thing as patch 1.16 in the pipeline (next one will most likely be named 1.04 since they follow a chronological naming pattern). Download the patch and install it. I've never had any problems with 1.03. I only had minor issues with 1.01 and 1.02 though.