The_Captain

It's nice to have the option; It would be frustrating not to be able to turn off some behavior if it was enabled by default. Thanks for making it optional!

Woo hoo! Thanks guys. You need "advanced artillery features" and "functions" modules in mission to get... additional artillery features. I suspected it was that module but couldn't figure out why it wasn't working...

Hi, I noticed that when making missions in the editor, I don't have the ability to enter "push" mode for the AT guns, or hitch mobile mode AT/AA guns to vehicles. I wasn't able to find an appropriately named module to get this behavior working. Has anyone found a simple way to get these working? In the meantime, I'll be digging through the IFA's to see how this is done in official missions. Thanks!

This will be very useful. Thanks!

Hi, I've been working on a scripted armor/ammo penetration system for an old Arma1 multiplayer map for a while, and I'd like to release it soon as a standalone addon for testing. My goal was to allow a level of fidelity in tank combat similar to Red Orchestra. (Not simulation level, but much less 'arcade' than bis' hitpoints style simulation). My main frustration was that abrams tanks were quickly disabled from front turret armor hits, making them useless even in a hull down defense. While there are good addon based solutions to this problem, I wanted an entirely script based one to integrate into a multiplayer mission without requiring addons. The code mostly grew out of a "what-if" hack about a year ago, where I tried using spooner's LOS code to see if I could detect an intersect between a flying tank shell and any nearby tanks. It's not a perfect solution, but it's good enough for most engagements and weapon types. Currently, the code tracks flying tank shells, rockets, and missiles, and uses cubic bounding boxes (determined from o2 coordinates) around tank sections to determine if a shell is about to impact. Since it is the angle of the round that is used for the penetration calculation, and not a heuristic such as direction to the firer, the impact calculations can be made relatively precise. For an impact, the code gets the angle between the surface of each bounding box hit, the entry and exit points of the intersection, the damage of the shell (which is close enough to RHA penetration for my purposes), and the armor strength of that surface. A penetration of one surface will allow the projectile to test for penetration into the next intersected section (eg, your RPG might penetrate the tracks, but lack the power to penetrate the hull.). Non penetrating rounds don't do damage, while ones that do penetrate cause damage relative to the distance traveled through the section (eg, nicking a t72's treads does not blow up the t72), and have a similarly scaled chance of causing critical events (crew damage if the crew compartment is hit, ammo explosion if the ammo compartment is hit, etc). RHA damage of projectiles is scaled along a bell curve to allow variation in damages, and also depends on speed of projectile for kinetic projectiles (indirecthit=0). Kinetic projectiles have a chance to 'overpenetrate' vehicles and emerge from the other side, or deflect on a failed penetration. All damage, armor, and section armor values are taken from the BIS configs, as they roughly correspond to real life RHA and penetration values. Example: A T72 sabot (~630 damage scaled downwards based on current vs. initial speed) hits an m1's front hull armor (85% of total armor, scaled to 100% for the front of a section, equaling roughly 725), at an angle of 10 degrees off perpendicular (scaling the 725 to 725/cos(10 degrees), which is roughly 770. The sabot round's penetration is scaled to a bell curve distribution, where about two thirds of the penetration values will lie between 700 and 560, with a small chance of higher and lower values. This gives the T72 a roughly 2% chance of a penetration higher than or equal to 770. The variation helps to account for differences in the armor strength along an armor plane, which simple bounding boxes for armor with a uniform strength can't simulate. If the t72 had hit at 0 degrees, the armor strength would stay at 725, and he would have roughly a 10% chance to penetrate the front hull. The side tracks are 15% of the total armor points, and scaled by 50% for 'side' hits, meaning from a perpendicular direction the tracks equate to about 63 RHA. After a round penetrates the tracks, the hull has .85*.5*850= ~350 RHA from the side, meaning that even an RPG can penetrate the side armor of an abrams and cause some internal damage (but not nearly as much as a tank round, as the tracks should have a mitigating effect). Limitations: Performance wise, the code relies on quick iterations to grab nearby potential targets and perform intersect calculations, and thus even a beefy machine can experience slowdown with a dozen or more tanks firing at the same instant. Because FFAR's and autocannon rounds have a high rof, the script does not track them. The code also relies on manually configured bounding boxes (min and max coordinates for turret, gun, hull, tracks, etc) to catch intersects, making it a pain to integrate 3rd party addons (and even new vehicles). The calculations for damage armor penetration are reasonably 'back of the envelope' and not perfectly scientifically accurate. Currently, armor has the same strength vs. kinetic or explosive rounds, though this will be modified in the future. I haven't tried to integrate with mando yet (I use a simple scripted system based on GDT missiles to allow precise SACLOS control), but I have a feeling both sets of code would interfere without specific integration. Cubic bounding boxes are imprecise, and allow for a few weird situations since they do not match the actual armor slope. The code is not foolproof: if a tank shell makes it through the code suite, it will cause normal BIS damage to a target. For example, a ricochet off the ground right in front of a tank sometimes causes the shell to ricochet into the target before the impending penetration is detected. Currently I only have a version for arma1, as the code is performance dependent. I plan to convert the time sensitive scripts to fsm for A2, though I haven't tried this yet. I should be able to release some code soon (I'm currently busy with exams). Sources: http://en.wikipedia.org/wiki/Sloped_armour http://www.steelbeasts.com/sbwiki/index.php/M1A1_(HA) http://www.steelbeasts.com/sbwiki/index.php/Image:M1A1_HA_frontLOS.jpg http://www.steelbeasts.com/sbwiki/index.php/Image:M1A1_HA_sideLOS.jpg http://www.steelbeasts.com/sbwiki/index.php/T-72M1 http://www.steelbeasts.com/sbwiki/index.php/Image:T72frontLOS.jpg http://www.steelbeasts.com/sbwiki/index.php/Ammunition_Data http://www.fprado.com/armorsite/US-Field-Manuals/abrams-oif.pdf

AA missiles should not be able to IR-Lock ground units. Period. This includes sidewinders, stingers, strelas, and tunguska missiles. In A2 you can often get radar locks just beyond visual range, which would make a vehicle with 8 ready to launch missiles extremely powerful. The tunguska would not be nearly as all-around powerful if its missiles could only target air units. (On the flipside, I'm sick of seeing AI gunners wasting their single stinger on a tank, but that is neither here nor there...) I would really like to see this engine limitation fixed in a later patch (EG: ammo with 'airlock = 2' would *only* be able to target air units).

I think you need "lctrl+lclick" to order the gunner to fire. Check your key bindings, command fire should have changed from control in arma to control+lclick in a2.

Good campaign so far! I'm on the second mission. Not too hard, not too difficult, not too complicated. Good work. The main improvements that I could think of would be fixing a few errors in the chat and radio text.

(nevermind)

I think most saved games won't work properly after a patch, especially if the missions themselves were modified. You'll need to restart the mission. :/

Agreed. The beginning of the campaign put me in somewhat-realistic command of team razor, and I expected this feeling to continue to the end. I would have preferred the last two campaign missions to either: 1) Put me in command of only team razor, with AI controlled supporting resistance units, to accomplish the story objectives. 2) Put me in command of team razor, with high-command resistance units given to me by the campaign, to accomplish the same objectives. I don't want: flag capturing, unit purchasing, base building, respawning enemies, supply trucks, and warfare mode in my campaign. If BIS wanted a warfare campaign, it should have been separate from the main story campaign. Maybe someone could mod the original campaign to behave like this... :)

HardOCP did a comparison between the 5870, 4890, and GTX 285 in Arma2. The 5870 dominates in arma2. (Naturally though you'd need a widescreen HD monitor to take advantage of the performance boost...) http://hardocp.com/article/2009/09/22/amds_ati_radeon_hd_5870_video_card_review/8

I'm most looking forward to the M113, BTR-60, and T55! Color me old fashioned...

Quick update: The ArmA1 version has taken longer than expected, and I took a much needed break during the summer to focus on some university courses. I have finished most of the major tasks for the v0.4 release, and only have a few smaller issues to clean up. After the initial scenarios are finished, and some private testing is done, I will release v0.4 as a public beta. What will be in the release: 3 PvP maps, for 4v4, 8v8, and 12v12 player sizes. At least one cooperative-style map for lower player counts Limited combat support for formation commanders (artillery, airstrikes, reinforcements) Fully operational briefing, deploy/spectating, and debriefing interfaces What will not be in this release: Chain of Command control of other player squads Full combat support interface and options AI-as-player support Extra unit types (HALO Special Forces, Engineer Teams, Artillery batteries, etc) MP Campaign play I will try to release a video demonstrating a round of play prior to release. After v0.4 is released and tested, I will work on porting this newer version to ArmA2. v0.39 was already ported to Arma2, but I will need some time to port over the latest batch of code and fix arma2 specific bugs. I will say that the new micro-AI in Arma2 vastly improves the experience of commanding a squad I intend to complete the A1 version first so I can focus fully on the Arma2 version. I aim to have both versions released before OFP2 comes out!

I've been able to get it working in Arma and Arma II. Generally, the unit needs to be local to the computer you're using for the switch (which means, as far as I've been able to test, you need to create the group on the client's computer and create units within it). It's possible you could create units on the server, move them to a group local to the player's computer, and then switch, but I haven't tried it. I have had rare CTD's (I think it's when the code tries to switch to a unit in a vehicle that has died within the frame that you're switching), but these commands used correctly are generally pretty stable. You also need to execute the commands on the local computer. In arma I, the player identity is not transferred to the new entity, so while the player retains his name in chat, the unit has the original identity ("David Armstrong" or similar). In Arma II, the identity is transferred to the new unit, which means the correct name shows up, but never leaves the old unit. So if a player switches between units within his group, if he waits a few seconds for the game to transfer identities, eventually they will all have his name. This additionally creates problems with MP vehicle control: If you are the tank commander, switch to the gunner, and back to the commander (and your identity is transferred to the gunner), the gunner won't fire when you order him to, because the game _thinks he's a human_, and won't send the fire command. (I have a workaround that overrides the commander fire/switch weapon action and sends a manual fire command, which works for all weapons except guided missiles...) Anyway, here's the code snippet I've been using. I use it in MP for direct teamswitch (T/Y/U) and group respawn. As stated before, the group is created on the client's machine, and all units are createUnit'ed on there. (Another simplification is that only AI units are within each player's group, so there's no danger of players switching into each other by mistake. This could complicate a coop mission with many players per group). I remember an old post where sickboy (I think) said bad things happened if you used non-local units or groups, so I try to stick by that. //get player's group _group = _this select 0; _units = _this select 1; _nextunitID = _this select 2; _oldplayer = _this select 3; _unit = _units select _nextunitID; if (!alive _unit) exitwith {}; addSwitchableunit _unit; selectplayer _unit; vehicle _unit switchcamera "Internal"; removeSwitchableunit (_oldplayer); (group _unit) selectleader _unit; From what I can understand, if you want to 'steal' remote AI for the purpose of teamswitching, you'll need to somehow make them local to the client computer first. Probably creating a local group and moving the unit over would work well enough. Good luck!