ECHO fire director

[dmarkwick 261]

I'm getting some great gameplay out of this :) it's great.

During one of my missions, I use DAC to spawn objects around the landscape, one of which is a UH1 Wreck ("UH1Wreck"). The spotter in my group for some reason will bombard it. I don't know why he does this, but I do note that that particular wreck is the only one that units will call out the position of, maybe because it has a functioning weapon on it. Is this desired behavior?

---------- Post added at 02:22 PM ---------- Previous post was at 02:02 PM ----------

Incidentally Evil_Echo, do you plan to make more of this FSM-enhancement stuff? It seems like a winning method :)

I'm thinking mainly of two things, an AI spotter/sniper 2 man team solution, and also an AI medic solution.

[Evil_Echo 11]

Don't know if you can call targeting a armed wreck desired behavior. Interesting that a spotter would report that as threatening ( via the nearTargets function ). The fire director must have been quite bored to select that target. :confused2:

Excluding that wreck makes sense, but there may be other things people want to add or remove. What makes sense to you folks? I'd like to stay flexible about this - people find unique applications for tools that the original developer never expects.

Had not thought about medic or sniper features. People who've read many of my postings know I'm hugely into precision shooting both in game and real life. Which is why ACE ended up with spotter scopes, wind drift effects/tools, etc. - kept giving Rocko these ideas. Hmmm - Evil Snipers. Teams working to select high-value targets.... YEAHHHHHHHH!

:681:

I'm guessing that medics would be simulating triage, etc. Or am I missing something?

First things first though. Need to get an updated manual and scripts version of the current stuff out. Hopefully in a couple days. Then on to new cool features.

[dmarkwick 261]

Glad you're thinking about the spotter/sniper thing :)

RE the medic - really just a method for the medic to act on his own as a medic rather than waiting to be told who to heal. Whether this is by proximity, severity, importance or some combo I don't really have a cast-iron suggestion, whatever works while not placing him in unreasonable danger I suppose.

I guess what this is kicking off is the idea that specialised units can be made to act more like useful autonomous units, spotters who can have a genuine useful role, snipers who act like snipers & not just like more accurate squad members, medics who act like medics upon unit injury etc.

---------- Post added at 04:35 PM ---------- Previous post was at 03:38 PM ----------

OK, now in my current sandbox mission, which is entirely DAC driven apart from 2 Blufor squads, 3 arty groups and one Opfor Shilka, I'm seeing a game freeze every minute or so for anything from 5 to over 30 seconds. Generally the pauses increase as I move further into enemy territory. Eventually I'm suffering >30 second pauses after every minute of gameplay. This doesn't occur if I prevent FireDirector.fsm from executing.

When I say about every minute, it seems to occur each 60 seconds plus a small random amount, consistent with the 60 + 20 jitter in the FSM call.

The vast majority of mission movement is DAC driven Opfor groups.

[Evil_Echo 11]

Dang - that not good.

Roughly how many units do you think are present around your spotters - say within 1,500m?

Obviously the two solutions are to increase the interval between checks and reduce the spotting range. Think the range might need to be a tunable - directly or based on skill level of the spotter. Maybe enhanced by owning optics like binoculars?

[dmarkwick 261]

Dang - that not good.

Roughly how many units do you think are present around your spotters - say within 1,500m?

My DAC reports somewhere between 60 and 110 units in between 20 to 33 groups (I do a lot of randomisation for variance across sessions) in an area maybe 2 or 3 KM across. They are spread across infantry, motorised infantry and armoured, and a couple of patrol helis with passenger loadouts.

Obviously the two solutions are to increase the interval between checks and reduce the spotting range. Think the range might need to be a tunable - directly or based on skill level of the spotter. Maybe enhanced by owning optics like binoculars?

I don't know how Echo Fire Director works, but something else I do in this mission is to use DAC to spawn a LOT of incidental objects for terrain variance. These include walls, boulders and wrecks, and there can be as many as 800 of these objects. (I randomise between 400 and 800, so 400 would be the minimum). Are ALL editor-placed/spawned objects regarded?

Edited September 10, 2010 by DMarkwick

[Evil_Echo 11]

It uses the data from nearTargets. Have not played with DAC - but suspect that you are getting some huge lists. Easy test would be to crank the debugging level to 2 or higher in your call to the FSM. You'll see much more data in the rpt file and markers placed on every cluster or outlier unit that has been spotted. For your mission I'm betting that this is going to be a lot of stuff.

If my suspicions are confirmed, we'll need a method to adjust the range used for spotting, your guys are seeing a lot of overlapping targets.

[dmarkwick 261]

Is it worth putting a sleep among the spotting code where it cycles though lists? Just to alleviate the bottleneck? It might require rethinking the fire mission repeat time, unless you time it from the end of the list cycle, however long that takes.

*edit*

Hmm, unless it's the nearTargets command itself that is bottlenecking.

I will retry the mission but without the incidental object spawn. See of that affects anything.

Edited September 10, 2010 by DMarkwick

[dmarkwick 261]

Yeah, I moved the object zone across the map out of the spotter's regard, and the problem went away. I guess all non-map objects are returned as targets? That's a shame, because I like to make use of spawned objects a lot.

(When I say went away, it became a small stutter ever minute or so instead of a large pause. There is still a small pause, but only like a half second or so.)

[Evil_Echo 11]

Ok - that gives me useful data. Will see what can be done.

Thanks.

[gunterlund21 10]

well I cant seem to get this to work. I have it set up exactly like the demo mission but the mortars wont fire on me for some reason. I know the spotter has seen me as he is dancing around.

// Start Fire Director.

_rus_batteries = [A_Battery];

_rus_spotters = [OB1];

waituntil { not isnil "bis_fnc_init"};

waitUntil { not isNil "BIS_ARTY_LOADED"};

FD_US = [_rus_spotters, _rus_batteries, 60, 20, 1] execFSM "x\echo\addons\fire_direction\FireDirector.fsm";

I placed this at the end of a longer init file. The demo mission works fine but not this. I have an arty module on the map named A_Battery and synced with a mortar, and a spotter named OB1.

I love the concept but this really needs to be a script that we can put in missions. Otherwise it will die as not one wants to load more addons.

Edited September 11, 2010 by gunterlund21

[Evil_Echo 11]

gunterlund21:

Hang on there - a script version is on the way.... :cheers:

I'd need some more details to determine what is going on with your problem. At first blush it sounds like you are just a lone unit and that would be low priority to the FD. Could be friendlies nearby ( how close are you to that spotter? ). Could be range or firing arc issue as well, depending on the type of arty used.

The easiest way to find out ( short of shipping me your mission files ) is to change the debug level on the FSM parameter. If you want to get ALL the gory detail, set the debug to 5 and run for just a polling cycle or two. Then shut down the mission and check your .RPT file for what is going on.

DMarkwick:

I have a plan to help handle your situation better, will code that into a new observation routine. A couple of the other things will need to get out first, so it may or may not make the next release that I hope to have out in a day or three. If not, it will be in the one after this. Hope that is ok.

[dmarkwick 261]

DMarkwick:

I have a plan to help handle your situation better, will code that into a new observation routine. A couple of the other things will need to get out first, so it may or may not make the next release that I hope to have out in a day or three. If not, it will be in the one after this. Hope that is ok.

More than OK, take your time :)

RE the moving target issue: I don't know what solution you're favouring but I'm going to change my DAC behavior so that targets spend longer at their waypoints before moving off. Currently they're almost always on the move with rather short stops, I think longer stops would be more appropriate. Maybe, as far as Echo Fire Director is concerned, any sufficiently non-desperate target should have two location samples before calling in fire, doing so only if the target is within limits, with maybe a small predictive offset? That way fast moving targets can be discounted from consideration while stationery or slow moving targets can be effectively targeted?

[gunterlund21 10]

gunterlund21:

Hang on there - a script version is on the way.... :cheers:

I'd need some more details to determine what is going on with your problem. At first blush it sounds like you are just a lone unit and that would be low priority to the FD. Could be friendlies nearby ( how close are you to that spotter? ). Could be range or firing arc issue as well, depending on the type of arty used.

The easiest way to find out ( short of shipping me your mission files ) is to change the debug level on the FSM parameter. If you want to get ALL the gory detail, set the debug to 5 and run for just a polling cycle or two. Then shut down the mission and check your .RPT file for what is going on.

Its a large MP mission and my team is in an AAV. I set the spotters so they are in range of me. The mortars are around 2 km away. They should be in range. I even had the team get out of the vehicle, hold fire and walk up to the spotter.

[kremator 1064]

Hang on there - a script version is on the way

You've just made me very happy.

Edited September 11, 2010 by Kremator

[gunterlund21 10]

evil also in your mission you have the russian guns firing on "staryeast". What is that. Is it a marker. I cant find it on the map.

update:

fixed my problem as I was not running it server side. Now there is a new problem. Dont know if its the russian weapons or what but the mortars will lock on but the rounds only travel about 50 ft and end up destroying the battery. You can literally see the rounds fall out of the sky in front of the tube. Craziest thing I have ever seen.

RPT Code

"Spotters [OB1]"

"Batteries [A_Battery]"

"Check Interval 60, Jitter 20"

"Debug level 5"

"Waiting 53 seconds"

Protocol bin\config.bin/RadioProtocolRU/: Missing word fieldhospital

" Number of active spotters is 1"

" 1 observations"

" 4 classes"

" Checking class 0"

" Class 0 has 0 entries"

" Max Sep 18, Min Neighbors 2, Color ColorBlue, Modifier 1"

" Found 0 cluster(s)"

" Found 0 outlier(s)"

" Checking class 1"

" Class 1 has 0 entries"

" Max Sep 10, Min Neighbors 1, Color ColorRed, Modifier 25"

" Found 0 cluster(s)"

" Found 0 outlier(s)"

" Checking class 2"

" Class 2 has 1 entries"

" Max Sep 20, Min Neighbors 1, Color ColorWhite, Modifier 2"

" Found 0 cluster(s)"

" Found 1 outlier(s)"

" Checking outlier [0], 1 members"

" Outlier OL-2-0, at [13049.6,9108.69,-0.0327172], 1 meters, quality 0.0071112"

" Checking battery 0, A_Battery"

" No competing fire missions"

" FM data [1,"IMMEDIATE","HE",2,1,3,4.67164,0]"

" Estimating 3 rounds"

" Modifiers: class 2, range 0.0934328, sheaf 1, friends 1"

" Fire mission quality is 0.000442946"

" Adding fire mission"

" Checking class 3"

" Class 3 has 0 entries"

" Max Sep 20, Min Neighbors 1, Color ColorBlack, Modifier 4"

" Found 0 cluster(s)"

" Found 0 outlier(s)"

" Checking class 4"

" Executing fire missions"

" Checking fire missions for battery 0, A_Battery"

" Queue [[0.000442946,"OL-2-0",[13049.6,9108.69,-0.0327172],1,"IMMEDIATE","HE",2,3]]"

" Queue entry [0.000442946,"OL-2-0",[13049.6,9108.69,-0.0327172],1,"IMMEDIATE","HE",2,3]"

"Fire mission FM-0-OL-2-0, at [13049.6,9108.69,-0.0327172], 1 mils, 3 rounds HE"

update:

Fixed the arty problem. It was the ACE arty module that was screwing things up.

Edited September 12, 2010 by gunterlund21

[gunterlund21 10]

Evil

Got this thing running and all I can say is wow. This is awesome. Only complaint I have is man are they accurate on the arty strikes. Ive been able to set up some very cool arty barrages from real gun emplacements, and it responds nicely to triggers to create rolling barrages. Cant wait to see what else you do.

[Evil_Echo 11]

evil also in your mission you have the russian guns firing on "staryeast". What is that. Is it a marker. I cant find it on the map.

....

update:

Fixed the arty problem. It was the ACE arty module that was screwing things up.

:D - staryeast is a traffic cone, at the intersection of the main road and a southern road on the east side of Stary Sobor. Using a piece of scenery instead of a marker seemed nicely subtle for this mission.

ACE arty module was the culprit, eh? Sigh.... I see that Xeno has decided to remove that module, too much grief after the new BI version of ARTY came out. On the good side, once removed it should make my work more compatable with rest of ACE.

I am glad you are enjoying the system now that you have it working for you. It does try to be accurate in a reasonable fashion, all that work on finding clusters of targets really pays off. For manual fire missions, feel free to use larger mils setting to get more of a spread - barrages are suppression fire meant to keep heads down after all.

Edited September 12, 2010 by Evil_Echo

[Evil_Echo 11]

The updated bundle is out. Has the hoped-for scripted versions.

Official announcement on Armaholic

Edited September 13, 2010 by Evil_Echo

[das attorney 857]

Thanks for the scripted version. Downloading now and looking forward to testing it out. It's great timing too as I've got three days off work to play about with it!

[dmarkwick 261]

Thanks for the update :)

[gunterlund21 10]

echo

the new system is AWESOME!!!!. Im having a great time laying waste with Grads on all sorts of stuff. Really gives the AI some heavy guns that they bring to bare. If the AI has spotters, your in deep doo doo if you dont keep moving. Sniff.... I love you man!!!!

[Evil_Echo 11]

That was the goal - restore artillery to it's position as "King of Battle".

If you look at German WWII tactics, a lot of it forcused on artillery. Combined use of HE and Smoke to isolate and screen flanks, using armor to punch through enemy lines to take out allied guns and THEN mop up the rest of the forces. You're never really safe until the enemy cannon are silenced.

Air power has it's place too, but it's not as fast to bring to bear on target, not all-weather and until recently not as accurate. Artillery does not need laser designaters to be scary close, but a Copperhead round will match a GBU if you do need that pin-point accuracy.

The larger weapons are bad enough, but mortars are worse. They're easier to hide, omnidirectional, pack a big punch for their size, and are FAR more common. Almost any mission could include medium mortar sections ( 3-4 tubes ) scattered in a couple places on the map.

Gamewise, good use of AI support fire eliminates a lot of the phenomena of player camping. No one in their right mind would park on a hilltop overlooking a town and casually snipe with long-range rifles or AT weapons for extended periods of time if the AI could whistle up some suppression fire on that location. I find that solution more satisfactory than trying to nerf the player weapons or impose artificial rules of engagement.

Anyway - looking forward to seeing the missions you folks create with this stuff. It'd be cool to see this in a large-scale scenario ala Domination.

Edited September 14, 2010 by Evil_Echo

[kklownboy 43]

...

Gamewise, good use of AI support fire eliminates a lot of the phenomena of player camping. No one in their right mind would park on a hilltop overlooking a town and casually snipe with long-range rifles or AT weapons for extended periods of time if the AI could whistle up some suppression fire on that location. I find that solution more satisfactory than trying to nerf the player weapons or impose artificial rules of engagement.

....

Word! Thnx for the work.

[das attorney 857]

Hey Evil Echo, I have a suggestion for E.C.H.O. Could there be a way to define areas of the map that the artillery are forbidden from firing into (like civpop areas, friendly structures, areas of interest etc)? Defined by ObjectID would be okay, or better from a marker (much like UPSMON).

I've only just started testing this tonight so apologies if the functionality is there and I've missed it.

Thanks, Das A

Edited September 14, 2010 by Das Attorney

[gunterlund21 10]

Echo

On the AI targeting is there anything on adjusting dispersion. When the AI is calling in arty from say three mortar tubes. The dispersion of those 3 rounds is very low. The accuracy is extremely high. Perhaps a perameter to adjust, like the jitter.