• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Data File Author Feedback Request on AB3

TheDaR said:
The other thing I've thought of is better error messages from the script compiler. 'Invalid use of reserved word in script' isn't a very helpful in terms of knowing what to fix. Even just adding the token which caused the error to that message would help a lot (Invalid use of reserved word "parent" in script) in narrowing down which context transition you messed up.

Now THAT is a great idea! I'd love to see this too.
 
I'd like to be able to italicize an option (using a name override) for some units, but have the option and description only appear once in the footnotes...

I guess what I'm asking for is that if an option name override is identical to the non-override name, except for the encoding, that it be treated as the exact same option in the footnotes.
 
At 07:06 PM 6/7/2005 -0400, you wrote:

>I'd like to be able to italicize an option (using a name override) for
>some units, but have the option and description only appear once in the
>footnotes...
>
>I guess what I'm asking for is that if an option name override is
>identical to the non-override name, except for the encoding, that it be
>treated as the exact same option in the footnotes.


This should already be happening? I thought we'd added this in v3.0b.
 
For the docs, maybe an order of action list which spells out specifically what happens when? For example (please don't correct this as I'm just BSing the list) Pre Link Global, Member, Cost, Post Link Global...That way we have a very quick and easy list to double check where priority happens...
 
Colen said:
>I guess what I'm asking for is that if an option name override is
>identical to the non-override name, except for the encoding, that it be
>treated as the exact same option in the footnotes.
This should already be happening? I thought we'd added this in v3.0b.

Hmm... Seems I didn't take enough notice when 3.0b came out... scrap that last request!
:oops: Sorry!
 
At 10:14 PM 6/7/2005 -0400, you wrote:
>For the docs, maybe an order of action list which spells out specifically
>what happens when? For example (please don't correct this as I'm just
>BSing the list) Pre Link Global, Member, Cost, Post Link Global...That way
>we have a very quick and easy list to double check where priority happens...

I hereby point you to the "Concepts" chapter of the existing docs
(kit_concepts.htm). Scroll down to near the bottom and you'll find the
topic "Evaluation Sequence". This walks you through the exact sequence in
which everything gets evaluated.

I realize that the documentation is lacking a lot of "why" and "how"
information, but it's not lacking on the crunchy bits. :-P

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
 
At 02:08 PM 6/7/2005 -0400, you wrote:
I've got some of these in my list. But I'd really love a list of topics
that YOU want to see addressed, since my list probably doesn't match your
list exactly.

Off the top of my head:
  • Naming conventions to make tracking options/entities easier
  • When to use costs on options versus on entities
  • Which scripts are best for calculating/testing various common things, when various ones can do the same thing (eval vs live, sizelimit vs postlink, etc)
Basically, some philisophical discussion of what the program's authors would do when confronted with various situations, knowing the program inside and out.
Hmmm. For the topics you list above, I'm not exactly sure what I could write. These three areas are SO subjective and SO dependent on the situation that they pretty much defy a deefinitive answer.

I'm including some suggestions on the selection of unique ids, but naming is such a personal thing. Something that is self-evident to one person might make no sense at all to someone else. The real key to naming is consistency. As soon as someone understands the rules you've used for naming, regardless of how strange those rules might seem, all the names start to make sense. Beyond that, I don't know what I could say in support of making the "tracking of names easier".

Whether to apply costs to options or entities is a very situational decision. I'm including some discussion on this, but the bottom line is really "it depends on the situation". I'll see what I can add regarding when it's better to use one approach over the other.

Deciding which script approach to use in a given situation is another classic "it depends". I'm including some suggestions, but each situation demands an independent evaluation. It also depends on what other factors are involved that need to be accommodated, since those can influence the solution used.

I guess the point I'm trying to make is that there are numerous ways to solve most problems in AB, and there will rarely be a definitive "right" way that can be identified. There will simply be "better" and "worse" solutions, but often times one solution might be better than another in some respects and worse in other respects. While I'll do my best to offer a lot of suggestions in the docs, don't get your hopes up that it will provide a definitive answer to everything. :-)

If you're going to be at GenCon this summer, definitely plan to go to our workshop on advanced AB data file writing. The entire focus of the workshop will be analyzing real situations and figuring out what works best. We'll also be available at the booth throughout the show to discuss solutions. And you can always post specific situations here. We'll be happy to offer suggestions if you want them. Just make sure to provide us with sufficient details about the game mechanics you're trying to model (since we aren't experts on every game).

Viewing (especially as a tool tip, something AB does very well overall) would be a very strong start.

I'd also be fine if following any unresolved links just popped up a dialog that said something like 'This link doesn't resolve in this file, would you like to (open another file) (create an option/entity in this file) (cancel)'. Those three options would pretty much solve 90% of the use cases I can think of; namely either wanting to switch to the link in the current datafile (most of the time), create a new option or entity as appropriate (most of the rest of the time), and on the very rare cases go to another file.
That's an excellent suggestion. Something concrete that we can probably do in a manageable chunk of time for a release. That's exactly the type of suggestion I was looking for!

The other thing I've thought of is better error messages from the script compiler. 'Invalid use of reserved word in script' isn't a very helpful in terms of knowing what to fix. Even just adding the token which caused the error to that message would help a lot (Invalid use of reserved word "parent" in script) in narrowing down which context transition you messed up.
Unfortunately, given the way the parser is written, this is a LOT harder than it sounds. Just adding something that seems simple like this would probably take me DAYS to put into place. It's all due to the parser design, which makes some things really convenient but others (like detailed error reporting) a real pain.

That being said, this is definitely something I want to improve upon. I'm just not sure how soon I can reasonably get it done.

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com)                                 (408) 927-9880
Lone Wolf Development                                      www.wolflair.com
 
rob said:
At 02:08 PM 6/7/2005 -0400, you wrote:
Hmmm. For the topics you list above, I'm not exactly sure what I could write. These three areas are SO subjective and SO dependent on the situation that they pretty much defy a deefinitive answer.

A discussion of what the trade-offs are would be fine. Basically, like with the Perl programming languages, when you have a tool like Army Builder which is so very flexible, it can sometimes be hard to get enough of a mental grasp of what the trade-offs even are. A few paragraphs on the merits of each would provide someone with enough foundation to be able to make a semi-informed decision about which is the best option for them.


rob said:
If you're going to be at GenCon this summer, definitely plan to go to our workshop on advanced AB data file writing. The entire focus of the workshop will be analyzing real situations and figuring out what works best. We'll also be available at the booth throughout the show to discuss solutions. And you can always post specific situations here. We'll be happy to offer suggestions if you want them. Just make sure to provide us with sufficient details about the game mechanics you're trying to model (since we aren't experts on every game).

I'd love to be at GenCon, sadly it's not in the time or money budget this summer. :(

That said, you guys have been very good about answering questions here, certainly.

rob said:
Unfortunately, given the way the parser is written, this is a LOT harder than it sounds. Just adding something that seems simple like this would probably take me DAYS to put into place. It's all due to the parser design, which makes some things really convenient but others (like detailed error reporting) a real pain.

That being said, this is definitely something I want to improve upon. I'm just not sure how soon I can reasonably get it done.

I don't know if you built your parser and interpreter with yacc/bison, but if you did, even turning on YYDEBUG would be a big help.

That said, in the long run, I'd like to see a script interpreter which was a little more 'standard' and powerful. There are a couple of really good options out there that are fairly easy to integrate and from my (still limited) perspective seem like they could fit into the AB datamodel pretty well. Lua is the first one that springs to mind, as it has some features that make it absolutely ideal for building an embedded scripting language which extends an application's datamodel. Python could also work well. Hell, I'd settle for VBA or something similar, given AB is pretty strictly a Windows app.

But that's obviously a ways down the road, if it gets done at all.

-DaR
 
Ok, so I think I've discovered one of my biggest problems with the docs...I'm able to speak English and that's about it :P ...
I found the list but it's things like "Invoke any Evalonce option script, applying all changes" that leave me scratching my head in confusion...While I understand that high level programmers are the primary targets for creating Data files there are some of us who only have more basic levels of programming in our backgrounds...

Oh, and the other big problem is confusion in finding things in the docs...I think it needs a better index...I wouldn't have even begun to guess where to look for an evaluation sequence...Also now that I've found it, the ability to cross refference an index for the word "Evalonce" would probably go a long ways to solving my technical deficiencies...
 
You'll find the details of all scripts defined in the chapter entitled
"Script API" (kit_api.htm). You can access all the script-related material
via the "Scripting" link on the main page of the Kit manual.

Unfortunately, the EvalOnce script was dropped near the end of development
on V3.0, and I forgot to remove it from the evaluation sequence. There is
only one Evaluation script now for options. I'll get that fixed.

I guess I don't understand what's confusing about the statement "Invoke
Script X once, applying any changes". That translates to the following in
my mind: "ScriptX gets invoked and any changes it triggers are applied".
That's all that gets done in the engine, so what more detail do you want on
this?

With the documentation overhaul, I'm going to do a better job of getting
links into place. With regards to an index, I have no idea what the best
solution is. Creating and maintaining an index by hand is prohibitive. If
someone wants to identify a tool that will take a set of webpages and
generate a unified index for them, I'd love to hear about it. Beyond that,
better cross-links between pages may have to suffice.

-Rob

At 06:50 PM 6/8/2005 -0400, you wrote:

>Ok, so I think I've discovered one of my biggest problems with the
>docs...I'm able to speak English and that's about it ...
>I found the list but it's things like "Invoke any Evalonce option script,
>applying all changes" that leave me scratching my head in
>confusion...While I understand that high level programmers are the primary
>targets for creating Data files there are some of us who only have more
>basic levels of programming in our backgrounds...
>
>Oh, and the other big problem is confusion in finding things in the
>docs...I think it needs a better index...I wouldn't have even begun to
>guess where to look for an evaluation sequence...Also now that I've found
>it, the ability to cross refference an index for the word "Evalonce" would
>probably go a long ways to solving my technical deficiencies...


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
 
rob said:
Unfortunately, the EvalOnce script was dropped near the end of development on V3.0, and I forgot to remove it from the evaluation sequence. There is only one Evaluation script now for options. I'll get that fixed.

THAT'S why it looked like just so many letters thrown together to me... :oops:

I guess I don't understand what's confusing about the statement "Invoke
Script X once, applying any changes". That translates to the following in
my mind: "ScriptX gets invoked and any changes it triggers are applied".
That's all that gets done in the engine, so what more detail do you want on
this?

To be honest one word you don't recognize can throw an entire sentence into confusion...And when that sentence is integral to the method that can throw an entire section into confusion...The point of this particular one was that the Evalonce (oh and the "O" isn't caps, the word also made more sense when I saw that in your post as an "o" in the middle of a word is pronounced differently then at the begining)...Once I know about that it's a (now gone) script the context comes to light...

With the documentation overhaul, I'm going to do a better job of getting
links into place. With regards to an index, I have no idea what the best
solution is. Creating and maintaining an index by hand is prohibitive. If
someone wants to identify a tool that will take a set of webpages and
generate a unified index for them, I'd love to hear about it. Beyond that,
better cross-links between pages may have to suffice.

A localized search engine that has a specified set of files or only searches text files (since that's really all html and xml files are) in a given sub/folder? Not having programming expirience much higer then C+ I don't know how difficult that is...I've tried using the search feature of my browser but it automatically goes to the web...
If someone else has the search capabilities on their browser they could possibly create an index (so as to pull some of the workload off you guys)...
 
The ability to mark a unit as being unique to an entire roster . . . easily.
This would be so nice. Just "Unique Unit?" "Yes/No" :wink:
Then, the user could only take that unit one time in the roster, having that unit "greyed-out" in the top list of units would be real cool too.

Cheers guys!
Butcher
 
another one ...

to be able to alter min and max for a unit from the global script sections or prelink script section.

Some in game options, i.e. kill team, allow the user to alter the min and max numbers in a squad but the change in the game rule applies to all the squads etc.

Instead of using an override for each unit, then the entity start via possibly the existing count[maximum] and count[minimum] to become read/write instead of read only.

This should save a significant amount of replication of overrides and unit changes.

thanks
 
Landscape printing seems to be missing - at least I can't get a print preview in landscape mode...

Two of the game systems I wrote data files for in ABv2 used to default to landscape mode - and the users liked it... :D

Russell.
 
and another ...

make mirroring more flexible if poss. Currently you can mirror in a linkset option setting to the state of the parent selection with the nature set to auto.

However if there was a way that the user could still select that option independantly of the parent selection, but if the parent selection state changed, this did not impact the user selection on the child. Maybe this could be achieved by adding an combo box similar to the parentreq option.

As a game example the possessed marines in chaos 40K have a list of 5 gifts they can choose from the main list of about 12. Every member of the squad must have the same gift, so the squad champion who is an upgraded squad member must also have the same gift. However the champion can choose from the whole list of 12 gifts, so for instance a user may select daemonic fire for the champion and speed for the squad, the champion then gets both. But the squad can have speed instead, which would then result in the champion having it selected twice.

Currrently, with the option linkset set to auto, the user cannot select for the champion one of the gifts of the list the squad may have. Hopefully this makes sense - I have now got a work around but it can get a bit messy as well as quite a bit of script.
 
OK, I'm going to need this one explained to me. Please lay out the
pertinent game mechanics for me in further detail so that I can either (a)
suggest a good way of solving things or (b) try to figure out what we need
to add/change so that we can add a good solution.

-Rob

At 03:32 PM 6/14/2005 -0400, you wrote:

>another one ...
>
>to be able to alter min and max for a unit from the global script sections
>or prelink script section.
>
>Some in game options, i.e. kill team, allow the user to alter the min and
>max numbers in a squad but the change in the game rule applies to all the
>squads etc.
>
>Instead of using an override for each unit, then the entity start via
>possibly the existing count[maximum] and count[minimum] to become
>read/write instead of read only.
>
>This should save a significant amount of replication of overrides and unit
>changes.
>
>thanks


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com
 
rob said:
OK, I'm going to need this one explained to me. Please lay out the
pertinent game mechanics for me in further detail so that I can either (a)
suggest a good way of solving things or (b) try to figure out what we need
to add/change so that we can add a good solution.

-Rob

Within the standard 40K 'game rules' each game squad has a start number of members and a maximum number, i.e. slugga boyz in orks start at 10 with a max of 30 orks in the squad.

Kill team is a subset of the main 'game rules' where the game squad numbers change to 5 to 12 for every squad, so the slugga boyz start at 5 and have a max of 12 orks in the squad.

The player can then disregard another one of the kill team game rules to allow them to have any number of orks in the squad, so the slugga boyz would be start at 1 and then upto anything of 20 (-ish).

When the ruleset sc_kill is enabled, all the units need to have the min and max changed to be min 5, max 12, however if the user doesn't select the ruleset for the standard squad numbers, i.e. kl_mut3, then all the units min and max change to be min 1, max 20.

Instead of doing this via an override for each and every unit, if a script within entity start that checks for the rulesets and then ammends the min and max, i.e

if (tagis[ruleset.sc_kill] =1) then

if (tagis[ruleset.kl_mut3] = 0) then

@min = 1
@max = 20
else

@min = 5
@max = 12
endif

endif

does that make a bit more sense?
 
Also in WFB there is a separate ruleset (or eventually there will hopefully be) for Warbands rules...Similar to "Kill Team" the minimum unit size for infantry is 3, minimum for cavalry is 2 and minimum for monsters is 1...the maximums don't change...

Adding this ruleset would still require giving every non-character unit in the game an additional tag but it's conciderably easier to add a tag then add size script...at least if you're predominantly using ABC instead of .txt coding...

(Of course there are many other changes in Warbands but those are easier to do on a unit by unit basis)
 
I'd like to be able to change the text format of a stat based on the selection state of an option assigned to the unit.
Access to option.selection from the finalize script perhaps?

Why?
For Necromunda, I'd like to highlight all the stats that have been modified by model "advances" so they stand out on the printed roster... The advances are taken by increasing the selection count of ranged options, so if the ranged option selection count is greater than 0, I want to bold the stat...
 
Yop,

On the item/unit selection window :

- Ability to highlight (change color, bold...) some of the items to be selected. It must be controlable via tags (higlight only if group.validtag)
Example :
for Confrontation and Rag'Narok, some priests/mage may take only one miracle/spell + a specific one, or one from thoses who are exclusively reserved for him. The aim is to identify in the list those special ones. For all others priests/mage the item must not be highlighted.

- Possibility to add a comment on this window : Display on this window the stat which define how many and which spell you may take. (the option I used to display it is hidden by this window.)

- Possibility to move the selection window to consult the army list while choosing a unit/item.

- Possibility to get the description of a unit/item/option from the availlable list or army list while the selection window is open.

- Controll the size of the name column.
- Controll the size of the description area.
- Choose a different name for the window for each option.


General:
- Change ALL the texts via overrides (especialy items/units summaries, and option texts.) It is very usefull for translation.
- Special Text Encoding for all names/description/summary.
- More option categories.
- Know exactly which kind of change in the data files make the old rosters unable to be reloaded. (to be able to inform the users if he has to load the old package if he want to load an old .rst file.)

Licencing:
- Get a tag depending if AB has a license or not. (I have special behavior on some units to be formated for one of my output extension. There is no need of it in shareware mode) Either, I would like to hide some descriptions in shareware mode (Game editor ask me to try it, if it is possible...)

- Possibility to call an output extension even in shareware mode giving only 'text summary' (or something like it whithout any id/links... I would prefer XML) which make it impossible to generate a .rst file from it. The purpose is to provide a French extension for example, or a forum preformated file with only few infos. I begun to program it outside of AB, but it would be better inside AB.


Garfunkel
 
Back
Top