ECHO fire director

[snoops_213 75]

yes to that for sure :)

[dmarkwick 261]

Yep, but make it a later build :)

[Evil_Echo 11]

Noted. Since I'd already had plans for a S2 module, seems like S4 (and E4) would be the logical place to look at for supplies, etc.

I like the interplay of ideas going on here, very refreshing.

...

More functions written. Set/get for battery minimum dispersion, maximum speed of target before de-rating. Plus a few

support functions to tie into the velocity stuff. So far, so good.

Edited September 19, 2010 by Evil_Echo

[kylania 568]

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

Official announcement on Armaholic

Does the scripted version still require CBA?

[Evil_Echo 11]

The scripted version does not require CBA - my quality assurance tests work fine when using vanilla ArmA.

I had required CBA in the pbo varients with the idea I might be using it's network code for possible client-server communications in the future. An example would be a UI for human players to request fire support via the fire director.

Reconcidering the need for CBA at all and using in-house networking code when the time comes - their splash screen is hugely annoying. Any thoughts yes or no are appreciated since I'm starting the build phase for the next release, could remove CBA for good right now.

[kremator 1065]

The CBA splash screen just winds me up. Please don't use it.

[Evil_Echo 11]

After some time, effort, and some mild oaths, CBA has been exorcised. After a bit more beta testing version 1.1 should be released soon.

[mr_centipede 31]

I just noticed, if it is possible, to have a sideChat between the FOO and the arty, that way we can know that an arty is inbound. and use a '+' marker just like you would see with SOM arty

[Evil_Echo 11]

The FSM puts down markers right now at various levels of debugging, but realise you are talking about a more general system using the hooks provided by the ARTY module's optional parameters.

The question of who should know what gets complex, ultimately it is something only the mission maker can determine. I'm leaning toward some method where you'd register a variable or routine with a battery to be used to signal artillery events. That would also work with out of ammo situations - allowing a trigger to resupply.

Opinions, thoughts, etc?

[gunterlund21 10]

The FSM puts down markers right now at various levels of debugging, but realise you are talking about a more general system using the hooks provided by the ARTY module's optional parameters.

The question of who should know what gets complex, ultimately it is something only the mission maker can determine. I'm leaning toward some method where you'd register a variable or routine with a battery to be used to signal artillery events. That would also work with out of ammo situations - allowing a trigger to resupply.

Opinions, thoughts, etc?

We definitely need a resupply option because the mortars run out of ammo too fast.

[mr_centipede 31]

My thought was to do like SOM arty does, using sideChat, that way everyone on that side will 'hear' it. Something like:

When the FOO reg the target he goes: "Fire mission. Grid Ref 123456 Fire for Effect."

Assuming, the fsm will chose which battery to fulfill the fire mission, and you can get one of the gun name, you could use (leader gun) sideChat "Target Ref received" or something to that effect.

About the markers, you could check the player side and the gun's side if same side then put in the markers... you could use it in debug 0 in the exec parameter

[galzohar 31]

Would love to see a script version of this that works with ACE and with dynamically spawned spotters and artillery sites.

[Evil_Echo 11]

Would love to see a script version of this that works with ACE and with dynamically spawned spotters and artillery sites.

Not sure of the benefit of spawning artillery on the fly. Can you explain the rationale to me?

Adding support for an alternate artillery system requires a lot of extra code. I'd need the candidate to be

• Stable. Not willing to spend huge amounts of time chasing bugs or constantly updating my code to match the release of the week.
  
• Well documented. My telepath rating is only P5, need to be in the line of sight to read minds of developers who won't write detailed manuals.
  
• Well supported. Want to be able to interact freely and without getting a run-around.
  

ACE artillery meets none of those criteria. When it does, I'll consider it.

[galzohar 31]

Basically any dynamic missions or dynamic mission makers such as MCC would make great use of spawning artillery on the fly. Usually at the start of the mission, but still not placed in the editor. Domination modifications could be another example where they would need to be created on the fly.

Does ACE artillery actually break BIS artillery? I thought you could use BIS artillery even when ACE is running, but from your posts it seems it isn't? Also, with the new artillery system implemented in the latest patch, are the artillery modules even needed? That is, are there actually are scripting commands to order AI to fire at a position with the new system and not just a UI to order the AI to fire when he's in a player's group)?

[Evil_Echo 11]

I can see the utility of dynamic spawn at the start of a mission. The trick would be ensuring good placement so your cannon have clear firing arcs. Otherwise that should work with my code right now.

My own tests a while back and more recent reports on this thread all point to problems using BIS arty calls when ACE is present. The conclusion I came to was that if ACE is loaded you have to use ACE's routines and class names. Which would lead to either having to code up a separate set of scripts and FSMs just for ACE ( maintainance nightmare ) or adding using lots of conditional tests to a merged version ( performance hit and maintainance nightmare ).

It's not that I hate ACE, I used to code for that mod after all. It's just a matter of cost/benefit. I can spend weeks unpacking pbos and reading their code line by line, hoping nothing changes in next week's release. Or spend that same time adding exclusion zones, support for reloading, and a notification system so mission makers can tell where my guns are firing. The latter choice seems to be the winning decision right now.

[CarlGustaffa 4]

Domination already have AI artillery. I've replaced the spotters function and the whole doarty system with my own, but it involves quite a bit of messing around with Dominations own parameters. If anything, the echo system should probably not touch the artillery side at all, and only deal with AI mortar systems (which is unused in vanilla Domination afaik, but I've replaced that too).

Also, in order to fight on equal terms, AI spotters should only be needed to actually call in the mission, not the actual spotting. Because that's how players play; "Hey mr arty man, we need HE on marked location". The reply "No can do, I don't have visual myself" never occurs. As much as I like realism and enforcing rules, I don't like putting stricter rules on AI side.

constantly updating my code to match the release of the week.

One of the reasons I'm delaying ACE support on (soon to be test released) Domino.

The conclusion I came to was that if ACE is loaded you have to use ACE's routines and class names.

Use #ifdef, #else, and #endif. Works nicely in Domination to support different setups. Biggest problem with this, is that when it get messy, reported line number errors may be off (compared to the line number in the editor).

Edited September 23, 2010 by CarlGustaffa

[Evil_Echo 11]

Good points CG. Use what parts of the fire director you like, even if just the doFireMission script. Splitting the observer/reporting functions makes sense in your way of making missions.

Using #ifdefs is completely fine, it's keeping the contents between the preprocessor tokens in synch that is the nightmare. Which is why I made that list of requirements.

At some point I will have a means for player/AI interaction. Again more a toolset. that way you can have a point-click UI or use a form resembling a real FO request.

Edited September 23, 2010 by Evil_Echo

[dmarkwick 261]

For squad members enabled with spotter FSM, it might be a nice idea to have them announce incoming fire. Say just a simple announcement via chat. Direction, range, approximate time in seconds, from the PoV of the spotter.

This might prevent accidental injury due to me moving in too fast in hectic situations :)

[Evil_Echo 11]

Back to the question of resupply....

I set up a test with some D-30s and found out the guns never run out. Checking the ARTY module code I found lines that add an extra magazine ( and never get rid of the old ones ) whenever it feels the piece is getting low. There does not seem to be any specific test for the type of weapon, so this should be happening to all artillery types.

So what were you folks seeing that made you think/know that your batteries had run out of ammo? Some sort of test case to clue me in would help because I'm out of guesses here.

[gnarly_rider 0]

Echo, this may be of interest (haven't tested it myeself) if you are still playing with AI and binocs

http://forums.bistudio.com/showthread.php?t=107888

[Evil_Echo 11]

Thanks GR.

[Evil_Echo 11]

Version 1.1 is now available. Posting at http://www.armaholic.com/page.php?id=11757

It includes a number of your wishes. Hope you like.

And extra thanks to DMarkwick for doing some extra QA testing for me - very much appreciated.

Edited September 30, 2010 by Evil_Echo

[manzilla 1]

Version 1.1 is now available. Posting at http://www.armaholic.com/page.php?id=11757

It includes a number of your wishes. Hope you like.

And extra thanks to DMarkwick for doing some extra QA testing for me - very much appreciated.

Thank you for the update. It's always appreciated. My apologies for not being able to help with the testing.

Thanks again bud.

[Evil_Echo 11]

NP Manzilla. You've done your share in the past as well. There will be plenty more new ideas to shake down in the future.

[gnarly_rider 0]

Loving this Echo!

Question for you, which is truly a noob arty question outside your script, and likely dependent on the arty and round type (flight time and trajectory): is there a table anywhere you can point too that will give some idea what mil dispersion equate to at various ranges, for instance for the Podnos Mortars?

My group is about to fell the pain, but I would like to get an idea how tight the groupings are at various ranges...

As someone mentioned previously (Gunter?), if testing locally in the editor, DISABLE the isServer line in the init line!!!! :butbut:

PS love the debug mode!

Edited October 2, 2010 by gnarly_rider