*zeewolf*

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?!