Strike_NOR

True true. I think I didn't explain it fully. Just like Thermal Imaging textures fade in/out with heat over time, the sound and smoke effects of a broken down engine could be visible during the same window, so that a cold/dark tank being shot in the engine won't produce noise/smoke because there is no heat, but a warm running engine will as long as it remains hot. There are other things that could go wrong than a broken radiator, like ruptured coolant lines, fuel lines, lubrication etc. They would all contribute to smoke/noise. I believe the advanced flight model has this when you damage the rotor from overstress. Very immersive imho. Also, there could be a better soundeffect when vehicles burn, with this metal clang/clack noise. RHS have implemented beautiful localized smoke effects for damage, but they still sound like a campfire to me :) A yellow state engine could have an audible sound effect over it such as knocking, whining, screeching or grinding noises to help the player understand that the engine is damaged. Just saying that it would be more immersive, doesn't have to draw away from simulation for that matter.

The way I see it: Arma AI today are incapable of training or thinking. Ergo, they can't learn to be good tank drivers, nor can they interpret commands or assess the battlefield in order to find "obvious" cover, as a human player would. Therefore, AI cannot be trusted or even used efficiently in combat pre 1.78. Even a simple traverse is always a huge oscillating back/forth wiggle thing. It is just unrealistically cumbersome. The new system, let's the player go exactly where he wants, where the audible commands are more there for effects/immersion. You can't tell the AI "Follow the road until you get to that large tree, then set up with hull facing 45 degrees to the left of the road behind those rocks". Instead you say "FORWARD, STOP, FORWARD, STOP, FORWARD, SLOW, STOP, LEFT, STOP, LEFT, STOP, RIGHT, STOP, SLOW, STOP". To summarize, it's not perfect, but the direct control allows a much better experience AND it appears more realistic. Tanks have more smooth movements, more precise and can be used more efficiently. It is therefore, gameplay-wise and one could even argue, realism-wise, a huge improvement over pre 1.78 driving controls. Not even mentioning the other possibilities that have followed in the wake of this: Tanks can now operate without drivers if the config is set up that way. Meaning if you have a vehicle where the gunner/commander controls the tank movement, so it is now possible to both drive and shoot at the same time. Great for mods, great for futuristic tanks (maybe tanks DLC stuff here). There is a middle-ground though for improving the voice issue. One could implement a form of "cruise control" for the AI. Instead of holding W to go forward, one could use a system where pressing W once, says "Forward" and the tank moves at cruise-speed until S is pressed for "STOP". If you press W again while you are at cruise speed, the AI will hit max speed. If you press W and S at the same time, the AI will cruise at "slow" speed. You would keep the traverse controls direct input, but speed is set more like on a boat/ship. It could work? Either way. The new system still rocks. If the AI driver dies, you can't move so it's still realistic :)

Hey OMAC. In the changelog you can see they changed the way a player commands the driver on purpose. It's been like this for a while on devbranch now and it makes the tank handle as if you are in the driver's seat yourself. The voice commands are technically only there for sound effects now. I believe part of the reason for this was to improve the single-player experience as a tank-commander for the upcoming tanks DLC. Also, devs have stated it is now possible to have tanks that do not have a driver at all, where the commander or gunner may control the vehicle. This is of course so that you can have a tank where the crew consists of gunner and commander, where the commander or gunner takes on the extra role of driver (think modern tanks with remote auto-loading turret systems). I find the tank a lot easier to control now and the tank gameplay much more enjoyable. Bear in mind, if your tank has 3 crew and the driver's seat is empty (no AI), you can't steer the tank. There must be AI crew in drivers seat in order to control it, just like before.

Wow, that's really great! If the Kuma sounds are anything to judge by, vehicles are getting a huge quality-boost in the sound department. After the weapon sound upgrade and jets DLC, the land vehicles were kind of left in the dust :) Here are a few ideas I think you should investigate (or maybe you already are you sneaky devs): Road -> tire sounds. In reality, if you think about cars driving by you. The faster they go, the less engine noise you hear and more tire sound you get. I think @LordJarhead with JSRS soundmod does this very well for vehicles as you can hear in this video: Various sounds for different surfaces (at least asphalt and gravel/dirt road) Anywhere with gravel makes a whole different noise. Completely offroad tends to be very low noise due to soft terrain, grass etc that silences the tires. Audible distance: In the same video, you can very easily get the correct feeling. You you easily think that "this is what it would sound like in real life". That's immersion! It makes you connect to the game better. Broken down sound effect: I suggest you take a look at adding engine smoke and damage sounds (typically the broken radiator effect works nice here with sizzling water on metal, making the metal "pop and crackle". This is a very good visual and audible indicator for players that a vehicle has broken down, without having the disappointment of entering it only to find "red engine status". As others have pointed out. Maybe a turbo sound effect that can be used for engines. Many, if not most diesels have turbo(s) and these operate on speeds of maybe 120,000 RPM average. The RPM generally increases with increase in exhaust pressure, so it could be a separate sound layer that increases pitch with RPM, but that it follows a different curve than the sound of the engine itself. Maybe, since turbo sounds are rather generic (whine), it could be added as a default config parameter for addon makers to use. Just a simple "Has_turbo = true or false" type thing and then what RPM it fades in/out and what "TurboRPMmax/min" it would operate at (to create varying pitch between vehicles). It could be used for piston engine aircraft as well. Then of course, maybe a second effect when you hit "shift" in vehicles (max throttle). Anyways, just a few thoughts while you are working on the effects anyways :)

Why not, like others have suggested, add the gorgon to the FIA factions with the new skin introduced with tacops? And throw in Edita for good measure ;)

I see you are a man of culture as well.. Touché! I hope the devs find some space in their hearts for some humor :)

It would be *such* an improvement if they slightly tweaked the mechanics here to more accurate simulation. Firstly. A first aid kit, or field bandage, does NOT heal you. It stops bleeding. Why is this important? Well, so you don't bleed out before you can get to a field surgeon, or medic. For some reason, in arma. This will magically fix you up to 0.75 hp. And if what @x3kj says is true, it will actually "damage" you if the generic health is over 0.75, but a body part is critical, allowing you to use a FAK. How I think it could be improved without breaking the game: Bleeding already exists in arma, but only at extremely low health, and is therefore rather uncommon to witness. I suggest tweaking when or how bleeding starts so that it either comes from a body part being critically wounded, or at a much higher "general health" %. Such as 50%. FAKs stop bleeding. They remove adverse player-effects such as limping or increased aim sway. However, they do NOT improve your health. Realistically speaking, there's still a bullet wound in you, and you need more than a FAK and pair of pliers to get that fixed ;) Medics fully restore health to 100%. How will it effect gameplay? Firstly. Realism without ruining the arma experience. Did you know that the "MARCH" (or MARCH-ON) first-aid drill means Massive bleedings, Airways, Respiration, Circulation and Head/Hypothermia/Handling? This is a step-by-step procedure of treating combat casualties. Why do you think that M (massive bleedings) is first? It is found that this is the by-far most likely reason you will die in combat. Not by fatal headshot, not by respiratory failure, but by bleeding out. So what? If you get hit in arma 3, you flinch. Big deal. You get hit again, return fire, flinch some more, shoot, survive. Now you are hurt. You are usually not bleeding, just hurt. You hear this by pain sounds and blurry vision. Fair enough, but there is an easy "arcade" fix. Use a FAK, which by the way you can take LOADS of in your inventory. These will return you to 75% health, guaranteed all the time. So you can take grenades, bullets, anything as much as you want as long as you live long enough to scroll mouse to "treat yourself" and voila, you are good to go! There is absolutely NO sense of urgency here. No life-threatening feeling or "shock" of being hit. You simply bite your teeth and carry on, or die from the next shot. However, if you start bleeding, that's an urgent ticking bomb. You have to prioritize: Do I continue to engage the enemy, staying in the line of fire and risking myself bleeding out. Or do I run for cover, stop the bleeding, then return fire? It gives you a better sense of urgency. Also, it means you are in trouble if you run out of FAKs in combat. This, however, is where the medic comes in. The medic is only 25% useful in ArmA 3. It's kinda hilarious. He has many FAK's, but they all do the same as the other team members FAKs. 75% health. So the medkit is really only worth 25%. Wow. So the medical specialist, with medkit is only 25% more than the infantryman with his single FAK. This is greatly undermining the role of the Medic in arma3. Also it's very arcade-ish if you think about it this way: If a bullet does 25 dmg, then 4 bullets = kill. With current FAK solution you could take 3 shots (25% hp left), then heal with FAK (75% HP). Take another two shots (25% hp), then FAK (75%). Another two shots (25%), FAK (75%). Get the picture? You have 7 bullet wounds, but you are still at 75% hp. From an inventory item that takes little to no inventory space and can be used by anyone on anyone. Heal yourself, your squadmates and all to 75%. My suggestion? Let the FAK only stop bleeding and remove limping/horrible sway. Do not let it heal the soldier. This means that he can only stop the process of dying, but not recover from the damage to the health. This is where the Medic comes into play, or medical vehicles or buildings. These special items have the ability to restore the soldier to full health, just like before. To summarize: I suggest making the FAK work as a bandage. To stop bleeding. For this to be interesting, the damage threshold where bleeding begins, should be way higher. If any limb goes "red" it should trigger bleeding, or if HP falls below, say 50%. This will make the medic more relevant in many ways. 1: He has FAK's for the whole squad, and has to distribute them as the team members need to stop bleeding. 2, he is the ONLY team member that can restore health. I also think it will create more interesting moments that are very immersive. Surviving an ambush, injured, having spent your first FAK, you find that you are still bleeding. It now becomes a life-or-death situation to scavenge for FAK's among the dead. It may also be a great reason to use medevac vehicles. To rush players to a nearby medic or medical facility in order to save the life. It makes you prioritize differently, instead of "well. I have 6 FAK's left so I can probably survive for a lot longer anyways", you are now thinking. "Crap, I've been hit badly, luckily I managed to stop the bleeding, but I seriously need medical attention or the next bullet will be the end of me.". It would play well both with and without incapacitated/revive mechanics. Just think this is seriously overlooked. It would even work with vehicles. A bleeding pilot must land somewhere before he bleeds out, a driver hit during an escape will only get "so" far before bleeding out.. etc. If anyone thinks it will never work, just look at Squad. Each soldier gets a first aid kit to stop bleeding. After that, they rely on the team medic(s) to restore full health. Results? Immersive, teamwork inspiring and functional.

This is actually so easy to reproduce that I managed this on my first recording attempt :) Please read my other post to see if this is what's going on.

I am going to make a "guesstimation" here and try to propose what may be going wrong. The way it appears to me, ArmA's wheels "snap" to surface. Meaning that if suspension of a given wheel is not fully extended, it is "snapped" to the surface (sticky). If the vehicle moves over a hill, and the front wheels extend their suspension to maximum extension, then the wheels do not extend further, but they still "seek" to snap to the surface of something. This method always works fine when there is a sudden increase in distance from vehicle hull to ground, because the wheel will simply "detach" from the surface, however it seems this has a really adverse effect when the opposite happens - when the distance suddenly decreases. When a tank traverses it's hull sideways, the roadwheels will hit some curb/stone/object and immediately, due to wheel/terrain "snap" it compresses the suspension in a nanosecond. This means that the force is happening at light-speed, transferring to the hull, and then launching the tank (this is ground control to major Tom, there's something really wrong). To me, this seems to be the reason. There is no "inertia" in arma suspension. In real life, the wheels are heavy, suspension is heavy and so if you try to compress the suspension, it will happen over time, not instantly. Sometimes it actually seems that ARMA 3 does not have physical suspension, only visual. Meaning that the 3D geometry model that acts with the surface is not really using suspension, but it's only animated for visual appeal. I may be wrong here, but that's how it feels some times. I found a video that strikingly resembles this theory of no "arma shocks". It's made by someone in algodoo, and shows a three-wheeled vehicle with suspension, and one without. Just look at the one without suspension as it hits a tiny "bump", and think about what you see in ArmA :) At 0:09 the first vehicle with suspension hits the small bump, look what happens to the second one immediately when it hits the bump: This is very much resembling what we see in arma. Now imagine that you "spawned" the vehicle without suspension so that the wheels where clipping through the object, but standing on the surface. The result? If the vehicle wheels are designed to "snap" to the surface, they will instantaneously travel the height of that object in virtually an instant. Leading to X amount of m over no time. A quick example of what this would look like. If a tank in arma, stands beside a curb that is 10 cm tall (0.1 meters). Imagine you traverse the track sideways so that the wheel "snaps" to the top of the curb as soon as it touches it. Let's say the time it takes for the wheel to perform this snap takes 0.01 seconds. 10 milliseconds. Then the speed becomes 10cm x 100 milliseconds = 10m/s. 10 m/s = 36 km/h which would definitely launch the vehicle upwards in a small jump, if it does not properly absorb/dampen the shock. Now what if the distance increases? Well the speed increases substantially. I don't know how many "ticks per second" the arma simulation runs at, but we can assume this is a constant. So then varying object height should vary the results. Poles seem to fling things to infinity and beyond, while small stuff seems to make vehicles jump. Have a look at this Quad ATV vs box. Although provoked by "moving the box", it seems highly related. Seems again that the game is trying to check if the vehicle should be ontop, or next to the object it is "half-way" clipping through. It suddenly decides "oh, you are trying to be on top of the crate" and transports the front up there in a single "simulation tick" then we have Liftoff! Like I said, I'm not 100% sure what's going on here, as I have not made any AddOns in O2 or tried to make vehicles in ArmA, but it does look to me that the problem that is causing this has to do with suspension, and wheels snapping to terrain/objects. The wheels should "transition" from the previous surface height, to the new object height over time, not in an instant. That would soften the effect some, and secondly the shocks should compress fast enough so that the force is not translated to the hull of the vehicle, subsequently launching it into space. I'm just adding my take on it and hoping it may lead the devs to the clue of what is going on. PhysX? More like SpaceX :)

Think about all the possibilities of women in ArmA 3??? *Peeks over at the Skyrim steam workshop*.... eeerrrr... on second thought..... ;) ARMA 3 LIFE NSFW pack! DOUBLE D EDITION, complete with Field Kitchen addon! Jokes aside, women are more and more common in armed forces which is only positive. I hope ArmA 4 utilizes a completely different character gear setup with clothes that scale to fit male/female characters. I hope this doesn't come off as gruesome, but I was almost hoping for a "character" damage model much like vehicles work. A generic man/limb-shaped hitbox (non-vitals) shape for bleed-damage, then very simple "internal hitboxes" to simulate brain, spine, heart, lungs, gut, main arteries (arms/legs/throat). Much like a vehicle has engine, fuel tank, wheels, turret etc. If the clothing system then properly absorbed bullet damage, a bullet proof vest would now work a lot better to protect vital organs. It would also open a new level of medical interaction.

Fantastic news! Tank you™ for your continued efforts to smooth out these bugs! It has been a long standing issue, contributing to all sorts of weird things. I must admit though, that while being incredibly frustrating at times, you also get some hilarious results as @dslyecxi so elegantly captured last summer :) Also this one had me in tears: One day we will hopefully look back and chuckle while rolling into battle with calm nerves, knowing that these things were a thing of the past :)

Tusen takk (Thanks for the rest of you) :) Many very good observations and some sincere feedback. Some of my inspiration came from the way frontlines worked in IL-2 Sturmovik (A WWII sim, where frontlines are more relevant to the time). They way it worked was by placing map markers (flags) in red or blue colors, these would all have the same "strength/weight" and push the frontline to the "average" point between friendly and enemy flags. Like you say, some big improvements are for Multiplayer TVT game-modes where the players decide where to go or where to send AI troops (player commander). This may allow players to act as special forces (recon, sabotage, deep-strikes etc) while AI populate the "generic infantry combat" role in the background. I do notice that AI try to use cover by moving behind them and peeking (strafing sideways wile leaning) to look around corners, but it feels more random to me than consistent. One sorely missed aspect is AI recognizing specific objects as "good cover". AI would prefer hiding in a sandbag circle, rather than behind a stonewall if both are equally available to him - such things. I do like your comments about using it for setting awareness, stance etc. Finally, it would have to be a module system because it would allow future missions to be developed WITH it, and older missions to work WITHOUT it :) It would also be a drop and setup module (setup side, faction, tactic style). (Asymmetric would seek to infiltrate enemy lines to cause havoc. Defensive would simply do all it could to hold the area it is given upon mission start and offensive would seek to expand. It's easy to use your imagination and see a much better dynamic war going on when there is a frontline. Everything is "safe and calm" on friendly side, aware towards the line, and finally combat/aware/stealth if you are in enemy territory.

Iz stell verr mach WIP projek :) Sorry, it's under development and will be posted in the Addons & Mods: Complete section when it is ready for download :)

This, coupled with the weird physics (no momentum transferred to the static technical) makes the situation so goofy! I can see numerous improvement areas from just this video: Fix collision avoidance. If Tesla can do it with real cars with cameras, so can you with an "all-knowing" game engine :). Slam brakes, steer away from object, recover when object is out of harms way. Fix collision physics (transfer of momentum). Both cars should have a "net" momentum, travelling together at a new speed which is lower than the speed of the crashing vehicles initial movement. Fix damage model. Just make it so that the fuel tank has to be critical before "unarmed" vehicles explode. This goes for "all" light vehicles. Technically they should not explode from fuel tank damage, but rather catch fire. Would be a nice addition with Tanks DLC. I get that explosions are fantastic for gameplay reasons (feedback to attacker that his target is definitely dead). This, however, is not how war is. Only high explosive ammunition of large size can obliterate vehicles. Either because it was fired onto the vehicle, or because the vehicle contained them (ammunition on board). A fuel tank can explode with a low pressure force if they are near empty due to the fumes. If a full fuel-tank gets hit, most likely you get a leak. At best you get a fire, and if that vehicle contains explosive yummies, of course it may explode. Man it would be beautiful to have a script that searched the vehicle inventory, looked for ammo and then randomly detonated that if the vehicle caught fire.

While on the topic... Technically speaking - the only thing that would make a tank explode (disintegrate) is if the entire ammo storage cooked off at once. The immense pressure would not escape quickly enough, further accelerating the reaction causing a detonation. This would shred the tank or blow the turret off as popularly seen in real life examples. Any lower pressure caused from less ammo going off would simply make a hollowing wooooosh as everything burns violently, like a blowtorch. Explosive warheads and coaxial ammo create secondary explosions. Contrary to popular belief, hitting fuel tanks do not cause high energy explosions unless they are near empty. Even so, the fuel bladder/tank does not have sufficient strength to allow pressure to build up. After all, theres going to be a large entry/exit hole which the gas can escape from. There may be a large fireball (not explosion) and ensuing inferno. This may, if heating up ammunition, lead to detonation of the ammorack and hence the tank. However not instantly. I sincerely hope and wish for more complex damage models where hull damage, wheel damage, fuel tank damage, engine damage, gun, turret etc DO NOT lead to vehicle destruction. The only thing that physically blows up a tank is ammo detonation. This leads to more types of "kills": Mobility kill Crew kill Combat ineffectiveness kill Tank burndown Ammo rack kill This will make engineering more relevant, to salvage wrecked husks of steel, repair in the field etc. Only the detonated wreck would be "beyond repair". All other kill types could be 'fixed' and crew replenished.

Fantastic. I was playing one of the Tac-Ops missions yesterday when a Varsuk decided to fire it's solid rocket boosters and head for low Malden orbit. Legend has it, it is now a modular part of the ISS (International Splendid™ Station).

Thanks for the input and i challenge you with a quote. Don't stop at pointing out problems, try coming up with the solutions Loads of fps sandbox games already incorporate enemies using objects for cover. Even GTA has dynamic cover behind vehicles, objects etc. I dare to dream of BIS figuring out this for infantry gameplay too. (Dont confuse with wall-hugging, or clinging to objects mechanisms, but the idea that they recognize cover in the first place.)

No, but reading the description it seems to be a simpler version of ALiVE without unit virtualization. It essentially takes units from one side and sends them to player-determined markers in the order of choice of the player. I am looking for a system that improves low-level AI also. I'd like the frontline to directly influence the status, arrangement and positioning of troops on squad level. Picture the following: An AI squad is placed in kamino firing range destroyed village with a hold/guard (etc) waypoint. They run to position and halt there. Since the "frontline" is now surrounding them (no known threats) they spread out evenly behind cover, and in buildings and occupy areas that are facing the frontline. Basically this means they will establish a 360 perimeter defense. Now introduce an enemy squad advancing from one side. As soon as the AI spots the enemy squad, the frontline dynamically shifts from omnidirectional to directional, between the known threat and allied forces. This means that whoever is facing away from the frontline, now automatically runs from their position towards cover/buildings on the side of Kamino village that are facing the frontline. This is the kind of system I want. That the squad assumes 360 defense without intel. As soon as enemy is known, the frontline is established towards them. The entire squad moves to counter the threat, effectively bringing more firepower to face the enemy. This kind of reaction really opens up the possibility of flanking maneuvers. The pinned squad, approaching kamino village, can now send a few guys to the sides to effectively flank them. In vanilla ArmA, some of the defending AI would just be wandering around the other side of the village, or be given orders to "attack" the enemy, meaning to move in their general direction until contact is made, then fire (dumb move). The smart thing would be to find some cover that is facing the frontline and be ready for the enemy to advance. In the same scenario, if a new enemy group approaches from a different angle, as soon as they are spotted the dynamic frontline shifts more towards the average area of the two attacking groups. The defenders now adjust properly and some are sent to watch/take cover by the new frontline area.

So far I'm loving it. It has much of the good stuff from LoW! Keep it coming! :) The only "bug" I have noticed is that the links in the tasks/objectives do some weird zooming in and out on the map, only tried first two missions of "Beyond Hope". 10 out of 10 will play again tonight.

If anything at all, it has to be implemented as an optional module based system, much like the way one would use the alive mod. Hopefully, such a system could tap into the BIS "Dynamic Simulation" module to simulate map-wide warfare. Instead of placing all unit waypoints manually there could be an AI commander module. The mission creator would pop down a "Dynamic Frontline" module, set it up to be either objective or subjective (objective manages frontlines for both sides, subjective manages per side). Then pop down an AI commander module for each side (which sets aggressiveness, style (tactics) etc.). This way it would be an all out sandbox warfare simulator, which is completely random and adaptive each time. By just using the frontline module alone, the AI would better react to threats, take cover properly and know where and how to flank. Even in squad on squad engagements.

Whoa, this is a really good/extensive list of improvement suggestions. I share most of your views and thoughts on this. There is a more complex, but sandbox-friendly idea that has popped into my head on many occasions. I would hope to see an AI system that works closely to how a human soldier, squad or platoon would operate when dealing with battlefield awareness and tactics. I'd call it something like Dynamic Frontline System (I realize there is a PVP conversion mod called Dynamic Frontlines, but this is not entirely related). Introduction How it would work is as follows: Each unit (U) has an individual "sphere of influence" which follows it, carrying the "side frontline". This dictates where "the average frontline" appears. If no known about threats are nearby, this average frontline encompasses a large area around friendly unit(s). Example 1. Single blufor unit surrounded by its sphere of influence, with its side frontline and finally average frontline (not to scale, this could cover the whole map). Each unit then has its own "weight factor". The higher the weight, the greater the sphere of influence becomes. These weights also combine with other members of the same group (G). Two soldier units of equal weight, will double the group sphere of influence weight. Two individual units that are not in group, will widen the side frontline, but not increase its weight. If any two units get too far away, their sphere of influence breaks into two separate spheres. If a group loses a unit, its weight decreases by the lost units weight value. Example 2. Pair of blufor units not grouped, overlapping sphere of influence leads to wide, but weak area of influence (top). Pair of blufor units grouped leads to higher collective weight and greater sphere of influence (bottom). Weight factor Like I mentioned above, weight is carried by each unit in arma. This can be best understood as the combat strength of the unit. When you combine units in a group, the group leader carries the collective weight of the entire group. As a quick example, if each soldier is "1" weight, then a group of 12 soldiers has a weight of 12. The sphere of influence in this group increases in strength, pushing the frontline further from the group center. Differentiating weight per unit would, in its simplest form, be decided based on unit type. A regular soldier has the lowest weight, machine gunner has more weight, anti-vehicle soldiers have more weight, snipers, special ops etc. The list goes on. This essentially means that a heavy weapons squad generally has higher weight than a regular squad. This same system carries on to crewed vehicles. Transport - unarmed/armored = lowest weight. Transport armed/armored = higher weight. MRAP<APC<IFV<MBT. This means that for example, a single MBT (Main battle tank) could have more weight than 2 infantry squads combined. Aircraft, as in real life, do NOT influence the front-line of a battlefield directly because they do not seize land. They are to be considered as a support role for attacking/defending at the frontlines and behind them. They play a key role in reconnaissance and battlefield awareness. Merging spheres of influence As mentioned before, a group shares the collective weight of all group members, and hence the sphere grows as weight increases, or shrinks when it decreases. However, they do not merge with other groups, unless the two groups use a "join" function in the game. If two individual groups "side frontline" touch (group A radius + group B radius = physical distance between A and B) then their frontlines merge, just as shown in the figure "example 2" with individual units. This creates a wider sphere of influence, but it may have an uneven distribution of weight, taking on a more "pear shape" appearance. This aims to help the system understand that the area between two nearby groups has more strength than the area between two distant groups. Example 3. A single tank unit has heavy weight merges with an infantry group nearby that has lower weight. Since they are separate groups, the spheres do not add together, but stretch their influence between each other. If you are paying attention to what's happening at the larger scale here, the system is becoming aware of the combat strength of allied units and groups in an area. It is also able to recognize where it is strong, and where it is not. The enemy and dynamic frontlines. Now we have seen some examples of how allied units influence the "side frontline" by means of spheres of influence that alter with weight and group size. Now it is time to apply that same system to an enemy faction and give the system something to work against! First we have to talk about two different terms: The subjective frontline and the objective frontline. The subjective frontline is a side-specific system that only uses the information that is available to its own side. In other words, it always knows the position of friendly forces, but only knows about revealed/spotted enemy forces. This system taps into the already working spotting mechanics of arma that reveals targets as unkown, eventually type, and later specific unit. At a distance, revealing an enemy squad will only give the system information about 12 men. If we use the weight parameters from before, this means the spotted enemies will have a collective weight of 12. This is then used to calculate the frontline. If the enemy either moves closer to reveal soldier type, or friendly forces have powerful optics that can reveal soldier type at long range, then the different soldier weights are also added to the system. This means that instead of having a weight of 12 (generic men), it now has the weight of 20 (heavy weapons, marksmen, grenadiers etc). Summarized, the subjective frontline only knows about spotted units and the quality of that information (how much details are revealed). When time passes, spotted contact information fades out, and the system adjusts accordingly. The objective frontline is not side-specific and knows about all units on both sides at all times with full information. This is particularly good for arcade game modes or multiplayer where "fog of war" is less relevant. This mode will immediately calculate the frontline across the map so both AI and players know where everything is happening in real time. This way, you would essentially be "safe" in friendly territory and crossing the frontline means that you are moving towards enemy forces that are generating that frontline in realtime. Mission makers decide when to use subjective frontline (realism, fog of war), or objective frontline (fast-paced action, good situational awareness) based upon their preferences. The dynamic frontline is where ArmA is taken to a whole new level of combat. Once a frontline system (subjective or objective) knows about both friendly and enemy forces. Their weights and location in relation to each other are averaged and form a frontline. This frontline could be visualized on the game map, or it could be hidden so that only the AI utilize it to make decisions. The whole objective being to improve AI combat awareness and tactics, but an added bonus of showing players the frontline dynamically (the visualization is where it is similar to the PVP mod "Dynamic Frontlines"). An example of how the system may look with all units known: Example 4. The clusters of units have a high weight that pushes the frontline towards the enemy units of lower weight. The frontline moves towards the side that has the lowest weight and is constantly shaped, dynamically. Another example showing how fog of war may look: Example 5. The enemy cluster is now unknown/hidden (not spotted). The subjective frontline system only knows about the single unit and draws the frontline based on this. Frontline does not match the actual situation. By simply looking at the two above examples you can immediately see why Recon roles are important. Recon can reveal enemy units and help develop the frontline. Observation helicopters, scouts, aircraft, UAV's now directly contribute to battlefield situational awareness. Cool huh? What can the AI use this system for? The AI would now know where the frontline is. In other words, a perpendicular line between friendly and hostile forces. It can use this simply to issue "scan direction" orders to it's troops, or form line and have the line formation aligned with the frontline. This way, AI would prepare for the threat by looking and forming up efficiently to combat the enemy. It also help the AI adapt to changes in the combat. If a new enemy force is revealed, the frontline may shift and cause the AI to shift attention to a new area. Even better would be if the AI could compare the frontline angle to the angle of suitable cover objects. It would prefer hiding behind objects in relation to the frontline system. The AI could chose to garrison buildings and prefer occupying positions that face the known frontline. They could prefer to run for cover by placing something with fire geometry between them and the frontline. Even more, it could be implemented into an AI commander system that coordinates groups of AI dynamically. Such a commander system would be able to detect areas of weakness and reinforce them, or spot enemy weaknesses and attack there, essentially flanking. In order for the AI to successfully flank, it needs to know where the frontline is, which comes from the dynamic frontline system. CAS missions, artillery strikes etc could be dynamically generated to cope with sudden influxes of enemy troops. Mission designers can set the "frontline resolution" to tailor the system to the scale of their mission. A huge war can have frontlines with segments that are 100's of meters long, or a small scale "capture the town" can have a 10m long frontline segment. The point being that having a very high resolution in a large scale operation may tax the system. Anyways. I can't code, but someone who can may comment on this and see if it is doable. If there already is a mod with dynamic frontlines, then there should be a possibility to make a system like "ALiVE" to take advantage of that frontline system to command AI troops around the map in an... "intelligent" matter :) . Feel free to give share your thoughts on this? I am rather serious about the idea and genuinely think it can work, even in arma 3, with the current engine.

@ski2060 This was one of the first ideas I came up with when sensors upgrade was first announced. A few of my hopes being: Semi-Active guidance (Vehicle/Antenna with fire-control radar guides a weapon which does not have its own sensor. Like AIM-7 "Sparrow" or the R-27 "Alamo") Early warning radars in the form of antenna, dome or aerial (Beriev A-50, E-3A AWACS) etc.. Anti-Radiation missiles, like the HARM missile or KH-58U. They will not seek physical objects so to speak, but radar emitting sources. They are perfect for SEAD operations. I think the HARM can even be pre-programmed to fly to a GPS location and search for emitters in an area. This way you don't have to designate a target, you just fire blindly and it will hunt anything that uses an active radar. Advanced Data-link guidance. A target spotted by tracking radar can relay target information through data-link. Any other vehicle, compatible with the datalink network, on the right faction, may target and fire on the datalinked target* *The hard thing about this form of datalink is that if say, a Blufor Cheetah used its radar to track an enemy chopper, then it would be shared with ALL blufor units that can receive datalink. While this is perfectly fine, I think, it is not realistic or "fair" that any allied vehicle with semi-active radar missiles can now fire on it. The datalink communications should therefore ideally use different "encryption" in order to work with certain weapons imho. It would be rather boring if a shilka could datalink for an S-500 missile system on the other side of the map and guide that thing to target. My proposed solution to this problem is to have a parameter in the electronic sensors attributes to allow data "encryption keys" to be manually entered. It would be a normal textbox window that you can enter as many codes as you want for a given vehicle, for instance: One search/track radar named "Alpha" is on the map, in addition to a circling fighter named "Bravo", and a distant sam launcher called "Sierra". There is one hostile aircraft circling the map called "Tango". Alpha can see the enemy at all times, Bravo every now and then (limited radar LOS) and Sierra can never see the hostile aircraft. In the sensor encryption field of Bravo it says "LK16", in the field of Sierra it says "SAM_RDR", and the following examples are entered in the field of Alpha - the search/track radar: "Alpha" encryption keys: ex1: *Blank field* = Vanilla datalink (all vehicles on same side share target info regardless and may fire their weapons on datalinked target). ex2: "LK16" = All vehicles share datalink target position, but only vehicles with matching encryption "LK16" may fire upon that datalink target. In this case both Bravo and Sierra can see the target on their maps, but only Bravo can acquire a lock with datalink weapons. ex3: "LK16; SAM_RDR" = All vehicles share datalink target position, and now both Bravo (LK16) and Sierra (SAM_RDR) may acquire a lock and fire on the datalinked target. In this way, you can set up a sam-battery that is 100% reliant on it's own fire-control radar. If that single radar goes down, then the entire battery is inoperable. If there is no encryption, then any other radar sensor anywhere on the map with datalink switched on will act as a sam-battery fire-control radar, which is just unrealistic and impossible to defeat from the enemy side. You can even set up multiple batteries, and give them each their own encryption, or have one fire-control radar provide guidance for multiple batteries. This could either be set up in the mission editor, made as an in-game action (set code on the fly) or a combination of both. A third possibility is to have it adjusted at modder level, in the addon config. This could lead to conflicting issues with other mods or other compatibility issues though.

But will it run over stone walls?

Thanks for the update! I like the subtle hints in the changelog.. Damaged wheels and tracks animation sources. Yummy :D