Umpire Tool: Manage Ammo

[James Sterrett]

This tool would allow the umpire to deplete the ammunition levels on selected units.

Selecting units and then selecting the "Manage Ammunition Levels" menu item brings up a float; what is active on the float depends on the units selected.

If all units are *identical* in type, then the tool will allow the umpire to manage selected specific ammunition categories for the unit(s).

If *multiple* types of units were selected, then the umpire is restricted to setting the percentage of ammunition available. Specifics ammunition types would be shown grayed out, if at all.

This tool can also be used for (and might replace) the resupply tool; units to be resupplied would have their current ammunition levels raised instead of lowered.

As an added bonus, this tool could be used to allow selective overstocking of units, to carry more ammunition than the game currently allows.

 

[GCoyote]

Interesting. More realistic for scenarios that begin with units in contact. Helpful for LOGEXs too, I'd imagine.

 

[Redwolf]

Export OOB to XML files, including ammo level data.

Reimport XML OOB, using possibly edited values.

Available tools (XML parsers) will go a long way to ensure the edited file has the proper format. I don't think anyone who havent used XML can appreciate how much these tools can do in the safety department. Slow as hell, but that's not relevant here.

 

[John Osborne]

Export OOB to XML files, including ammo level data.

Reimport XML OOB, using possibly edited values.

Available tools (XML parsers) will go a long way to ensure the edited file has the proper format. I don't think anyone who havent used XML can appreciate how much these tools can do in the safety department. Slow as hell, but that's not relevant here.

Ok, you got me to situp in my chair Talk to me on how to do this. What is an XML files?

John

 

[Redwolf]

A structured ASCII representation of data that comes in tree form and defines attributes for whatever the data is about.

The key factor here is that the data, which can have many different types of records all nested into each other, has to be checked for correct syntax and for a correct tree structure.

With XML you get standard tools where you define the "grammar" in a language similar to regular expressions and then your syntax checker is done.

To get the data into your own program you still have to traverse the tree, but you get help from the parser and you know for a fact that the file is well-formed (because that check just ran). That knowledge makes things a lot easier.

In short, you describe the legal form of a file in a (for a programmer) very convinient way, and then you get a very tight checker for correct syntax out of it. If a user ends that file and forgets a quote, or puts an ammo level attribute into a minefield marker, or an infantry headcount into an off-map artillery marker, then this file will be rejected with that tool. You don't have to do these checks yourself.

You still have to ensure that the numerical values make sense, and you have to plug your code (data collector) into the parser, but that becomes a very straightforward task when you know for a fact that all attributes are at the right spot and none will be missing or double.

Obviously it takes care of all the line end mess as well.

That was for the programmer. On the user side you can write graphical editors for the files easier, but I am not familar with that side.

Here's a tutorial:
http://www.w3schools.com/xml/default.asp
Here's the part about checking with the DTD:
http://www.w3schools.com/xml/xml_dtd.asp

This all looks scary, especially when it comes to the regular expressions in the DTD. But keep in mind this is for programmers. It beats checking the proper syntax of all the details in non-simple files in your own code by a long match.