Improved artillery

[JonasJurczok]

Preface

In our community we love Ares. It's the best tool available to make the Zeus actually effective and a also make it easy for him to curate a mission in a good way.

We recently started to use a fire mission protocol to effectively and accurately call in fire support whenever needed. This was also made possible by ares :)

There are a couple of downsides with the existing fire support module though:

• It only works on one artillery unit at a time
• you have to place an artillery target first.

Both are kind of annoying when it comes to more complex fire missions. Also you have to train yourself to place the artillery targets not on the enemy units but instead at the position that the JTAC actually called in. I really like it as a "beginners tool", though.

Anyway. This leads us to

Scope of this PR

I added a new command in the AI Behaviour tree called "Artillery Fire Mission". This is basically the AoE version of the existing artillery command.

How to use it

• Place artillery units like usual (mixed groups are possible now)
• Select "Artillery Fire Mission" from the menu
• Click anywhere near the artillery units (radius is 150m currently).
• A dialog will pop up to let you choose which battery should fire.
  • A battery is defined as "all units in the radius that are of the same type"
• After confirming a second dialog will pop up. You can pick
  • Number of guns (select box)
  • Number of rounds (free form text box)
  • Shell type (select box)
  • Target X coordinates (free form text box. Expects grid coordinates)
  • Target Y coordinates (free form text box. Expects grid coordinates)
• After confirming this dialog the selected battery will fire with the selected number of guns at the specified location

To achieve this I had to do two major things that might concern you:

• I had to enhance the chooseDialog to also show textboxes if no choices are given (feels like a hack)
• I had to use a CBA function (mapGridToPos). This adds a CBA dependency but as basically everyone has this one running anyway it should not be a problem. It's your decision though and as it is only one function I might just copy it right away.

  Tasks

• [X] Create new menu entry
• [X] Populate menu entry with functions
• [X] select battery
• [X] select fire mission details
• [X] Actually fire the guns
• [ ] Input validation regarding number of rounds (maybe switch to selectbox?)
• [x] Design special fire mission dialog for asking for the values
• [x] fix chooseDialogTextBox default value problem
• [x] Show estimated time of flight at some point
• [ ] Add "confirm fire mission" dialog with all details including etof
• [x] Remove all the debug statements
• [x] Do extensive testing on other ares functions if I broke anything
• [ ] Enhance documentation
  • [ ] Create video on YT on how to use it
  • [ ] Create publicly readable documentation on how we do fire missions and how this supports you
  • [x] Enhance the wiki page about behaviors for this new one
• [x] Add contributor note ( ;) )

  Conclusion

I would love to hear on what you think about it. Also if you have comments on how not to do things please feel free to do so. I'll update this PR regularly as new parts become available.

Also if you have opinions on how not to use your work please tell me, I'll adjust then :)

Thanks for the awesome work. After working with SQF for multiple hours now I have only deepest respect for people who fiddle with it for more complex projects. By now I hate it with a passion :D

[astruyk]

Wow, this looks like a great feature - I haven't looked at the code in detail or tested it or anything, but here are my initial thoughts:

• Typing in coordinates always kind of irks me - IMO it's really easy to get it wrong (typos and such) and feels a bit clunky. I think for your use case (having Zeus provide the role of controlling a battery using player-supplied coordinates) it does make sense though... It'd be nice if there was some way to use EITHER the supplied coordinates or existing artillery target modules... That could be a feature added afterwards though. FYI - normally I use the artillery module when firing enemy units - and so looking up coordinates is a bit clunky and less accurate than just putting a target where I want them to fire.
• Re: the Choose Dialog - It does seem kind of hacky - but it makes sense if you think about it a bit. I had been wanting to add support for text boxes already, so I'm glad you managed to do it first :) The syntax is OK I think (e.g. ["Label", []]) ... Maybe cleaning it up into ["Label", "Default"] or, in the case of no default, ["Label", ""] would be a little cleaner usage-wise. It's a bit messier on the backend, since it'd be switching around based on the type of the second argument - but I think it might be worth it.
• Yes, SQF sucks and I hate it too :) It doesn't get any better.
• Some of the 'SQF Sucks' is mitgated if you implement things in dynamic modules since you don't have to recompile the whole thing every time and can just restart the mission. I'm going 100% with doing things that way in the future, and I recommend it. Normally when I'm developing a feature I throw in a call to Ares_RegisterCustomModule in my init.sqf to add the module I'm working on, that way you can edit the SQF file and just restart the mission to have it reload. No rebuilding required. You can actually register (and re-register) the module on the fly using the 'Run Code' modules... Harder to debug because you don't get line numbers of errors though.
• Issue #95 has some other things I wanted to do with artillery firing. Just for future reference.

Anyways, looks awesome. Keep it up and I look forward to actually testing it out. Let me know when you think it's ready for a pull and I'll merge it into the main depot.

[astruyk]

Oh, one other thing, regarding CBA - I'd prefer not to depend on it if we can avoid it. Unless there's a ton of work or really complicated code (or, licensing issues) from CBA that we need I'd like to keep Ares runnable without any extra mods.

Edit: To be clear - ONE function doesn't really meet the litmus test for introducing a new dependency. I'd prefer to keep CBA out if you just need the one function. If there's other things that CBA can do for us, I'm all ears.

[jonpas]

If there's other things that CBA can do for us, I'm all ears.

Much better function compilation, tons of very very useful macros, ability to have packaging scripts and awesome development builds, better debugging functionality, better Event Handling, XEH... so on and on. :)

[astruyk]

Lemme think about it. I see they have a hashset implementation. I want hashsets badly. :) Leave your function call in there for now.

On Thu, Jun 25, 2015 at 10:50 AM, jonpas notifications@github.com wrote:

If there's other things that CBA can do for us, I'm all ears.

Much better function compilation, tons of very very useful macros, ability to have packaging scripts and awesome development builds, better debugging functionality, better Event Handling, XEH... so on and on. :)

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-115282771.

[jonpas]

Yes, look at ACE3 for example, using CBA's things and expanding vastly on it. You really can't go wrong with it.

[JonasJurczok]

Of course I'll ping you as soon something is working (so hopefully in 1h or so)..

On Thu, Jun 25, 2015 at 4:39 PM, Anton Struyk notifications@github.com wrote:

Wow, this looks like a great feature - I haven't looked at the code in detail or tested it or anything, but here are my initial thoughts:

• Typing in coordinates always kind of irks me - IMO it's really easy to get it wrong (typos and such) and feels a bit clunky. I think for your use case (having Zeus provide the role of controlling a battery using player-supplied coordinates) it does make sense though... It'd be nice if there was some way to use EITHER the supplied coordinates or existing artillery target modules... That could be a feature added afterwards though. FYI - normally I use the artillery module when firing enemy units - and so looking up coordinates is a bit clunky and less accurate than just putting a target where I want them to fire.

Ok I never thought about that usecase. As we only use it for friendly artillery and fake enemy artillery with the ingame Zeus fire support module... But of course that's also a good idea. I'll add it to the stretch goals.

• Re: the Choose Dialog - It does seem kind of hacky - but it makes sense if you think about it a bit. I had been wanting to add support for text boxes already, so I'm glad you managed to do it first :) The syntax is OK I think (e.g. ["Label", []]) ... Maybe cleaning it up into ["Label", "Default"] or, in the case of no default, ["Label", ""] would be a little cleaner usage-wise. It's a bit messier on the backend, since it'd be switching around based on the type of the second argument - but I think it might be worth it.

Ok if you like it I'll keep it this way and of course clean it up. Especially the possiblity for a default seems really appealling.

• Yes, SQF sucks and I hate it too :) It doesn't get any better.

mwah :(

• Some of the 'SQF Sucks' is mitgated if you implement things in dynamic modules since you don't have to recompile the whole thing every time and can just restart the mission. I'm going 100% with doing things that way in the future, and I recommend it. Normally when I'm developing a feature I throw in a call to Ares_RegisterCustomModule in my init.sqf to add the module I'm working on, that way you can edit the SQF file and just restart the mission to have it reload. No rebuilding required. You can actually register (and re-register) the module on the fly using the 'Run Code' modules... Harder to debug because you don't get line numbers of errors though.

Ok. I really like the line numbers.. But yeah. Will read into that.

• Issue #95 https://github.com/astruyk/Ares/issues/95 has some other things I wanted to do with artillery firing. Just for future reference.

I was thinking about some more stretch goals as well. I'll add them to the ticket then :)

Anyways, looks awesome. Keep it up and I look forward to actually testing it out. Let me know when you think it's ready for a pull and I'll merge it into the main depot.

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-115278761.

[JonasJurczok]

Okay this version is testable. The dialog is working now (restoring values from old iterations does not work, but that's kind of intended).

The only problem I have is that the artillery does not fire. I copied the code from the existing artillery module and changed nothing except adding a for loop.. This should not change the behaviour.. If you could take a look and check for the obvious stuff that would be awesome :)

[JonasJurczok]

Okay I'm confused..

I added a log statement to the existing ares artillery function. This is the log output:

23:37:58 "Jason/BIS_fnc_log: [[1649.35,5483.71,0],"8Rnd_82mm_Mo_shells",1]" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] "Firemission confirmed."" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] [1849,5549,0]" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] B Alpha 1-3:1" 23:38:09 "Jason/BIS_fnc_log: [[1849,5549,0],"8Rnd_82mm_Mo_shells","2"]"

As you see the first and last line are missing the filename. This is the log output from the "original" "Ares_FireArtilleryFunction". The first occurence comes from a traditional fire support mission (which works). The second one from the new one, without effect. Do you have any idea what the problem might be?

[astruyk]

In the second one you're passing in the string "2" instead of the number 2... Maybe that makes a difference?

On Thu, Jun 25, 2015 at 5:44 PM, Jonas notifications@github.com wrote:

Okay I'm confused..

I added a log statement to the existing ares artillery function. This is the log output:

23:37:58 "Jason/BIS_fnc_log: [[1649.35,5483.71,0],"8Rnd_82mm_Mo_shells",1]" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] "Firemission confirmed."" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] [1849,5549,0]" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] B Alpha 1-3:1" 23:38:09 "Jason/BIS_fnc_log: [[1849,5549,0],"8Rnd_82mm_Mo_shells","2"]"

As you see the first and last line are missing the filename. This is the log output from the "original" "Ares_FireArtilleryFunction". The first occurence comes from a traditional fire support mission (which works). The second one from the new one, without effect. Do you have any idea what the problem might be?

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-115406709.

[JonasJurczok]

I knew there is something obvious. Will try that later. Am 25.06.2015 11:47 nachm. schrieb "Anton Struyk" <notifications@github.com

:

In the second one you're passing in the string "2" instead of the number 2... Maybe that makes a difference?

On Thu, Jun 25, 2015 at 5:44 PM, Jonas notifications@github.com wrote:

Okay I'm confused..

I added a log statement to the existing ares artillery function. This is the log output:

23:37:58 "Jason/BIS_fnc_log: [[1649.35,5483.71,0],"8Rnd_82mm_Mo_shells",1]" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] "Firemission confirmed."" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] [1849,5549,0]" 23:38:09 "Jason/BIS_fnc_log: [Ares_fnc_BehaviourArtilleryFireMission] B Alpha 1-3:1" 23:38:09 "Jason/BIS_fnc_log: [[1849,5549,0],"8Rnd_82mm_Mo_shells","2"]"

As you see the first and last line are missing the filename. This is the log output from the "original" "Ares_FireArtilleryFunction". The first occurence comes from a traditional fire support mission (which works). The second one from the new one, without effect. Do you have any idea what the problem might be?

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-115406709.

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-115407699.

[JonasJurczok]

So.. this version is testable now. As soon as you merged it I will update the wiki with the new information and also start preparing a video about it.

[astruyk]

I did some more specific notes on the code. Mostly minor stuff. After those are done I'll merge the pull request.

[JonasJurczok]

Awesome :) I've updated the wiki. Are you going to release a new version for this?

[astruyk]

At some point :) I haven't actually had a chance to check it out for realz. I'll need to do that first. There are a couple small things I want to do before a release as well. I'll let you know.

On Tue, Jun 30, 2015 at 12:25 PM, Jonas notifications@github.com wrote:

Awesome :) I've updated the wiki. Are you going to release a new version for this?

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-117244858.

[JonasJurczok]

Okay cool :) Because we are now all waiting for it to be released and "officially" usable :D Am 30.06.2015 11:41 nachm. schrieb "Anton Struyk" <notifications@github.com

:

At some point :) I haven't actually had a chance to check it out for realz. I'll need to do that first. There are a couple small things I want to do before a release as well. I'll let you know.

On Tue, Jun 30, 2015 at 12:25 PM, Jonas notifications@github.com wrote:

Awesome :) I've updated the wiki. Are you going to release a new version for this?

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-117244858.

— Reply to this email directly or view it on GitHub https://github.com/astruyk/Ares/pull/197#issuecomment-117353555.