Kamakazi

Cant find my reference - but im fairly sure there is no module now, all of the BiS A3 functions are initialised before the map. So in effect they are always available all of the time. No need for any module. Perhaps one of the others can chip in with the reference and explain it better. Im sure it was Dev Moricky

I cant answer all your question, im still working a lot of this out too. I hope this will help and deserves more general circulation http://www.arma3.com/news/this-is-war-photography#.Ul0z2hCjHmF

When you run #monitor on the server the number returned is nothing to do with fps. Many associate it with a graphical term when the server draws nothing visually. I have lost my original reference sorry, but I believe is correctly called a simulation cycle so it is i guess more of a 'cycles per second'. What that is exactly only Suma could answer - but my guess it is every single object that has to be updated, moved, blown up or whatever. Not so confident on this next bit, but on top of that the server would be trying to send the information to every client AND calculate the next cycle ahead of the current one. Possibly even several ahead of the current one. Imagine the load and lvl of calculations to move every trigger finger and update this - in real time - Arma realy does push whats possible on something the scale of Altis. Low server cycles means low client fps because it (the server) simply does not know what happens next and cant transmit and syncronise anything about any object or player updates until it does. The server must basicly be one step ahead of anything a player see's at all times.

The _x is just the placeholder every time you loop - its a different unit if (side player == blufor) then { { if (alive _x and side _x == CIVILIAN) then { _x addAction ["Detain", "detain.sqf"]; }; } forEach allUnits; }; sort of the rough logic as I read the code Take a unit - call it _x Is it bluefor is it alive AND a civilian then Addaction NEXT unit finnish when you have checked EVERY unit on the map The _x increments every time you loop through - its a pointer to the current unit being checked. The _x is LOCAL to your FOR ... NEXT It is a system/ engine variable used to just keep track of where it is in the process Hope that makes sense. There are some good examples in the forums written by better coders than me - a couple of them were linked earlier. Do some searching for more examples of this used in similar pieces of code

You have created a For .... next loop with the forEach allUnits; piece of code This makes it step through the code for every single unit on the map - as it steps through the code the _x is the LOCAL variable currently being worked on In this case it is a specific unit, incremented as you go though all the units - an engine variable

I think its to do with the way DX11 works. The behaviour is different to how A2 worked and it was a DX9 program. It also interferes with Win7 - constantly poping up a window to kill theme's - you can try ignoring it but it will constantly pop up a demand to reset basic Win7 desktop Set your game settings to FULLSCREEN WINDOW - you will see your second monitor again, problem gone.

the units need to be unassigned from the vehicle - to stop them re-boarding it https://community.bistudio.com/wiki/unassignVehicle removes them from its cargo list

Works every time Baf Chinook called chop waypoint on activation box chop action ["useWeapon",chop,driver chop,1]; fires once

Dont know where to start, animations are one of the more complex and hidden parts of Arma. Lots of useful threads on the forums - do some digging. You have some reading to do. Good starting point might be this http://forums.bistudio.com/showthread.php?115889-PvP-Animation-replacement-enhancement-pack&highlight=animation+pack Probably state of the Art user made animations and poses Hard to judge your level of knowledge with only one limited post. So i added this link to try and put across some of whats involved to make new animations and link them to models/ rest of Arma. http://forums.rkslstudios.info/viewtopic.php?f=33&t=177 This is from a long time contributor of models, tutorials, pretty pictures and technical expertise. His Forum and several similar linked from posts you will find searching here.

good question, think i had an Ai group all individually named - just gave it a waypoint to board the chopper first, before any cargo - Ai will (usually) fill all the weapon stations first. Lost my original reference sorry - turrets a pain sometimes - quick search got this - might help if you can read its code. One of the real code heads might come up with better http://forums.bistudio.com/showthread.php?116330-assignAsTurret-moveInTurret-workaround&highlight=chinook+gunners and http://community.bistudio.com/wiki/moveInTurret

I had a lot of similar problems a while ago, had a BAF chinook landing into a hot zone, lots of unfriendly infantry about. The pilot responded to the threats and usually hit the ground/ mountain before clearing the bad guys out. Eventually used a couple of the newer AI commands - using Arma OA - placed this into a waypoint on its approach, before the "unload" part. The pilot was a specific named unit added to the empty chopper, all my crew were named individualy and boarded with the player cargo pilot disableAI "AUTOTARGET"; pilot disableAI "TARGET"; pilot disableAI "MOVE" This stopped him engaging, calling targets and moving to engage them leaving his gunners free to fire independently. Will take a little adjusting - the order of the waypoints when he goes into danger etc - worked well for me - the gunners engaged all the way onto the ground - during unload and on the take off/ way out. It forced the pilot to stay on the waypoints regardless. Hope this helps. The locality thing is important - good luck with that, basically keep the SERVER in control - anything defined on the Map from the beginning are global like the poster said earlier. If you need a working example of this I can point you to my map hosted on the [LOL] Clan server. co08_baf_LOL_Insurgents_V2 Same thing should work with the boats, I would have a specific unique driver name and refer to him as a global variable in the same way. Remember, I use the waypoints they good way to stay global and have a series of 'steps' as the unit/ driver/ vehicle approaches, delivers, waits, then buggs out.

You have the script just inside your mission folder?? Precisely how and where are you calling it?? The game error is looking for the script inside a folder inside the mission folder. Just change the reference when/ where the script is called or put inside a folder called 'scripts'. Open up a few more missions to get idea of internal structure. This is good practice anyways to seperate and keep stuff tidy in a busy mission.

Not the best answer. 1. Be the driver or move to driver before getting out 2. Make driver get out 3. Plan for him to move More a workaround until simple things like default AI get more PR. Done with a script in a mission - you would probly do the same 'routine', move position before get out or giving a chain of them to put driver back where he came from. If your inclined - CSLA and a couple of other mods have very nice 'unload' scripted routines.

Keep it simple, Create a trigger, make the area as big or small as you like. The size of the prison? set the condition 'not present' so its activation is when player leaves this area. Then use "pow1 setCaptive false;" or whatever neccessary. Basicly your just making a simple 'distance from guards' effect. The editor placed triggers can do all of this without any real scripts or fancy logic to break. The more complex it is the harder to trace any issues.

I feel your pain, yes documentation is sketchy at best, constant development has caused a real lag in clean information. There is a lot of real gems out there, http://www.ofpec.com/ and other sites like https://dev-heaven.net/. You will still have to sift through it to get what you need. The information is out there, but poorly distributed up until recently. One of the best examples for me is something like the Domination missions. Some fantastic coding with a number of features highlighting very sophisticated code. Arguably better put together than any of the original vanilla missions. Full of efficient snippets and specialised examples. It has taken months if not years to filter and disseminate all these best practices though the community. You can see it in level of sophistication now being used in common addons, or mods like DayZ. The bar moves upwards, I just wish we could have more definitive documentation to speed up this process. If you want an example of anything or more pointers usually worth asking the nerds here on the forums.

The posted code need to be saved as a "Something.sqf" - basically a simple text file, contained in the missions folder. Its then called from the mission, and the code is then executed as and when needed by Arma. Did you d/l the example mission from that thread ? Its a simple folder to be opened in the editor. Most missions contain many similar .sqf or .sqs files. They work outside the editor, and are called in as needed to serve some logic/ function/ effect needed by the author. That example uses 'init.sqf' a special script run once at the star of every mission, used to define and initiate the map and its elements. Usually the folder is then 'zipped' as a single file, the .pbo you normally see as a mission d/l. Missions often contain dozens of small script files or images- the resources need by the mission - within this pbo. Maps are as simple or complex as you can imagine, very time consuming detailed work. Its normal to define every single element by hand. Arma has many levels of complexity. Making AI do nothing is not easy, so many variables and built in 'intelligent' routines that make them respond and fight. They react to what they see and hear, you have to minutely control them and the environment, its often why .sqm /script is used in the first place. Will take a while to build up any sort of understanding why the AI do what they do, we are all still learning, they are that unpredictable and adaptable. One of the best ways to learn is sort of reverse engineer some of these missions and try to follow how it was done. Start small and simple. Lots of examples about in this forum, good luck. Quick useful links - http://forums.bistudio.com/showthread.php?134274-Arma-2-Editing-amp-Scripting-Tutorials-Youtube a good place to start http://forums.bistudio.com/showthread.php?78089-Mission-Editing-and-Scripting-Information-Links-only-NO-Discussion

Leopardi - check the uppercase/ lowecase FOLDER/ kohde they dont match and game never found the mod. Devil is always in the detail

It an old problem, many struggle at first. You have most of it sorted, but dont quite grasp all the variables at play. The editor is powerful but not intuitive, you have to precisely instruct or control the AI to achieve what is a common mission element. Name your units when you place them - easier then to use code snippes/ commands on significant AI. Couple of threads very old and new ish explaining similar misunderstandings. Search more and find dozens http://forums.bistudio.com/showthread.php?128352-Osprey-quot-Transport-Unload-quot-Hotzone-Eden http://forums.bistudio.com/showthread.php?9612-quot-transport-unload-quot-problem Follow your logic closer - start with empty helicopter - add crew seperately - movin cargo - explicitly state their names and set behavoiurs. At the right time, your cargo units are never assigned specificly to that chopper - hence chopper hangs waiting for the 'unknown cargo' to get out, yet cargo never recieves that order. Sort of double whammy. Could just be as simple as put this command into on activation line of unload waypoint : "unassignvehicle _x" foreach (units group player) Build with small logical steps and try to understand the "WHY?" http://www.armaholic.com/page.php?id=4847 Armed Assault Editing Guide - Deluxe Edition - English version by Mr-Murray Take time to read some of the great guides out there and have fun. answer to edit 2 Yes, you were an obstical - and which way was the wind blowing - both effect pilot AI

Basicly you need to de pbo the original campaign files. Working from that as your example. The structure of folders is similar inside one campaign folder, There is one campaign description.ext that defines how and in what order stuff happens. class CfgIdentities {}; class CfgSounds {}; class MissionDefault { lives = -1; lost = ; end1 = ; end2 = ; end3 = ; end4 = ; end5 = ; end6 = ; }; class Campaign { name = $STR_camapign_name; firstBattle = Beginning; class Beginning { name = "The Beginning"; cutscene =; firstMission = C0; end1 = ; end2 = ; end3 = ; end4 = ; end5 = ; end6 = ; lost = ; class C0: MissionDefault { end1 = C1; end2 = C0; end3 = C0; end4 = C0; end5 = C0; end6 = C0; lost = C0; template = C0_FirstToFight.Utes; }; class C1: MissionDefault { end1 = I1; end2 = I1; end3 = C1; end4 = C1; end5 = I1; end6 = C1; lost = C1; template = C1_IntoTheStorm.Chernarus; }; class I1: MissionDefault { end1 = C2; end2 = I1; end3 = I1; end4 = I1; end5 = I1; end6 = I1; lost = I1; template = I1_AmphibiousAssault.Chernarus; }; class C2: MissionDefault { end1 = C2B; end2 = C2B; end3 = C2B; end4 = C2; end5 = ; end6 = C2; lost = C2; template = C2_HarvestRed.Chernarus; }; class C2B: MissionDefault { end1 = I2; end2 = I2; end3 = I2; end4 = C2B; end5 = C2B; end6 = C2B; lost = C2B; template = C2B_RazorTwo.Chernarus; }; class I2: MissionDefault { end1 = C3; end2 = I2; end3 = I2; end4 = I2; end5 = I2; end6 = I2; lost = I2; template = I2_OneWeekLater.Chernarus; }; class C3: MissionDefault { end1 = C4; end2 = C4; end3 = C3; end4 = C3; end5 = C4; end6 = C4; lost = C3; template = C3_Manhattan.Chernarus; }; class C4: MissionDefault { end1 = C5; end2 = I3; end3 = C4; end4 = C4; end5 = C4; end6 = C4; lost = C4; template = C4_BitterChill.Chernarus; }; class I3: MissionDefault { end1 = C5B; end2 = I3; end3 = I3; end4 = I3; end5 = I3; end6 = I3; lost = I3; template = I3_DelayingTheBear.Chernarus; }; class C5: MissionDefault { end1 = C6; end2 = C6B; end3 = C6; end4 = C6; end5 = C7C; end6 = C5; lost = C5; template = C5_Badlands.Chernarus; }; class C5B: MissionDefault { end1 = C6; end2 = C6B; end3 = C6; end4 = C6; end5 = C7C; end6 = C5; lost = C5; template = C5B_Badlands.Chernarus; }; class C6B: MissionDefault { end1 = C7A; end2 = C7B; end3 = C7C; end4 = C7D; end5 = C6; end6 = C7EF; lost = C6; template = C6B_DogsOfWar.Chernarus; }; class C6: MissionDefault { end1 = C7A; end2 = C7B; end3 = C7C; end4 = C7D; end5 = C6; end6 = C7EF; lost = C6; template = C6_DogsOfWar.Chernarus; }; class C7A: MissionDefault { end1 = ; end2 = ; end3 = ; end4 = ; end5 = ; end6 = ; lost = ; template = C7A_WarThatNeverWas.Utes; }; class C7B: MissionDefault { end1 = ; end2 = C7B; end3 = C7B; end4 = C7B; end5 = C7B; end6 = C7B; lost = C7B; template = C7B_SettingSail.Chernarus; }; class C7C: MissionDefault { end1 = ; end2 = C7C; end3 = C7C; end4 = C7C; end5 = C7C; end6 = C7C; lost = C7C; template = C7C_MissingInAction.Chernarus; }; class C7D: MissionDefault { end1 = ; end2 = C7D; end3 = ; end4 = ; end5 = ; end6 = ; lost = C7D; template = C7D_EndOfAllThings.Chernarus; }; class C7EF: MissionDefault { end1 = ; end2 = ; end3 = ; end4 = ; end5 = ; end6 = C7EF; lost = C7EF; template = C7EF.Chernarus; }; }; }; class Awards {}; class Penalties {}; This is from the Arma2 original campaign, and is a small part of the research you need to start from. http://community.bistudio.com/wiki/Campaign_Description.ext for more details Good luck

OK, yes slightly different question. I'm not qualified to give a real answer on server efficiency in that way. I understand enough to stagger my scripts inits, usually with waypoints calling them (on map and global/ server) - randomly coming online over a few seconds as a unit gets to a point, avoiding the glut of traffic that Neo describes above. Quite a few problems with init lines MP, most have a solution. The server still has to have the basic capacity for what your doing, 30 groups suddenly active, local or global, can be a big lag. Again there are ways around this by disableFSM/ enableFSM tricks or staggering it with intelligent pauses. Big yes, good basic mission design - you have a good grasp of what Arma can do - script/ editor meh who cares, I would realy like a definitive answer myself but experiment is the nature of the game. Its such a flexible engine there must be ten ways to achieve anything. Good luck.

ahh - my bad then. Thanks for the tip about Halo scripts resetting direction. As always your full of nuggets.

Editor first - always for me With a few syncronised triggers or way points i can create much of the theatre im looking for. Objects are on the map from the start. Easier to 'see' and learn how these things interact and how the game engine moves along. Generally less problems in multiplayer too - everything on the map is the server. Fewer locality issues for me. Triggers/ waypoints etc are global, again keeping it simple. Small code snippets at the right time are very powerful, nudging AI into the scanario. Default behaviours when understood can create much fun and mayhem easily/ visually on the map. My scripting capabilities are limited. Will use it when its neccessarry - say a parachute eject script, or some fancy way of dealing with a specific dead entity. Generally i 'borrow' snippets or code thats proven itself - GDT respawn scripts, Norrins excellent chopper suite - easy to link into and add a sophisticated edge to your maps. I like to 'see' my map, the flow and density of objects etc - guess im just that kind of visual head type. All of the visual things we see on the map when editing are 'easily' reproduced with script. But its not easy building logic and code when the simple load a helicopter scenario is not understood properly. Some things are best done with script - its a brave man that scripts everything. Using Benny's warfare as an example, thats the only way to do it. The rest is probably done in Editor, Keeping it simple, linking into scripts as and when neccessary. Keeping elements of the scenario apart helps bug stomping Neo 's post is from a code head's perspective - What im trying to say is take your time - understand the basics properly - concepts of locality - default AI behaviour - then find your own way ;)

You created the player in the editor and start the halo scripts from its init line ?? Can change the units original orientation as it is placed - compass/ circle thing lower right. Edit unit box. Not as obvious as it sounds at first. F1 -units Double click him and fix it easily.

You have opened the missions - edited stuff and saved it with a new name?? There is an odd quirk in saving. Saving a new name creates a folder with a mission.sqm in it, nothing else. mission.sqm is a very special file containing all of the starting positions and basic init details for the map. Most, if not all, missions need other files inside the folder explicitly referenced by and interacting with the mission.sqm you have just created. These are more common in the big scripted missions, but many are essential for a proper map to function, especially in MP. Examples- description.ext init.sqf loadscreen.paa briefing.html Other folders Anything the mission needs has to be inside the folder - the whole thing is then bound up when you make a .PBO With a new save/ folder it does not transfer these files - you have to cut and paste them into it if a missions had 'stuff' inside before you edited - best put all of it back before running it default space for all the mission/ folders while editing. C:\Documents and Settings\USER\My Documents\ArmA 2 Other Profiles\PLAYERNAME\missions\ good luck

Realy great stuff here panther, Arma2 misses a lot of potential atmosphere in missions. Airports on maps have similar simple "automatic" systems but are frustratingly hard to work with. Potentially weeks of work just to make it look normal and active. The mission maker has to do all the precise work specific to each single mission. We need more similar modules/ FSM whatever to encourage "natural" behavoiurs. A bit like the random civilian modules they take away the artificial feel of many maps. This is the next step, combining many of the best functions/ mods/ scripts. AI airtrafic control is the next hurdle. kheiro - equally impressive work. Can't wait to blow it up.