Evil_Echo

Randy's passing was a severe blow. He was a team-mate for a software project of mine and a very fine model tuner. And over the years, he became a good friend as well. I could not let his passing go without saying a few words. But at this time all I can think of is, "I will miss you."

Recall the Marine motto - "Every marine is first and foremost a rifleman." Which also applies to airborne units once they hit dirt - they effectively become leg-infantry. Given the lack of battle fronts in today's wars, all units are front-line. As I pointed out earlier, there is an increasing chance these days of US forces finding opposing female units on the battlefield. From an emotional point of view putting a woman in the crosshairs is far worse than having a female compatriot hit/killed by incoming fire. We've already settled that female combat units exist, and at least some females are as capable as men of doing the job of elite forces. So what's left aside from that emotional element?

Time to blow a hole in the argument about women serving in combat roles. Perhaps not in the US, but since when was ArmA just about the US? A video about the 707th White Tigers, South Korean Special Forces, training. Watch carefully and you may note that one platoon is not male. You had better know the folks in that unit well and use a respectful tone before using the nickname "Killer Barbie Dolls" in front of one of them. And another with more emphasis on that platoon...

If you go toe-to-toe using conventional weapons and tactics, absolutely true. But the record using asymmetric warfare techniques is another thing altogether. The how's and why's of WMD deployal can be left to the mission designer though. All it takes is time to research a good enough storyline. To the weapons themselves then... What has to be kept in mind is what fits the scale of the sim and to some degree what is feasible within the system. Biological weapons are relatively slow acting. Excluding fantasy bugs like the one in Andromeda Strain the minimum time between exposure and onset of symptoms is at least several hours ( pneumonic plague ). While cheap to make, bio weapons are also very difficult to control precisely. So unless you are dealing with a madman wishing to infect the entire island, biologicals are off the list. Chemical weapons are cheap, fast, and do not spread outside the zone of contact. To appear realistic, you would need changes to people models and/or animations. Blister agents cause horrific burns, which might be concidered gore by some. Incendiaries as well - along with the need for fire to propogate to nearby locations. Nerve agents are "clean" in terms of models, but do require special death animations - violent spasms. Anyone who has seen bug spray vs ants has seen this, not suprisingly most nerve agents are molecularly similar to insecticides. Otherwise a good candidate. Nukes are the most controversial of course. They do damage to material and personel, leave persistent hazards in the form of radiation, and are quite spectacular. However, ArmA is not suitable for large nukes ( aka city-killers ). For one thing the immediate effects (blast, heat, radiation) would cover too much map for the scale ArmA supports. Additionally 100% fallout contamination would be a certainty. Another strike against city-killers is graphics. The ArmA2 engine bogs down with large cloud generation, if you increase the size beyond a certain point the GPU pipelines fill up and the effect degrades. Coded wrong and the end-user will experience severe lag, frame-frames approaching a slide show. Tactical nukes are a better fit to the sim. The smaller weapons damage radius is more to scale for ArmA map sizes. The graphics issues are more managable - with A3's new engine physics and particle effects would be expected to run better still. They also are a good fit with current geopolitics. Superpowers like the US have moved to smaller warheads as weapon delivery precision has increased. And a rogue state's first attempts at such weapons are likely to be low-yield as well. Assuming the weapons actually are used, NBC conditions apply. This would entails special game rules and equipment like MOPP suits and pressurized vehicles. Using non-rated gear would entail risk of exposure to whatever hazards are present. However, being suited up for long times strains one's endurance and limits vision and communication. Civilians would likely be unprotected with extreme casualty rates. Once alerted, professional forces would suit up, resulting in few injuries. Anyway - points to ponder during this discussion. Personally - I'd look at chemicals or tactical nukes, depending on what talent was available on the team.

All damage effects derive from impact velocity and projectile geometry. Arguments vary on whether momentum or kinectic energy matters more - but both include a velocity component. The impact velocity is directly tied to muzzle velocity. External ballistics revolve around a round's orientation and velocity. The slow-down is notable, as I mentioned earlier all supersonic rounds eventually drop to sub-sonic speeds - causing disruptions to stablilty as that threshold is crossed. You may model this to whatever level of detail desired. But unless the model is based on the correct fundamentals, no chance of realistic results can be expected.

Indeed, there are some other good threads discussing ballistics and wounding - some reaching back into ArmA2. One thing that deserves clarification is what is meant by realistic. One definition implies getting exactly the same results for a given RL situation. Another is where any deviations are statistically insignificant, which allows for greatly relaxing the amount of number grinding required. Let's stick to the statistical variant to preserve game performance and sanity ( those ultra-realistic formula can get really messy ). A .338 Lapau Magnum round is going to behave pretty much the same way inside any weapon designed to use it. So it would be easier to simply state the cartridge type along with barrel length and an optional fudge factor to correct for manufacturer differences to get the muzzle velocity instead of specifying a long list of obscure parameters that increase the risk of error creepage. The notion is to maximize precalculation in order to increase both performance and statistical realism. External ballistics is fairly unforgiving, since you do need to get the correct value for hit/no-hit. Fortunately it requires a relatively small number of parameters and would be imbedded in the core simulation so all weapons are treated the same way. Terminal ballistics - this is where individual opinion diverges. If you treat any armor as a homogeneous material ( not true IRL, but often close enough ) it is possible to compile a table of penetration velocities. One can take the residual velocity along with optional spall or scabbed armor and move on to the wounding calculations. At first view, it seems that statistical methods are the simplest. I would keep the use of random numbers to bare minimum though. It's not to disagree with the posting by maturin, but merely due to the fact that a good random number generator is fairly expensive in terms of cpu cycles, nor are sections of code using random numbers typically easy to make multi-threaded for use on large-core processors. So I recommend avoiding use of random numbers where possible. This brings up an important point - the simulation is worthless unless it can run the problem in a reasonable amount of time. Many games do not use any ballistics at all for shrapnel, instead using a technique called ray-casting to handle the cloud of projectiles flying around. This works because the relatively short range and sufficently high velocitiy of the fragments means that the assumption of straight-line movement used by ray-casting is close enough. I've spent considerable time enhancing projectile ballistics as part a project not involving BI. Good ballistics do make for noticably better simulation, but must be coded carefully at the core level for maximum performance. The mod maker is left to focus on the terminal effects, being sure to ensure consistant results using well-researched data. Hopefully, ArmA3 is following a similar path. If so it will be magnificent simulation.

One thing to understand - in ballistics, there is no one true formula. There are well-accepted formulas that model various aspects of projectiles as well as popular simplifications. The most controversial section is terminal ballistics - where a projectile interacts with another object. Muzzle velocity is the topic of interior ballistics. Stock Arma only allows for muzzle-velocity to vary by weapon - meaning that it's very limited in the situations where muzzle velocity will match reality. At least one mod mod does try to adjust for ammunition type by use of tables and extended configuration files - but that system is difficult to maintain due to difficulties in collecting accurate data. As a result, errors are bound to slip in now and then. If the tables were the results of actual calculations the performance would be about the same, but the developers would need good data about powder composition and geometry, primer type and geometry, barrel wear, and data on any suppressors/muzzle brakes or the geometry of the barrel crown otherwise. Exterior ballistics needs to account for subsonic, trans-sonic, and super-sonic speeds were applicable. Pistol rounds are typically slow enough that one only needs to deal with subsonic values. Everything else should be handling all 3 domains since the transition through mach-1 causes a significant change in flight behavior. The range at where a round drops to subsonic speeds occurs is generally accepted at the limit for accurate fire by markman. For indirect fire, one of the 6 degree-of-freedom models is a must since those rounds encounter environments that require extra calculations if the point of impact is be determined with any accuracy. The round impacting with it's target involves terminal ballistics, which is vastly more complex than what has required up to this point. Materials like steel, aluminum and concrete use radically different models to characterise how each is damaged or penetrated. For wound results - the research by Fackler is commonly cited, but it's not universally accepted. The gist of all this is that ArmA is using very simple assumptions on weapons behavior. It or mods could do much to improve on the stock program. But at some point you will have to draw a line on detail if you wish the simulation to not bog down during a large firefight.

While there are no promises, since ACE tends to change things without warning - the nukes should work with that mod as of last time I checked. The version of these weapons in the Mando system is greatly superior to what used to be in ACE, sans integrated NBC support in vehicle configs - but ACE never got very far in supporting that anyway ( I wrote the nuke package for ACE before leaving that team ). I believe Mando does support a nuclear AGM as well, the ECHO nuke warheads are certainly usable outside of the Scud. Mando even has a video showing a variant of a TLAM-N in operation ( cruise missile vs Russian aircraft carrier ). I made a version of a MIRV'ed MRBM that deployed 3 warheads in either ground or airburst mode for a mission a while back - scripting up such items was not at all difficult.

Loki left, I left, a bunch of people left. Tired of the bickering, the egos, the attitudes, and how the forums had devolved. Loki is happily tending his crops as a gentleman farmer. He considers ArmA a closed chapter. You all should concider this thread closed as well.

I always speak for myself, in this case having run a dedi server for our clan as well as being some who ran a lot of uptime-critical infrastructure in the real world. So stop your "Oh please" put-downs. ACE was mentioned as an example of a product with high update rates, nothing more. The issue is not ACE, it's the general situation of frequent mod updates. Too much, too fast, too often poorly tested. After enough annoyance - admins just give up and drop use of a mod that excedes their threshold. SU encourages such behavior by devs. From a server admin viewpoint, frequent updates are disruptive and any product that interrupts service too often will get the boot. That's my point - end of story.

My point is not ACE, it's mod updates themselves. Too much, too fast, too often poorly tested.

SU is not the solution, but part of the problem. Frequent updates may be great for developers, but it's hell for server admins. The constant restarts kill off player participation on a server. SU, by making frequent updates easier, actually makes the admin's situation worse - because the devs can increase the rate of update and do not coordinate their release schedules. The result is utter chaos. ACE is not widely hated due to it's content. But the rate of change drives server admin's crazy - they cannot keep up. So they chose not to use it.

Look around and count the number of devs that have gone dark in the last few months. It's not just Xeno, a bunch of notables have stopped work. A bunch of people seem to think that posting crap on BIF and Skype channels is harmless fun. They've turned the community forums into a stinking sewer. A good dev can always find something else to do. So we go to better places to continue our work. :butbut:

Whatever.... Please introduce yourself. National Honors Society commended student' date=' ranked in top 0.1% in science. Degrees in Computer Science and Physics. Served in US Army - 98G. 24+ years as a programmer/systems administor/security officer at a DoE weapons laboratory in support of the Defense Nuclear Technologies program. Enjoy a good day of benchrest shooting followed by lots of sushi. [/indent'] Why make mods? Writing good code is almost an art form. ArmA was a fairly decent platform for combat simulation. Extending it's capabilities into new areas was an interesting technical challenge. What is your motivation? Frankly, I could do better than what was already out there. With a few notable exceptions, a lot of mods for ArmA were inaccurate, poorly coded, and lacked acceptable levels of technical support. What does it give to you? Knowing that some people appreciated quality work was all the satisfaction ever needed. Who would you name as your personal idol and why? Idols - none. Owe a debt of gratitude to many mentors along the years who taught me all I know now. I pay that debt forward by helping others learn. If you could change something in the community, what would it be and why? Have commented on the problems in the ArmA community for quite some time. It'd be better to just search and re-read those thoughts vs re-ignite the fights of the past. Eventually found the situation beyond repair and moved on to better projects.

Nuclear weapons were among the features removed from ACE some time ago at my request as author of that software. Do not ask for this feature to be restored. Any documentation on ACE nuclear weapons should have been removed from the ACE wagn as well. If you wish to simulate a detonation in your mission you will need to use non-ACE code for that. There are a number of other bundles that offer nuclear weapons, include my collaborative effort with Mando Missiles, that may provide a satisfactory replacement in functionality.

I'm a pure metric guy - did not confuse units. BIS uses a very opaque system for explosives - look at the configuration numbers for a satchel charge vs the GBU. This leads to effects that are don't always match reality - one reason I use my own damage physics for my warheads. As a result - tried to couch my answer on a conventional HE warhead for the scud to best match BIS weapons, not the real thing.

Appreciate that. Did a lot of research trying to make the weapon work as realistically as possible within the constraints of ArmA2. The Scud is basically a souped-up clone of the old German V2 and does not have a large payload capacity - none more than 1,000 kg. The D version is the most accurate and can carry a payload of 985 kg. But even that weight is not purely HE. It needs sensors, fuzing, and a casing for the explosives. So I'd expect the blast to be no larger than a Mk83 bomb and no smaller than the Mk82.

A number of people have commented favorably about my little script to augment using BI's artillery. Some is good, more is better. So.... For those interested in scripting artillery - a toolkit to help out. http://www.armaholic.com/page.php?id=11757 Included are support routines to help in finding, evaluating, targeting, and of course shooting at units and groups of units with indirect fire. Plus some other goodies to help in scripting fire missions. Like a FSM to automate the entire process - just specify the spotter units, batteries to manage, and some stuff like time between missions. Using it in a mission seriously upgrades the threat of support weapons. As in real life - camping in plain site of a FO is not a healthy lifestyle choice, especially if you have a lot of friends nearby. Likewise, being a FO is not going to make you highly beloved by the opposition, stay inconspicous because you are the key to whether shells rain down in the area. Thanks to all who've helped test the code and documentation. Enjoy. Changelist: 15 Aug 2010 - Initial Release. Documentation in pdf format. Demo mission in pbo format, ready to install in MPmissions folder. Signed addons. 13 Sept 2010 - "Beta 2". Minor adjustments to demo mission. Improved documentation, more info on setup and getting started. Scripted version of routines and FSM included for those that dislike using addons. Unpacked version of demo mission included to show use of scripted routines. 30 Sept 2010 - 1.1 The previous version's code and documentation used coordinates above terrain level ( getPosATL ) vs above sea level ( getPosASL ). The effect was negligible due to consistancy of how it was used, but still deserved correction. Dependencies on the CBA mod have been removed. ECHO now requires no addons in either .pbo or script form. A number of new functions to manage observer and battery behavior have been added. These allow for greater control of overall behavior. Taking advantage of these new features, the fire director FSM now has a first-generation predictive fire capability, where it can optionally aim fire at where it believes a moving target group will be, taking time of flight and group speed into account. Improvements to the cluster quality algorithm, which should enhance the target selection processs. Various minor code changes as well as corrections in the documentation. 25 Oct 2010 - 2.0 Inter-Process Communications. A new subsystem for enhanced methods of exchanging data between routines. Routines to create IPCs and communication channel under them. Routines to transmit data locally and across hosts. Routines to recieve data and check for new data. [*]Fire Director. Cleaner layout of directories and files. Users will need to make minor adjustments to #include directives to reflect new paths. New functions that give the mission maker the ability to register routines that will be invoked for events like shot fired, splash, etc. Addition of a number of support functions that use the new IPC system, allowing them to be spawned vs called. This greatly increases performance. Offer a 2nd Finite State Machine. Code in that version eliminates a couple of situations that could cause a stall, making some to believe their batteries had run out of ammunition. This FSM also uses the new IPC system. Various improvements to further tune the targeting selection system. Updated demo missions. Updated documentation. Now over 50 pages long. 26 Jan 2011 - 2.1 Ability to terminate ECHO FSMs. Ability to create artillery batteries dynamically. Minor bug fixes. Updated documentation.

East certainly does work, my QA tests include batteries from both sides. You can designate any type of unit as an observer. I tend to prefer sniper/scouts for that role, but you are free to choose whatever suits the mission. Even a UAV should work. Two things that could prevent targeting. The batteries were too close/far/out-of-arc for that target. The other is if their were friendly units too close to the danger-zone ( danger-close ). The debug log would indicate those situations, raise the debug level if needed temporarily to see what the FSM was thinking about.

A couple thoughts on the problem. I see you setting up artillery modules by hand and not initialising them. You should do that for at least one instance to ensure the ballistic tables are loaded. Which is likely why your WP fire mission is barking. Not sure why you are doing that at all since you are using dynamic batteries and ECHO will set up the modules for you inside of that routine. The error regarding _Location seems to point to bad data. The syntax of both the function and calls inside the FSM are correct ( not an argument mis-match ) so only way _Location could be undefined is there had to be bad data fed to ECHO_fnc_SetBatteryExclusionList. I note that while you did get the return value for the calls to that function you did not check results for true/false. I suspect that it rejected the entry for "west_hq", but cannot prove that from the reports you provided. Note well - location in this context is a ArmA location value - normally predefined on the map or created via the createLocation command. It cannot be a mere marker, vehicle or unit.

Whether you think it sucks appears to be a matter of opinion. All I know is that I can make it work for me via a couple of scripts and some enlightened thought. The package is really just some nice wrappers and support functions to augment the AI. The ECHO package is usable as both an addon and in script form for ease of use. In either form, some minor adjustments to the mission would be needed to use it - but the instructions for that are documented and there are plenty of people to help out if questions arise. Because of this dual nature, you can use ECHO for just the missions you wish to and not have any problems with servers. In fact, ECHO works fine as a server-only system - no need for clients to even know it's there.

Encrtia: Just to be sure you understand, my package has no dependancies. It uses the vanilla Artillery system and nothing more. It works fine with OA - there is no problem with the BIS Arty Module's ability to aim and fire where directed. However - the system has not worked well with ACE's varient of artillery. Other systems have had trouble with that aspect as well, so I do not recommend ACE for this use.

Thank you snoops_213, appreciate the kind words. Don't let the nay-sayers fool you Encrtia, there are a couple of ways to make AI-driven arty useful. My ECHO package is a very flexible toolkit, not that hard to use, but you do have to read up a bit. Das Attorney is using my stuff for something you might find handy - his All Round Defence ( ARD ) package. Both his package and mine have threads devoted to them on this forum if you wish to learn more.

Or, in the case of a non-animated model, you can alter the dir and up vectors via a loop. As in this video.

Users of the RE command should read the BI wiki article on the Multiplayer framework. While somewhat confusing, it does cover some important elements needed to understand the MP system. One thing it omits is that you need to have the functions module included in your mission and do the standard waitUntil for that to ensure the module is fully initialized. waitUntil{BIS_MPF_InitDone}; In regards to using this system, it is basically a one-for-one substitution of the calls to kbtell and kbaddtopic. The overall structure of the BI conversation system remains, you still have the .bikb files and other parts. In fact, you can develop your mission using the regular commands and then substitute the MP versions one at a time as you debug your mission. All RE commands have similar leading arguments, then the name of the remote command to run and any parameters to pass to that command. The leading arguments are caller - a source unit or nil. Used to chose machine to run command on. In my usage of kbtell this is always nil. target - a target unit or nil. Used to chose machine to run command on. In my usage of kbtell, I want the target to be where my speaking unit is located on. While this may sound backwards, it is the correct way to invoke rKBTELL. options - a string to control how the remote command is run. "loc" - run where the combination of caller and target is local "per" - request persistance. Run this command for any new player that joins the mission after this call is made. "loc + per" - do both The default option is "loc", so if you wish you may skip the options altogether if using that setting. Which is how I run my remote kbtells. Following the rKBTELL parameter is the person my speaking unit is addressing, the topic and identifying tag. So, aside from some minor re-ordering of parameters it's quite similar to an ordinary kbtell command.