Data file authors - what would help you?

[Colen]

Hi everyone,

Last week, Rob and I spent a bunch of hours going through our list of "things to do" for Army Builder. A lot of changes have been requested over the last few years, many more than we had time to implement for AB3.2. We implemented the few we felt were most important, but there are still a lot left.

We're not sure if these would still be helpful, so I'm going to post the list here for you guys to look at. If you see a feature that would make your life easier when writing data files, please let us know which one(s). Also, please let us know what you'd use it for - we can sometimes think of alternative ways to do things that already exist, or would solve other problems as well.

Here's the list, in no particular order:

• Add numeric and text mapping tables to scripts that take a numeric value and translate it to a new value; add intrinsic to perform a lookup from a mapping table. This would let you easily map numbers to other numbers or strings, instead of (for example) having to define a procedure that looks them up.
  
• Add "array fields" - i.e. fields that can hold multiple values, instead of just a single value. This could be useful if you needed to store multiple values in a field to keep track of things throughout evaluation.
  
• Add button next to each squad that displays a list of all entities that can be legally added to the squad. This would be part of the "smart squads" functionality we've considered in the past - for example, if you had a squad with a Space Marine tactical unit in it, the button would allow you to add a Rhino or a Razorback. (This only makes sense if the appropriate units are added to the same squad, not as child units.)
  
• Overrides for options - just like units, you'd be able to specify "overrides" that changed option name, description, and other attributes of the option under specific conditions.
  
• Top-level units that are added as "detached" via a link from another unit should remember which unit added them; they can then access that unit via scripts and retrieve details from that unit, such as tags; this will enable a detached unit to "inherit" tags and behaviors from the unit that added it. (Detached units are units added to the same squad, NOT child units.)
  
• Allow the positioning sequence for top-level entities in a squad to be defined by the data files; this ensures that a transport could be forced to always come after the primary units in a squad, or that an IG advisor must be adjacent to the command squad he is associated with in a command platoon.
  
• Add support for comments associated with each section of the various data/defintion files; for example, attach comments to the Units section, separate comments to the Options section, etc.; also add an overall comments section to each file for comments that apply to the file as a whole. The comments would then be displayed in ABCreator when you were editing the files.
  
• Allow the Active tagexpr for profiles to be overridden within extension files, just like Member tagexprs.
  
• Add intrinsics to set the random number seed, get the seed, and generate a new random seed. This would let you control the "randomness" of random numbers and generate reproducible random numbers.
  
• When "new link" children are added, they are assigned the source link's priority plus one; allow a delta to be specified for the source link, with the new child pseudo-link being assigned a priority of the source link plus the assigned delta. This would let you have a "new link" option at priority 50, and a "delta" of 20, so the links it added would be at priority 70 (instead of 51, as they currently are). The default delta would be +1.
  
• Allow an option description to be modified via a script as a target reference.
  
• Ability to attach a linkset to an entity or option via an extension file, just like can be done for links.
  
• Apply deltas to overrides instead of specific new values. For example, you could say that a certain stat got a bonus of +2 in an override, instead of setting it to a fixed value.
  
• Add notion of a "placeholder" entity. This entity would be present in a squad if certain other entities were not. For example, you could have a placeholder "transport" entity that allowed you to select a transport, and which disappeared once one was selected. If the transport was deleted, it would come back. A validation warning would be given if there are any placeholders in the roster.
  
• Add a way to "lock" random values generated via scripts. Add a seed to each entity and randomize values based on the link's sequence number, thereby ensuring the same value every time for the same link; this also locks the values when deselected and re-selected. Also add the means to determine when a random number has been generated once, so that the value can be persisted thereafter and not re-rolled.
  
• Allow an option Evaluate script to retrieve the explicit cost assigned to the link; this would make situations where the cost have to tracked in a private unit stat for conditional testing much more "generic".
  
• Add new accrual context where every entity accrues tags upwards exactly ONE level; this allows items to accrue info only up to the containing unit, making it possible to easily write unit-specific rules that govern the assigned items.
  
• Add a new scope for rules that governs any entity and its immediate children only, allowing for a child unit to be treated as the "root" and only have all of the assigned items be included within the processed entities (equivalent of "tree").
  
• Add a new scope for rules that governs any entity and all of its children, allowing for a child unit to be treated as the "root" for processing.
  
• Allow scripts to iterate over the set of links attached to an entity (for example, to do something to N of the links on an entity at once); need to get the count of links to a given option id; need to transition context to the Nth link to a given option id (much like attachment iteration).
  
• Allow script-based control of the option name for pseudo-links, allowing an author to change the color (for example) of a magic item option selected from a list.
  
• Add "idtally" to the overall context, that does a tally that only targets entities with the specified id.
  
• Add support for arithmetic calculations within exclusion group limits, allowing for something like "# * 3" to set the limit as "3 times the model count".
  
• Add script target context to identify a specific link on a entity based on the link index instead of just the option id; this would allow explicit pinpointing of what link to apply a script effect to; might look something like "option[id:index].selection = 0".
  
• Allow author to specify the separator to be used between option summary entries for individual entities; allows the author to do funky things for items like Dwarf Rune items, which might be lengthy text for each.
  
• Have the selection or deselection of an option set the selection count for a different range-based option to a specified value (e.g. reset an option to zero when other options render it non-applicable).
  
• Add the ability to assign tag sets via overrides, so the entire tagset is added or not.
  
• Author can specify in definition file that any entities with a size of zero should have their size left blank within the roster; this eliminates confusion for users in situations where the entity count is specified on the parent unit and the child entity is just a placeholder to display a description for the entity (as is done in 40K files).
  
• Allow one entity to be designated to be always added to every squad created by AB; this would be similar to the auto-added units/items for races, but the unit/item would be added to every squad instead. This entity could potentially be "invisible" so that the user couldn't see it, but it could still (for example) run scripts or tally important values for the rest of the entities in the squad.
  
• Allow option "Cost" scripts to post-process the costs of child entities, with the final cost of the child entity being passed to the Cost script as a special symbol that can then be modified; the net cost adjustment must be propery applied to the accrued cost of units/items for the containing entity.
  
• Add support for wildcard handling in script target context - e.g. going children[tag template] to go through only a certain number of children.
  
• Allow linksets to reference other linksets in recursive fashion, allowing the author to break things down into small linksets that are then grouped via meta-linksets.
  
• When there are multiple entities in a squad, the order of their evaluation must be able to be controlled by the author, regardless of the order the user puts them in the squad; entities therefore need an evaluation priority that is used to control the order in which entities are evaluated.
  
• Add a script to entities that is performed after all Evaluation scripts for links but BEFORE all Cost scripts; call if "PostEval"; allows adjustments to be made by child entities that are needed by other links on the parent, without having to use options on the child entity to accomplish it.
  
• Add a hybrid between unit stat "finalize" and "calculate" scripts, that allows the generation of output that combines the values of other unit stats; for example, stat X displays the concatenated values of stats Y and Z; either the "calculate" script needs to operate on units in the Available grid or the "finalize" script needs to grant access to the other unit stats for inclusion.
  
• Allow rules to be defined directly on races, units, and items.

Phew, that's a lot of stuff. Please let me know if you have questions about anything, or if there are other common situations you encounter that you'd like us to look at.

Thanks!