The_Captain

I work heavily on my own MP map pack, and don't generally play single player missions. Most of the time I play I'm tweaking or playtesting my maps. I do heavily play my own maps against AI opponents or one or two actual players, but that fits more under the playtesting category rather than actually 'playing'. I usually check the server browser before I start my own local server, and if I see new maps that are well populated, I'll join to see what they're like. I usually join MP games once or twice a week to refresh my 'feel' for how players actually play during games, and for what's currently popular. From this thread (and just observation in general) it seems that the people who spend most of their time editing enjoy arma for the editing, and are not dedicated "player" types... I wonder if that makes most editors (including myself) out of touch with the wants and needs of the dedicated "player" types. My server joining mindset: I generally won't join a server that's less than half full, and there are usually only one or two (sometimes up to a half dozen) well populated servers when I check.. Not much choice for me, and thus I don't join servers too often. I usually won't join a map unless it has the "type" field set in description.ext (Team, coop, etc). To me, it doesn't seem like it will be a well made mission unless the designer has filled in the type field... Total bias on my part, but it's certainly there. I'm always on the lookout for new maps on populated servers that have a "team" flag set in the desc.ext OT: I know about OFPEC's beta testing forums (though I frequented OFPEC much more in the OFP days), but IMHO there needs to be some sort of MP mission editing group (with its own server if preferable) that frequently meets to playtest each other's maps. That might help more MP maps gain visibility and get finished. We need new and fresh MP maps and modes! I have a feeling many of us have half finished MP maps that could use some sort of organized playtest group...

That recoil mod really fixed the gun feel for me. Can't play without it. Also, I haven't really noticed the waiting-for-other-anim-t-play-before-death problem since it was greatly minimized in a patch. Now they quickly transition to the death anim instead of waiting for the other anims to play first.

I have a wounding system for a map I'm working on that incapacitates people (forces the healing animation) and setcaptives them when they take .5 damage. Any nearby friendly soldier (ai or player) can the bandage them until they an stand again (but not heal completely unless they're a medic). In a small config addon, I also doubled a man's health from 3 to 6. In this framework, a 7.62 to the limbs would wound, but not kill, while a single 5.56 would leave a soldier ambulatory. A 5.56 to the chest would wound, and a 7.62 to the chest was a kill. Anything to the head would kill. Wounded soldiers are unable to move or shoot, and aren't targeted by AI. They can, however, be manually targeted by ai or accidentally killed. I'm considering adding bleeding out while wounded as well. I was unsatisfied for a while with the general damage system in ArmA, and the addition of a 3rd 'wounded' state in addition to "alive" and "dead" make combat much more engaging for me. A further differentiation between .50 cal, 7.62, and 5.56mm also makes things more interesting (outright kill, usual kill, and sometimes kill). When every bullet kills in one shot, why have different bullet types? Now, soldiers who would be critically wounded instead of killed in reality are shown as wounded instead of killed outright. With the amount of rounds thrown around in arma, the wounding usually only happens with unaimed or distance shots (at close ranges you put full bursts into enemies anyway). As a player, catching a stray round gives you the chance to be healed (while being ignored by AI in the meantime), instead of being shot at while your crippled self tries to crawl to safety... That was just my simple solution to "lots of death, no wounding", as well as crippled AI who carry on the fight to the death. There's also something magical about executing a wounded enemy soldier to take his weapons.

If addon is only to hold the scripting core, but allows for better security, might be best to release addon and no addon version. Servers who are concerned with security can run addon version, while casual players and servers can run without. I recommend no config changes in the addon, like new vehicles or equipment. Best to keep compatible with as many players as possible.. Berzerk is best in public play, attracting lots of players, and less people will play if the addon is needed. (Of course, people will get the addon to join servers who require it, if it's optional and helps security...)

I agree, Nepumuk. In arma, infantry can be destroyed easily by point fire, so the best strategy for a squad in contact is simply to stay in position and return fire until the volume of incoming fire has dropped, either by forcing the enemy to retreat (unlikely) or killing a significant number of them. Movement in the face of able enemies means 1) your soldiers are not firing back and 2) they are exposed to enemies who cannot effectively be suppressed. Your volume of fire drops, and your soldiers often won't get a positional advantage by moving (usually, if the enemy can shoot them, they can shoot back just fine). Not a good idea to move when you can simply shoot back. Bounding would be of more use for soldiers in contact in arma if 1) soldiers could take cover from enemy fire, 2) soldiers behind cover could be easily suppressed by incoming fire, but not easily killed, and 3) your soldiers could gain a positional advantage on enemy soldiers via movement/flanking/bounding, after which they could easily kill the enemies. Without the need to move to gain a positional advantage, it's a better strategy to simply return fire until movement is possible. Bounding/Movement/Flanking *is* of use when a squad is out of contact, however. On many occasions, playing coop squad command missions, I have pinned an enemy squad with fire (enemies drop to ground, return fire, only focus in my direction) with my own squad while a friendly squad (human led) flanked and killed the AI squad (before mine was annihilated). (In one instance, our two squads of eight soldiers each killed around 30 troops in one engagement while only losing four from my original squad...) Tactics like these only really work if the flanking squad has not been committed to combat, and all squads are commanded by humans, with group respawn if possible. AI squads can't really execute squad level tactical maneuvers in the face of enemy fire without being summarily gunned down. I have the most success keeping my own AI soldiers in one combat formation, where I only need to worry about the formation, stance, and potential threats for one group of soldiers at a time. I have bad luck splitting my squad into subgroups. I also seem to have luck keeping AI moving (out of contact) in formation with stealth/stand up commands. When contact is initiated and I want to break contact, I often tell the squad to "stay back" (move 50m to the formation rear) while I and a few other AI focus fire on the enemies. Sometimes I die in the process, but usually the squad breaks contact and moves out of harm's way instead of staying put and dying. This really only works if the squad has some fire superiority at the start of the engagement...

I remember in OFP, AI squad members would run to catch up, even if you had stopped, if they were too far out of formation. I miss that behavior.

Though this weapon is .50 caliber (solenoid fired version of the M2), it seems to have some good overheating information: M296 .50 Cal. (12.7mm) MACHINE GUN: http://www.fas.org/man/dod-101/sys/ac/equip/m296.htm The key bits I picked up were that for this weapon, 50 rounds in a minute is the normal maximum, and by firing 150 rounds in a minute, you must wait ten minutes for the weapon to cool. So firing too much over the maximum means you need to wait a long time for the cooling process... 50 rounds, you should wait the remainder of a minute, but 150 rounds, you should wait ten... I think 7.62 weapons are more forgiving, but there's also a good description of the effects of overheating: bore wear, accuracy loss, weapon seizure, and rounds cooking off...

Re: Barrel overheating Will it be coded roughly so that: each fire of the weapon increases the "heat" of the weapon, while an equation lowers the heat by a steady rate after the firing? Will a higher heat amount increase the likelihood that the weapon "runs away" on its own, or 'jams'? Will a critical heat amount cause the weapon to be inoperable until the barrel is changed, or even permanently inoperable? I'd think these two would be good starting points, while barrel changes should be fairly easy to code as long as the gunner has unlimited barrels, or is assumed to be switching between two (ie, no barrels stored in inventory). A "barrel change" action similar to the remedial action, with a reload animation, would seem appropriate. I know from anecdotal evidence that the M60 (original model) was suggested to have a barrel change if 200 rounds were fired in a minute, and a burst length of 5-7 was the most an operator should fire at once. The M60E3 with a lighter barrel needed a change after 100 rounds. I don't have any data offhand for the M240, pk, or M249, but I'd assume they'd have similar operating parameters:sustained rate of fire at 100rpm, and rapid at about 200 (changing barrels every minute or so). Afaik, once a weapon like the M60 starts running away (chamber is hot enough to cook off rounds), the weapon will continue to overheat as more rounds are fired and the small parts inside (sears, springs, etc) may melt, seizing the weapon. 200 rounds a minute, with 5 round bursts, translates to 40 bursts in a minute. With a cyclic rate of 600rpm (550-650), a 5 round burst takes a half second to fire (10 rounds/sec). With 40 bursts in a minute, that means a new burst is fired roughly every 1.5 seconds. On average, this would mean .5 seconds of firing with 1 second of cooldown. After 40 iterations, the weapon's heat level would be raised to near the critical amount that would suggest a barrel change. (this could be represented by the weapon smoking) I think from here an equation could be found that would provide the amount of heat per shot, that given the average parameters above, would lead to a critical heat value being reached after one minute. I'd guess each weapon would need an amount of "heat" that each bullet added, a rate the heat would decrease (linear, geometric, exponential), and critical values for weapon stoppages. Using the M60 example, if each round added 1 "heat", and 100 heat was a "good idea" for having a barrel change, and firing at an average of 100 rpm in 5 round bursts would leave the heat at acceptable levels (close enough to 0), but firing at 200 rpm in 5 round bursts would raise the heat to the critical value after 1 minute, then you could assume the barrel would cool completely after waiting 2.5 seconds after firing, and the barrel would cool partway waiting 1 second after firing. The simple equation I cooked up is that each bullet adds 1 heat, and the barrel cools 1.5 heat per second (or .15 every 1/10th a second). One shot every 1.5 seconds would leave your barrel completely cool, while firing 100 continuous rounds would leave you at 85 heat (You'd need to wait almost 2 minutes for the barrel to cool back to 0 after that). Firing three belts in a row with 4 second reload pauses would leave you at something like 350 heat. To suggest players don't just fire on cyclic, maybe this hypothetical M60 would have overheating issues around 100, and start breaking down around 150-200 heat. I also think all rifles should be subject to overheating, not just MG's. Rifles have lighter barrels, can't have barrel changes, but the need to reload does limit their rate of fire. A hot barrel (esp for rifles) should increase the chances of a weapon malfunction. Just some ideas for overheating. The numbers are just wild guesstimates, of course. I agree that actual data should be used for determining what rate different weapons heat up when fired, after how many rounds they might seize up, and how long it takes them to dissipate heat. I know, for example, that some modern MG's have special barrel designs to allow much longer periods of sustained fire (anyone seen the youtube video of the mk43 firing 800 rounds in cyclic? woowee...)

A few thoughts: 1) Could the IA action be added upon the attempt to fire the next shot? IE, the weapon is considered "jammed" after the shot that actually jammed the weapon, but the player doesn't realize this until he takes his next shot. After attempting the next shot, the weapon enters the jammed state and the player is allowed to clear it with the unjam action. This could be when the icon pops up in the center of the screen, providing immediate feedback. 2) could the action be bound using actionkeys to an existing key? 'R' for reload is a possible candidate, if you could override the reload that happened when the player tried to clear the jam. (Or, heck, you could just have reloading be the trick that 'clears' the jam, and give the player the original magazine when the jam is cleared). This might make the unjamming process more fluid. 3) Could you start an animation, such as the reload animation, and cancel it partway through using switchmove "" or playmove ""? This might speed up the process if arma doesn't try to finish the old animation... Random thoughts..

I've long thought that conventional Arma PvP maps generally require at least a dozen soldiers/players to be fun. I think most players know this as well, and most people will not join a PvP server that has only 2 or 3 people on it: the game won't be fun. I think Evo is popular simply because you can start a server by yourself, and other people will slowly filter in until you have a full game. You are guaranteed to be able to fight enemies even if you start the server by yourself, and it's likely other people will join you as you play. (I'm not a personal fan of Evo because it feels too much like "work": One unit of effort, one unit of result. Repeat. Plus, the fact that you can't *lose* the mission removes all tension from it for me..) Most PvP maps only shine when the map's density increases to acceptable levels: usually at the very least 2v2 for small PvP maps and upwards of 10v10 for the larger ones. But unless players can be attracted to such a server, those maps won't be played often. This is the wonderful chicken and egg problem that I think contributes to unplayed maps and empty servers: No one plays the maps since there aren't enough players who are willing to play them, which all but guarantees that there won't be players willing to play them in the future... Here's what I think will make a PvP map successful on public servers: 1) Large kill counts. (Ffs, I'm tired of joining PvP maps and seeing the playtime at 1 hour and the most kills on the server hovering around '4'.). More killing and mayhem loosely translates into more fun-per-minute for the players. 2) Playability with a small number of players, with potential for more to join. No one wants to play a massive 200 player PvP CTI... by themselves. Make the map fun with a low number of players, and people will join and slowly increase the player count. 3) A quick resolution to the battle (in lieu of time limits): Small player matches are more fun when one team can press an advantage and win quickly, ending the map. Waiting around for time to expire or points to be scored as the main victory condition is deadening. 4) Dense combat areas: Proper density contributes to the fun in combat, while an empty battlefield leads to long range sniper duels between anxious players. Get a proper ratio of players-to-terrain and the battles will come alive. ~20 human players running willy nilly around the entire island is just too low of a density for there to be any fun. 5) A sense of progress or progression: It's enjoyable to play a map where you meet gameplay milestones and have memorable moments as you play. It's fun to push the enemy's respawn backwards with every location you capture, or to put certain vehicles permnently out of action. Super-equalized gameplay where every person you kill respawns nearly instantly until the end of the game, and the battle lacks a central focus aren't that much fun. How about maps where taking objectives unlocks new vehicles, or where there's a cap on how many times a team can respawn? Coop maps tend to meet the above criteria, and I think that's one reason they're enjoyable: Fun with a small number of players, lots of enemies (high potential kill count), dense combat areas, a sense of progression (usually the number of enemies is fixed, so every kill means you're closer to victory), and usually a quick resolution (though often they have "hunt the last bastard" syndrome, which fails "quick resolution" criteria miserably). I think some squad level PvP maps where two teams fight within a single town would do more to increase prevalence of PvP maps than massive, 200 player CTI's. Also, as much as people dislike the option, having AI players fill in for humans in PvP maps might allow small player numbers to enjoy the maps until more humans join. Even though AI can be pain, it's more fun to fight AI than no one at all. I enjoyed a few games of AAS on the 16th AAB server a few weeks back. It's a good game mode that's open to some stellar map design possibilities. Where's the killer AAS map pack that has a dozen well balanced maps for 32 players each? I groan a bit when I see maps intended for one or two hundred players... I want to see something that's more likely to get played to its full potential. I was a big fan of the 32 player C&H maps on the Stoner's House of Pancakes OFP server back in 2001-2. I want to see that sort of simple PvP mayhem return in some form. Disclaimer: this was a rambly 2am post. Edit: For Arma2 PvP to be successful, it needs competitive PvP playtested and well designed out of the box. Not CTI, not Evo-style Coop, and not a coop version of the campaign. At least a dozen medium scale, competitive PvP maps for 32-50 players that are roughly a kilometer square in size. BIS could do well to study games which are focused on multiplayer competition, such as World in Conflict, that were designed to work flawlessly out of the box. I think BIS focuses too much on the simulation aspect of their games, and not enough on the gameplay itself. While many of us buy the game for the simulation and simply to tinker, most gamers really want something that *plays* well... BIS should deliver this. The alternative is having BIS modes that don't work upon release, and no user modes working upon release.. which means no out of the box competitive multiplayer for players to play, which means no competitive community.. erg..

As far as I know sakura-chan's animation fixer fixes some of the transition bugs you outlined (like moving extra steps after selecting a new movement mode). http://www.flashpoint1985.com/cgi-bin....=sprint re: at position: I seem to recall that most AT launchers, even though the tube is 'open', still provide quite a jolt to the user, and thus a crouching stance is optimal. I forget which thread that was brought up in. Re: moving while reloading: I wouldn't mind moving while reloading, but I do think that reloading without moving should be a *much* quicker process than reloading while moving. Dropping a magazine onto the ground and replacing it while walking doesn't sound too hard, but replacing the old magazine in your vest, searching out a new magazine, and loading that into the weapon is much more difficult while moving, and pausing for a few seconds certainly helps the process.

I think I'm rather slow... what's the exact problem with the way the lighting is configured? It seems natural enough to me...

Yeah, the entire point of the snippet is to ignore component damage and make tank damage (towards destruction) entirely based on hitpoints, which is completely the opposite of your solution. I might consider faking component damage in the eventhandler by catching the damage level of certain components before "undoing" the damage. I'm assuming there's no way to catch the vector of a projectile that hits a vehicle... (to determine if it hits the front, side, etc. I assume you simulated this by relocating the tank's hitpoints) My goal was mainly to make tanks much less vulnerable to explosives: poorly aimed missiles, rpg's, mines, satchels, etc, while still allowing them to be weak against tank shells (their natural foil). The hitpoints system does bug me, as I much prefer a system closer to what red orchestra has: shots either penetrate the armor, or they don't, and they can damage internal components on the way in. By proper tank positioning you can manage to deflect or avoid shots... Without some sort of skill in applying and taking damage, tank v tank becomes a "shoot first" game. :-/ @NWD: What if, for the tank armor/ballistics mod, you make the direct damage tank weaponry do *much* more damage than all explosives, and increase component armor accordingly (keeping your same ratios of tank damage and tank armor)? That way explosives would still have a negligible effect on tank armor, while the direct damage projectiles would have a much more striking effect.

A quick idea for improving tank battles (even though it doesn't improve tank armor), short of redoing the armor system or writing new addons. Basically, this short script stops the crew from bailing when a vehicle takes damage that renders it immobile. This makes armored engagements more exciting, and fighting against tanks as infantry much more intense. (I hate the rotating tanks with dead crew nearby.. ugh). This makes abrams and even T-72's a LOT scarier, as you can land a good RPG/AT4 to the tracks, and the tank will often spin its turret around and machine gun you for your trouble. Missiles don't seem to be as effective as killing tanks than a good sabot shell, meaning that tanks are the reigning tank killer. You really need to pile on RPG's or other ordnance to kill a tank, instead of any little thing disabling the tank, causing the crew to bail. I run this script as the damaged eventhandler for tanks in my missions: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_tank=_this select 0 ?canMove _tank:Exit ?Fuel _tank == 0:Exit _tankDamage=Damage _tank _tank SetDamage 0 _tank SetDamage _tankDamage _tank SetFuel 0 This prevents the crew from jumping out of the vehicle when it can no longer move. It accomplishes this by setting the fuel to 0, and reapplying the damage across the entire vehicle, so the vehicle is immobilized but still fights. It was pilfered from a mission thread in the WGL forums (I forget whose clever idea it originally was). The crew does bail when the tank gets to a large damage value (ie, red and about to explode). This means that you have to actually accumulate enough damage to *destroy* the vehicle before it stops being a threat, which is *much* harder as a simple infantryman than you might expect. Multiple satchels or RPG's are needed. Merely tracking the tank just makes it angry. As a human tank commander, your crew actually stays in the tank instead of bailing and dying as is normal. There are a few annoying side effects, such as the vehicle being mobile again once refueled, and also there not being any way to move the tank once it's been tracked (when the track is knocked out normally in arma, you can at least move the tank around a bit as the human driver). This really should be paired with a script that checks for refueling and sets the fuel to 0 again, some sort of message feedback for the player, and another that gives fuel back to the tank if it gets repaired by a repair truck... but as a quick hack it works well enough. (By the way NWD.. your tank FCS/armor rework is awesome. )

In terms of aims for gangs: You could have gangs try to get a certain amount of money and then "buy" the government or courts on sahrani. That would allow the game to end once some civilians have enough money. (IE, gangs buys its legitimacy). Also, having player created gangs would be much more fun than "red vs. blue", esp if players could defect to rival gangs... For gangs, you might want to have the leader of the gang get a 10-50% cut of everything his gang members get. Also, buying & selling drugs in different towns for money (like in the old Dope Wars) is always fun for gangs to do...

What are the specific animation/transitions that are fixed? I'm curious.

Wow.. I can't wait for this fix to be released. I would also like to see fixed transitions such as these included in our 1.09 patch. A bugfix like this shouldn't just end up being a "clientside only" cheat when used on public servers.. it should be an integral part of everyone's game. </rant>.

Is this a server required addon or clientside only? Will there be versions of the maps which use the "addon" and versions which don't, or will all versions use the addon? I like playing Berzerk addon free because it makes dropping into a server easy. Just want to make sure there will be an addon-free version.

Zaphod, That is a simple solution which has much the same effect (keep squads together in combat). I say try it... Also will give a good reason for people to join squads. I had a quick question about your publicvariables. You said you packed them all in a string... does having one large publicvariable string take less bandwidth than lots of variables? Do you send it every second (for reliability) or only when one variable changes? Thanks.

Re: the tank doing 360's: In one of the arma patches, they decided to leave engines on when you eject or change positions in a vehicle. I assume this is because enemies target vehicles with engines that are on, and the devs wanted AI to engage empty vehicles. This had the nasty side effect, in tanks, of continuing to rotate tanks if they were turning any amount when the driver position was exited: (eg if you move to gunner spot). Hence, f*^ 360's. Also bloody annoying when you knock out a tank's treads, the crew jump out, and the tank does 360's. (To get around this, in my missions I set a tank's fuel to 0 when it can't move, so the crew don't jump out and the tank doesn't do 360's...) One could add a "getout" eventhandler to every vehicle that switched off its engine or a script that checked for a null driver and turned the engine off. Anyway, annoying. (P.S. I think arma animations are fine for MP PvP...)

A revive script wounds players in place when killed and allows other players to "Revive" (bandage, perform first aid, etc) them with an action to let them respawn in place instead of at base. Usually players die/bleed out after a short delay, and they can choose to wait for another player to revive them or choose to respawn at base. This makes it easier for squads to work together, because they can revive their teammates who are dead instead of waiting for them to drive all the way back...

I haven't looked at deletevehicle, but I have used deletecollection for my infantry-obliteration script. When people get a high velocity when damaged (ie flying through air), I deletecollection them to remove them from play and show a blood effect, but don't deletevehicle them in case they're a player (and need to respawn before I can do that, since deletevehicling a player crashes arma). It seems to work properly over MP, removing a unit from everyone's visibility... well... then again I execute it locally... I'm rambling but I should test this one out. Doolittle, what happens when you deletevehicle, in terms of connecting clients? Do they still see an object even though the server deleted it? Or are they sent position/location information though the object is removed? Time to test... I wonder if a vehicle which has been deletecollectioned takes up less bandwidth when it is sent over the server...

I second the request for a revive respawn option. It would really help members of a squad stay together...

This is interesting. I didn't know this. However, I'm packing all my publicvariables into a single string which is sent in short intervals, which should reduce the amount of handshaking. Is this solution preferable to having lots of publics, even though the string is large? What about clearVehicleInit? It seems that this might clear an init, but I haven't tested it myself. It was added in 1.08, and looks like it solves the problem you outlined. Edit: oops, looks like clearVehicleInit only removes pending commands, not executed commands...

I was a bit skeptical until I actually watched the new videos. The new speeds are fast, but not impossible, especially compared to other games. It might look silly watching a large group of AI walking and running at fast speed, but for fast PvP combat it should be fine... I prefer the normal speeds, as they seem more realistic to me, but to each their own. (aside: I wonder if going prone will be less useful since everyone's movement speeds are so much faster... hmm..)