Formatting Change to the WG

[Simon]

OK...I'm working on implementing the changes to bring HD more in line with the Writer's Guidelines. I'm going off of the list of deviations that Durnin posted. Durnn's original post is <a href="http://www.herogames.com/forums/showthread.php?s=&threadid=1006#post32043" target="new">here</a>.

As I go through the list, I'm going to have some comments on a few of the items. I'll post them here.

<hr>

To begin with:


"Energy Blast ------ Can be expressed as EB; don't include versus (USER)"

The versus will continue to be included by HD. It's valuable information (IMO) and, if anything, the WG should be changed to include it.

In general, I'm assuming that the items marked "USER" are things that the user needs to account for.

[Simon]

Linked ------ I'm not sure about how Steve wants this, but from what I can figure out, the limitation doesn't have any text, but if it does it should be in the parentheses with the value

Linked will stay the way it is, as it's more readable this way and gives what should be required information on the Limitation (i.e. what it is Linked to).


Multipower ------ For limitation list there should not be a colon after "all slots" or list the active points for the slots; after #) for slot there should be two spaces unless it is a double digit
The colon will remain after all slots, as there will be new functionality coming in v2 which will make this, if not required, strongly recommended.

The Active Points will be remaining as well, as it is very useful information for an MP slot. v2 will likely allow you to specify whether you want it to display or not.

[Talon]

I'd like to put in another huzzah for the possibility of using the WG abbreviations for things like NND, RKA, etc. Yes, I know you can hand-edit them at present, but that's time consuming, especially when you are loading characters from a pack.

[Simon]

Originally posted by Geoff Speare
I'd like to put in another huzzah for the possibility of using the WG abbreviations for things like NND, RKA, etc. Yes, I know you can hand-edit them at present, but that's time consuming, especially when you are loading characters from a pack.

That won't be changing. For the simple reason of ease of use. In order for that to change, the primary display of the abilities would need to change and, contrary to popular belief, not all newbies are fluent in the numerous abbreviations and acronyms in use in the Hero System.

Things like that are going to continue to be up to the user to edit when they're constructing the ability.

[Simon]

_General ------ Rolls should not be inside parentheses

The only rolls (to my knowledge) that are in parentheses are the secondary values for rolls (i.e. "Acrobatics 11- (15-)"). Those will remain that way, as there is no discussion of primary/secondary values in the WG and the current notation keeps them "clear".

[Simon]

_General ------ (added to XXXX Value) should not be included

Like rolls (above), there is no discussion/treatment of primary and secondary values in the WG. The text "added to XXX value" will remain as it is necessary for clarity, given the fact that we are using different means of totaling.

To give a very easy example, if you're looking at a character sheet without that notation, and there are two purchases of Armor, one added to the primary value, one not added to the totals at all, you have no way of knowing which is which without the note "Added to XXX value"

[Simon]

Age ------ Should be two separate lines, one for Age the other for Normal Characteristic Maxima

Because of the way Age and NCM are treated in HD, this is one that will not be changing....at least not in the forseeable future.

The "different" treatment of Age and NCM is something which I talked with Steve about during the implementation. It makes the use of those two disads substantially easier/more straightforward than they would have been otherwise.

[Simon]

Distinctive Features ------ Descriptors should be inside parentheses (USER), no comma after the description

DNPC ------ Name can be DNPC or spelled out (USER); format should be: DNPC: Name (who is) roll- (Type); descriptor after roll should not be there (USER); switch (Type) and roll.

Hunted ------ Format should be: Hunted: Name roll- (no description of roll) (Capabilities (Powerful as Pow, More as Mo), NCI, Limited Geographical Area (if appropriate), What Hunter Wants To Do) (USER for some, not the order)

Psychological Limitation ------ Frequency and Intensity inside parentheses (USER) No comma after Limitation

Reputation ------ No description on the roll (USER); no parentheses around roll.

Social Limitation ------ Frequency and affect should be in same parentheses (USER)

For all of these, because of the way Disads are handled in the system, there won't be any change. Disadvantages were a "generic" enough object that they were coded into the system in such a way as to allow complete freedom in their design. Users can create new disads, delete existing disads, change existing disads, etc. The price of this freedom is that disads are generalized....you can't change the formatting for specific disads as the system has no idea what disad it's working with at any given time (nor does it care).

[Simon]

Focus ------ Name of focus, if not apparent, needs to be in parentheses with the value (USER sort of); Bulky, Fragile, etc should follow right after OAF, etc.

This is the way Focus works. If the focus has a "name" then it is up to the user to type it in and to format it correctly. Bulky, Fragile, etc. are placed immediately after the "name" (normally just OAF, or whatever).

[Simon]

Killing attacks ------ List as HKA or RKA; don't include what it is versus (USER)
See my note on Energy Blast (above). I view this to be very useful information which is a vital part of the Power definition and will be leaving it in place.

[Simon]

Persistent ------ Has an extra space after it

Errr...no it doesn't.

[rjcurrie]

Originally posted by dsimon
That won't be changing. For the simple reason of ease of use. In order for that to change, the primary display of the abilities would need to change and, contrary to popular belief, not all newbies are fluent in the numerous abbreviations and acronyms in use in the Hero System.

Things like that are going to continue to be up to the user to edit when they're constructing the ability.

This is probably a version 2 thing and not something that can be done right now, but what about adding an ABBREVIATION attribute to the various Power containers which could specify the abbreviated version of a power name if one exists and including on a toggle on whatever "control panel" you implement that turns on and off whether abbreviations are used in Power descriptions.

Just a thought,

Rod

[rjcurrie]

Originally posted by dsimon
Like rolls (above), there is no discussion/treatment of primary and secondary values in the WG. The text "added to XXX value" will remain as it is necessary for clarity, given the fact that we are using different means of totaling.

To give a very easy example, if you're looking at a character sheet without that notation, and there are two purchases of Armor, one added to the primary value, one not added to the totals at all, you have no way of knowing which is which without the note "Added to XXX value"

Again, this is something that you should have the option of turning off in v2.

Rod

[rjcurrie]

Originally posted by dsimon
Because of the way Age and NCM are treated in HD, this is one that will not be changing....at least not in the forseeable future.

The "different" treatment of Age and NCM is something which I talked with Steve about during the implementation. It makes the use of those two disads substantially easier/more straightforward than they would have been otherwise.

Perhaps I'm missing something but I fail to see why it would be so hard to add two Disads instead of one based on the NCM/Age information on the Characteristics tab.

Rod

[rjcurrie]

Originally posted by dsimon
This is the way Focus works. If the focus has a "name" then it is up to the user to type it in and to format it correctly. Bulky, Fragile, etc. are placed immediately after the "name" (normally just OAF, or whatever).

Currently, you cannot enter the name for a focus and format it properly. It sould read something like:

OIF (widget; -1/2)

or

OIF Bulky (big widget; -1/2)

Rod

[rjcurrie]

Originally posted by dsimon
See my note on Energy Blast (above). I view this to be very useful information which is a vital part of the Power definition and will be leaving it in place.

Like many other things, the display of the "vs PD/ED" should become optional in v2.

Rod

[rjcurrie]

Originally posted by dsimon
For all of these, because of the way Disads are handled in the system, there won't be any change. Disadvantages were a "generic" enough object that they were coded into the system in such a way as to allow complete freedom in their design. Users can create new disads, delete existing disads, change existing disads, etc. The price of this freedom is that disads are generalized....you can't change the formatting for specific disads as the system has no idea what disad it's working with at any given time (nor does it care).

I seriously hope you are looking at changing this approach in v2. Currently, I find the format of Disads produced by HD to be quite unreadable.

I don't see why you couldn't add a FORMAT attribute to the current DISADVANTAGE tag that would specify the generic format for the disad and where in that format to place the values of the Disadvantage fields/options when filled out. If no FORMAT attribute is present, then the current generic (and ugly) format would be used.

Rod

[Simon]

Originally posted by rjcurrie
This is probably a version 2 thing and not something that can be done right now, but what about adding an ABBREVIATION attribute to the various Power containers which could specify the abbreviated version of a power name if one exists and including on a toggle on whatever "control panel" you implement that turns on and off whether abbreviations are used in Power descriptions.

Just a thought,

Rod

There's a couple of ways that I can handle it....but for now it's going to remain the way it is. Whether it is changed for v2 or not has yet to be seen.

[Simon]

Originally posted by rjcurrie
Again, this is something that you should have the option of turning off in v2.

Rod

Again, possible, but I have no definite plans for this at this time. We'll see what happens as development moves forward.

[Simon]

Originally posted by rjcurrie
Perhaps I'm missing something but I fail to see why it would be so hard to add two Disads instead of one based on the NCM/Age information on the Characteristics tab.

Rod

You are missing something.

[Simon]

Originally posted by rjcurrie
Currently, you cannot enter the name for a focus and format it properly. It sould read something like:

OIF (widget; -1/2)

or

OIF Bulky (big widget; -1/2)

Rod

I'll look into it, but I don't think that this will be changing at this point.

[Simon]

Originally posted by rjcurrie
Like many other things, the display of the "vs PD/ED" should become optional in v2.

Rod

Perhaps...but doubtful. Users that don't want it to display should just clear the text from the "vs." field in the edit window.

[Simon]

Originally posted by rjcurrie
I seriously hope you are looking at changing this approach in v2. Currently, I find the format of Disads produced by HD to be quite unreadable.

I don't see why you couldn't add a FORMAT attribute to the current DISADVANTAGE tag that would specify the generic format for the disad and where in that format to place the values of the Disadvantage fields/options when filled out. If no FORMAT attribute is present, then the current generic (and ugly) format would be used.

Rod

It may be changed for v2. I haven't decided yet. A "FORMAT" tag is not feasible, as it would entail an entirely new construct for how to specify the contents of the tag in relation to the other components that make up the Disad.

[rjcurrie]

Originally posted by dsimon
Perhaps...but doubtful. Users that don't want it to display should just clear the text from the "vs." field in the edit window.

Cool. I hadn't realized that. You learn something new every day.

Rod

[rjcurrie]

Originally posted by dsimon
It may be changed for v2. I haven't decided yet. A "FORMAT" tag is not feasible, as it would entail an entirely new construct for how to specify the contents of the tag in relation to the other components that make up the Disad.

Yeah, it probably would. But I fail to see why that makes it unfeasible.

I personally think that the ability to produce character sheets that meet the WG requirements and look like those that appear in Hero books should be one of the priorities of version 2.

[RPMiller]

So Dan,
Will you be implementing any of the formatting changes?
We are talking about Strings being put together in a certain order and concatenating punctuation into these strings correct?
I never realized how restrictive Java and XML are. Is the difficulty coming from the WG, or is it the DOM that you have created? Err... is there such a thing as DOM for XML? As I said, I'm just getting started...

[Simon]

Originally posted by Durnin
So Dan,
Will you be implementing any of the formatting changes?
We are talking about Strings being put together in a certain order and concatenating punctuation into these strings correct?
I never realized how restrictive Java and XML are. Is the difficulty coming from the WG, or is it the DOM that you have created? Err... is there such a thing as DOM for XML? As I said, I'm just getting started...

The difficulty in many areas is that the system needs to be flexible. It needs to be easily editable by the end user so that they can customize it to create whatever house rules they want.

As it is, many of the formattting items have already required me to make assumptions about the structure of various abilities (Languages, for example, can never be based off of a Characteristic and given a roll).

I've gone through your list and, wherever possible, made changes to the system to implement the correct formatting. The brunt of this work was in going through the entire system and putting 2 spaces after every colon that is ever used (except for KS, PS, AK). I tweaked the output of any of the specific items (mainly Powers, Skills, etc.) to work out the discrepancies that you noted.

However, there are some areas that will remain up to the user to fix or which will simply not be fixed in the interest of maintaining flexibility in the app. These have been noted above.

For those of you griping about it, get over it. You are the minority. I <b>WILL NOT</b> sacrifice the flexibility of the app in order to tweak it into place for the WG. The WG is a rigid specification that does not take into account the flexibility that you folks demanded for HD. I will bring the app as close as I can to the WG without sacrificing flexibility. Beyond that, you're on your own. Perhaps Steve will modify the WG one day to bring it more inline with the application.

[Simon]

Originally posted by rjcurrie
Yeah, it probably would. But I fail to see why that makes it unfeasible.

I personally think that the ability to produce character sheets that meet the WG requirements and look like those that appear in Hero books should be one of the priorities of version 2.

Because it's a minor issue that I'm not willing to create that level of complexity to work around. You'll just need to deal with it.

[RPMiller]

Originally posted by dsimon
<SNIP>
I've gone through your list and, wherever possible, made changes to the system to implement the correct formatting. The brunt of this work was in going through the entire system and putting 2 spaces after every colon that is ever used (except for KS, PS, AK). I tweaked the output of any of the specific items (mainly Powers, Skills, etc.) to work out the discrepancies that you noted.
<SNIP> I look forward to seeing what you have done. I will await the next update before continuing forward with my next macro. It is apparent that I'm still going to have to do some reformatting, but hopefully the strictures that were major hurtles will be gone, and my macro will be able to walk through the output and get it even closer to the WG.

Honestly, I haven't gone through each of your entries above. I'm waiting to see what you have done to compare our observations. I hope that you read the part in my message containing 'the list' that it was only a partial list currently, but I'm hoping that the changes you implimented will take care of others that I didn't write down.

I think the most difficult formatting to deal with has been the disadvantages. So, I'm eager to see the changes there. Thanks again Dan!

[Simon]

You may want to read above, then....there aren't going to be many changes in the Disads....for the reasons noted.

[RPMiller]

Originally posted by dsimon
<SNIP>In general, I'm assuming that the items marked "USER" are things that the user needs to account for. That is correct according to my original message.

[RPMiller]

Originally posted by dsimon
Linked will stay the way it is, as it's more readable this way and gives what should be required information on the Limitation (i.e. what it is Linked to).


The colon will remain after all slots, as there will be new functionality coming in v2 which will make this, if not required, strongly recommended.

The Active Points will be remaining as well, as it is very useful information for an MP slot. v2 will likely allow you to specify whether you want it to display or not. Fair enough.

[RPMiller]

Originally posted by dsimon
The only rolls (to my knowledge) that are in parentheses are the secondary values for rolls (i.e. "Acrobatics 11- (15-)"). Those will remain that way, as there is no discussion of primary/secondary values in the WG and the current notation keeps them "clear". All the rolls that have parentheses are in the disadvantages section.

[RPMiller]

Originally posted by dsimon
Like rolls (above), there is no discussion/treatment of primary and secondary values in the WG. The text "added to XXX value" will remain as it is necessary for clarity, given the fact that we are using different means of totaling.

To give a very easy example, if you're looking at a character sheet without that notation, and there are two purchases of Armor, one added to the primary value, one not added to the totals at all, you have no way of knowing which is which without the note "Added to XXX value" Agreed, I think it is useful as well, however there should be a way to exclude it if possible (Version 2?)
===============================
As a side note, have you ever found out why Steve wrote the WG as he did? There are some inconsistances that from Technical Writer position bother me. I'm just curious. It seems to me that Steve is depending on Players' assumptions quite a lot.

[RPMiller]

Originally posted by dsimon
Because of the way Age and NCM are treated in HD, this is one that will not be changing....at least not in the forseeable future.

The "different" treatment of Age and NCM is something which I talked with Steve about during the implementation. It makes the use of those two disads substantially easier/more straightforward than they would have been otherwise. I asked Steve about this as well. He was adament that they be two seperate disadvantages as stated in FREd.
No suggestions or ideas on how to fix this. I guess I'll try to have a macro break it into two pieces.

[RPMiller]

Originally posted by dsimon
For all of these, because of the way Disads are handled in the system, there won't be any change. Disadvantages were a "generic" enough object that they were coded into the system in such a way as to allow complete freedom in their design. Users can create new disads, delete existing disads, change existing disads, etc. The price of this freedom is that disads are generalized....you can't change the formatting for specific disads as the system has no idea what disad it's working with at any given time (nor does it care). Ok, I was with you until this reply. I hazard to point out that we are discussing formatting again. The disadvantages' content is correct, and I totally agree that they are customizable and general, however the order that HD puts the bits and pieces is just wrong.

The WG is consistant with regards to the Disadvantages and the order of the different parts. i.e. rolls come right after descriptions, commonality/frequency comes after that, etc. What HD does is output everything in the wrong order. I can easily put in parantheses as needed no complaint there, but to then have to reorder everything seems to be excessive. Are you saying that the individual parts can't be output in a different order? That doesn't sound very flexible or generic to me.

[RPMiller]

Originally posted by dsimon
This is the way Focus works. If the focus has a "name" then it is up to the user to type it in and to format it correctly. Bulky, Fragile, etc. are placed immediately after the "name" (normally just OAF, or whatever). I think you may have it a little backwards. The Bulky, Fragile, etc. comes after the abbreviation but before the name per the WG.

[RPMiller]

Originally posted by dsimon
See my note on Energy Blast (above). I view this to be very useful information which is a vital part of the Power definition and will be leaving it in place. Agreed again, and no problem as far as I'm concerned. As I originally stated it would be nice if HD did end user settings in a config box or something, but this item is low priority.

[RPMiller]

Originally posted by dsimon
Errr...no it doesn't. Oops, my bad! I guess that was an error when cleaning up the output. Sorry.

[RPMiller]

Originally posted by dsimon
You may want to read above, then....there aren't going to be many changes in the Disads....for the reasons noted. Ok, done... shwoo... I'm still very much looking forward to any changes that you have/will implement. I honestly think that you can only make it better!
Keep up the great work, and I appreciate everything you are doing regarding my points, and I will do what I can to clean up the output via macros and such.

[Talon]

Originally posted by dsimon
Perhaps...but doubtful. Users that don't want it to display should just clear the text from the "vs." field in the edit window.

This works...but it's highly impractical to do for large quantities of villains.

Given that the WG and published products make significant use of abbreviations, and given that shortening item text can make a huge difference on a character sheet, I'd hope that v2 would include a "use abbreviations" feature that would incorporate a lot of the suggestions in this thread. Perhaps I'm wrong, but I suspect a large group of people would appreciate this feature.

[Simon]

Originally posted by Geoff Speare
This works...but it's highly impractical to do for large quantities of villains.

Given that the WG and published products make significant use of abbreviations, and given that shortening item text can make a huge difference on a character sheet, I'd hope that v2 would include a "use abbreviations" feature that would incorporate a lot of the suggestions in this thread. Perhaps I'm wrong, but I suspect a large group of people would appreciate this feature.

And an even larger group would rather have it in, I believe. It is useful, perhaps even vital, information about a Power. You MUST know what defense an EB acts against.

If you don't like it, then clear it out.

[RPMiller]

Originally posted by Geoff Speare
This works...but it's highly impractical to do for large quantities of villains.

Given that the WG and published products make significant use of abbreviations, and given that shortening item text can make a huge difference on a character sheet, I'd hope that v2 would include a "use abbreviations" feature that would incorporate a lot of the suggestions in this thread. Perhaps I'm wrong, but I suspect a large group of people would appreciate this feature. Geoff, can you email me off-list? I was wondering if you can change two things on your RTF -WG Export template.

[Simon]

Originally posted by Durnin
Ok, I was with you until this reply. I hazard to point out that we are discussing formatting again. The disadvantages' content is correct, and I totally agree that they are customizable and general, however the order that HD puts the bits and pieces is just wrong.

The WG is consistant with regards to the Disadvantages and the order of the different parts. i.e. rolls come right after descriptions, commonality/frequency comes after that, etc. What HD does is output everything in the wrong order. I can easily put in parantheses as needed no complaint there, but to then have to reorder everything seems to be excessive. Are you saying that the individual parts can't be output in a different order? That doesn't sound very flexible or generic to me.

I believe that I had misunderstood what you were looking for, then.

I've done what I can with the Disads. Check out the current update (1.25) to see. They're much closer to the WG now. There are still some discrepancies, but those are due to inconsistencies in the WG and there's really nothing that I can do about them at this time.

[RPMiller]

Originally posted by dsimon
And an even larger group would rather have it in, I believe. It is useful, perhaps even vital, information about a Power. You MUST know what defense an EB acts against.

If you don't like it, then clear it out. Dan and Geoff,
I keep hearing Dan saying that "a larger group" this or "a majority" that, but I never hear contrary to our suggestions from anyone but Dan. In fact, more people pipe in about making it per the WG.
I'm not trying to start a "let's attack Dan campaign" because I think that what Dan has done has been exceptional and his support is truly incredible, but I am curious about who the large majority is Dan refers to. Could we start a simple poll or something to see?
I have been involved with many projects over the years, and more often than not the Beta teams and pilot groups have been poorly chosen regarding what the majority is looking for, and I have a sneaky suspicision that that may be the case here as well given the majority of comments that I have read on the boards.
I need to reiterate, I DO NOT WANT A FLAME THREAD AGAINST DAN. He works very hard, and deserves a professional discussion no matter what might be on people's mind.

[Simon]

Originally posted by Durnin
Dan and Geoff,
I keep hearing Dan saying that "a larger group" this or "a majority" that, but I never hear contrary to our suggestions from anyone but Dan. In fact, more people pipe in about making it per the WG.
I'm not trying to start a "let's attack Dan campaign" because I think that what Dan has done has been exceptional and his support is truly incredible, but I am curious about who the large majority is Dan refers to. Could we start a simple poll or something to see?
I have been involved with many projects over the years, and more often than not the Beta teams and pilot groups have been poorly chosen regarding what the majority is looking for, and I have a sneaky suspicision that that may be the case here as well given the majority of comments that I have read on the boards.
I need to reiterate, I DO NOT WANT A FLAME THREAD AGAINST DAN. He works very hard, and deserves a professional discussion no matter what might be on people's mind.

A poll won't work terribly well.....the "majority" that I speak of are the normal, day to day users of HD. Not many of them know or care about the WG. Most of them are probably simply ignoring this thread to begin with. More power to them, if you ask me.

This subject isn't open for discussion. I will work to bring HD as close as I can to the WG, but I will not sacrifice flexibility or customization to accomplish this. There are areas in which the WG will either have to change, or simply be in disagreement with HD.

Nor am I willing to "overcomplicate" the app to bring it closer to the WG. As for what amounts to "overcomplication" that is for me to decide.

[RPMiller]

Originally posted by dsimon
A poll won't work terribly well.....the "majority" that I speak of are the normal, day to day users of HD. Not many of them know or care about the WG. Most of them are probably simply ignoring this thread to begin with. More power to them, if you ask me.

This subject isn't open for discussion. I will work to bring HD as close as I can to the WG, but I will not sacrifice flexibility or customization to accomplish this. There are areas in which the WG will either have to change, or simply be in disagreement with HD.

Nor am I willing to "overcomplicate" the app to bring it closer to the WG. As for what amounts to "overcomplication" that is for me to decide. First, let me apologize. I didn't mean to imply or sound like I was making demands or anything. I was in a bit of a rush when I wrote my last reply. I was saying it for your benefit. In other words, to help you better identify and target your market. It sounds like you already know who your market is, and hopefully get plenty of feedback from them as well.
Second, I took a look at version 1.25, and I would like to be the first in line to say "DAN SIMON, YOU ROCK!!!!":D
I am very impressed with the changes you have made, and even though I only had a minute or two to look at it I was pleased with everything you have done. Thank you very much for your understanding and the rantings of myself and others. Great Job Dan!!

[Simon]

Originally posted by Durnin
First, let me apologize. I didn't mean to imply or sound like I was making demands or anything. I was in a bit of a rush when I wrote my last reply. I was saying it for your benefit. In other words, to help you better identify and target your market. It sounds like you already know who your market is, and hopefully get plenty of feedback from them as well.
Second, I took a look at version 1.25, and I would like to be the first in line to say "DAN SIMON, YOU ROCK!!!!":D
I am very impressed with the changes you have made, and even though I only had a minute or two to look at it I was pleased with everything you have done. Thank you very much for your understanding and the rantings of myself and others. Great Job Dan!!

No need to apologize...you've been coming across fine. I just wanted to make my position on this issue very clear.

The list that you posted was extremely helpful. As you find more discrepancies, post them up and I'll do what I can. Where I can't come fully inline with the WG, I'll explain why (as I did above).

As a general rule, specific Skills, Perks, Talents, Powers and Modifiers can (by and large) be formatted in whatever manner is required by the WG (though there are some exceptions to this).

Maneuvers, Adders, Disads and other "generic" items from the template are much more generalized in their formatting. The best that can be done in those cases is to find any patterns that exist in the WG and set the generalized formatting to match as closely as possible (also making any changes to the text contained in the template as necessary).

[Simon]

Just a note:

The next update (1.26) will include the following:

1. Focus. I've modified the Focus class so that it will use whatever is entered for the Display as the name of the Focus. This value, if present and not "Focus", will be placed inside of the parentheses, before the value, as per the WG.

2. Active Points. I'm tentatively including a new checkbox in all edit dialogs which will allow the user to specify whether the Active Points should be displayed for a given ability. This checkbox wil only be available when there is a difference between the real and active cost of a particular item and it will default to checked. Unchecking it will cause the system to not display the active cost in the printout. The state of the checkbox will be saved with the character.

3. Abbreviations. I'm considering allowing template entries to have an ALIAS attribute. This will allow the template to define both the DISPLAY and the ALIAS for an object. The Alias will be used in the edit dialog, allowing you to specify abbreviations in the template. I'm not sure if I'll have this complete for the next update....the change in the code is simple enough, but propagating it through the templates will take some time.


I'll post more as I come up with it.

[Simon]

Hey all!

I just wanted to post up a quick note regarding abbreviations:

I've been looking into things and, as stated, I <i>can</i> include code in the templates which will allow you to specify the "alias" for any given ability. The alias is whatever is entered in the "Display" field in the edit dialogs, so this would have the effect of allowing you to specify an abbreviation in the template.

So far so good.

Except that, throughout the WG, all abbreviations are couched in phrasing like "You <b>may</b> substitute XXX if desired". In short, abbreviations are optional.

For many "newbies" (and others), using abbreviations is not a Good Thing&trade;. Many people won't want them, in short.

So they shouldn't become the "default".

What this means is that the idea of using the ALIAS attribute won't work until such time as I have a preferences screen where the user can specify whether they want to use the "alternate" names of abilities by default.

Which means this will have to wait for v2.

[RPMiller]

Dan,
I've been able to spend some time with 1.25. Here is what I found so far. I realize that the majority are disads. That is because they were the ones that I was most concerned about. I have to admit, you have made a facinating work around :) .
Disads have 3 spaces after colons in output.
Is Steve retentive about capitalization? If so wrong case is used on language freq., but that can be changed by the user if it is too much for you to handle right now, Literacy should say literate
Vulnerability - a space is needed between # and x
Language is clunky to include "(something is native)" after the first listing if English is not native any chance of adding that as a 0 cost adder or something so that it would be easier to add/format? It's tough because it is only used infrequently.
Danger Sense, Contacts have parens around rolls, this must have been what I saw in my last listing.
The characters that I already created when opened, disads defaulted to lowest values. This is probably because I changed so much in the character the CKC pack doesn't behave this way so it is probably my changes.
Enraged - Berserk should go at the beginning of the description if used. Not sure if you can make that work concidering what you already pointed out.
Reputation - If Extreme and Known to a small group, extra parens are included obviously due to the paren in template.
I don't think Unluck is supposed to have a + in front of the dice. Not sure though. I'll keep plugging along and let you know if I find anything else, but I don't think I will. You didn't a great job, Thanks!

[RPMiller]

Originally posted by dsimon
Hey all!

I just wanted to post up a quick note regarding abbreviations:

I've been looking into things and, as stated, I <i>can</i> include code in the templates which will allow you to specify the "alias" for any given ability. The alias is whatever is entered in the "Display" field in the edit dialogs, so this would have the effect of allowing you to specify an abbreviation in the template.

So far so good.

Except that, throughout the WG, all abbreviations are couched in phrasing like "You <b>may</b> substitute XXX if desired". In short, abbreviations are optional.

For many "newbies" (and others), using abbreviations is not a Good Thing&trade;. Many people won't want them, in short.

So they shouldn't become the "default".

What this means is that the idea of using the ALIAS attribute won't work until such time as I have a preferences screen where the user can specify whether they want to use the "alternate" names of abilities by default.

Which means this will have to wait for v2. A thought regarding abbreviations:
FREd regularly refers to the abbreviations both in the text of the powers/skills and elsewhere. I think even a newbie (assuming they actually purchased the book) will learn the abbreviations rather quickly. My players and even myself were able to pick up abbreviations pretty quick.
I generally consider most gamers to bit on the upper end of the intelligence spectrum due to what is required to be a gamer so my personal opinion is to not baby them and perhaps even force them to learn the abbreviations along with everything else.
That all being said I can totally appreciate what you must have to do to implement abbreviations, and I don't think it is that major of an issue, but would be nice in the greater scheme of things. Thanks again Dan!

[rjcurrie]

Originally posted by Durnin

Language is clunky to include "(something is native)" after the first listing if English is not native any chance of adding that as a 0 cost adder or something so that it would be easier to add/format? It's tough because it is only used infrequently.


Hmmm. just adding a 0 point Custom Adder (editing to read "somehting is native" puts that phrase in the parens containing the language level as it should. It's a minor thing for the characters that need it.

[Simon]

Language is clunky to include "(something is native)" after the first listing if English is not native any chance of adding that as a 0 cost adder or something so that it would be easier to add/format? It's tough because it is only used infrequently.

Use a Custom Adder and call it "Native" (or whatever you want). Set the points appropriately.


The characters that I already created when opened, disads defaulted to lowest values. This is probably because I changed so much in the character the CKC pack doesn't behave this way so it is probably my changes.

The disads on existing characters probably won't change (much) in their format. The values shouldn't change unless they are made using custom templates (and you switch the template). I intentionally didn't change any of the ids in the template....just the default ordering and formatting.


Enraged - Berserk should go at the beginning of the description if used. Not sure if you can make that work concidering what you already pointed out.

That's one that can't be accomplished at this point. At least, not by the app. What you can do is include it at the beginning of the Circumstance and then delete the text from the Adder. That will get it to display correctly.


Reputation - If Extreme and Known to a small group, extra parens are included obviously due to the paren in template.
Again, not much that I can do about that one. All you need to do is remove the parens from the beginning of the second adder and you'll be fine.

[Simon]

Originally posted by Durnin
Disads have 3 spaces after colons in output.


Errr...no they don't.

I believe that your macro is still inserting a space for you...the app only has two.

[RPMiller]

Originally posted by dsimon
Use a Custom Adder and call it "Native" (or whatever you want). Set the points appropriately. Hmm... problem with that is that it puts it inside the parens. It is supposed to go in its on set of parens after the fluency. Darn the WG!!! This may be best left as an edit by the user.

Originally posted by dsimon
The disads on existing characters probably won't change (much) in their format. The values shouldn't change unless they are made using custom templates (and you switch the template). I intentionally didn't change any of the ids in the template....just the default ordering and formatting.[/B] Ok, I investigated and what happens is this: I open the original character and go to Diadvantages. The point totals are correct but the levels default plus my "extra" end paren is there. I open the disad, delete the "extra" paren and click ok. Cost changes to reflect the default lowest values.
Originally posted by dsimon
That's one that can't be accomplished at this point. At least, not by the app. What you can do is include it at the beginning of the Circumstance and then delete the text from the Adder. That will get it to display correctly.[/B]
Ah, very good! Will do.
Originally posted by dsimon Again, not much that I can do about that one. All you need to do is remove the parens from the beginning of the second adder and you'll be fine. [/B] That's what I figured, no biggy certainly worth having the other stuff work. Thank you very much Dan!

[RPMiller]

Originally posted by dsimon
Errr...no they don't.

I believe that your macro is still inserting a space for you...the app only has two. Problem is I didn't run my macro yet...
I just checked again by using the plain text export template. Sure enough, there are 3 spaces.

[Simon]

Originally posted by Durnin
Problem is I didn't run my macro yet...
I just checked again by using the plain text export template. Sure enough, there are 3 spaces.

Ah ha! I found it. I'll have that pesky sucker removed in the next update.

[rjcurrie]

Originally posted by Durnin
Hmm... problem with that is that it puts it inside the parens. It is supposed to go in its on set of parens after the fluency. Darn the WG!!! This may be best left as an edit by the user.


You may want to check with Steve on this one, Durnin. I suspect the format this produces -- once you edit the fluency phrasing to match the WG -- is acceptable because I have seen that exact format Hero book. That is, I have seen entries of the form:

Language: French (idiomatic; English is native)

Rod

[RPMiller]

Originally posted by rjcurrie
You may want to check with Steve on this one, Durnin. I suspect the format this produces -- once you edit the fluency phrasing to match the WG -- is acceptable because I have seen that exact format Hero book. That is, I have seen entries of the form:

Language: French (idiomatic; English is native)

Rod I'll ask him. However, the last time I asked him a question similar to this his reply was "Do as I say, not as I do ;)"
I would be happy if he did sway though. There are several consistant inconsistances within the WG.

[rjcurrie]

Originally posted by Durnin
I'll ask him. However, the last time I asked him a question similar to this his reply was "Do as I say, not as I do ;)"
I would be happy if he did sway though. There are several consistant inconsistances within the WG.

Sounds like Steve. :)

And to be honest, I sincerely doubt that there will be any changes made to the WG (except, perhaps, to correct some formatting problems that exist in it), because that would result in, effectively, two sets of guidelines that writers would be using. This would mean two sets of standards that Steve, Darren, or anyone else doing editing for Hero would have to keep in mind when editing manuscripts. Thus, I don't really see changes being made to the guidelines.

Rod

[RPMiller]

Originally posted by rjcurrie
Sounds like Steve. :)

And to be honest, I sincerely doubt that there will be any changes made to the WG (except, perhaps, to correct some formatting problems that exist in it), because that would result in, effectively, two sets of guidelines that writers would be using. This would mean two sets of standards that Steve, Darren, or anyone else doing editing for Hero would have to keep in mind when editing manuscripts. Thus, I don't really see changes being made to the guidelines.

Rod That means that will probably be a no to the native language issue than :(

[RPMiller]

Originally posted by Durnin
That means that will probably be a no to the native language issue than :( I got a reply back from Steve that was a negative about letting it be inside the quotes so that means post edit fix.
Also, the case as specified in the WG is a must as well.
Dan,
I'm not sure if you want to go as far as changing the case within the application. Let me know though because if you do, I won't have my macro change it.
From the way Steve speaks of the WG, he isn't going to ever change it except for the mistakes in it. So, ultimately I think we are going to need some sort of post editing macro like I made and a good export template to be able to make output jive with the WG, without putting a ton of work on you to do.

[Simon]

Originally posted by Durnin
I got a reply back from Steve that was a negative about letting it be inside the quotes so that means post edit fix.
Also, the case as specified in the WG is a must as well.
Dan,
I'm not sure if you want to go as far as changing the case within the application. Let me know though because if you do, I won't have my macro change it.
From the way Steve speaks of the WG, he isn't going to ever change it except for the mistakes in it. So, ultimately I think we are going to need some sort of post editing macro like I made and a good export template to be able to make output jive with the WG, without putting a ton of work on you to do.

I've already got the case changes made on Language. They'll be part of the next update.

[RPMiller]

Originally posted by dsimon
I've already got the case changes made on Language. They'll be part of the next update. Did I mention how cool you are? ;)

[Simon]

Originally posted by Durnin
Did I mention how cool you are? ;)

Not yet...but to add to the Coolness Factor&trade;, I just talked to Steve to find out the full scoop on Languages, and he was mistaken in what he told you.

When you want to state a Native language, it goes inside the parens, separated from the "level" by a semicolon.

As stated, this matches the published examples.

It also happens to be the way HD is doing it ;)

[RPMiller]

Originally posted by dsimon
Not yet...but to add to the Coolness Factor&trade;, I just talked to Steve to find out the full scoop on Languages, and he was mistaken in what he told you.

When you want to state a Native language, it goes inside the parens, separated from the "level" by a semicolon.

As stated, this matches the published examples.

It also happens to be the way HD is doing it ;) Just got that correction in my email. Thanks! How about the "/"? It shouldn't have a space on either side.
Also, anyway to exclude rPD, and rED from characteristics section if they have a zero value?

[Simon]

Originally posted by Durnin
Just got that correction in my email. Thanks! How about the "/"? It shouldn't have a space on either side.
Also, anyway to exclude rPD, and rED from characteristics section if they have a zero value?

Err....which one? I don't know of any in Language, and I removed the spaces from the others....at least, I think I did.

As for the defenses, that's entirely up to your export template. You have individual tags which allow you to export each piece independently.

[RPMiller]

Originally posted by dsimon
Err....which one? I don't know of any in Language, and I removed the spaces from the others....at least, I think I did.

As for the defenses, that's entirely up to your export template. You have individual tags which allow you to export each piece independently. Oh really, cool! The one I just found was on Damage Resistance. I'll check the others here shortly.

[Simon]

Originally posted by Durnin
Oh really, cool! The one I just found was on Damage Resistance. I'll check the others here shortly.

Hrrrm...It seems I forgot to include those in the update. There are a number of abilities that still have spaces before the "/". Primarily for the "split" values.

I'll have the new files in the next update.

[rjcurrie]

Another formatting issue is Perks. The descriptor for a Perk is supposed to be separated from the Perk name with a colon. Currently, HD is putting the descriptor in parentheses. That is, it should be:

Money: Well Off

and not the current

Money (Well Off)

Thank you, Dan, by the way, for making these changes for those of us who care about the WG. It is appreciated.

Rod

[RPMiller]

Good morning Dan,
I've got some changes for you for 1.27 (so what's new :rolleyes: ):
Money Disad has 3 spaces after colon
When the word "Focus" is replaced there is no semi-colon between the new word(s) and the value
Reputation - a comma is missing after the description
Perks - the description shouldn't be in parens
Professional Skill - should only have one space after colon

I'm going to work on new WG - Export Templates and reformatting macros today. Thank you for all your work Dan!

[Simon]

Originally posted by rjcurrie
Another formatting issue is Perks. The descriptor for a Perk is supposed to be separated from the Perk name with a colon. Currently, HD is putting the descriptor in parentheses. That is, it should be:

Money: Well Off

and not the current

Money (Well Off)

Thank you, Dan, by the way, for making these changes for those of us who care about the WG. It is appreciated.

Rod

I'll get those changed for today's update.

[Simon]

Originally posted by Durnin
Good morning Dan,
I've got some changes for you for 1.27 (so what's new :rolleyes: ):
Money Disad has 3 spaces after colon
When the word "Focus" is replaced there is no semi-colon between the new word(s) and the value
Reputation - a comma is missing after the description
Perks - the description shouldn't be in parens
Professional Skill - should only have one space after colon

I'm going to work on new WG - Export Templates and reformatting macros today. Thank you for all your work Dan!

I'll get those corrected for today's update.

[Simon]

Originally posted by Durnin

Reputation - a comma is missing after the description


This is one of the ones that's just going to have to stay the way it is.

The WG is inconsistent in it's use of commas to separate the roll on Disads. In most cases, there is no comma or other separator between the "description" and the first Adder. In the case of Reputation, there is.

The best way to handle this is going to be to manually put a comma at the end of your description.

[RPMiller]

Bad news Dan, A couple Perks still are not displaying correctly.
Fringe Benefit should have a colon followed by the benefits no parens.
Reputation - group and roll should be separated with a semi-colon

[Simon]

Originally posted by Durnin
Bad news Dan, A couple Perks still are not displaying correctly.
Fringe Benefit should have a colon followed by the benefits no parens.
Reputation - group and roll should be separated with a semi-colon

I'll get both of those adjusted for the next update.