ECHO fire director

[Evil_Echo 11]

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.
  

Edited January 27, 2011 by Evil_Echo
Changelist updated.

[DaveP 66]

Ever since the early days of Neural Nets and Chain of Command's Unified Artillery, as soon as I hear a confusing AI related term my mind points towards fire support

Sounds rather neat, will check it out

[manzilla 1]

Thank you for the continued work! I look forward to using this.

[Evil_Echo 11]

Ever since the early days of Neural Nets and Chain of Command's Unified Artillery, as soon as I hear a confusing AI related term my mind points towards fire support

Sorry, no neural nets here. :butbut:

fnc_ClusterID uses a variant of the DBSCAN algorithm used in data-mining research to find groups of units near each other. That bad boy took the most work to code, SQF is a bit awkward when it comes to multidimensional structure access/modification.

The fire director's finite state machine use some heuristics and a type of priority queue to grade the potential fire missions. Then the director selects the "best" mission for each battery.

All things being equal - the order of target types is static weapons, heavy armor, light armor, infantry. But the system makes adjustments for how well the target is known, optimal distance, friendlies nearby, etc so what gets hit first is quite fluid. Tuning those heuristics is definitely art, no doubt they will be enhanced over time. Even now they seem to do a good job of messing up the other side's forces in quick order.

Anyone interested in FSM could certainly use the low-level routines to roll their own as well. Customize as you see fit, I'd be happy to see other's developing their own ideas with this toolkit.

[Evil_Echo 11]

Had a request for script versions in addition to pbo's. Will do that next release.

[miles teg 1]

Wow....so basically this script allows the AI to use the BI arty??? If so that's a BIG deal and I'm definitely going to try out these scripts to see if I can figure them out. I just hope that the docs with it are not as confusing as they were for the old UA system back in OFP. His docs were written for computer software engineers rather then average users and thus was not very user-friendly for average mission makers.

I can't to actually see the MLRS and BM-21 doing their thing.

EDIT- Just unPBO'ed it and immediately noticed that the mission was in .pbo format. I recommend that you add an unPBO'ed version of the mission as well. Just one less step for mission makers who need it as a template mission.

I also just read the readme....ouch. Sadly yeah its like UA. Written for scripters. I suppose thats fair as the top mission makers know how to write scripts and thus can appreciate your brilliant coding.

However I'm afraid that for the average Joe like myself who can't script himself around his own ass and who has difficulty with high school level algebra, it's very difficult to understand (I don't remember what an array is for example). I'll still mess around with it though...maybe I'll get lucky and figure out how to use it.

Chris G.

aka-Miles Teg<GD>

Edited September 7, 2010 by Miles Teg

[mr_centipede 31]

private ["_us_spotters", "_us_batteries"];

if ( isServer ) then {

// Start Fire Director.
_us_batteries = [AVENGER,RIPPER];
_us_spotters = [OB1,OB2,OB3,OB4,OB5];

waituntil { not isnil "bis_fnc_init"};
waitUntil { not isNil "BIS_ARTY_LOADED"};

FD_US = [_us_spotters, _us_batteries, 60, 20, 1] execFSM "x\echo\addons\fire_direction\FireDirector.fsm";
};

I just copied that piece of code from the demo mission, put in my test mission, and put the spotters name as above, and voila... Though I dont know about the 60 20 1 part.

oh yeah... the readme is also a little too cryptic

[kuIoodporny 45]

EE, if I get into reinventing Warfare again, You'll be the one I will ask for artillery support :)

[Evil_Echo 11]

:butbut: Would never concider myself or coding as brilliant, just trying to provide decent products for fellow mission makers.

Miles Teg & Mr. Centipede:

The comments about the documentation are well-noted. My first aim was to get the details out there - think that was accomplished. Will try to add more how-to for you folks.

I could unpbo the mission as well. Good idea.

To answer a couple of the questions.

• An array is a list of data. In sqf that's stuff between square brackets, like the parameters to a call.
  
• ... 60, 20, 1] - wait 60 secs +/- 20 secs between scans and possible fire missions. Debug level is 1, just a little chatter in the logs and a marker on the maps to hint what is being shot at. Use debug level 0 for no marker or chatter.
  

zGuba:

Glad to hear from you. And quite the compliment - thank you. You're always welcome to use this for zWarfare and other missions. The new scud warheads that I and Mando have been working on could be useful in the right mission as well.

[kremator 1065]

Evil Echo ... Looking forward to the script version mate. Good job!

[jeza 5416]

Many thanks for the work matey, looks like a fantastic bit of work as well.

Regards Jeza

[Evil_Echo 11]

I'll add a better how-to in the document. Mr. Centipede basically has a good start. Some more detail in the meantime.

1. Create groups of AI-manned artillery. They all have to be the same type in a given group, say Russian mortars.
   
2. Add an artillery module for each of those groups and synch it to the leader of that given group. Also give each module a unique name to make it easy to reference by script. I use A_Battery, B_Battery, etc.
   
3. Create some spotter units, give them uniqe names. They don't have to be infantry.
   
4. Then someplace, like the init.sqf script, include the lines Mr. Centipede mentioned. The parameters to that execFSM being...
   
   1. 
      
   2. The list of spotter units.
      
   3. The list of artillery batteries.
      
   4. How long to wait between checks for fire missions, in seconds.
      
   5. How much jitter between checks.
      
   6. A debug level - should be 0 or at most 1.
      

[*]Fire up your mission and watch the fun.

If you want to do a special fire mission, I had a couple examples in the demo using the support functions directly. This used a heavy artillery battery further away, Z_Battery.

Firing 12 rounds of WP on the position of "StaryEast", 25 mils of dispersion.

_ok = [Z_Battery, getPosATL StaryEast, "WP", 12, 25.0] call ECHO_fnc_doFireMission;
waitUntil {Z_Battery getVariable "ARTY_COMPLETE"};

Firing 9 illumination rounds at same position, 20 mils dispersion.

_ok = [Z_Battery, getPosATL StaryEast, "ILLUM", 9, 20.0] call ECHO_fnc_doFireMission;
waitUntil {Z_Battery getVariable "ARTY_COMPLETE"};

Missions like Domination just spawn the shells over the area. Besides not looking very realistic, you don't have any easy way for players to suppress the AI support. With my method, you could either find/eliminate the spotters to nullify fire missions in an area or knock out the guns. Both make interesting side-tasks for your players. A human player could even serve as a spotter, you automatically call in your observations just like the AI does. But the director make the decisions of what actually gets fired on - so a spotter is not god-like in power.

At some point I may add an interface for specific fire mission requests, still subject to fire-direction control.

[_William 0]

Evil_Echo: super job. You write some nice and clean code.

Question:

Have you considered writing a full blown fire support coordinator which directs artillery and close air support based on AI observations and player radio calls while managing battle space so fast moving fixed wing, slower rotary wing / spectres and artillery don't bite each other? You've sure got the skills to do so!

Suggestion:

The Arma2 artillery module can automatically communicate fire mission progress for you if you pass a fourth parameter to BIS_ARTY_F_ExecuteTemplateMission. For example:

// fire mission; pass on messages to communicate, with are invoked on a set of parameters with _batteryScope being the second.
_mission = _mission + [[{((_this select 1) call BIS_ARTY_F_BatteryLead) sideChat (format ["shot, over."]);}, 
						{((_this select 1) call BIS_ARTY_F_BatteryLead) sideChat (format ["splash, over."]);},
						{((_this select 1) call BIS_ARTY_F_BatteryLead) sideChat "rounds complete, over.";},
						{((_this select 1) call BIS_ARTY_F_BatteryLead) sideChat "cannot execute fire mission, over.";},
						{((_this select 1) call BIS_ARTY_F_BatteryLead) sideChat "check your fire, over.";}
					  ]];

[_batteryScope, _target, _mission] call BIS_ARTY_F_ExecuteTemplateMission;

Also, IIRC, the MLRS accepts LASER ammo.

[Evil_Echo 11]

Thank you _William, glad you like the code.

I have thought about CAS, wanted to see how well artillery worked first. But to be honest - I'd probably add S2 ( intelligence assets ) next. After all, once you have observers, the AI should deploy them in a useful fashion as needed. Once you have S2 management, then some hierarchical method for battlespace oversight could be possible.

I guess this leads to answering a big question -- What's the big plan for @ECHO?

It helps to know a bit about my mindset. First of all, I like to design missions for my clan - challenging training to keep them sharp. I write documents, perhaps overly detailed documents, that try to be thorough enough so that other coders have a decent chance of understanding my software. Not in it for any glory or adoring fan base. I don't impose rules on a fellow mission maker about how to run their game. Also, please don't splash my name all over some startup screen - just a nod in your readme is good enough.

So everything here is intended as a tool box. You pick what you like, ignore what you don't. I won't have a temper tantrum if you take just a couple core functions and make your own FSM or swap out one of my functions for something you think is better.

A good toolbox is consistant. In this case all the individual parts should work well together and well with outside code that follows whatever spec I've documented. The tools should be high quality. Routines are heavily tested by me before release - you folks are my patrons, not beta testers. It may take a bit longer that way, but you should be happier.

That's the plan - so far.

To other questions....

The support routines support laser rounds. I use a slower rate of fire for those so a player can switch designation points between rounds. If you are thinking about having a spotter lase a target and having the fire director order a laser fire mission - I did plan along those lines, but not it's not there yet. That might be part of the S2 system.

Was also aware about the special parameter and dialog, but was unsure how desired that was - given the fire director is primarily for AI. But if there is sufficient interest I could look at some options for that.

[gnarly_rider 0]

Very nice work Echo, I've been looking for enemy AI arty fire for awhile, with 'defeatable' spotters and artillery units.

Will give this one a good go.

[CarlGustaffa 4]

Missions like Domination just spawn the shells over the area. Besides not looking very realistic, you don't have any easy way for players to suppress the AI support.

Not entirely true. Iirc the enemy needs their radio tower to call for external AI artillery support (maybe I added that myself, not sure), you can eliminate their spotters, and a side mission renders their future artillery inoperative by taking out their firebase.

Problem with the spotter idea is that while we can ask our artillery operators to target a specific area, the AI has to rely on spotters knowsabout alone. I let every AI act as "spotter", but the spotters are the ones that actually calls it in - just like for us. And I've taken steps to make them less obvious to spot as well. To increase survivability, they will often fire a spotting round - start running :) The AI will then guesstimate where you are trying to run to, and call for fire on the location they think you will be at after flight time. It's still a bit "too magic" (even compared to the original targeting code), but with the spotting and missing, it keeps the pressure up at the same time not being a guaranteed kill. Much more fun this way I think.

Furthermore, I've added mortar bases as well around the target zone (which is huge compared to vanilla). These doesn't require radio tower since the mortars are already within short range radio coverage. To silence these, you have to find them and neutralize them. Enemy also seem to favor mortars against light infantry rather than artillery. And during the fires, the whole area goes into suppressive mode trying to make you stay put (and trust me, it works :D) to make the rounds count.

To further increase the odds for AI, I will "warn them" of our incoming artillery rounds if they have an artillery radar in the area, and they will start running away from the impact zone long before the rounds hit. Want to use artillery? Pay attention to the tactical situation :) I'm considering to base the AIs accuracy with artillery on the servers own difficulty setting; the more "GUI help" we are getting (such as extended map info), the more accurate the AI will become as well. AI will also follow the same firing rates that we have. Decrease the timer so we can fire more often? The AI will get the same (or, half) ability :) I've also reduced to only one artillery operator, the other one (sniper team spotter) gets mortars instead. Our guys calling in external fire support will also be denied the support if they call for destructive non precision ordnance near "populated areas" (marker check, simulating FDC being under ROE). I'm sick of people always leveling the place. I also have a three man CSW/SF team with their own dedicated Stryker Mortar Carrier that nobody else can use. Need to see how it "plays out" or if it becomes too much. They can also obtain (as the only ones) mortar backpacks, I only wish they were 60 mm instead.

Having true guns at a firebase fire true rounds would ruin the game mode, as they would be too simple to destroy (since nobody cares about if they die in the process). You can't populate the map properly to make it realistically dangerous for aerial scouts (and at the same time have realistic hopes of reaching the target zone) due to overhead. I don't think you could even spawn a realistically sized external firebase for each target. So sometimes this "fake ammo spawning" is a necessity. As a game mode, it needs to be kept challenging.

And with challenging I mean that even if you can't technically loose in any way, the pressure is up to keep your assets. Most other modifications I see goes the other way, making everything even more convenient for the players completely getting rid of any risks. War is risky business. Makes you wonder what would happen if default game had nukes and AC-130s :S

Edited September 8, 2010 by CarlGustaffa

[Evil_Echo 11]

My experiences regarding the use and impact on gameplay of large weapons are quite different from CarlGustaffa. That is to be expected since we design our missions very differently. All I can say is that my player base likes the challenges posed and have no issues with the resources the AI utilizes.

In the versions of Domination I know about the radio towers only control reinforcements and there is no way to stop illumination rounds. Regardless, the method of spawning shells is very artificial.

I'll leave the debate about merits of real guns to another thread - here that matter seems off-topic.

The fire director functions include an uncertainty of target position, the game engine takes distance, observer skill and clutter into account. That uncertainty is used to evaluate the quality of a target and eventually factors into whether it's chosen as a fire mission. Other factors include range from battery to target, proximity of friendlies, and target type. A cluster of enemy artillery pieces is far more attractive than a lone soldier.

Unlike some human-controlled artillery - the fire director is not interested in routinely leveling a town. It choose the best target(s), fires at it, and moves on to whatever is next in priority. It does not fire warning shots. It uses just enough rounds to get the the job done. The hooks are there for much more - the FSM could be extended to provide cover fire, smoke, or illumination.

As I said, this is a toolkit. Use it as you see fit.

Edited September 8, 2010 by Evil_Echo

[mr_centipede 31]

As I said, this is a toolkit. Use it as you see fit.

And an excellent toolkit at that. Thank you for your hard work. I'm still learning deeper on how to use this thing... but so far I can have 1 squads of AI, duking it out with another squad of AI, both have FOO and watch the carnage that Arty brings... wonderful... Looking at the functions and try to

imagine how to utilize in in one of my scenarios

Thank you very much good sir

[Evil_Echo 11]

Sounds like the beginning of a cool mission. Could you make a video?

[dmarkwick 261]

I noticed that the spotter will often target moving units, meaning that by the time the rounds land it's far away. Is there a chance for some logic either adding movement as a reducing factor, or a predictive impact point? Or maybe a little of both ;)

But, all in all I'm really getting a kick out of this.

[Evil_Echo 11]

I noticed that the spotter will often target moving units, meaning that by the time the rounds land it's far away. Is there a chance for some logic either adding movement as a reducing factor, or a predictive impact point? Or maybe a little of both ;)

But, all in all I'm really getting a kick out of this.

Good ideas, I had thought of adding velocity to the observations. Perhaps a linear prediction of the weighted group velocity. But your idea of derating the cluster value due to movement has merit as well.

[dmarkwick 261]

I've never served in an artillery battery, but I might make the assumption that delaying the fire order is more "realistic" than trying to predict a course :)

However, gameplay is the thing ;) so, whatever solution works best, works best.

As an aside, I note that a spotter in my group will call in fire even under a Hold Fire command. Now, I realise that calling in fire and using your weapon are two different situations, is there the possibility of a "Hold Fire"-type command under the 6 menu? So I can have weapon status and artillery-calling status as separate controls for the squad leader?

Edited September 9, 2010 by DMarkwick

[Evil_Echo 11]

Certainly the current "Hold Fire" should manage use of personal or crew weapons. I use that in my missions to ensure my spotters stay relatively stealthy.

The notion of silencing a spotter is intriguing. Perhaps a setVariable/getVariable would suffice? We'd just need to agree on some convention to use.

[dmarkwick 261]

Certainly the current "Hold Fire" should manage use of personal or crew weapons. I use that in my missions to ensure my spotters stay relatively stealthy.

The notion of silencing a spotter is intriguing. Perhaps a setVariable/getVariable would suffice? We'd just need to agree on some convention to use.

Whatever solution is easy to implement & use :)

I've no real issue with the notion of spotters being autonomous, after all that's what this addon is all about, I just think that as a squad member he could be controlled by the squad leader, including calling in targets. No predicting what a squad leader needs his crew to do (or not do) :D

[Evil_Echo 11]

I'll ponder the idea. Leaning toward a pair of new functions to enable/disable reporting by a unit. That way I can manage the details and you folks don't have to worry about how it works.