Forum:Planned changes to skill datarecords and related presentations

Rappelz Wiki is dedicated to players of Rappelz Epic 6: Navislamia.

Please review this list of proposed changes and provide your feedback, comments or questions here.

To make this process efficient, please:

• discuss each proposal under it's own section
• suggest solutions rather than pointing out problems
• notwithstanding the above, do point out showstopper problems
• sign your feedback using four tildes ~~~~

If feedback is positive (or non-existent) then I will start on these changes in November. Your help is always appreciated. najevi

Contents 1 Revised layout for prerequisite: Job, Job level, Skill and Skill level 1.1 Alternative - row labels instead of column headers 1.1.1 Skill page example 1.1.2 Strider job page example 1.1.3 Notes 2 Delete the Infobox_Skill template and related data fields 3 Icons for skill characteristics 3.1 Magic added to attack type data field 4 Other data fields to be deleted 4.1 Apparent redundancy stays ... 0cumfxN and fxNdesc 5 Data fields to be added 6 Expand and collapse feature - post-phoned 7 Significant changes to data field names 7.1 Motivation 7.2 My request of you 8 Upgrades begin from 6pm (UTC) on Tue Nov-4 9 Very wide cost and effect tables

[edit] Revised layout for prerequisite: Job, Job level, Skill and Skill level

• Armor Mastery is a skill that is used by numerous jobs. As a result the cost and effects presentation table is extremely long primarily due to the column listing prerequisite job level for each skill level and secondarily due to the column specifying prerequisite skill.

  About two thirds of the 330 or so job skills are this way but to varying degrees.

• The prerequisite skill column is not an efficient use of table width because an entry appears only once for each job that uses a skill.

• Within each data record, the existing practice of using the HTML line-break element <br> and the font-shrinking element <small> to simulate a table within a cell is intimidating for contributors and we can expect data entry errors to arise because of this.

With the above facts in mind I propose that the next version of Template:Cost and effect take a more space efficient approach.

• Original proposal erased. See the next section #Alternative - row labels instead of column headers for proposed data in rows format table view. najevi 14:22, 27 October 2008 (UTC)

najevi 07:40, 25 October 2008 (UTC)

[edit] Alternative - row labels instead of column headers

See also: FAQs at Template:Cost_and_effect4

A rather simple workaround that would help the prerequisite and even cumulative effect data (but not so much the JP cost per skill level data) is to rotate the table layout so that a 20 level skill displays 21 columns where the first column contains "row labels"

• This would facilitate bundling prerequisite skill name and level in the same cell as each job that can use the skill. A smaller font size can be used for long skill names just as is done today.
• Cumulative effect descriptions (many of which include a formula) would be displayed in a single line of text or maybe two lines. This would be much more pleasing to read than the current column heading vertical layout.

The down-side is the necessary column width to display the larger JP cost numbers that require 5 or 6 digits. That's 6 or 8 characters if we retain the comma as the thousands place separator. It just would not be practical to have uniform column widths for 20 columns of such data and variable column widths might look unprofessional.

• A rather simple template could be written to abbreviated all JP costs to just one two or three significant digits and a single character thousands or millions multiplier. e.g. 1, 12, 123, 1.2k, 12k, 123k, 1.2m, 12m, 123m At least that way each column only needs to accommodate a maximum of 4 character widths. With an appropriate font that should easily allow 20 columns of JP cost per skill data in a horizontal table format. The underlying raw number (formatted with comma thousands separator) could easily be displayed in a tool-tip fashion whenever the mouse cursor hovers over a truncated value.
• If we can received a guarantee that 3rd jobs will not increase the maximum job level beyond 20 then this horizontal table layout would be a far simpler format to develop and to manage.

I'll prepare a demo table to see how this would look on 1024x768 and 800x600 browser windows. We may need a printer friendly page view link for the 800x600 case.

najevi 19:45, 26 October 2008 (UTC)

I've been thinking about this one for a while and these methods seem to work just fine. The only other possible solution I could think of with some quick brain storming is to split the current cost/effect table presentation into two presentations. The current cost/effect table covers quite a bit more data than just cost and effect. Since the future idea is to be able to expand the skill tab presentation on the jobs page into the cost/effect presentation similar to the alizarinhq style, the more detailed information such as required job and job level could then be displayed on a separate presentation table (maybe called "details" or something along those lines) only viewable from the skill's page.

The new cost/effect presentation would then only display skill level, MP Cost, JP Cost, and cumulative effects per level, so the presentation shouldn't take up a whole lot of vertical space. Having the "details" presentation not be vertically efficient wouldn't matter very much since it would be exiled to the skill's page which not a whole lot of reader traffic would likely come across.

I THINK this might be a bit easier to do, but I'm not sure because I haven't the faintest idea of what is involved with splitting one presentation template into two.

The expanded/more difficult version of this idea would be to then use some sort of parser to pull the job requirements from the data record and then only display the relevant levels on each class's page. For example, displaying Armor Mastery 1-5 cost/effect on the Cleric's job page and 11-20 on the Knight's job page. This part might be significantly more difficult than the first part (is it even possible?).Vstar 04:56, 27 October 2008 (UTC)

Ah, I like the way you are thinking. I am certain that I can pass the current PAGENAME to the datarecord template and use that as a switch to display only the prerequisite skill and job levels for the current job. I have not developed the code for this but I know it can be done rather easily using the inline style property:value pairs:- "display:hidden" and "display:block".

With that in mind look at the following sample recognizing that Armor Mastery is used by the largest number of jobs. So this worse case (size wise) table will appear only at the wiki article for that one skill and not upon expansion of the currently compact skilltab view at each job page. The skilltab view is included here only for context. (It is looking feasible that the two tables can nicely be made the same width.)

[edit] Skill page example

or

[edit] Strider job page example

[edit] Notes

1. Notice the more / less link at far right. Click to show more/less detail.
2. Hover over each JP cost abbreviation for a familiar number format.
3. I intentionally pushed the cost and effect information to the bottom of this table and repeated the table header because I was shocked by how big the table was! My reasoning being that this table will appear immediately below the skilltab view which already displays the incremental cost and effect data.

You are correct to comment that the above presentation is much more than just "cost and effect". We may rename it and then spin off two separate templates e.g. Template:skillprereq and Template:skillcosteffect from this one. That is very easy to do after development and debug is complete.

I very much like the fact that you can see at-one-glance the range of skill levels unlocked by each job. (It reminds me of a gantt chart.) I wish I'd had this view of skill levels before today.

• As a regular contributor you may appreciate the much more intuitive and streamlined datarecord field names for prerequisite jobs, skills and job levels. You should read the FAQ's at Template:Cost and effect4 and open Template:Skill/Armor Mastery2 for edit just to browse the proposed new data fields.

By the way, I now realize that the vertical column heading approach would have broken badly on such a skill as Armor Mastery because this many jobs could not have been squeezed into one page width if they were arranged as 15 columns.

najevi 08:40, 27 October 2008 (UTC)

This looks absolutely awesome. It also doesn't have some of the downsides you mentioned with your first solution. Vstar 04:26, 28 October 2008 (UTC)

[edit] Delete the Infobox_Skill template and related data fields

[Template:Infobox_Skill] is rarely used. It appears to be designed to display information about one skill level only and for one job only. The current datarecord fields used by this template are:

<!-- used by "Template:Infobox Skill" -->
| nickname    = 
| job         = 
| skillreq    = 

| typelong    = passive

nickname  

I have occasionally used this field to list some previous name that a skill may have been called but the reality is that a redirect page can be used for this and has much greater utility.

job  

made redundant by the proposed reformatting of prerequisite data columns.

skillreq  

made redundant by the proposed reformatting of prerequisite data columns.

typelong  

made redundant by a proposal (to follow) that uses the already existing "type" field

najevi 07:40, 25 October 2008 (UTC)

[edit] Icons for skill characteristics

The current "type" field introduces an acronym that is not used in game. This is confusing to new and veteran players. The title tag feature that causes the expanded description to appear when the mouse cursor hovers over the acronym is useful but the acronym itself is not.

The original motivation for an acronym was to save space in the skilltab presentation. That same motivation remains valid today.

As the game develops this type field may have an increasingly important significance:

• Currently the most fundamental distinction is between
  1. ACTIVE skills
  2. PASSIVE skills

I propose that the background color of the cell containing the skill name be transparent (i.e. reveal the default table BG color) for active skills and a pastel color (or simply gray) for passive skills.

• Note also that entering NC into a fxNcard field will cause N.C. to appear which is yet another tell-tale sign for a passive skill.

As for the other characteristics:

1. The type of magic can be:
   1. Holy (previously known as Light)
   2. Shade (previously known as Dark)
   3. Earth
   4. Water
   5. Air
   6. Fire
2. Buffs deliver a benefit to the recipient:
   1. of benefit to other players, pets or mobs
   2. of benefit to one's self (the caster)
   3. a benefit (usually to self or pet) that must be toggled on ... consumes upkeep MP periodically ... and must be toggled off again
3. An attack either delivers damage or makes the recipient more vulnerable to subsequent attacks:
   1. Melee
   2. Trap
   3. Ranged - Note: all magic attacks are ranged whether they deliver damage or a debuff.
   4. PASSIVE (see the first note below dated: najevi 05:07, 26 October 2008 (UTC) )

• Are there any other important characteristics?

Armed with the above icons three cells of the table are used to display one, two or three such icons to communicate, at one glance, these three pieces of information.

• Hover over each icon to see an explanatory tool-tip.

najevi 07:40, 25 October 2008 (UTC)

As I started work on this it made sense to add PASSIVE to the attack list since it is mutually exclusive with any of the other three ACTIVE skill characteristics. Here are a few trial examples based on real skills. Note that three new data fields were added to support this feature. Three new data fields would replace the existing "type" and "typelong" data fields. The expected values are not case sensitive:

type.magic

holy, shade, earth, water, air, fire

• Use to specify which type of magic a skill uses. Leave blank if no magic.

type.attack

melee, trap, ranged, passive

• Use for a skill that delivers damage or makes the target vulnerable. (Note: all magic attacks are ranged)
• Passive skills must be identified here.

type.buff

self, others, toggle [Edit: replaced 'target' with 'others']

• Use for a skill that delivers some benefit to the recipient.

Enchant Weapon: Lightning					Cost per use: MP 40 MP +10 MP -4 upkeep cost (MP) per tick 4 +2 -0 increase damage by 16 +10 +0 chance of stun 10% +0% +0%
Enhances basic attacks. Only one enchant weapon toggle may be active at any time.
	1s	15s	toggle

Speed of the Wind					Cost per use: MP 60 MP +20 MP -6 target's MovSpd increases by 21 +1 +1 duration 20min +0 +36s
increases MovSpd of target and allies in a 4m range of the target
	2s	15s	20min

Snare of Corrosion					Cost per use: MP 50 MP +10 MP -5 damage 430 +30 +0 enemy's P.Atk decreases by 90 +10 +0 enemy's P.Def decreases by 90 +10 +0 trap expiry time 60s +0 +0 trigger range 1m +0 +0
affects enemies within AOE range of trap
	1s	10s	15s
		3m

Shield Charge					Cost per use: MP 48 MP +18 MP -4 base damage +80 +80 +0 scaled damage = (initial distance) * ? +? +? duration target is immobile 3s +0s +0.2s increase threat by 150% +0 +0
requires shield to stun and push target back 5m
	0s	20s	3s

Cloak of Shadow					Cost per use: MP 60 MP +10 MP -6 MovSpd decreased by 50% -2% -2%
make caster invisible
	0.5s	30s	1min

Mental Concentration					Cost per use: MP 26 MP +12 MP -3 increase CriRatio by +12% +2% +1% duration 25s +0s +1s
	0s	2min	25s

Shield Blow					Cost per use: MP 45 MP +15 MP -4 target's P.Atk decreases by 15 +15 +5 base damage 100 +100 +35 scaled damage = P.Atk * 90% +5% +5% increase threat by 150% +0 +0
requires shield
	0s	10s	5s

Dual Blade Expert					Cost per use: MP 0 MP +0 N.C. sword AtkSpd 75.5 +0.5 N.C. dirk AtkSpd 83.5 +0.5 N.C. main-hand P.Atk 91% +1% N.C. off-hand P.Atk 46% +2% N.C. dual-wield Acc = Acc * 90% +1% N.C.
enable dual wield dirks & swords

The word "selfish" in that last table is an intentional typo to demonstrate how easy it is to recognize an error and be prompted to go back into the datarecord template to fix it.

• Hopefully a picture really does speak a thousand words. Be sure to hover over each icon.

najevi 05:07, 26 October 2008 (UTC)

Does the new scheme adequately handle healing skills?

• Like any other magic skill those are "ranged".
• Like any other buff skill those are "target"-able.

Does this seem adequate? najevi 18:28, 26 October 2008 (UTC)

I've given the above question more thought and I now think that the fundamental distinction between "type.attack" and "type.buff" should be:

• attacks deliver damage or make the target more vulnerable to a subsequent attack (a.k.a. debuff) to the target object

  even if the attack also results in some benefit returned to the caster - as in Life Leech

  even if the attack also increases one ability at the expense of another - as in Provoke Shot

• buffs deliver a benefit to the target object

By that reasoning I would not assign "type.attack=ranged"-> to healing. So I'd have to handle it like any other target-able buff skill. i.e. "type.buff=target"->

So now this has me wondering if the hour glass icon is really suitable for self buffs and target-able buffs. How about a gold star icon with the same inward pointing or outward pointing arrow to indicate self and others respectively. An image is easy enough to change after the fact, so I won't lose much sleep worrying about the merits of the icon itself.

najevi 02:28, 28 October 2008 (UTC)

As far as I know, there are only a few exceptions (a couple self buffs that affect more than just self like the self + pet buffs on evoker and a couple things like that). These very few exceptions can easily be noted as such in the description and don't need separate icons. I think the icons would make things look much nicer overall and are far less cryptic than the current abbreviations in the type field.Vstar 04:22, 27 October 2008 (UTC)

Of course right after I posted that I remembered an important exception. There is "non-elemental" magic damage. Energy beat claims to be non-elemental for example (though I've never tested to be certain). There are also some buffs that give non-elemental resistance. We might be able to treat this as an exception and just be very careful to note it prominently in the description field. Energy beat still even uses the "holy" icon.Vstar 05:26, 27 October 2008 (UTC)

Regarding your first comment I would handle any skill that must be targeted at your summoned creature as "type.buff=target"-> unless it is either described as a toggle and/or consumes upkeep every tick in which case I'd give it "type.buff=toggle"->.

I never have fully understood the elemental/non-elemental defenses. I find it easy to confuse them with with mob characteristics such as organic, inorganic, undead, spirit, mecca, beast and maybe a few others that I can't remember right now. I'd love for somebody to write an article that spells (sic) this out clearly. The following is my current best understanding:

The magic characteristics associated with each race overlap with one other race.

(Non)-Elemental:	NE	E	E	E	E	NE
Race \ Can use?
Deva	Y	Y	Y	no	no	no
Gaia	no	Y	Y	Y	Y	no
Asura	no	no	no	Y	Y	Y

• See also: Terminology - please explain these in-game adjectives

Until now I had thought that earth, water, air and fire are the so-called elemental characteristics while shade and holy are the non-elemental characteristics. If the above table is not correct then please set me straight.

What tends to confuse me are the various derivatives of the four elemental powers:

• earth: poison, rock, avalanche etc.
• water: ice, rain, dew, etc
• air: wind, lightning, stun etc.
• fire: burn, power, ?I've drawn a blank?

Because of the above perspective I probably would have labeled Energy Beat as being "type.magic=holy"-> due to it being a Deva skill and holy being the only non-elemental characteristic the Deva race has access to.

I have been wrong before and I may be wrong about this as well, hence the discussion.

najevi 11:19, 27 October 2008 (UTC)

My understanding of how elements are treated in this game is that all 6 of the icons are considered "elemental". Non-elemental is then a 7th element. Basically it means that it does magic damage, but it is not an element. This is sort of like Final Fantasy (if you are familiar with it) where there are generally 8 elements, but certain spells such as Ultima do non-elemental damage. A more specific Rappelz example is that Heaven's Spear is a Holy Attack Spell that does Holy magic damage. However, Energy Beat is a Holy Attack Spell that does non-elemental magic damage. This means that holy resistance applies to Heaven's spear but non-elemental resistance applies to energy beat. Non-elemental attacks are few and far between, so I think they can be treated as a special exception and don't need a special icon.

My first comment refers most specifically to a couple buffs like Anger of the Wild which are self buffs (you don't target, they work like mental concentration, hit the button and it's on), but they apply to not only self but also to summoned pets.Vstar 04:11, 28 October 2008 (UTC)

As I finish these last few Asura skills I have been imagining how I would filling in the planned new data fields. I now think that "type.buff=target" is better replaced with "type.buff=others". This shifts emphasis from the direction of the buff to simply who benefits (cui bono?). To that end I plan to replace the hour glass icons with gold stars or smiley faces to indicate whether the happy party is many (others) or one (self).

In the case you mentioned were self + pet benefits I would interpret that as a "type.buff=self" skill.

najevi 21:45, 28 October 2008 (UTC)

[edit] Magic added to attack type data field

I am half way through the overhaul of these skills and have reached the conclusion that the typeAttck data field needs a 5th value: "magic". The original plan was to specify ranged for all magic attacks reasoning that the caster does not need to be physically close to the target to cast the spell and deliver either damage or a debuff.

• there is something not quite right about making ranged have two purposes in this field.

Whether the distinction is necessary or not it is much easier to merge two distinct values into one after the fact than it is to split one value into two over a couple of hundred data records. Therefore the expected values for the type fields are now:

|typeMagic = holy, shade, earth, water, air, fire
|typeAttck = melee, ranged, magic, trap, passive
|typeBenef = self, others, toggle

A fifth icon will be added to reflect this new value for typeAttck.

This distinction may help bring clarity to the debate over what type of damage is delivered when a magic attack does not specify one of the six "typeMagic" values. e.g. Does this mean the active skill delivers non-elemental magic damage? ... or just plain magic damage in the same way that basic melee or ranged attacks deliver physical damage?

It also serves to distinguish between a basic ranged attack and a ranged attack that has been enhanced by one type of magic or another.

najevi 00:56, 13 November 2008 (UTC)

I didn't think this was a big deal originally either, but now that I've been making some edits of the new skills I definitely agree. It was getting confusing with some of the skill changes because there are a couple skills that changed from magic attacks to physical attacks from Epic 4 to Epic 5 (the chips you needed to use for the skill changed). It's very nice to have this added distinction to be able to remove that possible confusion.Vstar 00:08, 25 November 2008 (UTC)

[edit] Other data fields to be deleted

The following fields in the datarecord schema are not serving any useful purpose so I propose they be deleted:

jlv  

made redundant by 1prereqjlv.Job_Name (see next section for an explanation of the dot extention)

jobnum  

jobnum serves no useful purpose wrt describing the skill per se

type  

reuse or replace with 3 fields per the proposal in the section above

6maxlvl  

made redundant via columns of prerequisite JLv per job in the "cost and effect" presentation

6mastery  

made redundant via columns of prerequisite JLv per job in the "cost and effect" presentation

5noname  

not a deletion but rather rename it to 5aoerange because it is already being used for the range (in virtual meters) for any AOE skills

najevi 07:40, 25 October 2008 (UTC)

Suggested addition:

4dotper  

not a deletion but rather rename it to 4tick assuming that this is intuitive to readers. Also change the cell BG watermark to "tick" as well as

• DOT style references to "damage per tick";
• HOT style references to "HP per tick"
• upkeep style references to "upkeep MP per tick".
• etc.

najevi 17:56, 26 October 2008 (UTC)

[edit] Apparent redundancy stays ... 0cumfxN and fxNdesc

As I work on these upgrades the apparent redundancy between fxNdesc and 0cumfxN ocured to me however I am leaving this note to explain why this apparent redundancy is actually necessary. While it is true that 0cumfxN may be a copy of fxNdesc (and this is even more the case now that the presentation of cost and effect data presents cumulative effect data in a single row rather than a single column) there is one very significant function served by the 0cumfxN data field.

• That is to instruct Template:Cost and effect to present a row of data if it's value is defined and to not create any row at all if the value is undefined.

This is important to those cases where an effect changes with card level but not with skill level. In such cases printing a row of unchanging effect per skill level is a waste of a row in the table. najevi 22:55, 6 November 2008 (UTC)

[edit] Data fields to be added

With this week's release of a new version of the skilltab template those complex skills that exhibit 4, 5 and 6 different effects can be better catered for. As illustrated at Template_talk:Skill/Shield_Charge the number of rows dedicated to incremental skill effects and MP cost is now dynamic on the right-hand side of the table. Any any vertical height mismatch with the left-hand side appears within the Description cell. This is appropriate since such complex skills may need more than one line of description in any case.

To enable this flexibility new data fields must be added to the datarecord. They are simply a copy and paste of the existing:

1. fx1desc, fx1magn, fx1perlvl, fx1card
2. fx2desc, fx2magn, fx2perlvl, fx2card
3. fx3desc, fx3magn, fx3perlvl, fx3card

but with names:

1. fx4desc, fx4magn, fx4perlvl, fx4card
2. fx5desc, fx5magn, fx5perlvl, fx5card
3. fx6desc, fx6magn, fx6perlvl, fx6card

Similarly these fields are added to display the cumulative effects.

1. 0cumfx4, 1cumfx4, .. 20cumfx4
2. 0cumfx5, 1cumfx5, .. 20cumfx5
3. 0cumfx6, 1cumfx6, .. 20cumfx6

• Perhaps some day these cumulative effect data fields can be deleted but for now I know of no easy way to generate them automatically. Wikimedia parser functions do not provide good support for variable length for-loops or while-loops.

There is no need for these additional fields to be present in a data record if a skill does not need them. Please do not interpret this as license to go cleaning up lines in existing datarecord templates. We do not yet know the effects of 3rd jobs on the existing base of skills and so some of those unused data fields may be needed during the Epic 5 life cycle.

najevi 07:40, 25 October 2008 (UTC)

[edit] Expand and collapse feature - post-phoned

So near and yet so far! User:Najevi/Show_or_hide demonstrates the desired expand and collapse feature I was hoping to implement but sadly, it also demonstrates a problem we will run into on every job page.

• Templates stop expanding after some threshold is reached.
• These templates are very large (byte-wise).
• This threshold seems to have more to do with source code bytes than rendered HTML code bytes

Until my enquiries at wikia central forum yields a satisfactory workaround I plan to shelve the idea of implementing expanding and collapsing tables of prerequisite JLv and cost and effect data.

• Late breaking news - a solution may be at hand in the near future.

For now though I plan to focus on only what you see in the above discussions.

najevi 06:03, 31 October 2008 (UTC)

Where there's a will there's a way! User:Najevi/More or less demonstrates the desired expand and collapse feature as you might expect to see it behave at a Job page.

• The first three presentations (there are 40 in total) have typo or missing values for job name passed to them. Notice how no prereq data is displayed in this case.
• The 4th through 27th each pass a different job name just to check that all job names are recognized by the template. Notice how only one row of data is generated. Of course on a proper job page these would all be for the same job, in fact the magic word {PAGENAME} is intended to be passed.

The 28th through 40th pairs of tables do not currently expand successfully. I have confirmed that these will expand correctly (view a side by side comparison) after our wiki is migrated to the new parser preprocessor. This was an extremely tight fit and I am more than just a little concerned that the current method of datarecord templates and presentation templates might not scale very well when at least 15 new 3rd jobs arrive on the scene.

The demo skill I have used is a worse case scenario so maybe we won't hit this limit with the actual skills even while using the old preprocessor.

• There is another promising technology called Semantic Forms (a derivative of Semantic MediaWiki) and that may prove useful for skill data, item data, mob data, in fact just about everything we need here.

However for the time being, the above expedient approach will be used and I plan to get started on this from Monday. If you have been contributing to datarecord templates before today then you will notice some subtle changes (as noted above) but I am confident you will find the new datafields very intuitive.

Thanks for your comments through out the past week.

najevi 08:28, 1 November 2008 (UTC)

Update on the new preprocessor expansion of these pages. I have just confirmed that the worse case job page using what I have called the "heavy weight" template code will expand and render successfully all 40/40 skill tables and cost and effect tables with the new preprocessor. View a preview here. najevi 05:36, 4 November 2008 (UTC)

[edit] Significant changes to data field names

A rose, by any other name, would not smell as sweet! This analogy is a poor one since rose is a 4-letter word. But if that famous quote from Shakespeare's play was, "A frangipani by any other name..." then it would be spot on for my purpose in this post!

Bottom line

The data field names are going to change and become 4 or 5 characters in most cases. I hope you still find the names intuitive. Certainly this will be helped by the fact that data values are already populated.

[edit] Motivation

At each job page, between 15 and 40 skills are displayed on the one page. When the presentation and datarecord templates are included but before the processing of each template takes place, these 27 pages run into a preprocessor limit called the pre-expand size - which happens to be 2MB per page. Every byte in these templates counts toward that 2MB limit. Each data record template itself does not contribute significantly however, the data field names are prolifically used in the presentation templates which are now huge (31kB is the largest) and this number will only grow larger after 3rd jobs are introduced.

So the primary motivation for shrinking these data field names is to complete a project I have been referring to in my change summary notes as: "my template code diet".

In the new datarecords that I plan to create this week I will also be cutting down on white space and comments although hopefully not to the point where the datarecord is difficult to navigate.

[edit] My request of you

I am too familiar with these field names to be impartial so I'd like your feedback on whether the new names have become so brief that they are no longer intuitive. Of course the Template:Skill/schema will be updated to reflect the new field names so there will always be that point of reference. Also keep in mind that just about every skill has some skill data already populated and so associating this expected data with the adjacent field name will help with recognizing the new field name.

Please review the side by side comparison below and leave your comments - either positive or negative. If you don't like a proposed new field name then please suggest an alternative.

        LEGEND:
        1.     ! this data field will no longer be used.
        2.     |"new data field name" = "example data values"
        3.       All field names are case sensitive.
        4. <!-- --> Old comments to be removed.
        5. (!-- --) New comments to be added.

 OLD NAME       NEW NAME
 ========       ========
<!-- common to more than one "presentation" template -->
| name        = name
| icon        = icon
| jlv         = !


<!-- used by "Template:skilltab" -->
| jobnum      = !
| type        = !
| 6maxlvl     = !
| 6mastery    = !

| 1cast       = cast
| 2cool       = cool
| 3duration   = durn

| 4dotper     = tick
| 5noname     = rnge
| description = desc

               |typeMagic = holy, shade, earth, water, air, fire
               |typeAttck = melee, trap, ranged, passive
               |typeBenef = self, others, toggle

                (!-- incremental cost per use --)
| cost4magn   = MPmagn
| cost4perlvl = MPpLvl
| cost4card   = MPcard

                (!-- incremental effect: fx1 .. fx6 --)
                (!-- make 1 block for each effect   --)
| fx1desc     = fx1desc
| fx1magn     = fx1magn
| fx1perlvl   = fx1pLvl
| fx1card     = fx1card

<!-- used by "Template:Infobox Skill" -->
| nickname    = !
| job         = !
| skillreq    = !
| typelong    = !


<!-- data per skill level - used by "Template:Cost and effect" -->
<!-- the full range of valid skill levels (current maximum is 20) -->
                (!-- possible skill levels --)
|1lv =          1lv
|2lv =          2lv
|3lv =          3lv
|4lv =          4lv
|5lv =          5lv

<!-- JP cost per level -->
                (!-- JP cost per level --)
|1jpcost =      1jp
|2jpcost =      2jp
|3jpcost =      3jp
|4jpcost =      4jp
|5jpcost =      5jp

<!-- MP cost per use -->
                (!-- MP cost per use --)
|1mpperuse =    1mp
|2mpperuse =    2mp
|3mpperuse =    3mp
|4mpperuse =    4mp
|5mpperuse =    5mp

<!-- cumulative effect #1 -- Note: 0cumfx1 is a suitable column heading string -->
                (!-- cumulative effect: fx1 .. fx6 --)
                (!-- make 1 block for each effect  --)
|0cumfx1 =      0fx1
|1cumfx1 =      1fx1
|2cumfx1 =      2fx1
|3cumfx1 =      3fx1
|4cumfx1 =      4fx1
|5cumfx1 =      5fx1

<!-- prerequisite job(s) for each skill level -->
|1prereqjob =   !
|2prereqjob =   !
|3prereqjob =   !
|4prereqjob =   !
|5prereqjob =   !

<!-- prerequisite job level for each skill level -->
|1prereqjlv =   !
|2prereqjlv =   !
|3prereqjlv =   !
|4prereqjlv =   !
|5prereqjlv =   !

<!-- prerequisite skill for each skill level -->
|1prereqskill = !
|2prereqskill = !
|3prereqskill = !
|4prereqskill = !
|5prereqskill = !

               (!-- prerequisite skill per job & --)
               (!-- range of skill level per job --)
               (!-- prereq. JLv per skill level  --)
               (!-- Please make 1 block per job  --)
               (!-- ... no spaces in "Job Name"  --) 

               |preSkill.JobName = [[Skill Name]] Lv1
               |1JLv.JobName     = 1
               |2JLv.JobName     = 5
               |3JLv.JobName     = 10
               |4JLv.JobName     = :
               |5JLv.JobName     = and so on ...

As I have done in the past: no comment will be interpreted as your approval. I plan to start with these changes around Nov-5 ... after testing a few tools that I hope will make the process more efficient and error free. najevi 11:32, 2 November 2008 (UTC)

[edit] Upgrades begin from 6pm (UTC) on Tue Nov-4

After each upgrade the skill datarecord will still have the old data fields but these will be clearly marked by placing them all between these two sets of comments:

<!--  = =  DO NOT UPDATE BELOW THIS LINE  = =  -->
<!--  = = =  data fields to be retired  = = =  -->

<!--  = = =  data fields to be retired  = = =  -->
<!--  = =  DO NOT UPDATE ABOVE THIS LINE  = =  -->

Also, the edit summary (viewable in revision History) will read:

Upgraded to new (shorter) field names. Retired data fields preserved only for a short transition period. Please DO NOT UPDATE any data fields to be retired.

• So if you come across such a template then please make your edits to the new data fields and not the data fields to be retired.

Once I have touched all 350 skills I will then upgrade the job pages and the skill pages to use the newer presentation templates (Template:Skilltab and Template:Cost and effect). Only then do I plan to go back through the 350 skill datarecords to delete the retired data fields.

• This two pass approach is being done to avoid the live pages appearing corrupt at any time during the transition period.

This may take a week or two. I may post progress summaries (e.g. as I complete each job, class or race) in this thread during that time. najevi 23:21, 3 November 2008 (UTC)

I'm watching as the pages are changing. This is looking really great by the way. BIG thumbs up. Vstar 03:47, 25 November 2008 (UTC)

Thank you, I am also very pleased with the way it is turning out. The cost and effect table has irregular column widths but that was necessary to allow it to fit within a page width at 1024x768 resolution. I have not been checking on appearance under IE6 or IE7 so please do point out any anomalies that you see. (IE6 and FF2.0 had problems rendering collapsed width cell borders as 1 pixel lines - IE7 and FF3.0 have corrected that so if there are problems under the old browsers then I will be less motivated to fix them since the upgrades are free to all users.) najevi 11:04, 25 November 2008 (UTC)

The only thing that is happening differently is that IE7 is not wrapping things that Firefox 3 is in the cost/effect. I'm not really convinced that this will be a big deal though. Unlike the skilltab presentation where everything is supposed to more or less line up, the cost/effect presentation will most likely never line up anyway due to the fact that the width of the columns isn't constant to begin with. There also isn't a place on the website where there are 30 or 40 of them stacked on top each other. I believe they'll look perfectly fine as they are currently rendering. Vstar 15:37, 25 November 2008 (UTC)

[edit] Very wide cost and effect tables

I am noticing that certain skills that use percentages to describe the effect on an ability cause the table width to grow exceptionally wide. Refer to: Bloody Blade for an example.

I wonder if it would be confusing to readers if such skills used simple decimal digits instead of percentages. e.g.

• "1.4" instead of "140%"
• ".75" instead of "75%"

This may not be the only contributor to wide tables but it is certainly one of them. najevi 12:56, 26 November 2008 (UTC)

I noticed that as well. I don't think it would be a problem to change to decimal format. The meaning is still straightforward.Vstar 14:03, 26 November 2008 (UTC)