Guest
Posts: n/a
|
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/bQ8...SFAA/IMSolB/TM ---------------------------------------------------------------------~-> |
#1 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 8,232
|
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/bQ8...SFAA/IMSolB/TM ---------------------------------------------------------------------~-> |
#2 |
Guest
Posts: n/a
|
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/txl...SFAA/IMSolB/TM ---------------------------------------------------------------------~-> |
#3 |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Suggestion: List items by order damaged | Bishop37 | HL - d20 System | 1 | March 14th, 2007 11:50 PM |
On items... | Bluefool | Army Builder | 8 | March 8th, 2006 10:26 AM |
Wish list items | mur at qtm.net | Card Vault | 1 | February 25th, 2005 01:23 PM |
Help on Items | pyro330 at hotmail.com | Army Builder | 3 | January 21st, 2004 03:26 PM |
Space Wolves list Assassins twice in Allies for Army list | B-Morgan at concentric.ne | Army Builder | 1 | October 16th, 2000 02:26 PM |