wolffy.au

Thanks for the feedback guys. You can blame my new PC to lack of activity, as I've spent 3 days trying to get the best quality/frame performance in ARMA2. For everyone who has posted issues above, please confirm you are using the build from the MSO File Tupolov has posted above (http://dev-heaven.net/projects/mso/files). By default, I have turned down the intensity of everything. If ambience is still an issue, there is a setting for that, which I can turn down also.

Download: http://dev-heaven.net/projects/mso/files What is an MSO? The Multi-Session Operation (MSO) is a reality-based game mode: it is a persistent mission simulating real-life warfare to the best of our abilities with ARMA 2's capabilities. Unlike hour-long single-session missions that restart when the players disconnect, an MSO mission can persist for days, weeks even. When you disconnect, your location, health, weapons and ammunition are saved for when you reconnect. Up to 4,000 enemy units could be out there waiting for you 24 hours a day. Most of the components revolve around realism, although its up to the mission editor what their MSO consists of. The seeds of the MSO began with Rommel during ARMA 1 until recently when a request was put out to assist in developing this game mode. Nov, 2010 - Wolffy joined in the development of the game mode to the point where we are today. Other members have contributed greatly testing and creating documentation. Here are two of our manuals: MSO User's Manual MSO Editor's Manual The MSO is a collaboration between Australian Armed Forces clan and AEF Combat Team Bravo. If you have any questions or are truly interested in making and developing MSO missions with us, then contact us on our website, Skype or Teamspeak. Forums: http://www.ausarma.org/forum/viewforum.php?f=49 Dev-Heaven: http://dev-heaven.net/projects/mso Skype: ryeonaaf, rommel160 or wolffy.au Teamspeak: ts.ausarma.org port 9987 What are MSO modules? The MSO is really a mission building framework, with 3 example missions provided. It contains a number of modules that can be included in your missions if you wish. The modules provided are: RMM After-Action Reports: You'll need a radio to submit AAR's. Let players that come online after you know where you engaged, how many were there, etc. Usually good to mark it up with a JIP marker. RMM Close Air Support: Call in an A10, Apache or Cobra to lend a hand. RMM CASEVAC (in development): Call in a dust-off chopper. CEP AI Unit Caching: Originally based on Myke's CEP AI Caching, reduces AI squads to squad leaders only if all players are 1000m away. CRB Ambient Civilians, Traffic, Vehicles and Animals: A patched version of the BIS modules that works perfectly on dedicated servers with minimal CPU load. RMM Construction: Simplified Construction module CRB Convoys: Spawns random convoys from the edges of the map to a destination. Great for recon and ambushing. RMM Call To Prayer: Initiates a Call To Prayer multiple times of the day while in Takistan or Zargabad. RMM Developer Debug Console: Great for debug or spawning objects. CRB Dogs: Uses Big Daddy's Blitzy code to provide wild dog packs and patrol dogs. Random Enemy Population: Spawn random enemy throughout the map on hill tops, in forests and within towns. Can populate the map with thousands of AI waiting to spawn when you come within range of them. CRB ATV/Motorbike Flippable: Useful for up-righting ATVs and Motorbikes Gen Carvers Pack Cow: Uses General Carvers Insurgency Pack Cow. RMM JIP Markers: Persistent time stamped markers that stay on the map between sessions. RMM Logbook: Journal for general information RMM Logistics: Simplified Logistics system Multiplayer Rights: Restrict players to infantry, crew and pilot roles (see below). RMM NOMAD: This is the MSO module. NOMAD maintains the persistence in between sessions. R3F Logistics: R3F Logistics for MSO. Recruitment: Recruit and control AI for your squad. Uses Dr Eyeball’s Team Status UI. RMM Revive: Simplified Medic Revive system. RMM View Distance Settings: Set your view distance and terrain grid detail. RMM JIP Tasks: Persistent tasks that stay with players between sessions. RMM Tyres: Allows the changing of tyres on vehicles RMM Weather: Randomly synchronised weather generation and forecast. Customised ZORA: Using BIS ZORA module, generates enemy randomly who will head towards you within a few kilometers of your position. Great for those random incursions. Item Re-Supply Due to the length of these mission, re-supply of building supplies, ammunition and vehicles needs to be catered for. There are 2 types of re-supply: static re-supply (building materials, ammo crates, etc) whereby items are respawned once they have been move 10m from their original location, and vehicle re-supply (vehicles, artillery pieces)whereby, once the item is destroyed will it be respawned. Sample Missions Mission: GUE/PMC vs RU/INS on Utes Version: 3.3 Developer(s): Wolffy.au Required Add-Ons: CBA Mission: BAF/USA vs TK_GUE on Takistan Version: 3.3 Developer(s): Wolffy.au Required Add-Ons: CBA (optionally BAF) Mission: AAW/ACE vs GUE on Chernarus Version: 3.3 Developer(s): Wolffy.au Required Add-Ons: CBA, ACE, ACEX, AAW_OA (optionally ACEX_RU) How do you play the sample missions? It is really up to the imagination of your Commanding Officer. Typically this will involve recon, patrols, assaulting static positions, clearing areas and settings up Checkpoints and Fire-bases, or recon and ambush of enemy convoys. If you’re by yourself, go do some recon or covert ops. Place JIP Markers for what you see and add Tasks to the mission. When the next bunch of guys come in, they can take over where you left off. Take a moment to familiarise yourself with the layout of your FOB and the resources available to you. When you find the infantry ammunition crates, carefully select your equipment to ensure you can remain combat effective for several days on patrol. Do not count on resupply in the field. Frequently Asked Questions Why can’t I connect anymore? Most likely, you’re trying to connect as a different class than you did the first time. Just choose the class you previously used and it should be fine. The only other reason is that you’ve run out of lives. You’ll have to wait until the mission is restarted to join again. What am I supposed to do again? Go on a patrol or recon an MSR. Make sure you mark what you engage and see using JIP Markers and fill out your AAR’s ASAP for the rest of the team to benefit. Will the vehicles respawn? They’ll only respawn if completely destroyed. If they are repairable, mark them on the map using JIP Markers and treat it as an objective to recover them. What should I take with me on patrol? MASH tent, ammunition, a mortar is handy, some spare tyres and anything else you think would be great to have in a squeeze. Why is there so much mess at the base? Its all building materials for you to go forth and reproduce. Pack what you need in a shipping container (transport by heli) or in a truck, and go setup a Fire Base on a hill top somewhere. Your team will really appreciate the Artillery if you need to take down something big. Server Installation and Setup The one thing the server admins will need to do is setup MP Rights. Create an mso directory under your server’s ARMA2 directory (for example C:\Program Files\Bohemia Interactive\ArmA 2\mso) and create a text file called mso_uids.txt. Its contents should look something like this: [ ["1234", "CORPORAL", ["crew"]], /*namex*/ ["4567", "PRIVATE", ["pilot"]], /*namey*/ ["7890", "LIEUTENANT", ["admin"]], /*adminx*/ ["6789", "SERGEANT", ["pilot","crew"]] /*namez*/ ] Each line identifies a players UID, rank and roles. Without these, new players should not be able to crew armour, pilot aircraft or use the admin debug console.

Download here - http://creobellum.org/node/54 This mission is to demonstrate the use of automated Mine fields. Use the radio commands to teleport and camera functions. Usage: To use, drop rectangular markers on the area you want to cover and edit your Init.sqf file with the following: call{["Mines","Mines_1"] execVM "crB_scripts\crB_MineFields.sqf";}; Where "Mines" and "Mines_1" are the marker names. The area will auto-populate with danger signs and hedgehogs. To state the obvious, yes you will explode if you enter the area. Created by: (AEF)Wolffy.au [2CAV] Change Log: Changes - v1.2 - Markers indicating mine fields are drawn without delay. - Triggers are placed without delay - Each minefield marker is populated in its own spawned process - Removed real mines from function to improve FPS - Reduced number of objects per metre to improve FPS - Added hedgehogs to prevent vehicles from entering the area - Added multiple blast size options - Odin - Changed only healthy or lightly injured units will trigger mines - Odin Changes - v0.2 - Fixed angled markers - Added marker array inputs - Fixed not killing everyone Thanks to: RotatePosition function by Joris-Jan van't Land Visit us a http://creoBellum.org

MSO use two different methods to minimise AI CPU when they are far away. The first method was infact originally written by Myke as part of his Coop Essentials Pack in Arma1. I've heavily modified it, but the core is still the same code he wrote, whereby if a group is 'x' distance away from all players, it is reduced to a Team Leader only and continues on its patrol, etc. The group 'respawns' once they are within distance to a player. The second method was suggested by Nou and although not as CPU saving as Myke's method, the advantage is units remain entirely intact but all their simulation is disabled when they are 'x' distance from all players. We use the enableSimulation command. MSO is a game mode whereby you can disconnect/reconnect to a mission (and resume exactly as you were) which means it can last for days. Supply and logistics, building FOBs, etc all become a worthwhile exercise when you know they will be around for a week instead of a few hours. See http://dev-heaven.net/projects/mso for more info.

Are you referring to the vanilla BAF/USA MSO? Those are the default BIS models - I didn't think they were Delta Force.

Ok guys - I'm putting the call out there. If you've got MSO's you're willing to update to 3.42RC, I will distribute them as part of the 3.42 release. I am about to upload a bunch of missions as 3.42RC's and I ask if you're able to help "fix" any mission related bugs (vehicles missing, gameplay stuff), please do and re-submit back to me. If its an MSO bug (broken functionality), I'm happy to get a ticket logged and we'll try to fix. Unfortunately what I'm finding is that I don't have enough time to release, let alone fix every mission I want to distribute. If you play an RC mission, and somethings broken you can fix - please do and get back to me with it for re-distribution.

Have you read the Editors manual (although its outdated?)? http://dev-heaven.net/projects/mso/documents

All great ideas guys. I will release tonight hopefully and start work on a TvTvT version. Any of you are welcome to pick up these ideas and join the team in making a version as described. The more, the merrier.

So guys, a conclusion I am reaching is that the MSO cannot have all the Enemy modules running at the same time with 100% intensity. What do you guys think about about MSO's that only run Terrorist Cells, or only run Enemy Pop? The other option is all enabled by default but all running at low intensity, so we don't kill the servers with AI numbers. What do you think guys? Any suggestions?

Yes, just put that line in your Activation Field. Not sure if 'position this' works, but its worth a try.

There is a side parameter in there, for which side you want to spawn.

I don't have time to reply to everything, but you can add Refuel trucks with AI drivers on SUPPORT waypoints, and the OPFOR units will call them out when they need fuel. Try it, let me know if it works for you.

No, the AI handoff is not in that code. Nou's Caching was supposed to reduce the amount of network traffic by not deleting/recreating units across the MP game, but rather suspend and hide them until they were needed. My suggestion is take this discussion to the MSO thread, as Nou's Caching is my implementation of his idea and not necessarily anything to do with distributing AI processes among clients (yet).

Yeah - RL gets in the way. I'll package up what I got and release. It may be a little buggy, but I'm sure we can work out the hitches between us (read that: you guys will fix what you can and give back to me to redistribute! :D)

Good to see - the more places you can use the MSO code, the better. I was planning to put in a dedicated server compatible SOM next, but no timeframe on when it will happen unfortunately.

Big thank you to Friznit2 for updating the MSO Users Guide! It can be found here: http://dev-heaven.net/projects/mso/documents

Thanks guys - my 3rd, first daughter. Unfortunately keeping me away from the keyboard most nights, but we'll get there.

No it doesn't work that way. It counts the total number of "locations" on the map (+600 on Chernarus, +400 on Takistan) and iterates through them using the formula above. Depending on the random outcome, a unit is spawned. Part 2 of that is, the AI is not "spawned" until you come withing 2000m of them, thats why flybys are not good for server performance. Once they spawn, they cache, but the performance difference between the two is significant. Yeah, not sure how it would affect game play, but it can be done. The potential there is you approach a location, it doens't spawn cause the limit is reached, you kill a few guys and they spawn in your vicinity. Might be able to get around it by ensuring no one spawns within 2km of any player. Can you log this as a feature request please? ---------- Post added at 22:58 ---------- Previous post was at 22:53 ---------- It basically means, you have 8 times more chance of getting a Infantry patrol than an Armoured patrol, etc. It doesn't mean for every 8 infantry, you will definitely get an Armoured patrol, but with randomness, you would hope it works out to something like that. Log a bug please - once I release v3.41 (when my newborn lets me), I will start going through bugs.

Never tried. Its an interesting point, as to make it PvP, it would need to take sides into consideration, so I'm interested in how hard it is to get working.

The intensity decreases the chance of random spawn. The an example formula is: (random 1 > 0.33 / rmm_ep_intensity) where rmm_ep_intensity is 0.25, 0.5, 1, or 1.5. Low intensity (0.25) would be: random 1 must be greater than 0.4356 whereas high intensity (1.5) would be: random 1 must be greater than 0.222 I know, not a huge variation, but a variation none the less! :)

Not sure as I've never used I44. Maybe DPG-Wall can let us know how he got it to work. Norrin's Revive is difficult to turn into a module, but can still be applied to the MSO. Reezo's Ambient stuff is not MP compatible, so I still need to fix it before I include it. IIRC v3.41 has an Enemy Pop Intensity mission parameter, which should help. Let me know if this is sufficient.

Well, the MSO gets its fair share of "why is this mission killing my server?"!! So I've written a method to "profile" my functions, by measuring how much time they are spending executing and being about to identify the "hogs" of my scripting. I'll publish here what I've done and feel free to re-use (credits are nice) but in all honesty, its really is dead simple. To use it, this is what you do. private ["_profilerid","my_other_private_declarations"]; _profilerid = ["start","A name to identify my function"] call mso_core_fnc_profiler; // this is // where my //. CPU intensive // code goes ["stop",_profilerid] call mso_core_fnc_profiler; Here's the code that does everything. The code that makes up mso_core_fnc_profiler is this: private ["_result","_param","_status","_start"]; _status = _this select 0; _param = _this select 1; _result = 0; if(isNil "CRB_PROFILER") then { diag_log "CRB_PROFILER,NAME,TIME"; CRB_PROFILER = []; }; switch(toLower(_status)) do { case "start": { _start = diag_tickTime; _result = count CRB_PROFILER; CRB_PROFILER set [_result, [_param, _start]]; }; case "stop": { private ["_id","_functime"]; _id = _param; _param = CRB_PROFILER select _id; _start = _param select 1; _functime = diag_tickTime - _start; _param set [1, _functime]; CRB_PROFILER set [_id, _param]; diag_log format ["CRB_PROFILER,%1,%2", _param select 0, _param select 1]; }; }; _result; So what it does is, it produces a whole bunch of lines in your RPT file, which identify how many times a function was called, and how long its taking. You can throw this info into a spreadsheet (MS Excel or OpenOffice Calc) and identify the functions that a chewing the most performance. In the example above, I ended up with the following figures. Average Function Time NAME AVERAGE TIME mso_core_fnc_initLocations 103.59 Nou Caching cacheGroup 0.0005138401 Nou Caching closestUnit 0.0061846531 Nou Caching server 13.61749 Nou Caching triggerUnits 0.1968103143 Nou Caching uncacheGroup 0.00505464 Total Result 0.2756398595 Total Function Time NAME TOTAL TIME mso_core_fnc_initLocations 103.59 Nou Caching cacheGroup 0.08221442 Nou Caching closestUnit 1.558532572 Nou Caching server 54.46996 Nou Caching triggerUnits 49.5961992 Nou Caching uncacheGroup 0.465026878 Total Result 209.76193307 The result - I know which function I need to work on improving (this example Nou Caching (triggerUnits)).

MSO_FACTIONS array is what dictates which factions are spawned. It is selectable in the mission parameters, but there is nothing stopping you from hard coding it.

Nah man - graphs aren't from ARMA2! :) I just export the data into the RPT file, which I then import into Excel and create the graphs there.

For anyone interested in the performance improvements from 3.4 to 3.41, see: http://forums.bistudio.com/showthread.php?p=1933737#post1933737