Strike_NOR

Enlightenment 🙂 First of all, GBU-10/12 Paveway II and GBU-24 Paveway III are pretty much ballistic without guidance. Only the III has an improved guidance system which may cause it to pitch up early to extend range a little bit, but I'm not sure that this happens without laser detection. I have no idea where you are getting these range numbers from, but the self-lase distance depends on which TGP you are using (Lantirn, Litening, Sniper XR or similar), weather and atmospheric conditions etc. The whole Idea of dropping GBU's are to do it way above IR missile threats from manpads and other short range air defense systems, with extreme accuracy. The Paveway II guidance kit is very coarse and its control system only makes "full deflection" corrections (aka bang-bang control). Hence it will often cause the bomb to oscillate if target is being painted while the bomb is at great distance from the laser spot. Not only that, but a lot of modern combat vehicles have laser threat detectors and will alert the crew once painted. The unnecessary oscillation will reduce bomb range significantly, and the early warning to enemy forces will allow them to pop smoke/hide/flee. Therefore, the aircraft attack system is generally set to activate the laser about 5-10 seconds prior to impact time, thus giving the enemy minimal reaction time as well as facilitating better bomb ballistics/accuracy. Drop altitudes may be well over 20.000 ft, by using a second pod-equipped wingman, the lead attacker may drop the bomb and immediately bug out, while the wingman flies a few km behind and paints the target, thus keeping both planes outside enemy air defense range. I assume ARMA is limiting at 200m AGL to either minimize chance that bomb picks up the wrong laser (vanilla arma does not use laser codes, only side-specific), or to save resources on game scanning functions. I'm not exactly sure, but realistically the bomb should be 100% ballistic until a laser appears within its visual cone, meaning it should perform 100% like normal CCIP bombs. Vanilla arma does not do CCRP either, so level bombing is at best guesswork. In my experience, vanilla arma GBU's seem to fly like small lightweight glideplanes, like an arma missile does without its rocket motor burning. It should follow a completely ballistic course when unguided, and just like in real life, may be used as a dumb bomb in a pinch.

Brits : "Keep calm and carry on, gents" Germans : "ÜBERRASHCUNGSANGREIF"

Absolutely beautiful. Can't wait to watch these get smacked by Mavericks 😉

Brøther.. this looks 'mazin. Also like the Nørwegian houses! Much norgie, very børk børk! I know modelling and texturing all that is a lot of work, but boy does it pay off as clearly shown in your videos. Makes me want to crack open a can of Joika Kaker and watch the 1980 Eurovision Song Contest again.

It's in the guidance material for implementing armored vehicles into the game. It states that fire geometry can't overlap or be too close, or the bullets may not register a hit on the second material. In other words what you are saying is : The backback counts as a hit, and the shell does not interact with the second layer (main armor) of the target, because the layers are too close to one another. I have not experimented with importing armored vehicles into ArmA my self, but it seems like a natural consequence of how the armor and penetration mechanics are modeled/coded in ArmA.

The urge to play more IFA is increasing with these updates :D Amazing audio for the Panther. It's truly beautiful! Not only the engine, but tracks and all. Sounds very authentic! Regarding the rocket sounds. Well, of course the rocket nozzle, and combustion chamber pressure both play a vital role here. Some rockets may indeed produce something closer to the "elephant" version, "nebelwerfer" or "katyusha". Then again, how on earth are we ever going to prove what the Katyusha sounds like, without firing a 40's Katyusha with modern recording equipment nearby? And how many % of the playerbase are going to be hanging around an artillery camp next to the Katyushas while they fire, so they can hit their audio satisfaction climax? :) Forgive me, but rocket fire, while very awesome, does not produce music :P It only creates tinnitus! We all have our most precious parts of the game that we love and want accurately represented, I can relate to that. But the Katyusha replacement sound (WIP) sounds very good to me as it is, and is a worthy compromise of "what it may actually have sounded like" :) This also seems to produce a "SHWOOOO" sound more than a simple "SHHHHHH", but then again, it could be the microphone picking it up weird, or the rockets being home made, dunno. I assume a lower-pressure rocket motor (poorly manufactured) will have a lower frequency sound (leading to more of a "SHWOO" sound).

@GBee2 Thanks for the reply. Where is this info "noted" ? Couldn't find anything official on it. AFAIK, most contemporary SAM sites utilize one or multiple search/track radar and/or fire control radar that relays information to the launch units (launchers). As you state, this is done in order to "hide" the launch units completely from Anti Radiation missiles, but some of the point is lost if the launchers themselves are equipped with radars that emit energy. I would figure that the missile could be configured to fire in "maddog" mode, where it is launched and immediately activates it's onboard radar to chase the juiciest target in front of it. However, based on my experience with them in ArmA, they seem to be unable to fire when the radar is either A: Missing, or B: destroyed, which corresponds to most RL systems. However, in case B, there seems to be a "grace period" where the missile can somehow launch after all. After this period, it behaves just like in case A again, just looks for the target but never fires (even if it is directly aiming at it). Also, I forgot to mention: There seems to be no proximity fuze on the new SAM missiles. At least the CSAT variant missed a Wipeout by <2 meters and didn't explode on several occasions (head on vs the missile).

If that's the case then I suppose it checks out. I've just never seen the launchers fire at anything by themselves, even when they are obviously tracking the target.

@nodunit Dunno if this has been reported, but after playing around with your SAM systems yesterday I was repeatedly able to reproduce what I assume is a bug: Place blufor Black Wasp armed with Anti-Radiation missiles in air about 3 km away from a move waypoint. Place CSAT Radar and launcher at the move waypoint (make sure radar is facing black wasp, and there is a line of sight to the black wasp). Spawn as civilian spectator or whatever nearby the sam site. What happened to me: Black wasp fires Anti Radiation missile first, but radar detects black wasp. (You can see that the launcher is preparing to fire at the black wasp). The Anti-Radiation missile hits the radar module and destroys it. After that, the launch unit starts firing at the black wasp, firing up to its entire 4 missiles, even though the radar (datalink transmitter) is dead. So knowing arma, targets have a "history" (seen when things move behind cover etc) that remains for a while after line of sight is lost. Does this mean that the datalinked target will remain "in history" for a while after the radar is destroyed? So that it is still available for lock by the launch unit? It seems like if line of sight to the black wasp is lost, then after a short while the launcher looses interest in anything and returns to being harmless. It does not resume attacking the black wasp even if it comes back into line of sight. It may be a known game limitation, but just wanted to let you know.

Sound is so immensely dynamic and extremely relative to the observer (or listener rather). I've spent my fair time on the firing range with guns and explosives to tell you that even the weather affects the result. Recreating sounds in games that play loops of audio triggered at given points with fadein's/fadeout's and transitions between RMP's, distances etc just "mimics" the real world. Sometime in the future, we may be lucky enough to witness a true sound simulation (that uses calculations and algorithms rather than sound files) and supercomputers to run it, but for now let's just appreciate the work of art the likes of Laxemann and LordJarhead manage to create with the tools that are available to them. To me personally, I can be completely put off by the soundscape of a game. If everything else looks realistic and beautiful, and plays great, a bad soundscape will just wreck the experience completely. From first hand experience I have witnessed the static test fire of an AIM-9 rocket motor, and it is just a deafening "SHHHHHHHHHHHHHHHHHHH" sound. It's like recording the noise of two pieces of paper sliding against eachother, and cranking the volume up x100. There is a little bit of rumble, but not that much, as most of the pressure was released upwards in my case. The most terrifying thing I have heard so far was probably a CV9030 (IFV) firing on the other side of a sand hill next to us (no line of sight), about 150 meters away. It was so dang loud and the shock/soundwaves went through my bone and marrow. I instantly decided I was never going to find myself anywhere near the opposite side of that cannon. Remember guys, sound kills! (Overpressure ;) ) On a completely unrelated note: I have been having a small break from the ArmA community so forgive me if this is "old news", but the Halftracks are behaving super silly (at least the M3). Probably Vehicle PhysX related due to tanks DLC update, but it was doing pirouettes like a ballerina on the battlefield :D It actually took out half an infantry squad while it was being a Half-Tracknado.

Speechless! Really got some sexy sounds on that Panzer V! Almost bringz out ze german panzerkampfwagen in mich. Sehr Wunderbar! Feels to me like you really nailed the correct volume/sound at distance too. This fits into my idea of realism at least :) Love that acceleration roar coupled with black smoke. Katyusha sounds so good even Putin would give it a 10/10 would fire again rating. Fantastic sounds, even for WiP. Can't wait to try it out for myself in the future! Cheers!

Any word on what was done to "increase predictability of HEAT penetrations" introduced with fridays devbranch update? :)

It spawns on hitting "things" right now, and does currently not use scripting, only config adjustments, which should mean better overall performance. There are some occasions where it does not work as intended, but they are easily outweighed by the times it works as intended. It also spalls on bunkers, houses, vehicles and other, making both HEAT, AP and even HE cause spalling lethal to unfortunate bystanders. Right now, only used by high caliber, long reload or "one shot" weapons which mean less performance drop. The beyond cover/armor effects are highly satisfying and more realistic, causing increased crew lethality. They also obey same penetrating laws as parent munition, so if the main shell doesn't fully penetrate, then most likely spall won't either. However, since spall generates in a cone, the occasional fragment will travel through armor at a more oblique angle, and may therefore get through. This is acceptable, and will roughly simulate "buckling" of interior walls chipping off spall fragments, like HESH is designed to do.

Right now it's experimental, but the fragments are simplified as much as possible. I also noted that there is a pretty scalar relation between damage and number of fragments. I can do 20 fragments that deal 25% damage to crew each, or make 10 fragments that do 50% damage each and get quite similar results. I can also play with fragment speed, dispersion, hit values, lifetime and airfriction to get different results. For instance, gravity is disabled to save computing ballistics. The big difference is performance. I have experimented with 20 fragments and I'm not noticing any FPS drops in 4v4 tank battles. There are'nt many situations where AT weapons are spammed, so performance impact is not an issue so far.

As far as I can tell right now, the damage simulation has received the following "core" alterations: - Exterior armor (anything specifically designed to protect from armor-penetrating threats), when penetrated, will transfer quite little damage to the vehicles "global health" aka hitHull hitpoint and crew members. - A new firegeometry or material called "vehicle_interior" now serves to detect damage that happens once the penetrator has entered the vehicle, which does significantly more damage to hitHull and crew. - All HEAT weapons now utilize a penetrator ammo type, that spawns upon impact, which can "reach inside" the vehicle - unlike before where splashdamage was the way HEAT was incorrectly simulated. - Armor Components was introduced to subtract energy from the ammunition "type" (AP/HEAT/TandemHEAT) accordingly, so certain weapons are ineffective against certain armor protection types (SLAT, ERA, HEAVY ERA). What remains a little "unpolished" is that since all vanilla AT weapons use a single penetrating projectile, only a direct hit will "directly damage" a crew member. So to kill a driver, and only the driver, you need to hit exactly where the driver is, and the shell has to physically impact him. Otherwise, crew receive damage as a factor of damage dealt to the hitHull global health. A simplified example would be if all units have health range from 0-100, an impact on vehicle that deals 80 damage to vehicle, would deal on average 60 damage to all crew members (0.75 factor). There are slight variations between each crew member, but generally the distance between impact to crew does not matter, only the damage dealt to vehicle global health. How I try to fix it: I am currently working on a modification that creates spall fragments, shards and whatnot depending on ammo type upon vehicle impact. The shards have a high ricochet chance and will bounce around inside the vehicle upon impact. These shards do little to no damage to the vehicle itself, but they are lethal to crew members. It also means, that if the upper front glacis is struck at an shallow angle, the shards can ricochet off the hull and spray over the drivers hatch and turret, causing damage to turned out crew. It allows for vehicles to be completely knocked out by a single shot, although unlikely, by killing all crew members before tank health is dead. Because you have to hit EXACTLY where the crew are with vanilla config, you are more likely to destroy the vehicle before you can take out the crew. With my WIP mod, I am able to consistently kill crew by aiming for weak spots where I know the crew are, preferably in line with each other. I am also looking into creating spall for HE ammo, and have some success, but I have met a wall when it comes to submunition parameters. I have made a help request in the config editing and scripting section, if anyone wants to help me out :)

Best of luck to you @PiZZADOX! I hope you figure out a way of beating arma animations into prone-position submission :p

Hello community! I am currently doing a lot of config work revolving around submunition parameters. I am getting pretty much all the results I expect, and I am very happy with how its implemented, but there's one thing that I can't find out how to get right. I am trying to create a specific submunition pattern, but have met the wall. What I am looking for is that the submunitions spawn omnidirectionally (in a perfect sphere) with random chance of direction. Basically, if the parent ammo strikes something, the submunitions will spawn from that hitlocation, and can basically go in any theoretical direction afterwards. What I am experiencing, is that no matter what settings I tweak, I am getting a 45 degree cone (off the parent vector) (meaning a total of 90 degree spread). I can't get the submunitions to face a direction greater than 45 degrees. Here is the relevant config code: submunitionAmmo="fragment_medium"; submunitionDirectionType="SubmunitionModelDirection"; submunitionParentSpeedCoef=0; submunitionInitSpeed=1000; submunitionInitialOffset[]={0,0,0}; submunitionConeType[]={"random", 20}; submunitionConeAngle=90; submunitionConeAngleHorizontal=90; Swapping submunitionDirectionType from "SubmunitionModelDirection" to "SubmunitionAutoLeveling" has no effect on the spread angle, it just effects the initial direction (retain parent or align to horizon). Changing submunitionConeType from "random", to "randomcenter" or "poissondisc" etc has little effect on what I'm trying to achieve. Altering submunitionConeAngle and submunitionConeAngleHorizontal within values of 45 degrees has an effect (I can tweak how narrow the spread is within +-45 degrees off center - for a total of 90 degree spread. However, changing this to between 45-359 (Degrees) has no effect. Setting it to 360 causes the "cone" to collapse into "0" spread (all submunitions retain parent vector perfectly). So can anyone please help me? The https://community.bistudio.com/wiki/Arma_3_Weapon_Config_Guidelines#Ammo_changes_on_fly_and_on_hit guidelines do not describe accurately what the various patterns mean, or how the custom one acts. Any help would be greatly appreciated, Thanks Str|ke

Will see if I can look at it later. The question is: Does the ERA hitpoint fail to register, so that the ERA does not destruct when being hit? or Does the ERA component, fail to register - and give no benefit against the HEAT round? OR^2 Is both of the above true? Maybe I can figure out exactly what's wrong :P

Thanks for the feedback. I agree. This is only a few hours of work. Trust me, if there are ammo cookoffs on YT, I've seen them. I want to end up with a dynamic, emergent effect based on ammo contents, vehicle type and some random weighted chance of each variation. But nonetheless, thanks for the two cents :) It's going to take a while as I'm learning by doing. Will report back once I've tuned the values further :)

I know you did not ask me, but I don't care :p According to Raytheon and other unofficial sources, the Javelin (FireFist) is an IIR seeking weapon (imaging infra red), meaning it locks onto infra red heat and can distinguish shapes/geometry. This is why it can be employed against vehicles, slow moving helicopters, structures and infantry, because the algorithms try to trace the shape of the object it is locked to during flight. Either way, this means it does not target laser spots from target designators. HOWEVER!!!! This is a game, and while approximate to reality, there are liberties to consider. There are a few things that come to mind: Technology of 2035 could allow this kind of behavior. The recon and AT Nyx would better compliment each other if the AT variant could hide behind cover, while the Recon does the scouting/designating for it. These points argue towards having the FireFist laser-homing capable. It is, after all, a bigger-better variant of the Titan AT, and the Nyx already is kind of an underdog tank. I think it's worth considering at least :)

Thanks for the feedback. It's definitely going to undergo some improvements and alterations. As for the turret ring, well that depends on vehicle design. Generally speaking, these tend to be well armored, and air/water sealed with large packings. However, as pressures and temperatures increase, things may get out of hand and leaks of flame will occur. I agree the current effect is probably overdone somewhat, but I disagree that it can't escape through the ring. As for roof hatches, the same applies. They are sealed and locked in place. Generally they won't just "pop off" 10 out of 10 times, but depending on tank design they may break during pressure buildup and vent through. As soon as a hatch gives away though, the pressure inside drops and the chance of subsequent explosion or hatch failures decrease. As for barrel burn, this is the most random phenomenon if you ask me. The barrel is normally sealed by the breech, and normally withstands extreme pressures from normal operation when firing shells. There is no reason for this to smoke, unless the breach is open or unlocked when the ammo inside the compartment cooks off. The popular video from youtube with (RPG-29 vs T-72) shows something interesting. At the same moment that the tank is hit, the gun fires a shot (either the heat charge hits and penetrates the breech, setting it off, or the gunner was startled and pulled the trigger). If the autoloader then proceeded to open the breech and eject the shell casing during cookoff, then this would explain why smoke came out the barrel. However, this must be considered a very rare condition. As far as I know, the most common way for a fully loaded MBT to "die" from ammo cookoff (if all hatches are sealed) is instantaneous detonation, where large parts of the tank is ripped open (or turret displaced). If there are open/unlocked hatches, then pressures won't reach as high and the tank will mostly burn out structurally intact (like the Syria video, where the gunner appears to open the hatch just in time to get out or, literally, get blown out). Some tanks feature separate stowage compartments with blowout panels to prevent failure though. Either way, this is just my first draft. I am going back to the drawing board to tweak the effects and add variations. I also plan to link it to the pressure intensity, to cause variations in fire intensity/size.

Just thought I'd follow up on the Ammo Cookoff thing. Warning: I have practically 0 experience with ArmA 3 scripting, and the following footage is not part of the ACE mod. It is my personal script made from scratch™, which only: Tests if the vehicle is a tank Creates a particle effect on vehicle position (with offset to match Slammer appearance) Plays a sound Sets vehicle fuel to 0 After 5 seconds sets damage to 1 I have borrowed the "cookoff_high_pressure.ogg" file from ACE mod (I believe HybridV is the author - he has been credited in the YT video description). It is simply a placeholder for now, and I am not publishing this anytime soon - not without the original authors approval. Let me know if that's allright or not. Now that's out of the way: Here's a first draft (only fire effect - smoke and sparks to be added later). !!!WARNING: SUDDEN LOUD AUDIO!!! - TURN VOLUME SLIDER DOWN!!! Let me know what you think! I will improve on this further, and may ultimately try to incorporate it into the standard ACE 3 cookoff addon. This way, we will see different kinds and variations of brewups (from turret ring, hatches, etc). Maybe also intensity.

I guess seat switching mechanic in arma, would be in it's utmost simplest form, a time delay between pressing the action "switch to x's seat", and actually moving there, coupled with a fade to black/fade in effect that matches this time delay. You could even add some sound to it of "cramped tankmen fidgeting around" to emphasize the fact that they are switching seats. A more advanced and complete function would be the restriction of certain switches, such as hull to turret (where these are physically separated) , or for heli's, gunner to pilot etc. Then you would have "everything" needed for gameplay reasons. Animations would be extremely resource demanding and all the "what if's" are virtually impossible to get. It's simply a time drain to do the animations, that give very little in return.

To do its job as a Recon element and provide target designation for other vehicles.

@ski2060 what artillery piece did you face and which ammo type did you use?