*zeewolf*

Version v1.0 release Hotfix 1 Hotfix 1 Version 1.1 release WW4 based multiplayer total conversion. Persistent client side player profile implemented using Sinews of War saving. In game currency: FlashPoints, earn ten flashpoints per kill in core game modes, earn a match bonus based on how long you play. Use your FlashPoints to purchase weapons and attachments in the Create-A-Class mode. Gamble your FlashPoints against other players in wager matches. Several lobby buy-in options available, in-game double down voting supported. Create-A-Class mode; Try out weapons at the firing range, purchase weapons from an in-game shop that can be saved to one of five customised loadouts. Saved custom class loadouts are available for use in core game modes. Five base classes available for use until the player replaces them with custom classes (base class loadouts can be tailored to the mission by the mission designer). Modular Weapon Attachments; purchase custom optics and accessories. Up to 72 possible accessory combinations per weapon, 32 weapons available. MP weapon balancing; carefully chosen weapons and parameters to ensure no weapon is identical to another, each have their own strengths and weaknesses in terms of damage, recoil, rate of fire, magazine capacity, price and accessory range. Arcade health system; regenerating health, wounds cause blackouts depending upon severity. Inverse armor, hitting the torso does more damage than hitting arms or legs. Only sniper rifles and explosives are one hit kills. New gear; including proximity triggered claymores, underslung shotguns, grip-pods, flashbangs, frag-12 ammo and more. Killstreak system; all core game modes support the following killstreaks; 3 kills=UAV recon, 5 kills=Predator missile, 7 kills=Precision airstrike/JDAM, 10 kills=Reaper UCAV, 15 kills=AC-130 pass Support for faction dependent multiplayer announcers in all game modes (audio files are not included). Template mission folders for each game mode to allow rapid creation of new missions. Just add props and vehicles (lots of multiplayer missions for all of the MWC game types have already been written to support beta testing). Choose the camouflage you want to use from the lobby (each playable role in a free-for-all mission corresponds to a different camo pattern). Core game modes: All core game modes support two to eight players, 3 Team Capture and hold supports up to nine players (three teams of three). Wager Match modes: All wager matches support two to six players, the winnings are split accordingly. Weapons: In MWC you may carry a primary weapon, secondary weapon, launcher and ancilliary equipment (hand grenades, mines etc). The primary weapon can be of any type except a pistol. The secondary weapon can only be a pistol, SMG, carbine, assault rifle or shotgun. Why bother to take a pistol you may ask? In MWC it is much faster to switch to a pistol than either reloading your primary weapon or switching to a secondary long barreled weapon. Magazines for the primary weapon consume standard ammo slots which must be shared with launcher ammo and ancilliary equipment. You may carry up to four magazines for a secondary weapon (regardless of type), secondary mags don't use up inventory slots. The weapons of MWC have been carefully selected to provide strengths and weaknesses that match their real life counterparts. A few examples: When you want an assault rifle do you choose the lower damage, low recoil, 30 round clip AK-107 or the high damage, high recoil, 25 round clip ACR 6.8? When you want a carbine do you choose a fast firing but less accurate G36C or the higher damage Groza or the low recoil AKS-74U or the jack of all trades M4? When you want a sniper rifle do you choose a one hit kill L-115A3 or a low damage automatic marksman rifle like the Mk-12? Whatever your style of play you should be able to find a weapon that suits you and use different attachment sets and customised loadouts to tailor your gun to a wide range of battlefield situations. Weapons List: Attachments list: Oh and here's the MLODs for Macsers G36C, I forgot to include them in the main release. I've included an excessively detailed editor guide for those wishing to fiddle with this mod or just learn from it, you'll need to read at least part of it to make MWC missions. Not every unit or weapon class available in the mod's configs is listed in the editor guide, mostly because I forgot about them, I guess you can consider them Easter eggs. The included multiplayer missions all use content included in the mod, no extra addons required. Since most of the missions used in the beta test have exotic addon requirements only about half of the missions included were in the beta test. The remainder have been cranked out from the MWC templates and stuff I had lying around (grass templates and the like). The remaining missions from the beta test (which also happen to be my favorites) may be released as themed "content drops" which require common addon sets. Possible content drops would be: Afghanistan (CAT Afghan and Taliban based) Africa (BAS Tonal based) Japan (BOH Buren and Kanon) Vietnam (Seb Ilo, RIJ, HC Meekong) since every FPS needs Vietnam DLC Chechnya, Chechnya island (the controversial but brilliant .chechen one). But that depends on what happens with supporting the main mod with patches etc.

I mentioned in this thread that I'd come up with a bodge to allow players to change their class while in a mission, which apparently has never been done. I've gotten around to making a little demo mission. It can be used to give the player the impression that they are simply changing clothes (except for the globalchat "killed" message). Just open the dialog from the action menu (note the reused MWC assets). You can pick any unit from the class database declared in init.sqs, notice that you can even use unit classes from another side (although you will still remain on the same side). This needs to be run as a multiplayer mission due to it relying upon engine respawn mechanics to shift the player into another class, but I don't see that as being a real problem as there are already ways to load and save game data in multiplayer. If you want other AI units in a player's group then you'll need to modify the mission to shift players into temporary groups when they class switch using "join" before moving them back to their original group once the class switch is complete. If you need to transfer a player's identity to their new unit then I suggest you use saveIdentity in the init script to save their initial identity then use loadidentity to transfer it to the new unit whenever they switch. The demo mission is permadeath. If you want to respawn as well as class switch you'll need to spawn a second unit into the player's group for them to respawn into before they die!

This year will mark the 10th anniversery of Operation Flashpoint's release (June 22nd 2001 according to Wikipedia). Should BIS do something to mark the occasion? If so what would you like to see?

The track25 bug is to do with the MWC_sounds.pbo issue. I.e. Your Create-a-class mission is probably setup to use tracks that aren't included in the distributed MWC_sounds or defined in the main config.cpp. Track25 in my unreleased version is the menu music from Modern Warfare 2! Here's a link to a new Create-a-class.pbo that won't attempt to play track25, just tracks 21 and 22 (which should be a cut down version of "Into Dust" and the "Against the Tide" instrumental which are used in the mod's desert island intro mission). Regarding the FAMAS, it's not a big deal, I'm pretty biased against bullpups due to being left handed, but I feel they need some representation in the mod. Also the FAMAS and AUG are a bit too 1980s for my liking, aside from essentials like the AKM and M16, I've tried to style MWC to be a bit "cult of the new" in terms of its armory to make it feel a bit more like the Call of Duty or Battlefield series (hence the dubious desire for "rails on everything"). Regarding the RPK-74, the point is that it is technically possible and fills a valuable niche in the mod's armory. Specifically the need for an LMG/SAW which has lower recoil and stopping power than the M249 but doesn't completely nerf the magazine capacity. An alternative that would probably fit this role better would be the QBB-95 (which would provide more variety in terms of country of origin).

Lol, Hi Macser. Good to know there is still a talented modeller in the CWA forums. As you may recall the number of weapon combinations that you can achieve in this mod is pretty huge since it follows an attachment system. It's unrealistic to expect this ever to include attachment combinations for every weapon. A lot of the weapons are limited however by the requirement to have a model with a second muzzle for the UGL or masterkey attachment options. So the original selection was very much based on what was available in its main source mod (WW4). The result of me trying to use this limited range of models to achieve a wide range of weapons which have realistic trade-offs has resulted in some really annoying compromises: ACR 6.8 Currently using WW4's LR300 model. The other issue is the ACR looks really similar to a SCAR-L, ideally I'd have something more visually distinctive but I really need a weapon that's available in 6.8mm SPC to fill a spot in MWC's AR power/recoil trade-off (5.45, 5.56, 6.8, 7.62). So I'm open to ideas for a visually distinctive replacement (Barrett REC7 maybe?). 6.5mm Grendel is an option as well if anyone can think of a cool looking AR chambered for it. AK107 Currently using WW4's AK74M model. This fills a really important niche of really low recoil full auto but low stopping power (aka "fancy Russian balanced recoil thingy"). The AEK-971 may be a better one to replace this given that it is more distinctive looking. PKP Pecheneg Currently using WW4's PKM. You could argue that if you were running around COD style with a GPMG, you'd prefer a PKM given it's 0.7kg lighter. But I needed a "cool modern" 7.62mm belt fed GPMG, the PKP is in MW3 so seems the logical choice. RPK-74 with 75 round drum Currently using WW4's RPK74 with 45 round mag. The purpose of this one is to provide an LMG/LSW which is more controllable than the M249 while compromising somewhat on the magazine size and stopping power (i.e 5.45mm). I know the original weapon uses 45 round mags, but I'm pretty sure there are 3rd party drum mags about for it. Again if someone can think of a cooler alternative that fills the same niche then please suggest it. SCAR-H Currently using WW4's SCAR-L model. The point of this option is to provide a modern select fire 7.62mm rifle, so people have the option of attempting to control 7.62mm on full auto. SVDK Currently using the WW4 SVD model. Fills a nice niche in the MWC sniper rifle stopping power/mag size/fire rate continuum. M39 EMR Currently using Mk14 EBR model. MWC's jack of all trades 7.62 designated marksman rifle. FAMAS Would be nice to replace this with something a bit more modern (no RIS rails blegh!), L85A2 maybe? It fills the 5.56mm SA trigger group niche (as opposed to the M16A4's SB group). The assault rifle models need to be available in a minimum of the following varieties: No attachments Under barrel grenade launcher Suppressed It would be nice to have models fitted with masterkeys rather than relying on the UGL models. It's hard to say where to start with provision for the 6 scope options so they can be ignored. It would be nice to have a "suppressed" version of the PKP, although in-game this would be the flash-suppressed version, i.e. it would only be acting as a really good flash hider not a silencer. The RPK would need a "suppressed" version again because in-game you can buy a flash-hider. Regarding vehicles the only extra vehicles I really, really like to use with MWC is BAS little birds since MWC air combat is all about using "gunnerless" vehicles where the pilot controls the weapons and any gun turret directly and no gunner's seat is provided. Ridiculous I know, but brilliant fun. The main concern I have with adding vehicles is that a lot are ridiculously detailed, such that when spawned in MP they lag every client. The vanilla BIS and WW4 vehicles don't do this. The BAS littlebirds seem ok despite being very detailed but they seem to be an exception. If anyone can think of some vehicles that would fill a niche then please suggest them.

Thank you for the kind words. But the reasons for the lack of development aren't what you may think. The mod was developed mainly as something to play with my colleagues during our lunch break where the average game time is around 20 minutes. I released the content here just in case anyone else was interested in it and to provide access to the scripts used so they could be applied to other missions. I stopped developing it simply because it had reached a feature level we were happy with, then we stopped playing the game entirely. That said it may see a new lease of life as after a long break people have started to miss it. Things I would like to change: 1. More models for the weapons (I'm not knowledgeable in this department so would be relying on 3rd party content or others to assist). 2. More low poly vehicles, preferably filling some niche role. 3. Optimise all of the scripting for v1.99 (using getposASL would be beneficial to a lot of scripts) and convert some calculations to .sqf. 4. Develop some new game modes and/or killstreaks. 5. Somehow provide the voice packs that we use. You may not have realised but the scripting is actually setup to use voice acting from the COD MW series to announce game modes, kill streaks and the like. But due to copyright reasons the audio files themselves aren't included in the released mod. I could perhaps provide some kind of utility that generates a .pbo from the audio in a user's local copies of the COD4, MW2 and MW3 .iwd files. Regarding AI, I did create a demo of MP compatible AI state machines for my "Battlefield 1985" series missions (nothing to do with this mod and doesn't require it), you may want to try it out, here's a link to the .pbo, as you can see the AI can play a reasonably complex game mode and make full use of vehicles without any assistance from the player, the same thing could potentially be applied to MWC but a lot of work would be needed to provide support for MWC specific features. It's possible for example for AI to control an AC130 killstreak (this is demonstrated in some scenes of the mod's intro mission). It's all possible, it's just there is no motivation for me to pursue this direction, given that my colleagues and I prefer to play without AI and the lack of interest in the MWC general concept in the game's community. So for now AI is unlikely to be appearing, but some form of development may restart soon given the revived interest of my friends/colleagues.

I don't have the original copy, here's something similar. If you want multiplayer missions with sophisticated back end game mode scripting, I suggest you try my Modern War Crisis mod. It's a multiplayer only mod with a lot of game modes and advanced features like kill streaks, create-a-class mode and wager matches. It includes a load of templates that you can use to quickly make your own missions from the available game types.

OK, yes, you're right. Here's the thread with the nuts and bolts of OFP loop performance. I must have been thinking of the performance hit incurred by using @'s in scripts. Isn't another advantage of scripts that you have more control over the locality of MP variables they control than triggers since they can implicitly synchronise them? I also checked and found that a trigger's list is only updated twice a second, it's not just the evaluation of the scripted condition (which makes sense from an engine perspective). So that means having scripted loops that check the contents of a trigger area more than twice a second are wasting CPU cycles.

Please post the activation parameters of the trigger. Bear in mind that you can bind a triggers activation to a single group by using the editor's group mode to drag a connection between a unit and the trigger. You should be able to link the trigger to the A-10 pilot's group, since you need to have an editor placed unit to provide a group to spawn the pilot into. Alternatively just set the trigger to "Anybody Present" and monitor the units in the trigger zone using a script. So normally, I would just place a soldier down in the editor with "A10Group = group this; deletevehicle this" in the unit's initialisation field. This gets you a reference to an empty group for spawning units into. Put down two waypoints for the unit, a move and a cycle to provide simple scripted navigation. Then a trigger set to "Anybody Present" called Trigger1 with no other parameters. The spawning and trigger script would then be: ; spawn A10 _pilot = "SoldierWPilot" createunit [_pos, A10Group] _vehicle = "A10" createvehicle _pos _unit moveindriver _vehicle ; "winch" the plane for instant takeoff _vehicle setpos [getpos _vehicle select 0, getpos _vehicle select 1, 500] ; fly the A10 to the position [A10Group,0] setwppos (getpos Trigger1) [A10Group,1] setwppos (getpos Trigger1) ; wait for A10 to be in trigger zone #lp ~0.5 ?!(alive _pilot): exit ?!((vehicle _pilot) in list Trigger1): goto "lp" hint "The A10 is in the trigger area!" This has an added advantage that no complicated code is required in the trigger itself, which is desirable since triggers are checked every frame of the simulation, putting lots of code in a trigger's condition field is inefficient. With a script you can choose how often the condition code is run by adjusting the loop period, the loop's list will still be recalculated every frame by the engine, but it will be considerably quicker with no trigger condition code to parse.

Binocular slots: magazineType = 0; Pistol mags: magazineType = 32; Single slot mags: magazineType = 256; Dual slot mags: magazineType = "2 * 256"; Six slot mags: magazineType = "6 * 256"; etc. I can't think of an answer to your second question. Like you said you need the corresponding weapon to pick it up using the in-engine action menu. You may be able to simulate it using a scripted addActions while keeping the magazine unusable in the player's weapons.

To figure out what is going on you need to determine whether the script line is definately being run on the server and know the locality of the object you are assigning the eventhandler to. You need to be very careful when using eventhandlers in MP; "Hit" and "killed" eventhandlers will only be called on the machine that the object is local to, I believe "dammaged" (sic) is global however. For example if I assign a killed eventhandler to a given player unit even if I add it on every machine, the eventhandler will only ever run the script on that player's machine (because the player is local to their machine), not on any others. I only use eventhandlers in MP when there is absolutely no other way of getting the data I need. E.g. there is no reliable way of getting the "killer" of a unit other than using a killed eventhandler. For damaged the only thing you can't determine using a looped script (or a trigger if you want brute force and ignorance) is selectionname. I recommend using this script system to respawn vehicles in MP. It provides a client side script for calling local effects (player.sqs) as well as efficiently managing the respawning of a large number of vehicles on the server side (vehicles.sqs). It's a good starting point for experimenting with and learning about the locality of objects in MP. There's a lot that can be said about managing locality and MP game state data efficiently and reliably but you need to get a grip on how locality works first.

I think a guard waypoint script hybrid would be the most elegant way, since you want to avoid micromanaging the groups. Just use scripting to move the groups' waypoints around according to the "big picture" as happens in an RTS. I believe groups tend to "retreat" towards their leader's original editor position (the invisible waypoint 0 in their waypoint array, which can be moved as such) so bear this in mine if you are going to make use of group morale mechanics. You could try two philosophies with an RTS style AI script, first is to try to make them human like by tracking the number of units they know about (as detected by their side) then responding according to the disposition of known enemy units. The second way would be to have a more "godlike" AI that knows the entire game state and responds according to the player's current state (think of the Left4Dead AI director), this would give a more consistent challenge to the player but could get predictable without some randomisation. Another way of doing it would be to run a separate FSM script for each AI group in the game that responds independently of the other groups on its side. This would allow you to put more intelligence into the group's decisions but can make the overall response disjointed since there would be no coordination with other groups.

First you need an invisible laser target object of the appropriate side to "persuade" the AI to drop the bomb. BAS Tonal OPFOR includes laser targets for all three sides, alternatively you can make your own mini-addon with them in. So you can just spawn or setpos an existing laser target near to the map position, the AI will then drop the bomb when they fly over, the same way they do if you have a black op shooting a laser designator at the target. You may want to put a little height extra on the target to ensure the pilot gets a clear line of sight to the target.

The short answer is no. Only group leaders can access the "commander view". The long answer is it can be fudged, either by modifying the unit's class in its respective config.cpp, or by using a rather extreme camera script. For the first option you would need to modify or override the unit or a parent class' ViewPilot class. E.g. class Man:Land { [indent] ... extCameraPosition[]={0,0.3,-3.5}; ... class ViewPilot:ViewPilotBase { [indent] initAngleX=8; minAngleX=-360; maxAngleX=360; initAngleY=0; minAngleY=-125; maxAngleY=125; initFov=0.7; minFov=0.42; maxFov=2.00; [/indent] }; ... [/indent] }; This doesn't actually allow you to move the camera toward/away from the unit since the camera is fixed by the extCameraPosition array. What it will do is extend the minimum FOV that you can obtain using the "zoom out" key binding. This will give a "fisheye" effect at extreme FOVs (>0.9). It will also affect first person view as well. Second option requires a rather complicated script like this: _unit = _this select 0 hintc "Press V to exit camera control, press L to toggle crosshair, use move up/down/left/right/forward/back to move camera." #start _pos = getpos _unit _theta = ((getdir _unit) +180) mod 360 _r = 4 _phi = 20 _rx = _r * (sin _theta) * (cos _phi) _ry = _r * (cos _theta) * (cos _phi) _rz = _r * (sin _phi) _cx = 0 _cy = 0 _cz = 0 _camera = "camera" camCreate [(_pos select 0) + _rx, (_pos select 1) + _ry, _rz] _camera cameraEffect ["internal","back"] _camera camSetTarget _pos _camera camSetFOV 0.7 _camera camCommit 0 @camCommitted _camera _campos = GetPos _camera _i = 0 #orbit _pos = getpos _unit ;_pos set[2,1] _rx = _r * (sin _theta) * (cos _phi) _ry = _r * (cos _theta) * (cos _phi) _rz = (_r * (sin _phi)) + (_pos select 2) _camera camSetPos [(_pos select 0) + _rx, (_pos select 1) + _ry, _rz] _camera camSetTarget _pos _camera camcommit 0 @camCommitted _camera _camera camCommand "Manual on" _oldpos = getpos _camera _oldDist = _unit distance _camera ~0.02 ?(_camera != _camera): goto "end" _camera camCommand "Manual off" _newDist = _unit distance _camera _newpos = getpos _camera _cz = ((_newpos select 2)-(_oldpos select 2)) ; DEBUG TEXT CONTROL ;_i = _i + 1 ;?(_i == 10): _i = 0; titletext[Format["%1 %2 %3 %4",_cx, _cy, _cz, _theta],"PLAIN DOWN",0.05] _phi = _phi + (_cz * 10) ;?((_cz > 0.05) or (_cz < -0.05)): goto "orbit" _cy = _newDist - _oldDist _r = _r + (_cy * 2) ?(_r > 40): _r = 40 ?((_cy > 0.1) or (_cy < -0.1)): goto "orbit" ?(_newDist < 1): goto "orbit" _cx = (((_pos select 0) - (_oldpos select 0)) atan2 ((_pos select 1) - (_oldpos select 1))) _cx = _cx - (((_pos select 0) - (_newpos select 0)) atan2 ((_pos select 1) - (_newpos select 1))) _theta = _theta - _cx goto "orbit" #end _camera camCommand "Manual on" _camera cameraEffect ["Terminate","back"] _camera camcommit 0 @camcommitted _camera camDestroy _camera exit The above code is pushing the game really hard due to the high speed needed to "interlace" camera movements with scripted translations. You could improve the performance by putting the maths either side of the 20 millisecond delay into sqf functions which will remove the overhead caused by parsing the sqs each iteration. I have listed all the code in one script for clarity's sake, although that won't help much if you don't understand how spherical coordinates work :) The script is called with [player] exec "MyScriptsName.sqs", but you can actually pass a reference to whatever unit you want. Oh by the way, the script is designed for slow moving or stationary objects. There should a way to cancel out the unit's velocity but I'll leave that open for discussion :P

I suspect your problem can be solved using some extra conditions in your mission's waypoints (and not using hold waypoints!). There is another way: MORE SCRIPTS! The method below can be used if you want to control a group using scripts rather than editor placed entities like triggers and waypoints. So on many missions (mainly dynamic ones where you are spawning AI rather than using editor placed units) it's better to just move the AI around in a script by using the setWPPos command. To make this work, you make just two waypoints for the group you want to control, a move followed by a cycle (no conditions set just two standard waypoints a move and a cycle). When you want to move the waypoints in the script you would do: [myGroup, 0] setwppos _pos [myGroup, 1] setwppos _pos You would usually initialise "myGroup" using the init line of the group leader in the editor: myGroup = group this; Would initialise the global variable myGroup to provide a reference to the group of a given editor placed unit (you can't create groups on the fly, all the groups you are going to use in the mission must be pre-placed in the editor). The above script will actually move the move waypoint you placed (waypoint 1 in the editor waypoint order list) and a second move waypoint (waypoint 0) which is invisible in the editor but every group has, its initial placement corresponds to the group leader's initial editor placed position. The cycle (waypoint 2 in the editor) doesn't get moved anywhere but causes the AI to cycle between their two move waypoints (the invisible one and the one you placed), since you are moving both of these to the same spot the AI will always go to that waypoint. Also the above method really comes into its own when scripting dynamic missions where you want to spawn AI into an empty group, because you know that the spawned units will always go to a single position, there's no need to try to force them to start a waypoint chain again.

It would have been better to post a new thread on this. The answer to your question is unfortunately quite complicated due to something called locality. Certain events (like a player dying) can only be detected reliably on a single machine (the machine of the player who was killed, i.e. the victim) due to the locality of killed eventhandlers. When you try to implement an auxilliary scoring system, you are trying to find out who killed a player on the victim's machine, then you really need to some how transfer your "currency" to the killer's machine in order for them to spend it (because until you do the killer's machine won't know they killed the victim). This can be done, normally by manually transmitting data over the network using the publicvariable command, these are notoriously unreliable when used incorrectly due to their low bandwidth priority versus game engine data and general inefficiency. There are other methods as well as publicvariable like using the position of a game logic (which is more reliable but less efficient bandwidth wise). For multiplayer it's not good enough for your scoring system to work 95% of the time, because this will quickly upset players who find themselves robbed of kills. So you are faced with the challenge of creating an incredibly reliable synchronisation system with very little in the way of methods to efficiently and reliably transfer that data. To actually test this out you really need a couple of PCs to actually watch debug information from your scripts when running a multiplayer game. Because of locality many things you take for granted in SP will work completely differently in MP or not at all. Once you've got your head around locality. I suggest you read up about adding a killed eventhandler to a unit first, since this is what you need to link a victim to their killer. You would then need to add a script that monitors global score variables transmitted via publicvariable or some other means to control each player's score. I am going to (shamelessly) recommend you read the editor guide included in my mod Modern War Crisis. The mod includes among other things a scripting framework to implement persistent in-game currency (a BLOPS style Create-a-Class system) and killstreak rewards for players. The editor guide goes into excruciating detail on how the framework operates at a low level, so even if you want to make your own from scratch, it's thoroughly useful.

Yes they should be, that was the main reason for releasing it actually, Blitzen reported that some links had died. Regarding Tonal, it's the model names of the units that are critical if you are going to use the Tonal extensions (e.g. WW4 cars - UAZ DshK (U) Driver/Gunner). These classes call the models from BAS_OPFOR, it's just an efficient way of calling up models from other addons without distributing or modifying them in any way. The included missions were made on the original BAS Tonal release afaik. Sorry, you are right. Links updated (it's on Multiupload now). Juggernaut is in editor as MWC Men - Juggernaut. The BF1985 missions should be: BF Bridge.Noe, BF Ford Focus.Noe and BF Modrava.Noe in MPMissions. Oh and there is a demo Team Juggernaut mission and a 3 Team Juggernaut Capture and Hold MP mission. I never got a completely stable free for all Juggernaut mode working (which used my novel method of switching a player's model out using squad respawning), the game just seems to get out of sync in real world MP games. Well, I'm afraid this mod is really all about pushing the boundaries of what is possible in MP. I am lucky enough to be able to play regular LAN games with this mod against seasoned Flashpoint players, so what does/doesn't get done with this mod by the wider community is quite frankly not a big factor in its development. On the SP side, the mod does work ok as a Total Conversion (at least my clan mates have played the 1985 campaign using it). One project I may take on is converting all the 1985 campaign missions to use Battletech grass, I suppose I could also take that opportunity to add in some of the new weapons to the mission loadout. But again I'm not sure what exactly people want in terms of single player additions.

There are a couple of options here for multiplayer. Radio triggers are less obtrusive than action menu items since they don't interfere with gameplay. There's nothing more frustrating than having to scroll past a dozen menu items to select your LAW launcher in the heat of battle. So there are two options here: If I want to make a given radio trigger "local" i.e. only visible for one player in a mission I would add the radio trigger to the mission (in the below example I use Radio Alpha) as normal but add the following code in init.sqs: 1 setradiomsg "NULL" ?(S1 == player): 1 setradiomsg "Alpha" So in the above code, initially the radio message is disabled for all players. It is then re-enabled only for the player controlling the unit named S1. If I want to add an action to an object (even the player) I would use addaction as in the following code: myAction = S1 addaction["AC-130","killstreaks\r_ac130.sqs"] In this case an action is being added to the unit S1, it will appear in the action menu as "AC-130" and will call the script killstreaks\r_ac130.sqs. If this is the player unit then the action will appear in their action menu. If it is applied to an object other than the player, it will be appear in the player's action menu only when they are near the object (about 15m). Note that actions added with the "addaction" command always appear at the top of the action menu, above the in-engine commands like reload etc. This means it quickly becomes cumbersome for a player if there are too many actions in their menu. You can remove the action at a later time by calling removeaction and passing the number of the action to be removed so if I wanted to remove the action from the above code I would call: S1 removeaction myAction There are also issues with addaction to do with locality. As far as I remember addaction is only local in effect, so it only effects the computers on which the script is being run. The same goes for setradiomsg I think (although this isn't a problem in the above example because all machines will run init.sqs on mission start). Another problem with addaction is that if you attach an action to the player unit, that action is linked to that specific unit. If the player is killed and respawns, the action would remain linked to the player's dead body. So you would have to trap that event and move the action to the player's new body. Isn't multiplayer scripting fun?!

Triggers are two dimensional, their activation list will contain all activating units within their radius regardless of height. You should process the trigger's activation list with a script to sort out what to do with it. If you can't modify the addon script to add an effect you could use a delay equal to the flight time used by the scud addon. DSF's flight time is (0.0125 * distance to target) + fixed time for scud to launch and descend. So you can calculate this flight time again in your script and pass that to the effects script to synchronise the effect to the explosion. E.g. scud launch request script _pos = _this select 0 _scud = _this select 1 TargetTrigger setpos _pos TargetLogic setpos _pos ; code that announces scud launch and launches it _flightTime = (0.0125 * (TargetLogic distance _scud)) + 25 [_flightTime] exec "processTrigger.sqs" ; code that runs after scud launch processTrigger.sqs ; wait for approximate time for scud to hit ~(_this select 0) _myList = list TargetTrigger _i = 0 #lp _unit = (_myList select _i) ?("LandVehicle" CountType[_unit] != 0): DO SOMETHING BAD TO _unit; goto "next" ?("Man" CountType[_unit] != 0): DO SOMETHING WORSE TO _unit; goto "next" etc #next _i = _i + 1 ?(_i < count _myList) : goto "lp" You may have to adjust the fixed 25 second offset of _flightTime I just worked it out roughly from the DSF script. You can also scale the effect applied to an object by its distance to TargetLogic. Note I'm using a game logic for distance calculations because the trigger will be positioned at sea level, while the game logic will be positioned at ground level.

Version 1.1 released. Changes: Added "Juggernaut" suit and animation set. Added integration with BAS littlebirds, BAS Tonal and Chechnya island. These addons aren't included or strictly required but are highly recommended for the full MWC experience. Added new game mode; Battlefield conquest, integrates Battlefield 1985 with MWC. MWC based versions of three classic BF1985 maps included; Bridge over the River Pie, Ford Focus and Strike at Modrava. Fixed various bugs in template missions. See previous posts for addon requirements for ready made MWC MP Missions (a selection of non-addon missions are included).

You should also run a "reveal" when setPos-ing the player to a position, essentially assume that if a player has never "seen" a vehicle that wasn't present at the start of the mission (i.e. it was spawned) that you need to reveal it to them, or wait for the engine to catch up (this take a surprisingly long time in multiplayer) before they can be interacted with. When I setpos a player unit I always run a scan for vehicles in the area and "reveal" them as necessary. E.g. In my missions all respawning vehicles are added to the global array "Vehicles" so I can do: player setpos _somePos {if(_x distance player < 150) then {player reveal _x}} foreach Vehicles To reveal nearby vehicles when a player is teleported near to them. Obviously you need to make sure that the Vehicles array is kept up to date (and synchronised in MP).

Ahhhh! I think you forgot something very important when it comes to ballistics and the user's perception of bullet drop in OFP; the zeroing of a weapon's optics (distanceZoomMin/distanceZoomMax). You will find that nearly all weapons are zeroed to 300m, this means that the perceived bullet drop of lower velocity rifle rounds is considerably reduced (because the zeroing is compensating for it). In MWC I was careful to ensure that scopes "marketed" as close combat optics were zeroed at 200m, while "tactical" were zeroed to 300m and "sniper" scopes to 400m. The ART scope actually the only one that allows a variable zero, making it one of the most popular scopes in MWC despite its inferior zoom compared to the "ballistic scope". The reason the ART is the only one that can have a variable zero is that the engine links the zero directly to the zoom level (opticsZoomMin/Max), so as far as I know you can't vary zero/bullet drop compensation independently of zoom in OFP because it was specifically designed for the ART mechanics. I suggest you experiment with some different optics and zeroes on your weapons to get a good feel for the engine ballistics (which do work). I think you'll find that at long ranges there is a clear difference between weapons even when using real life muzzle velocity values. Regarding damage, as I said I used real life muzzle energy figures as a base line then applied some modifiers for rounds that had a "reputation" for better/worse terminal effects (due to all manner of real and imagined phenomena often quoted by gun nuts). For example I made sure 5.56mm carbines do much less damage than a 5.56mm round from a full length barrel since the round is supposedly unlikely to fragment when fired from 14-inch barrels, thus greatly reducing terminal effectiveness. Again playing into the hands of a gun/calibre's "reputation" not only gives you some bollocks to throw at gun nuts (and there are a lot playing this genre) as "realism" it also actually "feels right" in normal gameplay (you are reinforcing the player's preconceptions of a particular weapon).

You need to be careful when fiddling with damage values for weapons, if you start changing damage values you may need to tweak armor values as well and end up in a vicious circle of tweaking each ammo type and armor value. You will find "indirectHit" actually has a massive effect on the damage of a round even when a direct hit is scored, for example if a soldier is hit in the arm, the direct hit damage is applied against their armorHand, but I found indirect damage is actually dealt to their other body parts depending upon the relative distance of the hit to other body parts and the round's indirectHitRange, so you can actually cause fatal damage to the head from a hit to the arm or leg, depending upon the weapon's indirectHit capability. So you can broadly separate mods into two categories; balanced and realistic. The BIS weapons are what I would call "balanced" where by the weapons available to each side, west, east and resistance are exactly the same with the exception of their appearance. E.g. a BIS AK-74 does the same damage as a BIS M-16. While not as important for single player missions (they can be rebalanced by mission design), in multiplayer this kind of "balance" is absolutely critical. "Realistic" would be a mod that tries to replicate the real world characteristics of a gun as closely as possible. JAM would be a reasonably good example, where all the muzzle velocities and accuracies are based on real world data and terminal effects are also estimated. But you will find a lot of examples in JAM where apparently balance had to be applied to achieve good gameplay. You will find mods that try to be both realistic and balanced have to be VERY careful with their weapon selections to achieve fairness in multiplayer. WW4 is a good example of this, as is, (if I do say so myself) MWC. In MWC I was very careful to offer realistism in terms of muzzle velocities and accuracy. But being a multiplayer mod, balance has to come in somewhere. Namely the damage done by weapons is proportional to their real life muzzle energy, while still being "arcade like" for fun gameplay. MWC uses a baseline damage for 5.56mm NATO of hit=9; indirectHit=2; indirectHitRange=0.1. With a range from hit=6; indirectHit=1; indirectHitRange=0.05 for 9mm Parabellum from a suppressed pistol, up to hit=20; indirectHit=2;indirectHitRange=0.1; for .50 BMG fired from an M82. This is then applied to over the top arcade infantry armor of armor=6; armorStructural=2; armorHead=2; armorBody=2; armorHands=0.5;armorLegs=0.5. Or armor=50; armorStructural=6; armorHead=2; armorBody=12; armorHands=12;armorLegs=12; for a player in a Juggernaut suit!

Hi, Ever since I installed the ACR DLC I've been getting an error when launching Arma:OA from Steam. "Cannot load texture ca\plants2\clutter\data\c_grasstall_ca.paa" This appears on startup, the game then loads Bukovina, the demo looks fine. I open Bukovina in the editor and I get another popup: "Cannot open object ca\structure\misc_powerlines\powlines_wood2.p3d" After, putting a player in and launching the mission from the editor, some of the vegetation is completely white, clearly missing textures. I try loading Bystrica in the editor and I get the following warnings: "Cannot open object ca\roads2\asf1_7 100.p3d" "Cannot open object ca\plants2\misc\misc_stub2.p3d" "Cannot open object ca\signs2\sign_36b.p3d" Attempting to spawn one of the new ACR units (which are all available in the editor) gave: "Cannot load texture ca\weapons\data\aimpoint_glass_flat_nohq.paa" This is pretty much making ACR unplayable for me and incredibly annoying to get an error every time I launch the game. I have tried reinstalling Arma:OA from scratch and it made no difference. All the other islands are working fine (including PMC and BAF). Any ideas how to fix this?

I don't know, it's probably a bug in the addon (which I didn't make). You can of course add extra conditions, time delays and debugging output (using the hint and format commands) into scripts to find problems in any sqs script. To be honest I find the DSF addon over the top in terms of special effects and scripting (CEP calculation, flight time, minimum range etc), which makes me reluctant to start tracing it. Do you really need all of the effects it provides? You can cherry pick some of the particle effect scripts as long as you know their calling convention (which you get by unpacking the pbo and reading the relevant script file to find passed variables). To just run the nuke particle effect on a given position just call (_this select 0) exec {\DSF_Addons\scripts\nuke.sqs} from launch_scud.sqs, obviously this wouldn't kill anyone but it would generate the mushroom cloud at the map location. A simple way to do it would be have the launch script launch the scud then run the particle effect some time later at the target coordinates, while killing everything there with a trigger. E.g. onMapSingleClick {} ; get the position _pos = _this select 0 ; move the triggers DeathTrigger setpos _pos FireTrigger setpos _pos ; animate the scud scud2 action["SCUD LAUNCH"] ~10.5 scud2 action["SCUD START"] ; calculate distance to target _dist = scud2 distance DeathTrigger ; flight time based on DSF distance coefficient ~((_dist/80) + 35) ; run nuke particle effect _pos exec {DSF_Addons\scripts\nuke.sqs} ; kill everything in DeathTrigger {_x setdamage 1} foreach (list DeathTrigger) ; Get everything in FireTrigger but not in DeathTrigger _burnList = (list FireTrigger) - (list DeathTrigger) ; burn them {if(vehicle _x == _x) then {[_x] exec {\DSF_Addons\scripts\fire.sqs}}} foreach _burnList Should launch the scud then kill everything at the target of radius DeathTrigger (a circular Trigger set to Anybody), burn to death any infantry in FireTrigger (a larger circular trigger also set to Anybody) and generate the mushroom cloud. I haven't tested it so you may need to play around with it. Oh the above code and the DSF addons scripts aren't designed for multiplayer either, since the particle effects would need running seperately on every client machine while a single machine runs the "killing" code. Do you need it to work in multiplayer?