The_Captain

I'd be interested to know how this game is firsthand (esp with the patch). Personally I still play CC3 & its campaigns head to head with my gaming buddies, and haven't seen the need to upgrade. maybe my mind can be changed...

Thanks Jerry, and Suma for the interview. It was really enlightening to hear Suma's thoughts aloud. I'm now kicking myself for not submitting a question about the MP modes that will be included in Arma II...

If players are going it alone rather than acting as a team, more fault lies in the way the map is designed rather than the players. If the map encouraged players to stick together rather than go it alone, they would quickly figure that out and do so. Hitting them over the head with an 'anti rambo' script is not an ideal solution. For example, if it were possible to actually *lose* a game of evolution by the AI attacking the poor players, they might decide to stick together. As it is, players figure they can harvest points their own way by going it alone, especially if all other players are occupied ramboing themselves. (The high travel time and low enemy count is also to blame: with players travelling long distances to a combat zone, they're unlikely to wait for fellow players before embarking. With such a long time spent traveling, players are most often alive while in transit, far from any fellow players, making teaming up rather difficult.) Arma is also to blame for its high lethality, especially when 'ramboing' against AI or players: you're the only target for every AI or player nearby, giving them no other distractions.. and a single bullet, not to mention all of arma's other weaponry, can kill. This makes actually surviving combat with fellow players incredibly problematic. With such a high investment in time and energy in actually working with other players, and the low group survival rate in a map like Evo, sticking with other players is more trouble than its worth in many situations. If the map and game are set up to make it hard to: locate, travel, fight, and survive with other players (and there are few systems to discourage ramboing, save individual death), ramboing will probably be a preferred strategy for many players. I personally prefer games that emphasize teamwork, but I don't think it's fair to lay all of the blame on players when they're just trying to have fun in a way that works for them, given the game they're playing. If you want to encourage players to play as a team, punish the entire team for being uncoordinated, don't punish the individual players. A quick loss at the hands of AI or other players does wonders to encourage even rudimentary teamwork.

The setpos trick is quite handy... I just might have to use that! My clients use the elapsed time to calculate 'time left' in various screens (server sends the end time value only once). In the rare cases the elapsed time is out of sync, the clients' timers are all screwy. Handy trick noted... To be fair, missions can't be guaranteed to work correctly if the admin or players leave others in the lobby when the game warns them.. but I'd like to make a system that's nearly foolproof regardless. I don't like blaming the user As an aside, something I haven't written yet but have in the pipeline is a TK script that disconnects players if they reach or surpass the server-set threshold, using the (finddisplay 46) closedialog 0 trick (which I believe Doolittle also uses in the ACS, but I haven't checked for sure). Disconnect-on-TK might be a much nicer server script than building in hacks into each mission piecemeal (bananaphone room, self damage, weapon removal, etc). Such a simple, portable TK protection script that runs serverside might be something for MP scripters to consider (perhaps even combined with a 'forgive' feature or a time/name based lockout (5 mins or so) to prevent quick rejoins...)

unassignVehicle (unit) should work to make the units not try to get back in the vehicle after you eject them.

Re: time: Time seems to be synchronized well enough for players who start at mission start and players who JIP. However, time is NOT synced for players who are stuck in lobby or briefing when the game starts ("If you start mission you may leave players behind. Would you like to continue?" or such). Naturally these players also do not get additional updates since mission start, and I wish there was a simple way to 1) figure out which players are in this state, and 2) give them an accurate time value from the server to replace their timelagged value. Re: network engine: I just want to chime in that I wrote a network engine similar to sickboy's which has publicVariableEventHandlers on the server to recieve info from each client, and clients that wait for broadcasts from the server. This method is far easier to implement & cleaner than setvehicleinit as sickboy has pointed out, especially now that we can send arrays (been waiting for this since OFP..). Also, in terms of publicVariables being synced for JIP players: The client seems to receive the variables either before or while his init.sqf is running (ie, before sleeps). So, if in your scripts you initialize a publicVariable (say, so you can wait for variables to be sent to that client later), your client will end up with his variable initialized without the value that was sent as he connected. This means you either need to check for an existing value when you initialize client variables on JIP, or resend publicvariables from the server after a player is connected to ensure they get the value. As well, I think the publicvariable that is synced when a player connects will not trigger the publicVariableEventHandler (unless the handler is added in the init, before any waits), but I have not tested this specific case. (ack, looks like DrEyeball pointed this very fact out on the wiki) And to chime in about 'lock': I'm happy that command is local! In my own mission I lock east's crew restricted vehicles to west, and vice versa. (Tanks, helis, etc). This would not be possible if the command were global...

I've had MP teamswitch (using a custom interface and selectplayer, not the BIS interface) within my own mission for a little while now, limiting use only to units local to the switcher's computer and within his own squad (and no players are ever in another player's squad, to prevent horrible bugs). From hearsay, I've heard that switching to a unit not local to your computer causes a crash. However, testers of my mission have occasionally experienced the "john malkovich" bug where they are accidentally inhabiting an AI which is local to the server (I suspect) and have no control over it. if you 'addswitchableunit' more than one unit, the BIS dialog becomes enabled (also I think there's a command to enable or disable the dialog itself.) All of my tests have been done with a custom interface, so I can't comment on how BIS' works in MP. It thus seems that if you wanted to enable teamswitch in MP missions, you should override the default BIS interface and write your own that changes a unit's locality before the switch, as long as the unit is not controlled by another player. And as stated, the original player's identity stays with his server joined unit. In another thread it was pointed out to me that identity can be changed in MP, but I have been unsuccessful trying it myself. If you *never* use setidentity on a player's new unit, he retains his name in chat but not on his new unit's in game tag. Another infuriating bug with teamswitch in SP or MP, is that when you change to another unit within the same vehicle (say, driver or gunner), the original player unit retains control of the vehicle. So if you 'move to cargo' from the driver position, and then teamswitch to the driver position, the cargo unit will retain control over the vehicle. Or, a player who gets in as cargo and then teamswitches to driver will also encounter this problem. Teamswitching within the same vehicle can thus cause problems when a player cannot retain control over his own vehicle, or can't switch to other positions (because he is no longer the effectivecommander). A clever combination of getin-getout actions to reset the commander of the vehicle to the original player works, but it's still an annoying workaround.

You should be able to email support for a new activation key (I had to when the earlier betas used up my activations by mistake). Also, I think you can use beta 1.09 without activation. Good luck.

There's a sneaky way to get radio commands to execute only on the local machine: for a radio alpha to execute on the local machine only: trigger 1: activation: radio alpha (repeatedly) condition: this && !radio_alpha onAct: (your code here); radio_alpha = true; publicvariable "radio_alpha"; trigger 2: activation: radio alpha (repeatedly) timeout: min/mid/max: 2 condition: this on Act: radio_alpha = false; This effectively stops clients besides the client that executed the radio command from having the effects execute locally. You might also want to use "addswitchableunit _newunit" and "removeswitchableunit _oldunit" in the radio trigger to prevent crashes. (I think if you don't addswitchableunit the new unit, and selectplayer a second time, the game crashes) the Teamswitch dialog activates in MP if you use the "addswitchableunit" command and there are more than one 'playable' unit (eg, the original player and the new unit). I generally make sure I only have one switchable unit so the dialog is disabled, but you may want to experiment with it. Also, I think you need to make sure the player unit is local to the computer calling the command, otherwise you may get a crash. If you selectplayer to a unit local to another client it may crash the game.. I haven't experimented with this in a while but I believe it to be the case.

The WGL 4.1 mod for OFP used a similar "instant cloud" effect for explosions. It was extremely frightening and powerful, especially with the sharp explosion sound effects. I much prefer insta-clouds to slowly expanding clouds like most addons/mods use... you really cringe while waiting for a grenade to go off... Looking forward to playing with that effect, DMarkwick...

You need to use scripts to enable teamswitch in multiplayer. Setting a unit to playable in the editor does not make it switchable in MP. If you use the script command "addswitchableunit _unitname" to units in MP,as far as I know teamswitch will be active. But if the unit is not local to the computer you will crash. The group is local to the group leader. (so other players cannot switch to the AI).

Teamswitch works in MP *only* if the unit you are teamswitching to is local to the switching player's computer. This means it must: 1- be part of the player's group, with player as commander, that he selects on the server screen 2- created on the player's machine using the createUnit command. You can switch to another unit in mp with the "selectplayer _unit" command after running "addswitchableunit _unit" on the unit you want to switch to. if you try to 'selectplayer' a unit that is NOT local to the player (ie, a server AI), you will crash the client and possibly the server (can't remember). One sideeffect of using selectplayer is that the player's name and identity remain on the original player unit. One workaround which Doolittle implemented in DLCTI is to literally switch positions/weapons with the AI, so the player retains his original unit and model but is moved to the same location/vehicle of and given the weapons of the AI. If I recall you can engage this by clicking on the map location of your AI. DLCTI

I think the BattlEye implementation only detects 'real time' cheats, not addon modifications. Thus, since addons can have clientside modifications, signed addons are needed to make sure client and server have the proper addons. There's no need to make the arma battleye anticheat detect pbo/addon changes: that's what signed addons are for. Battleye without signed addons would likely prevent more severe non-addon based cheats while allowing clients to still use clientside mods. Sounds good to me...

Another minor note on the m60: You can carry an M60 and a LAW/carl gustav at the same time. Looks like the m60 doesn't restrict the secondary weapon carry. The wiki says that the bit flag to restrict secondary weapons is 16, which is how the m60 is coded in cfgweapons in cwrrifles.pbo. However, in the BIS configs, the bit flag for 'type' is 4 to restrict secondary weapons. So "type=1+4;" works to keep the 60 user to only the primary weapon. The config also does not have a dexerity value (like the m240, which is dexterity=.57), which would decrease the aiming and handling precision of the weapon. Since it inherits from rifle, it has perfect dexterity, making it very easy to make snap shots with the weapon. (Not sure if this intentional, to make the weapon more ofp-like, but thought I'd point it out) The lower dexterity value also makes it more of a challenge to control the weapon's low recoil when firing at long ranges. Also, M60 fire rate is too fast. Reload time is 0.075 which is ~800rpm. The M60 is usually 600-550 rpm, which would be a reload of about .1 or .109 for 600 and 550 rpm respectively. edit: Not sure if this is intentional, but west sniper's pants are OD in front and woodland in back. Great stuff, guys.. having a blast playing with the goodies!

A few things I noticed playing CWR: 1) Grenadiers are fairly innaccurate or the grenades do low damage/low splash, but grenadiers still only get the OFP loadout of 3 grenades, making them somewhat useless. It might be worthwhile to increase the power of the grenades or give more to the grenadiers. 2) Machine guns have fairly low recoil (when standing, esp the M60), making them either unbalanced+too powerful or a godsend for engaging enemies at 300+ meters, depending on how you feel when playing. the standing recoil should perhaps be adjusted, but at least keeping the low recoil while prone is necessary to make the weapon useful for engaging distant enemies. 3) Medics only have four slots (like original ofp) while all other classes have 12. Perhaps since all classes have 2 more slots than in ofp, the medics should have 6 slots instead of 4? 4) '12.7mm machinegun' has an m240ish rate of fire and uses the m240 sound from Arma. perhaps these should have the same rate of fire and sound as the .50 cal browning machinegun? I recall that they did in OFP... 5) Tanks have HEAT ammo loaded before SABOT ammo, so they seem to engage both infantry and other tanks with the heat. Scary for infantry, not too scary for tanks. I think OFP loaded sabot first, then heat. edit: 6) VOX Sound sample for west LAW and AT soldiers is "aa soldier" 7) Carl gustav takes up two inventory slots instead of 6. Overall, CWR is a very tense experience. I converted over a few of the CWC campaign missions to CWR and it was a very different feel from both OFP and arma. Much more deadly at long ranges, and perhaps because of the grass, camo, or overall muted colors, enemies tend to blend into the terrain better and snipe from long range, making the game very frightening and tense. I don't seem to have the same feeling in vanilla arma, which is more frustration than fear. CWR's fearful atmosphere is very enjoyable. Also, the graphics are stunning and have a wonderfully drab feel, which is a nice change from arma's bright and clashing color schemes. It actually felt like the camo of both sides blended nicely into the terrain. (CWC mission 19 "Turning the Tide" is a great one to convert and play in CWR. Most unpbo'ed OFP missions work well in CWR as long as the T80's get turned into T72's, and the mi24's into mi17's, etc in the mission.sqm. Just make sure to use an OFP pbo tool to unpack the missions before editing...) Great job guys!

Hopefully main weapons are significantly destabilized when firing from a moving vehicle, such as firing out of a humvee or MH-6. I don't want to see the aforementioned vehicles driving around with a half dozen pinpoint gunners. Firing from a vehicle should mainly be an act of suppression or used to gain fire superiority. It should not be possible to make repeated aimed shots against enemies, as it is when using a stabilized gun turret in arma.

I think it's two javelins per vehicle, but I could be mistaken. I recall that number being used for Bradley CFV's and M113's... Additionally, I think tank platoons usually support an entire company or battalion of infantry, so it might be more balanced/realistic to only use a section (two tanks) to support the stryker platoon. (I think the field manual has a whole section on combined infantry/tank operations. Should be useful for your mission). For arma balance reasons, it might be preferable to give the at soldiers either one javelin or three AT-4's. AT-4's are often used one after the other (even though they are single shot), and it's hard in arma to reload from a vehicle. Limiting the AT soldiers to one AT-4 might make them less effective than in real life... Good luck!

This was proposed but never actually delivered (likely due to technical issues). I certainly would like to see it. About game modes being set by the mission designer: Perhaps a bit disorganized, but I MUCH prefer arma to other engines as arma's game logic is stored in the map, not in the game's codebase itself. This means you can add or change new game modes without modding the game. This is a huge advantage arma has over other games which have one or two game modes hardcoded in. This makes new types of game much easier to create and distribute in arma, and as such the game types can get quite creative. That said, arma 2 needs some solid out of the box game modes which can be played right away... I don't want to wait another year for the mission designers to come out with good modes for arma 2... I recall reading that arma 2 would have a coop campaign which saved progress between sessions, and also a "capture the island" mode much closer to the OFP CTI map. Here's hoping...

How's v2 progressing? Very much looking forward to it. Keep up the good work!

I see CWR will use the same classnames as OFP. Will it also use the same display names? Specifically I prefer "rifleman" to "soldier". Also, can the ARMA classes be included with the new models? I saw that the arma classes might be included but I'm not sure if you guys meant with the original arma models or with the new cwr models and stats. I would really like to include automatic riflemen, squad leaders, and team leaders into my missions. Thanks.

Add irlock=1; to the cfgammo entry for the m136 and the rpg7's. That'll do the trick. It only allows AI to fire at 'irlockable' targets. All ammo has a cost value which tells AI when and when not to use it. Sometimes AI will use a weapon or ammo with a high cost when they think they're in danger of dying. (This was quoted from BIS afaik). I think BIS likes the fact that AI occasionally use rockets against infantry, and I doubt they'll make an official change. I'm afraid there isn't a good way to fix this with scripting only and no addon, and thus it can't be fixed on a per mission basis. My main problem with AI using AT rockets on infantry is that they miss most of the time, and that the ammo is so scarce. As a human squad leader, YOU know that they need to save their rockets for the armor which is about to arrive, but the AI does not know this and will happily waste their rockets (and ammo is especially scarce). My other beef, is that AT weapons generally aren't used on personnel due to their explosive design (penetration not fragmentation), and are only *occasionally* used to destroy structures. They are not typically used in open field combat. This is why I recommend the irlock=1 change. These weapons should require a valid 'ir lockable target' before they are used. Human players often don't use rockets against infantry, so why should AI? *Proposed change* For 1.09, all infantry AT weapons should have irlock=1; added to their configs, so AI only use them against proper targets. (I also think AI should not use stingers/aa launchers against ground vehicles! This behavior should be prevented at a config or AI level. it's useless to have aa soldiers in your squad as they simply fire their weapons against vehicles when threatened.)

I have a hunch about this issue: Combat density in arma PvP is pretty low. You might have a total of 20 players fighting in a 500x500m sector, much much lower than in traditional "army vs. army" combat. In a large scale & high density battle, straying from your comrades means facing unknown dangers, and your chances of survival are arguably higher is you stick with your fellow soldiers. In arma, with low troop density, sticking with fellow soldiers means that you're more visible: enemies that spot your comrades will likely spot and kill you as well. By moving individually, you minimize the chances of detection and thus death, in the short term. Since the combat density is low, it's easy for individual players to hide, and much harder for small groups to remain undetected. In addition, individual players have an easier time ambushing small groups of enemy players if the individual stays undetected. Also, small unit techniques are hard to execute effectively without training and proper tactics. Such techniques, combined with good communication, would likely make small units more powerful than an individual in combat. I think an increase in battlefield density would encourage players to group together. In 5v5 or 10v10 games over a large area, players will tend to split up. Plus, 30 second respawn timers in PvP maps encourage players to run off on their own instead of waiting to join a group of players, ensuring it's hard to form a small group and go into combat together (and even if you do, individual players will pick you off until only individuals remain). My thoughts.

Most weapons in arma kill with one bullet (7.62 and up), so a wounding script isn't very helpful unless all men have their armor increased (say, from 3 to 6). This prevents them dying outright. By catching their armor state dropping below a certain value, like with the dammaged eventhandler, you can run a wounding script. In my missions' wound script, when a unit's health drops below a certain threshhold, I play the "healing" animation, setcaptive the soldier so AI don't kill him (usually), and allow any friendly soldier who reaches him to bandage him to fighting ability (but not heal fully). It works well enough, but with men only having armor 3, they usually die before being wounded. Even two 5.56 in a row is enough to kill... With armor 6+ they can be merely wounded and disabled with a 7.62 to the limbs, instead of killed. I enjoy having soldiers wounded and screaming on the battlefield. Anyway, a wounding script is much more useful in context of an addon rather than just a script you can add to missions.. a pity.. Looking forward to what SLX cooks up.

Quoted for truth. IMHO what makes the AI 'dumb' is their squad level intelligence. AI is quite good on an individual and tactical level, engaging targets and returning fire. In terms of movement, deployment, and strategic intelligence? Not too bright, as these behavirs need to be dictated by AI scripts or mission waypoints. However, with a human in command, a squad of infantry becomes a very dangerous enemy... That's the PvP I want. Squad on Squad battles with humans in the important positions.

Still love using this pack. One thing I love: the minor recentering after each shot still requires you to reacquire a target at range, which makes repeated aimed shots still take skill and correct timing... The requirement for skill has increased and the guns feel more solid than 'vanilla'.