User talk:Technical 13/2013/1

Any plans on putting Epic levels in? I thought about adding 'em myself, but realized 1) it's 7:30 AM, and i've been up since about 10:30 yesterday; 2) I'd probably break something anyway; and 3) Epic would probably have to be put in differently than non-epic, especially with the "Life" column... Actually, looking at it, probably wouldn't be too hard (a fourth set of current levels with an Epic y/n toggle and Epic levels, with that added to the total levels *after* figuring out how many lives - which, hopefully, would be a multiple of 20! However, I'd still probably break something *g* → LrdSlvrhnd (Contributions • Message) 07:39, January 4, 2013 (EST)

I've thought about it, but I decided to wait until they have finish debugging some more on their end... I'd have to add a new column and Epic levels don't carry though TR, but EDs do, so I would have to make a separate ED column and some other tweaks... I was basically waiting until they go a couple updates without adding a new ED... I'm lazy and just want to get it done in one shot... Also, as a side-project related to this, I am working on (still in brain-storming phase) an extension that can pull all of this from MyDDO / data.ddo.com and populate all of these pages automatically every time someone pulls it up... I've found that I just can not keep mine up-to-date between creating new toons, deleting toons, leveling up, TRing.. Oy vey!!!

ShoeMaker (Contributions • IRC) 13:09, January 4, 2013 (EST)

Well, I was thinking more about epic LEVELS and not EDs... like my ranger/rogue Grynd is actually L24, not 20. So instead of listing at 15/5, he'd list at 15/5/4, but can't do it. The EDs are so ephemeral anyway... But that's why I'd think simply another couple of rows in the "current level" section would do the trick. I'm simply afraid of breaking things if i tried adding it myself lol

G'luck pulling stuff from MyDDO; I suspect you'll need it. Especially for epic characters... → LrdSlvrhnd (Contributions • Message) 15:12, January 4, 2013 (EST)

|Watch| button/tab/link issue[edit]

As a continuation of the following post:

Quote:
Originally Posted by Bladedge (Contributions • Message) on July 28, 2012 On minor note the "Watch" links not functioning, for me anyway.

I emailed Xevo, and he seems to have figured out the problem. Test it out, should be able to (un)watch pages via that link now.

ShoeMaker (Contributions • IRC) 18:34, January 5, 2013 (EST)

Monster Races[edit]

Tech I understand what you're trying to do but you're undoing months of my work. I have been painstakingly going through and editing all monster entries to accurately reflect Turbine's in-game classification. I would have very much appreciated you putting this up on a talk page before reversing the entire classification scheme for the monster pages and so many of my edits. I was going to propose a change to the monster infobox template the introduced a sub-race section where we could add things like "Hill Giant" and "Hezrou" in addition to their race. That way we could have these categories in addition to the correct race categories already in place. In game, if you select a Hezrou and click examine, the race is listed as demon, not hezrou. If you click a hill giant, it says giant. The classification scheme I have been using follows Turbine's lead, which is the policy of the site. The monster manual is not relevant in this discussion because nowhere does it claim to list the monsters in it by race, and you can tell that certain categories have been lumped together in order to simplify things. For example, wights, ghouls, and ghasts are all lumped together under "wight" in the MM.
If you believe things should be done differently, that's your right, but I ask that you stop changing the categorization and the races on the monster pages until we have had a chance to discuss it. It is my understanding that site policy calls for discussion before undoing another editor's work on such a large scale. Thank you.→ Susalona (Contributions • Message) 20:07, February 4, 2013 (EST).

Actually, Ghouls and Ghasts both have their own independent section in the MM. I was not trying to step on your toes, and I have no issue with having some other method of classifying them. However, in order for the MM to have accurate information, I was starting with what seemed simplest. Do you need help in modifying the template to accommodate the MM? Perhaps add an argument of |MMrace = and a coding for the display to be something like [[Monster Manual]] classification: {{{MMrace|{{{race|Undefined}}}}}}? Either way, I apologize if you feel I was stepping on your toes... I had been waiting almost a week for you to speak up since I made the modification to the table on the MM page, heard nothing and figured I would start populating the categories at very least.

ShoeMaker (Contributions • IRC) 20:34, February 4, 2013 (EST)

I modified the template to now accept a MM type argument and restored all of the races I changed to what you had them as. Again, I apologize if you feel I was stepping on your toes...

ShoeMaker (Contributions • IRC) 19:40, February 7, 2013 (EST)

Yeah, that sounds great actually. Thanks for changing the template, I'm afraid I know very little about working with the templates. I overreacted a bit the other day anyway.

I saw some of those old categories coming back like a bad penny and posted as a knee jerk reaction. I was having a bit of a bad day that day, not that its any excuse. Thanks for listening to my suggestion.

The other thing I might suggest as far as the template goes is having the race and type field link directly to the race and type pages I have been creating. Many of them already do, since there is no other page with the same name as that race (Quori race, Demon race), but many don't (Beholder race, Lich race etc.) I think people who click on those links are probably looking for more general information than what is on the Beholder and Lich pages. I plan to update and reorganize the chart on the main Monster page to match the one on my User Talk Page, hopefully sometime this week, which will also link to those pages. I figure that from the race and type pages, people can navigate to whatever individual monster pages they want, as well as being able to use the lists at a glance for the monster manual.

Susalona (Contributions • Message) 09:50, February 8, 2013 (EST)

So, what you're asking is for type and race to link to the associated type and race pages, but they're not all created yet and you're not quite ready? If that is the case, let me know when you are ready and I will make the needed minor adjustment to the template (it's a simple one).

ShoeMaker (Contributions • IRC) 10:44, February 8, 2013 (EST)

Yeah Tech, that's exactly what I was asking for. I figured it was an easy change but couldn't quite figure it out myself without being able to play with the template more than the preview button allowed.

I just created the last race page I needed today, so you could go ahead and make that change when you get the chance.

One thing I did want to mention is that I noticed that the new MM classification line in the monster infobox template is overriding the race line for the purposes of categorization by race. Since the monster manual classifications (Flesh Golem, Hill Giant, etc) you were concerned about are all at a lower level in the classification scheme than the monster's actual race (Golem, Giant, respectively), my opinion is that these categories should not be labeled as though they were at the same level. For example, instead of Category:Flesh Golem race monsters, the category should be called Category:Flesh Golem sub-race monsters or something similar. I don't much care if we actually call it a sub-race, I just think that calling it a race is misleading. In that case Flesh Golem would be put into Category:Golem race monsters and Category:Flesh Golem sub-race monsters. This makes sense not only from a purely logical perspective (following the Kingdom>Phylum>Class, etc. example from biology), but it will also preserve the structure of the race pages I have been creating. I can go through and add sub-race pages (or whatever you want to call them), for Marilith sub-race, Hill Giant sub-race, etc. I have a chart on my User Page listing potential sub-races and how they would be categorized.

Susalona (Contributions • Message) 13:40, February 12, 2013 (EST)

I understand where you are coming from on things that have defined differences and a flowing tree structure like Construct → Golem → Flesh Golem; however, I am concerned about things that don't follow the linear structure in the MM, such as Aberration → Beholder → Sub types (chaos, frost, etc). I don't want to have to create a massive #switch when I create the "table row" template for the MM table that says these use race and those use sub-race. Do you understand what I am getting at, and do you have any suggestions for how we can make it work? The only thing I can think of is to create the category structure using the linear type → race → sub-race and then create a MM Category with sub-categories to the proper (sub-)race that the MM uses.

Examples of how this would work:

Flesh Golem
- Category:Construct type monsters → Category:Golem race monsters → Category:Flesh Golem sub-race monsters
- Category:Monster Manual/Flesh Golem (16) → redirect → Category:Flesh Golem sub-race monsters
Beholder
- Category:Aberration type monsters → Category:Beholder race monsters → Category:Chaos Beholder sub-race monsters
- Category:Monster Manual/Beholder (50) → redirect → Category:Beholder race monsters

ShoeMaker (Contributions • IRC) 13:58, February 12, 2013 (EST)

Yeah I get what you're saying, it's complicated because not every monster actually has a sub-race. Having to create a table like that in the template would definitely be cumbersome. The only thing I can think of would be to make it similar to the

|rare
line in the template, where if no one puts the line on the page (or if they leave it blank) it defaults to "no". If the line is filled in, then whatever is filled in could then be assumed to be a sub-race. The only issue I see with doing it that way is that it puts a burden on the editor to make sure what the correct sub-race is (or even that it has a sub-race) before filling it in. However, there really isn't much difference between that burden and the burden of making sure the race, type, alignment are correct so I think that isn't really a problem.
I think I mostly understand what you are suggesting as an alternative. I just think that the linear structure (where each sub-race category is fully contained in a race category and each race category is fully contained in a type category) would cause more problems than it would solve. The fact that races can be more than one type and the way the <ncl> command works with nested categories is a big issue. Some of my concerns with the nested structure are discussed here, and it was based on that discussion that I adopted the cat structure we have currently. → Susalona (Contributions • Message) 14:43, February 12, 2013 (EST)

Oh snap! I had no idea you could specify depth for the <ncl> command but it makes sense that you should be able to. I think I withdraw all my objections to nested categories now that I know that. That is fantastic.

→ Susalona (Contributions • Message) 15:05, February 12, 2013 (EST)

All of the arguments that the <ncl> tag supports are listed on it's help page on this wiki (Help:Extension:NiceCategoryList2).

ShoeMaker (Contributions • IRC) 15:31, February 12, 2013 (EST)

Item template update / refactor[edit]

I've created a revised template for Spell Power copying some from the refactored Skills template.

Worth noting is that 1) I made use of defined variables inside the template to keep down the duplication of lowercase and ucfirst functions (templates) and 2) In order to make the template more readable ( and not have the code all mashed together) I put in line breaks enclosed in html comments. I'm on the fence that it actually DOES make it more readable though.

Also, the template still needs some more work in that 1) The reference to the strength value has no logic to determine if value is negtive or positive and injects a + for all values. I should be able to peel some of the functions you used in the skills template to convert the strength value to either + or - and remove the injected + pretty easily though.

I figure if you think the template is good enough then you can copy the guts over to the live Template:SpellPower, otherwise let me know what needs to be worked on and I'll update and resubmit. -Joe → Joenuts

This is wonderful that I have someone else as interested in creating and updating templates as I am. You may find the list of Category:Meta templates (templates to be used in other templates) useful. Specifically, Template:Int, Template:Scase (Sentence case), and perhaps one or two of the "Dec2xxx" templates.

Okay, so, I've taken a look. Way too many unnecessary variables. Makes more work for the wiki core. Variables are used for heavily repeated multi-tiered algorithms. The attempt to space it out with HTML comments to make it easier to read, doesn't work. I've tried it before, and found it just adds more to the "wall" of code. I usually use Notepad++ to edit large chunks of code (If you don't have a WikiText UDL, use TeX because it is close) in an indented easy to read format. When I get to a point that I want/need to plug it into the wiki to test it, I copy it into a new Notepad tab, remove all line-feeds and unneeded whitespace, copy and paste it back into the wiki. I'm hoping to post the WikiText UDL(s) I've been working on before too long, but that project is delayed due to my lack of Internet from the divorce. Lastly, when using Template:Post, the correct format is {{SUBST:Post| Number of post you're responding to +1, 0 for first post |~~~~| Your comment, message, question, or rant... }} Other than that, my only question is, do you plan on adding functionality for temporary spell power buff clickies? (Say yes, )

ShoeMaker (Contributions • IRC) 09:56, February 18, 2013 (EST)

Please review :

I've finished the bulk of the work for Template:Sandbox/joenutsSpellLore. Template:Sandbox/joenutsSpellLore2 is the same template without the variable (template) declarations. Keep in mind, that element_dereference is used 5 times, magnitude_dereference is used 3 times, magnitude_dereference_percent is used 1 times, and magnitude_dereference_multiplier is used 2 times. This means whenever a new spell school or modifier needs to be added, someone will need to go to the template up to 5 times to update ( rather cumbersome ). I use wiki very heavily where I work and have a development environment set up to test various things. If you can tell me what tools you're using to determine how much of a load the various templates cause on the wiki core I'll be glad to try and optimize the code that's developed for the engine. As of yet, I havent found the var references we use here to increase load at all, and helps provide for a much more modular development effort.

I dont like how magnitude value spacing isnt uniform. Perhaps a table, or preformatted text would be better suited for the diagram, not sure. What do you think about that?

Category that the template injects is Spell Lore Items/[magnitude] [element] ( copying your format from spell power). I lost our conversation from earlier today, so dont know if that's correct.

I suggest Spell critical should be renamed to Spell Critical.

The long popup link in the template goes to Spell Critical, not an individualized page for each element. Healing_Lore page exists, and contains a static chart listing crit profiles for various magnitudes ( which I think should reside on Spell critical to prevent duplication for each element ), and also statically lists items that have healing lore properties of various magnitudes ( which is going to be redundant once spell lore categories are properly injected on items ). I didnt know if it was worthwhile to try and maintain the link to each elements spell school pages, or just dump everyone to Spell Critical. → Joenuts (Contributions • Message) 16:48, February 18, 2013 (EST)

I've finished the bulk of the work for Template:TemporarySpellPower. I took the opportunity to not carry over the clutter from pre name conversion ( beatitude etc ).

Category injected is Temporary Spell Power, hard link goes to Spell Power ( not element, if element is desired, that should be pretty easy though ).

Something I forgot to mention earlier was that the percentage and multiplier values for Template:Sandbox/joenutsSpellLore were taken from Template:Spelllore which I think may be outdated. A review of those figures is warranted. → Joenuts (Contributions • Message) 22:28, February 18, 2013 (EST)

I've taken the time to look them all over. I've made a couple minor edits and commented some other things in the one-line edit summary. Here is a recap and a few new thoughts.

While I understand your idea of less editing on the template by putting everything into a variable, these things that the templates represent rarely, if ever, change.# #switch: default values should ALWAYS be marked as "#default=." This eliminates some of the confusion for new editors trying to learn how to make a template or anyone that needs to add a new value to a template or change the default.
If you use a switch, and multiple values have the same output, you don't need to break them out.
- {{#switch:{{{1|2}}}|1|2|3|4=Less than five|5|6|#default=Greater than or equal to five}}
- {{#switch:{{{1|2}}}|1=Less than five|2=Less than five|3=Less than five|4=Less than five|5=Greater than or equal to five|6=Greater than or equal to five|#default=Greater than or equal to five}}
  - "Less than five" is the same thing as "Less than five"
You don't need to use a #switch for everything. If it is something that only has two possible outcomes use an #ifeq: or #ifexpr: instead.
- {{#ifexpr:{{{1|2}}}<5|True|False}} → True
- {{#switch:{{{1|2}}}|1|2|3|4=True|5|6|#default=False}} → True
Spell critical is the proper page name per the naming policy, but I have made Spell Critical a redirect to it.
I was hoping to have Template:TemporarySpellPower incorporated into Template:SpellPower and not two separate templates. Since the temporary and permanent bonuses have different names, it should be easy to have the template try and distinguish based on the name of the effect. ie, combustion +120 is perm for fire whereas inferno +15 is temp for fire. Further than that, only temp bonuses would have charge and recharge, so the "USAGE" could be something like:
- {{SpellPower|(type)|(bonus)|(charges)|(recharge/day)}}
  - (type) equals type:
    - Permanent bonuses
      - Combustion = Fire
      - Corrosion = Acid
      - Devotion = Positive (Healing)
      - Glaciation = Cold
      - Impulse = Force, Untyped, and Physical 
      - Magnetism = Electricity
      - Nullification = Negative (Necrotic)
      - Potency = Universal
      - Radiance = Light and Alignment 
      - Reconstruction = Repair and Rust
      - Resonance = Sonic
    - Clickie bonuses
      - Ardor = Healing
      - Brilliance = Light and Alignment
      - Cacaphony = Sonic
      - Efficacy = Universal
      - Erosion = Acid
      - Freeze = Cold
      - Impact = Force * Force Spell Power also increases physical and untyped spell damage
      - Inferno = Fire
      - Mending = Repair and Rust
      - Nihil = Negative
      - Spark = Electric
  - (bonus) equals Spell Power increase
    - Proper format is [+|-] ###
  - (charges) equals number of charges for clikies * Skip this if permanent bonus
    - Any number acceptable.
    - Assumes 1 charge if not specified.
  - (recharge/day) equals number of recharges per day for clikies * Skip this if permanent bonus
    - Number of charges restored at end of quest, rest shrine, or per minute at tavern.
    - Assumes a full recharge if not specified
    - 0, no, off, or none if the item does not recharge.
Finally, great job at remembering the tildes (~~~~) to sign your posts. On my personal talk pages, I also like it if you put your closing }} on its own line as doing that adds somewhat of a visual cue as to where posts end.

ShoeMaker (Contributions • IRC) 13:55, February 19, 2013 (EST)

1. Simple enough, mark switch defaults, good practice. Concerning creating stored variables, I will say that the templates are MUCH easier to modify with an outside program ( i used vim last night ) for the syntax highlighting, etc. ( 4 mistakes when using outside program vs over a dozen when using wiki editor ). Dealing with code duplication is much easier to deal with outside the wiki, something just doesnt sit right about essentially being forced to use something other that the wiki editor to modify code. Since the amount of changes are minimal I'll migrate away from storing variables and leave the code duplication, but I'm still not convinced the trade off (readable / easily editable code vs processor load ) is worth it.

2/3. Switch shortcuts, noted. I'll try to make use of that.

4. My mistake on the Naming policy. I looked at Spell Power with the capitalized second word and assumed Spell critical should be updated. I see now that it is the reverse that is true. Spell Power should have been fixed instead, and my references to Spell Critical need to be fixed.

5. I do agree that it's best to merge TemporarySpellPower with SpellPower. I'll work on that some tonight. I also think that it would be nice to distinguish between temp / perm bonuses. Perhaps the template can dump out an additional category identifier for temporary/permanent spell bonuses that can then be viewed. Thoughts?

6. What do you think about another template to be created that converts bonus name to element school? Combusion/Inferno goes in to template, template spits out "Fire" is what I'm thinking, that would eliminate some of the duplication of code in the parent template. Also, Force items have additional information listed in the description which is not in line with the base school information, so I think another template that returns a true/false if the description is force related would be handy. Thoughts? The more I think about that structure, the more I like it. → Joenuts (Contributions • Message) 14:42, February 19, 2013 (EST)

On #5, you mention distinguishing between perm/temp bonuses and I'm not sure what you mean. The name of what the bonus is called is its own distinguishing. Are you talking just about Cat: structure? If so, I would like to get the template working before working on Cat: structure too much, but I was thinking it could be:

[[Category:Spell Power items]]
- [[Category:Spell Power items/Permanent]]
  - [[Category:Spell Power items/Permanent/'''''(type)''''']]
  - [[Category:Spell Power items/Permanent/'''''(type)''''']]
  - etc...
- [[Category:Spell Power items/Temporary]]
  - [[Category:Spell Power items/Temporary/'''''(type)''''']]
  - [[Category:Spell Power items/Temporary/'''''(type)''''']]
  - etc...

I don't think that it is beneficial at this point to define the + bonus to spell power in the cat: structure, however, the actual line of code could read something like:

{{#ifeq:{{lc:{{PAGENAME}}}}|item|<noinclude>[[Category:Spell Power items/{{#switch:{{{1}}}|combustion|healing|other perm bonuses=Permanent|ardor|impulse|other temp bonuses=Temporary|#default=Undefined}}/{{Scase|{{{1}}}}}|{{padleft:{{Int|{{{2|0}}}}}|3|0}}</noinclude>}}

That will add a default sort to force the items in the category to be listed by power instead of names... Top of the list, less powerful; bottom of the list, most powerful.

As far as your #6 goes, Combustion/Inferno are usually of the school Evocation and not "fire." I think I know what you want to do with it, but I can't quite figure out why.

ShoeMaker (Contributions • IRC) 15:29, February 19, 2013 (EST)

I got a decent chunk of Template:Sandbox/joenutsSpellPower refactor done, which a couple of important points.

As it pertains to the item itself in the game, permanent spell power bonus values are not in the actual property name ( i.e. "Devotion" is the name, not "Devotion +60" ). The template appends the value of the bonus when sending the property name to the long popup so "Devotion +60" is displayed. This is a copy of previous behaviour, and I like that it gives more information, just wanted to point out that it was different.

Next, for temporary spell bonuses, the template expects the value of the bonus and determines the name (lesser..superior) based on the value given. I still have one statement to include in there as I just realized that Efficacy has different values than other elements. Also, the previous TempSpellAmp expected magnitude first, and element second. If references are going to be combined, a pass on the temporary transcludes will need to be done. I also need to build in logic and display for the charges / recharges.

I noticed that your Template:Scase is missing the noinclude closing tag.

Also, on grouping Spell Power items by bonus value, I do see benefit in that. I personally wouldnt want to have to click through 30 devotion items just to find the ones that are +120 Devotion. I was thinking of having the groups cascade up. Devotion +120 group is transcluded in Devotion group is transcluded in Permanent Spell Power bonus is transcluded in Spell Power bonus Items. It's nothing to tackle at the moment, just my thoughts.

I'll make another pass on the template when I have some more time. → Joenuts (Contributions • Message) 00:10, February 20, 2013 (EST)

Yes, I know the line on the actual items is just "Devotion" and not "Devotion +[value]"; however, I expect that this may change in a near future update...

In the above linked discussions, we know what the mechanic is to determine what the power is for the temporary effects, even if one is "special" that shouldn't be an issue using a #switch:. I frequently forget my closing include tags, if you fixed it that is great and if not, I'll get to it within an hour. I don't think we need to create a separate sub-category structure for spell power bonus value. I think that including the value (or some value) into the area after the pipe in the categorizing statement, which groups the items on the category page should be enough. For per bonuses, it would group them as such: 0-9 grouped under "0", 10-19 grouped as "1", 20-29 grouped as "2", ... 90-99 grouped as "9", 100+ this is where it gets tricky and we may have to use some dec2hex conversion to group 100-109 as "A", 110-119 as "B", 120-129 as "C", 130-139 as "D" 140-149 as "E", and 150-159 as "F" for now... Just an idea...

ShoeMaker (Contributions • IRC) 07:20, February 20, 2013 (EST)

Template:Sandbox/joenutsSpellPower is pretty polished and ready to replace the active Template:SpellPower. References to Template:TempSpellAmp can also be replaced with some massaging. If you have a way of automating the transition, cool, otherwise let me know and I'll track down the transclusion instances and update by hand.

I'll finish up spell lore next. → Joenuts (Contributions • Message) 21:41, February 20, 2013 (EST)

posting from my BlackBerry 9330/6.0.0.706 so it's short and will fix later. Will take a look, make any tweeks needed and fire up AWB to make the replacements.

ShoeMaker (Contributions • IRC) 07:14, February 21, 2013 (EST)

Template:Sandbox/joenutsSpellLore is ready to replace live Template:Spelllore. Make sure the category classification is what you had in mind, and it should be just a drop in replacement. I'll work on more as I have time. → Joenuts (Contributions • Message) 22:03, February 21, 2013 (EST)

Okay, so I have looked them both over. Template:Sandbox/joenutsSpellPower needs to recognize 0, no, none, off as arguments for recharges per day, and if one of those exist, don't display " (0/day)" at all.

It also needs to be set to assume that all charges are restored if left blank or is a number greater than the number of charges. So, a person should never see "Charges: 3 (/day)" or "Charges: 3 (5/day)" ever... That template still needs some work and adjusting... Template:Sandbox/joenutsSpellLore on the other-hand I think is ready to be moved. I will move it on Monday when I have more time. I'll probably not be on much this weekend if at all, so that gives you plenty of time to work on Template:Sandbox/joenutsSpellPower some more. I was also thinking we can just remove the "(TYPE)" argument for now, since there are only the two types that I am aware of at this time. The other option if you don't want to remove it is to make it require "|type= " so that it can be used anywhere and will not require an empty argument for temporary bonuses.

Also, as a side not that I just remembered above about naming policy and Spell Power, the current page name uses the capitalization in game which is why it is "Spell Power" and not "Spell power"

ShoeMaker (Contributions • IRC) 08:54, February 22, 2013 (EST)

Incorrect Category Structure[edit]

Discussions related to creation of our Category: policy have been moved to →DDO wiki talk:Category policy

Template Progress[edit]

Striding[edit]

Template:Sandbox/joenutsStriding ready for drop in replacement to Template:Striding ( self references inside template to Sandbox will have to be updated ).

Not much work to do on that one, changed formatting a little bit, and used Int template inside long popup.

I'll look at template:stat next. → Joenuts (Contributions • Message) 20:21, February 25, 2013 (EST)

Striding is fine, look at the changes I made to your final version. I would like them all to have exactly the same format, look, and coding everywhere that it is reasonable possible. Most of what I changed was little stuff, like "Long popup" instead of "long popup" and the <includeonly> tags for categorization at the end should only wrap around the category itself. Not sure what you are trying to do to Template:Stat, but I do want to warn you that that template can be finicky... You may want to leave that one for me to take care of, it really shouldn't need much except for minor stuff like a few capitalizations and line space formatting.

ShoeMaker (Contributions • IRC) 06:48, February 26, 2013 (EST)

Int[edit]

A couple of updates on the stat template. I had to make a version of the Template:Int that catches when the template is called with a empty/null variable. Problems occur when an empty variable is sent in, as the template does not detect the empty as needing to be populated by a default value. {{templatecall|1=|2=value2}} ; inside templatecall {{{1|value1}}} evaulates to empty.

I removed the extraneous verbage in the exceptional and insightful classifications that does not exist in the game any more ( ... stacks with unlike values ... ).

I removed the 'ability' catchall for items that have a random ability to be "one of" the six stats. I feel that it's not consistent with how other random properties on items are handled. If an item has one of six choices for skill modifications, the six skill modifications should be listed independent of each other, same with ability modifications.

When an item DOES modify ALL six attributes, I think the template should be used, but the items I've found that modify all attributes have their own unique modifier.

As for the noinclude / onlyinclude / includeonly tags, I think the onlyinclude tags surrounding the template that's to be injected is extraneous (the noinclude says not to include already, what's not in the noinclude shouldnt be included, there should be no need to ALSO put what should be included, as that's the nature of templates ... to be included ). My reasoning behind moving the includeonly tag to the outside of the entire category qualifying statement is that I can not think of a reason for the parent template to EVER run any part of the qualifying statement. The statement is there to determine if a category should be injected on the page, the template will never be injected in to the item category pages, so why even bother having the template process the statement? It will save a little overhead, and I think it's cleaner. ( "if you're not a template page, dont do anything. if you are in item namespace, add category" is to me nicer than "if you're in an item namespace (fail right there for templates), if you're not a template (this is meaningless because no template would be in item namespace), add category". The includeonly surrounding the category injection doesnt really serve any functionality.

Joenuts (Contributions • Message) 12:25, February 26, 2013 (EST)

I'll have to look over and modify Template:Int then, that should have its own error checking for a lack of a value, or a non-numeric value.

ShoeMaker (Contributions • IRC) 12:47, February 26, 2013 (EST)

Stat[edit]

The "Ability" section of Template:Stat was put in place for the Crystal Cove hates on which would can add +# of any stat which is built into a table... Having to list out each one individually would GREATLY increase the size of the table on an oversized page to begin with. Please leave it in. I was also thinking that a couple more could be added based on MotU stuffs that allows groups of things like Mind stats or Body stats... I haven't spent much time looking at what's what, but that was something I would like to look at.

The importance of <onlyinclude> tags in a template, is to have better control over what the template includes. You are correct in the statement it is in the nature of a template to be included, but it is greedy and the onlyinclude tags don't allow it to be (I had one template I spent like a week and a half on that had an extra linefeed where it didn't belong because I didn't have a set of onlyinclude tags).

Wrapping the entire if:NAMESPACE clause in the includeonly tags is fine. Just make sure to go through and apply that specific fix to all of them.

ShoeMaker (Contributions • IRC) 12:47, February 26, 2013 (EST)

I understand what you're saying about the template being greedy and onlyinclude giving more control. I'll give the templates I've worked on a pass to make sure that gets in there.

I dont like the idea of cluttering up a streamlined stat template to account for an assortment of random or crafted attributes that may exist on an item. It's going to add logic to the hundreds of legitimite calls to the template at the cost of the few edge cases where a single value from a pool of multiple values may exist. I think another template may be in order, give me some time to let it sink in, propose a better solution. That Cove page definitely does not need any less consolidation.

What item groups would item's like Dread Admiral's Tricorne fall in to? ( if it's in each of the Stat categories at every rank it would be in 36 item categories ( considering skill bonuses, any one of those cove hats will be able to exist in 100+ categories ) ? . → Joenuts (Contributions • Message) 19:49, February 26, 2013 (EST)

"If" the content was in Item:, then there would be 6 × 6 = 36 stat categories and 19 × 5 = 95 skills categories for a total of 131 possible combinations...

ShoeMaker (Contributions • IRC) 09:37, February 27, 2013 (EST)

Stability[edit]

Template:Sandbox/joenutsStability ready. → Joenuts (Contributions • Message) 23:07, February 26, 2013 (EST)

Almost. I would get rid of the verbose input options and {{Stability|}} should be the default the same as {{Stability}}

ShoeMaker (Contributions • IRC) 06:57, February 27, 2013 (EST)

I cleaned the verbose out and fixed the defaults for you. It is much shorter and cleaner this way.

ShoeMaker (Contributions • IRC) 09:37, February 27, 2013 (EST)

Few BIG Templates or Hundreds of little templates?[edit]

discussion moved to: Request for Comment -- (Item property) template design / structure / naming policy.

Bum[edit]

Hey jump on IRC quick... I don't have much time at the moment and have a question for you... Ague (Contributions • Message) 16:10, March 4, 2013 (EST)

Edittools[edit]

I took some time today to learn some about the edit tools. I installed it on a development mediawiki installation at my office. It's a version behind what ddowiki is running, but the CharInsert extension is downloaded from the repository, so should be current. The first thing I ran in to that I didnt like was that there was no way to have the button display one value, and have the onclick action inject another value. I've customized our version to allow for a variable to be passed in the charInsert tag that will be displayed to the browser. I'm going to work on the modifications needed to allow for multiple drop downs, with sub selects being populated dynamically from primary drop down.

If there is anything in particular you think feel has the more value that I should be focusing on instead, let me know.

-Joe → Joenuts (Contributions • Message) 19:50, March 8, 2013 (EST)

Wait, you changed the PHP in the extension to work or the JavaScript portion of it? Please copy and paste your your changes here using <syntaxhighlight lang="php"> OR <syntaxhighlight lang="javascript"> ...snip... </syntaxhighlight> to encapsulate the code so I can see what you did. That has been a back-burnered want of mine for a while to have one thing display and another inject, it's also a hot topic on the talk page for the extension.

ShoeMaker (Contributions • IRC) 20:08, March 8, 2013 (EST)

First thing I noticed was that missing capability. I modified the php file itself. Since it's an extension, variables can be passed to the parser inside the definition tag <charinsert display=ace>ventura</charinsert> will display a tag ( at the bottom ) with the word "ace", and when clicked will inject "ventura" in to the page. I'll supply the diff as well as the whole page. It was 3 or 4 functions modified total in one extension php file ( CharInsert.php ). → Joenuts (Contributions • Message) 21:06, March 8, 2013 (EST)

joe@devweb:/var/www/mediawiki-1.18.1/extensions/CharInsert$ diff CharInsert.php  ../2013-03-08.CharInsert/CharInsert.php
53,62c53,55
<
<       $aReturnValue = array();
<       $aDataList = explode( "\n", trim( $data));
<       foreach( $aDataList as $nKey => $szValue) {
<               $aReturnValue[] = charInsertLine( $szValue, $params);
<       }
<
<       $szReturnValue = implode( "<br />\n", $aReturnValue);
<
<       return( $szReturnValue);
---
>       return implode( "<br />\n",
>               array_map( 'charInsertLine',
>                       explode( "\n", trim( $data ) ) ) );
65,76c58,61
< function charInsertLine( $data, $params ) {
<
<       $aReturnValue = array();
<       $aDataList = preg_split( '/\\s+/', charInsertArmor( $data));
<       foreach( $aDataList as $nKey => $szValue) {
<               $aReturnValue[] = charInsertItem( $szValue, $params);
<       }
<
<       $szReturnValue = implode( "\n", $aReturnValue);
<
<       return( $szReturnValue);
<
---
> function charInsertLine( $data ) {
>       return implode( "\n",
>               array_map( 'charInsertItem',
>                       preg_split( '/\\s+/', charInsertArmor( $data ) ) ) );
93c78
< function charInsertItem( $data, $params = NULL ) {
---
> function charInsertItem( $data ) {
96c81
<               return charInsertChar( $chars[0], $params, $chars[1] );
---
>               return charInsertChar( $chars[0], $chars[1] );
98c83
<               return charInsertChar( $chars[0], $params );
---
>               return charInsertChar( $chars[0] );
100c85
<               return charInsertChar( '+', $params );
---
>               return charInsertChar( '+' );
104c89
< function charInsertChar( $start, $params, $end = '' ) {
---
> function charInsertChar( $start, $end = '' ) {
112,114d96
<       if( isset( $params) && isset( $params['display'])) {
<               $inline = $params['display'];
<       }
141a124
>

joe@devweb:/var/www/mediawiki-1.18.1/extensions/CharInsert$ cat CharInsert.php
<?php
/**
 * Extension to create new character inserts which can be used on
 * the edit page to make it easy to get at special characters and
 * such forth.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 * http://www.gnu.org/copyleft/gpl.html
 *
 * @file
 * @ingroup Extensions
 * @author Brion Vibber <brion at pobox.com>
 * @copyright Copyright (C) 2004,2006 Brion Vibber <brion@pobox.com>
 * @license http://www.gnu.org/copyleft/gpl.html GNU General Public License 2.0 or later
 */

if ( !defined( 'MEDIAWIKI' ) ) {
        die();
}

$wgHooks['ParserFirstCallInit'][] = 'setupSpecialChars';

$wgExtensionCredits['parserhook'][] = array(
        'path' => __FILE__,
        'name' => 'CharInsert',
        'author' => 'Brion Vibber',
        'url' => 'https://www.mediawiki.org/wiki/Extension:CharInsert',
        'descriptionmsg' => 'charinsert-desc',
);

$dir = dirname( __FILE__ ) . '/';
$wgExtensionMessagesFiles['CharInsert'] = $dir . 'CharInsert.i18n.php';

function setupSpecialChars( &$parser ) {
        $parser->setHook( 'charinsert', 'charInsert' );
        return true;
}

function charInsert( $data, $params, $parser ) {
        $data = $parser->mStripState->unstripBoth( $data );

        $aReturnValue = array();
        $aDataList = explode( "\n", trim( $data));
        foreach( $aDataList as $nKey => $szValue) {
                $aReturnValue[] = charInsertLine( $szValue, $params);
        }

        $szReturnValue = implode( "<br />\n", $aReturnValue);

        return( $szReturnValue);
}

function charInsertLine( $data, $params ) {

        $aReturnValue = array();
        $aDataList = preg_split( '/\\s+/', charInsertArmor( $data));
        foreach( $aDataList as $nKey => $szValue) {
                $aReturnValue[] = charInsertItem( $szValue, $params);
        }

        $szReturnValue = implode( "\n", $aReturnValue);

        return( $szReturnValue);

}

function charInsertArmor( $data ) {
        return preg_replace_callback(
                '!<nowiki>(.*?)</nowiki>!i',
                'charInsertNowiki',
                $data );
}

function charInsertNowiki( $matches ) {
        return str_replace(
                array( '\t', '\r', ' ' ),
                array( '&#9;', '&#12;', '&#32;' ),
                $matches[1] );
}

function charInsertItem( $data, $params = NULL ) {
        $chars = explode( '+', $data );
        if ( count( $chars ) > 1 && $chars[0] !== '' ) {
                return charInsertChar( $chars[0], $params, $chars[1] );
        } elseif ( count( $chars ) == 1 ) {
                return charInsertChar( $chars[0], $params );
        } else {
                return charInsertChar( '+', $params );
        }
}

function charInsertChar( $start, $params, $end = '' ) {
        $estart = charInsertJsString( $start );
        $eend   = charInsertJsString( $end   );
        if ( $eend == '' ) {
                $inline = charInsertDisplay( $start );
        } else {
                $inline = charInsertDisplay( $start . $end );
        }
        if( isset( $params) && isset( $params['display'])) {
                $inline = $params['display'];
        }
        return Xml::element( 'a',
                array(
                        'onclick' => "insertTags('$estart','$eend','');return false",
                        'href'    => '#' ),
                $inline );
}

function charInsertJsString( $text ) {
        return strtr(
                charInsertDisplay( $text ),
                array(
                        "\\"   => "\\\\",
                        "\""   => "\\\"",
                        "'"    => "\\'",
                        "\r\n" => "\\n",
                        "\r"   => "\\n",
                        "\n"   => "\\n",
                ) );
}

function charInsertDisplay( $text ) {
        static $invisibles = array(     '&nbsp;',     '&#160;' );
        static $visibles   = array( '&amp;nbsp;', '&amp;#160;' );
        return Sanitizer::decodeCharReferences(
                        str_replace( $invisibles, $visibles, $text ) );
}

→ Joenuts (Contributions • Message) 21:09, March 8, 2013 (EST)

Unused // Deprecated templates[edit]

What's the procedure for pruning out templates that are not longer needed? Absolute Law template has no more dependencies, I didnt know if there is a to category/tag for safe to delete, or if you leave it there forever.

-Joe → Joenuts (Contributions • Message) 21:42, March 8, 2013 (EST)

For that one, the code should be:

<noinclude>{{Deprecated|2=Dmg}}</noinclude><includeonly>{{Dmg|Absolute Law}}</includeonly>

ShoeMaker (Contributions • IRC) 22:33, March 8, 2013 (EST)

The reason we do that is because there will always be revisions of pages using the template. Most of the ones currently deprecated this way are still manually put into Category:Item description templates, which should be removed.

Also as a hint, most of the code for those pages is just a couple clicks using the current edittools default section and Meta template

Sections if I remember correctly. ShoeMaker (Contributions • IRC) 22:43, March 8, 2013 (EST)

That makes sense. dont want to break any historical pages. ( makes for clutter, but necessary evil. )

Which leads me to my next question, how do you distinguish between templates categorized as deprecated that are referenced and need to be fixed and the ones that are deprecated with no links. Are you hitting each one manually to find out if it's transcluded? or is there a master list of templates that are referenced where the reference needs to be fixed? → Joenuts (Contributions • Message) 00:31, March 9, 2013 (EST)

I don't understand what you are asking. No deprecated template needs to be fixed. If the template was merged into another one (like Absolute Law int Dmg) then it simply passes any input into the template it was merged with and let the new template worry about keeping it current. If it is replaced by another template (like (perm|temp)spellamp changed to SpellPower) then the template needs to be stripped down as much as possible while keeping it's original appearance (those ones are going to be a pain, but I'll deal with them to work out the kinks). There is no way to know what templates "use to be used" and what old revisions are using them, we must assume there is at least one and pass any input to a new template or strip out as much clutter as possible keeping the output correct. If your asking how to know which pages to change the template call (like backstabbing to Sneak Attack Bonus we just did), then in the "Page Toolbox" section of the sidebox is a link "What links here" that takes you to a list of pages that link to or transclude the page you are on or you can simply type it into your URL bar as ddowiki.com/page/Special:WhatLinksHere/{FULLPAGENAMEE}

ShoeMaker (Contributions • IRC) 06:46, March 9, 2013 (EST)

I assume for the sake of keeping things consistent, that should a template get depracated all references to the template should transition to use the new template ( not rely on the old template, even though it's going to be redirected).

It just seems to me that having a depracated template included on any page is not desirable behaviour. → Joenuts (Contributions • Message) 08:43, March 9, 2013 (EST)

Huh?

ShoeMaker (Contributions • IRC) 09:29, March 9, 2013 (EST)

Toolbox revamp / restructure[edit]

Shoe, I've been learning about the MediaWiki:Edittools, and it seems to be that trying to synchronize our existing item modifications template structure with the edittools toolbox is just going to be an uphill fight as we would be trying to make it do something it's not designed to do. It's not as dynamic as what we would want, and trying to modify it to be more flexible I think is wasted effort.

I've started working with the jquery.ui.tabs libraries that come installed with mediawiki, and I've put together an example framework that I think is pretty flexible, and not too difficult to maintain. The tabs library handles tab recursion very nicely. It's a single tree structure so if it is decided to split up the categories to make it as deep as we want, that's not a problem.

If you copy my User:Joenuts/common.js to your User:Technical_13/common.js you can see what I've put together so far. It shouldnt take much more work to copy the remaining buttons that are used over from the existing toolbox in to the jquery toolbox.

What I plan on working on next is designing extra pulldowns to exist in the item modifications children so that when a template that requires an extra value is selected, someone can select the value they want from the dropdown, hit the button and it will inject the proper template along with the value.

-Joe

→ Joenuts (Contributions • Message) 15:33, March 12, 2013 (EDT)

Javascript watchlist update[edit]

discussion moved to: User_talk:Joenuts/Watchlist.js

Chill[edit]

I know its easy to get carried with "your own" project, but trust me, the wiki is still here after you get all personal things sorted out.

I was there couple years ago and when I got back, to my surprise the thing that was supposed to go down under in flames and to be gone and forgotten, I found it still kicking and to my big surprise regarded as _the_ DDO wiki. Although a lot of things are still on the wrong track (that's why it was supposed to go down under) and some things are ...twisted, it is still here. If its up, you can fix it (after tackling the resistance to change with solid arguments). Wikis are great in that way. So chill, go kill some stuff and don't sell your sailing boat. → BlackSmith (Contributions • Message) 17:37, March 14, 2013 (EDT)

Talk:Overview[edit]

Please follow the topic as your reverting actions for the overview sections are against the wikiquette and (for all the cases this far) there has not been need for a separate overview section as the overview of the article is in no magnitude long.

→ BlackSmith (Contributions • Message) 08:39, March 18, 2013 (EDT)

Inquisitor Gnomon[edit]

Dear KW,

Went to the NPC page and attempted to replace a "no pic" image with an image of Gnomon as he appears inside Bogwater Tavern (seated). Received a message that the page was locked to edits. I uploaded the image and added a small summary but it is not linked to anything.

I also have a pic of Gnomon as he appears when you first meet him inside the cultist's base (standing) but have not uploaded that pic yet.

Anyone with the rights to add the pic can just grab it and do so.

I'll upload the second pic as well if you wish to use it instead. The second one doesn't have the blue quest completion symbol above it.

Gnomon 1 seated

Gnomon 2 standing

Peace

Xeno

common.css updates[edit]

I'm not necessarily a fan of the color changes made to the Special:RecentChanges. Is there something I can put in my User:Joenuts/common.css to revert those changes? Or something I can set in preferences or theme to not be effected by the changes? The bold green in particular shows up blurry on my screen.

-Joe → Joenuts (Contributions • Message) 13:51, March 27, 2013 (EDT)

It's a project I am working on. I'll comment them out for now. It'll end up being a widget that will allow for the change. It doesn't work on the site's default skin anyways.

ShoeMaker (Contributions • Message) 13:57, March 27, 2013 (EDT)