more wish list items

[drothman.dmth94 at gtalum]

rob -

I would _really_ like to have some subset of the following:
For items:
invs: and/or disp: and/or hide (e.g. let me determine whether the
item will be rendered on-screen, on-report, neither, or both)
improved and expanded version: permit such an implementation
mechanism to be toggled by environmentals (particularly unit type at
run-time). This might be implemented by #when. An alternative
implementation might be to provide a set of tweak attributes that
control the rendering of the parent item - thus permitting rich
semantics through existing tweak logical controls.

For Rendering:
consistency in rendering for comments, notes, and report output.
currently, the three sets of output operate differently in units,
items, options, tweaks, etc., etc. Particularly tiresome is the
inconsistent implementation of ^ (which I'll address next).

Also... can I have a line-break please? at the moment, semi-colon
does it in some places, but not others... It would also make tabular
output _so_ much easier (such as the spell lists from WFB)

For Maintainability:
Floating Text Blocks!! If there were an extension for the messages
mechanism that permitted the incorporation of text blocks into
comments/notes/report output THAT WAS CONSUMABLE BY ALL OBJECTS (e.g.
both _options_ and _items_ then a lot of overlap/multiple text
instances might be avoided, improving the
maintainability/orthogonalization of some data files (again, see the
WBF magic section, which must be a _bear_ to maintain...). A possible
implementation might be to have a special category of message
objects, with id's beginning with <& (in a manner similar to the x*
unit types). Any comment/note/report field could than include a
reference (with a trailing >), and "suck in" all the text from the
shared message. Example: messages <&foo defined as "rockin' common
text into uncommon places", and referenced as "my local object is
<&foo>"

and now back to retyping a few hundred entries, once as options, and
again as items <sigh>

daniel


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->

 

[rob]

At 07:34 PM 8/22/2001 +0000, you wrote:
>I would _really_ like to have some subset of the following:
>For items:
> invs: and/or disp: and/or hide (e.g. let me determine whether the
>item will be rendered on-screen, on-report, neither, or both)
>improved and expanded version: permit such an implementation
>mechanism to be toggled by environmentals (particularly unit type at
>run-time). This might be implemented by #when. An alternative
>implementation might be to provide a set of tweak attributes that
>control the rendering of the parent item - thus permitting rich
>semantics through existing tweak logical controls.

The AB engine is already highly complex. And most people's eyes cross when
they try to wrap their arms around the complexity already present. You must
truly be a sado-masochist, since adding this would be ugly for me AND ugly
for yourself if I can implement it.

Give me an idea of how "invs" would truly be useful for items. Same for
"disp". I can almost see where "hide" might be useful in rare
circumstances, but I'd appreciate a concreate example or two. I REALLY need
to understand how a complex set of rendering controls is going to make AB
vastly more useful. The more justification you can provide, the more likely
your requests get implemented.

>For Rendering:
>consistency in rendering for comments, notes, and report output.
>currently, the three sets of output operate differently in units,
>items, options, tweaks, etc., etc. Particularly tiresome is the
>inconsistent implementation of ^ (which I'll address next).

This is artifactual. When V1.0 was released three years ago, the scope of
comments, notes, and report output was quite limited. It was also very
distinct for each type of record. As AB evolved, the line began to blur.
However, AB has always provided 99.8% backwards compatability (I'm sure I
broke something along the way that I can't remember). That means that all
of the original (distinct and dissimilar) handling of the different record
types has needed to remain.

You will find that the behavior of comments, notes, and report output work
identically between options and tweaks. They also work VERY similarly to
units (I'm sure there are differences, but I honestly can't even think of
them at the moment). The big exception is items, which are utterly unique
unto themselves. I'm guessing from your other posts that the oddness of
items is what's really bugging you.

As for the inconsistent handling of "^", there are only two ways it's
handled. Normally, it's a literal character, except within items. For
items, it provides a means of inheriting the notes from the previous level,
which was intended as a means of minimizing data entry for data file
writers. This worked quite well for the WFB5 data files and a few others
from way back. As AB's engine has grown in sophistication, this has become
less used (if at all anymore). But again, the issue here is backwards
compatability.

>Also... can I have a line-break please? at the moment, semi-colon
>does it in some places, but not others... It would also make tabular
>output _so_ much easier (such as the spell lists from WFB)

In the old days, data file writers had to use ABData. Nowadays, few people
use it, but it is still valuable in some circumstances. However, since
ABData uses a tab/carriage-return delimited file structure, it doesn't work
to embed carriage returns within the data. The semi-colon was used to let
authors insert appropriate breaks, although some authors refused to bother
with semi-colens (Hi Colen!), so I had to make AB a bit more adaptive.
That's what has resulted in the less than optimal behaviors with
semi-colens in AB. :-(

It would be possible to introduce the notion of a line-break, but it can't
be a carriage return (since ABData would be hosed), so it would need to be
a character sequence that has never been used within an AB data file before
(remember backwards compatability!). Then everything within the AB engine
and output would have to be modified to support that special sequence. It
has never been a big enough need for the few people who have asked for it,
so it's never been a priority to implement, but it IS on the todo list.

>For Maintainability:
>Floating Text Blocks!! If there were an extension for the messages
>mechanism that permitted the incorporation of text blocks into
>comments/notes/report output THAT WAS CONSUMABLE BY ALL OBJECTS (e.g.
>both _options_ and _items_ then a lot of overlap/multiple text
>instances might be avoided, improving the
>maintainability/orthogonalization of some data files (again, see the
>WBF magic section, which must be a _bear_ to maintain...). A possible
>implementation might be to have a special category of message
>objects, with id's beginning with <& (in a manner similar to the x*
>unit types). Any comment/note/report field could than include a
>reference (with a trailing >), and "suck in" all the text from the
>shared message. Example: messages <&foo defined as "rockin' common
>text into uncommon places", and referenced as "my local object is
><&foo>"

That's an interesting idea that I never thought of. With all the data files
I've written, I've never run into a situation where I needed to duplicate
text across options and items for multiple records. Yes, there have been
the rare instance, but it was always a special case. I'll put this on the
todo list, since it's a cool idea.

>and now back to retyping a few hundred entries, once as options, and
>again as items <sigh>

What about copy and paste? It's still duplication, but it's not nearly as
bad as retyping things.

Thanks, Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development www.wolflair.com


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/M8mxkD/bQ8CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->

 

[demandred at skrill.org]

At 02:45 23/08/2001 -0700, you wrote:

>As for the inconsistent handling of "^", there are only two ways it's
>handled. Normally, it's a literal character, except within items. For
>items, it provides a means of inheriting the notes from the previous level,
>which was intended as a means of minimizing data entry for data file
>writers. This worked quite well for the WFB5 data files and a few others
>from way back.

Indeed, the 40k files use it a lot too.

>In the old days, data file writers had to use ABData. Nowadays, few people
>use it, but it is still valuable in some circumstances. However, since
>ABData uses a tab/carriage-return delimited file structure, it doesn't work
>to embed carriage returns within the data. The semi-colon was used to let
>authors insert appropriate breaks, although some authors refused to bother
>with semi-colens (Hi Colen!),

oi! I didn't refuse, I just forgot

And "semi-colens"? What a horrible thought, there's quite enough of me
already

>That's what has resulted in the less than optimal behaviors with
>semi-colens in AB. :-(

There you go again


--
Colen 'Skrillboy' McAlister, demandred@skrill.org
http://www.skrill.org/, http://www.incompetence-central.co.uk/
1 = 2, for large values of 1.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
The Nissan Sentra
Everything but compact
http://NissanDriven.com
http://us.click.yahoo.com/3vsIKC/txlCAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->