Question Regarding General Tags

[RPMiller]

I'm still confused when I should use General Tags in the Export Template, and when I shouldn't.

I tried using COST under the SKILLS tag, but it shows 0 if you have a Separator in the list of Skills. When I use SKILLS_COST I don't get the 0.

I am getting the feeling that I should be using all the "old tags" to make the output handle everything correctly. I'm honestly trying to do things the "new" way, and follow the existing Tag Matrix, but it seems like I have to include a bunch more "IS" and "IF" tags to avoid "strange" output.

I know I'm probably not using them right, but I am doing everything per the Tag Matrix so I'm confused about which tags should be used when.

please?

[Simon]

The old tag "SKILL_COST" didn't actually return the cost of the ability, it returned whatever HD showed in the first column of the purchase list -- which would normally be the same as the cost of the ability, but may vary on items like a separator or a MP slot, in the case of POWER_COST.

When the new general tag "COST" was created, it was made to return the cost of the ability, whatever that may be. In the case of a separator, the cost is 0.

It's mainly a matter of determining which output you want.

[RPMiller]

Ok, I understand. So this raises the next question. Why would I use the COST Tag?

I noticed that in the Default Export Template it is using the "*"_COST tags.

[Simon]

The Default Export Template hasn't really been updated since v1, so pretty much all of the tags used in it are the v1 versions.

As for why you would use "COST" rather than "SKILL_COST" it depends largely on what you're looking to do. If you're looking to add numbers up, you would not want SKILL_COST (which may contain non-numeric characters). If you're looking to have a "cost column" that shows the cost for each ability, you may prefer to have even 0 cost abilities show their value......any number of reasons.

I put COST in the way it is for v2 because it made the most sense (to me) to do it that way, so that the output is exactly what you would expect from the tag (the cost of the item, regardless of type or positioning in a list).

[RPMiller]

I see. So then it would probably be best to add in all the "IF" and "IS" tags to get around the 0 cost for separators and lists?

I'm still working on the Published Version templates. So I don't have a need for a "cost column", but based on what you said to me before I got the impression that I should be using the new tags because they would be easier/straight forward and less confusing.

I do notice that it is a lot easier to build the template by copying and pasting the chunks of code. Without having to type in the specific container names. So based on that, would it be worth the extra trouble of putting in the "check" tags?

[Simon]

That is entirely up to you.

[RPMiller]

That is entirely up to you.

Understand, I was just looking for your expert advice and thoughts on it. You would better know where you were going to take HD next and what features you might be adding so I figured it might be better to get your input before jumping in and making a final decision of the technique I'm going to use for the Export Tags.

I think I may just do the "extra" work, to get a better understanding of how the tags work. Thanks again.

[RPMiller]

Ok, I ran into a problem. I can't figure out how to differentiate between a separator list and a regular list for purposes of display without and with the cost.

FREX: If I have a skill list that includes a separator and a Skill Enhancer, I can make the separator show without the cost, but then so does the Skill Enhancer.

Is there a way to do this using the General Tag COST? If there isn't, I'll have to drop any further attempts to use the General Tags I guess, and go back to using the "specific" tags. I'll go ahead and attach my current template to this post so that you can see how I'm using the tags, and find any errors in their use. Thanks in advance to any assistance that can be provided.

[Simon]

I'll change things in the export so that a separator does not evaluate as a list (it really shouldn't).

Try it out in the current interim build.

[RPMiller]

Thank you very much! Will do!