Template talk:Named Weapon

Needs fixing on the blank variables for pictures, don't have privileges myself Neouni 15:03, March 9, 2011 (EST)

promoted you to be able to. --yoko5000 00:10, March 10, 2011 (EST)

Crafting

Can this be re-tweaked so that the "to" between the type of crafting and item is put back? (ie, "Epic Crafting to Epic Whatever" instead of just "Epic Crafting Epic Whatever") I looked at it, and said "... yeah, I'm gonna break something if I try to fix this..." -LrdSlvrhnd 01:31, April 17, 2011 (EDT)

Such low rez argh

Can we please modify this template and others to allow better sized pics? 180px/400px is just too small and ends up looking really blurry on high rez monitors with zoom/resize happenin when it really doesn't need to happen. I mean most of us run widescreens now, so theres tons of room for better pics in these template.

It's probably the main reason I dont do many item page edits.. They just look terrible and dont show me what I want to see easy, like the itemwiki does. In a perfect world: It should display the full item, and full descript pic, all on 1 page, and look nice and not resized. At the bare minimum, the descript size needs to go up to around 470 width, as thats what the actual size is if you do a perfect crop of the games infoboxes with borders.. Or 410px with borders cut. Prolly 410 since borders aren't needed, and jj's got them like that anyways, so we can be different.

Actually technical_13 your image popup would be really nice for the full weapon pic too. So we can have a decent sized preview, and full high rez on mouse over to not kill thoses with poor bandwidth.

Here's some quick n dirty paint edit screenshots of what im talking about:

• How it looks now
• How it could look better

--Shade 14:21, July 5, 2011 (EDT)

The picdesc images dont always display well, they tend to blur since the template is telling small pics even if its a a few px to re-size to 420px and it becomes noticeable unlike the pic images which has no text to distort. After some testing would suggest using thumb Bladedge 19:14, March 26, 2012 (EDT)

Resizing option: upright might be better than thumb (which you can't use in this template as it would be ugly) and would replace 420px with, "Resizes an image to fit within reasonable dimensions, according to user preferences (suitable for images whose height is larger than width)." I've not yet tested this option and discretion would have to be aired. ShoeMaker (Contributions • Message) 20:23, March 26, 2012 (EDT)

Thumb won't have any effect on the poor image re-size algorithm the wiki uses. All it does is add a border around the image.

Yea ideally we simply don't re-size the images, but I don't know any way to do that.. Specifying no dimensions automatically re-sizes to 300px (if the image is larger then that, smaller pics are left alone) IIRC last i tested.. That seems to be the max, and well that looks like crap.

At least for us though, the simple solution is just to crop your pics to 420px as I do.. All of my recent uploads are like that, and they look fine, no resizing. See: Sword of Shadow and it's epic version I've just fixed.

It's pretty easy to do, it would not involve resizing for ANY users. As the game UI simply does not scale, all screenshots, not matter what rez you run the game at, picdescs are always 420px exactly (with wings clipped, border intact). If we get any that are a lot smaller or bigger, that means the user forcibly re-sized the image.

Maybe Xevo or Tech can figure out a way for us to be allowed to link up to 420px images without any automatic re-size, without specifying a px range.. So at least all pics up to 420px will look fine, (ones over will still be re-sized, but we can clean up manually at least).

Also read the update Naming policy as I've included some tips on how to get your images to look nice.

Shade 21:09, March 26, 2012 (EDT)

Oversized handwrap generic pic

This may be related to "argh low rez" above, but the generic pic on handwrap pages (eg Adamantine Knuckles (Level 25)) is comically oversized at 420px compared to the ~300px of normal generic pics. Can we maybe have a handwrap-specific check that fixes that? Cdr (Contributions • Message) 17:19, March 13, 2013 (EDT)

Tiefling Scoundrel

... should be added to Race options. Similarly T:Named Clothing, etc. Various items (e.g. I:Sureshot) currently say Scoundrel, which should be Tiefling Scoundrel. ⇒ Hoopy Froodle (Contribs • Message • Email) 16:46, June 22, 2019 (EDT)

• So I changed a bunch of critical templates quite a bit. Let me know it there's anything terribly wrong. --⇒ Cru121 (Contribs • Message • Email) 03:51, June 23, 2019 (EDT)

Empty input to the new 'sentience' parameter

Hey Joenuts, I think there may be something weird happening with the new parameter 'sentience' when an empty input is applied. I noticed that the idea of computing it automatically based on the minimum level works flawlessly in your sandbox example. However, you can verify for instance in Morninglord's Heavy Pick that sentience is being shown as 'No' despite the item being lv 29. Maybe there is some delay for the update to work properly on every weapon page? ⇒ MrLizard (Contribs • Message • Email) 22:22, October 14, 2020 (EDT)

Copy that. It's still a work in progress. Weapons currently call the 'named items' template with a 'weapon' attribute, which then calls the Named Weapons template, so the value of sentience needs to be passed through both. I'm aware and still testing. Thanks for pointing it out. ⇒ Joenuts (Contribs • Message • Email) 23:10, October 14, 2020 (EDT)

• Why did you implement a "hack" in the Template:Named item instead of properly using {{IO|{{#if: {{{sentience|}}} | {{{sentience}}} | {{#ifexpr: {{{minlevel|0}}} > 19 | true}} }} }} in Template:Named Weapon? ⇒ Faltout (Contribs • Message • Email) 14:57, October 15, 2020 (EDT)

• Without the "hack", the #if: {{{sentience|}}} expression in the Named Weapon template >>ALWAYS<< evaluates to false when Named Item is not called with the parameter defined. This is because if a page calls the Named Item template without defining the parameter, the Named Item template then calls Named Weapon with the same parameter, but this time passes in an empty string. Named Weapon template then sees a "defined" value of empty string, treats this as false, and assumes the page explicitly has defined the parameter as false. So all the logic of how to handle when the parameter was not defined is ignored.

If it's still unclear to you, let me know, I'll draft up a diagram of the code flow through the templates and how values are interpreted. ⇒ Joenuts (Contribs • Message • Email) 18:35, October 15, 2020 (EDT)

• I beg to differ. Let me draft up a diagram of the code flow to explain how the code I posted above works:

1. Template:Named item is called with no |sentience= defined.
2. Template:Named item passes {{{sentience|}}} to Template:Named Weapon which evaluates to an empty string because this is the default value requested (by using the character |)
3. Template:Named Weapon sees {{{sentience}}} as defined with an empty string.
4. {{#if: {{{sentience|}}} | {{{sentience}}} | {{#ifexpr: {{{minlevel|0}}} > 19 | true}} }} becomes: {{#if: <!--empty--> | <!--empty--> | {{#ifexpr: {{{minlevel|0}}} > 19 | true}} }}
5. Since the test value of the #if function is empty, it executes the 2nd part: {{#ifexpr: {{{minlevel|0}}} > 19 | true }}
6. If the {{{minlevel}}} is 20+, then the expression evaluates to true and the true part of #ifexpr is executed leading to a value of "true".
7. If the {{{minlevel}}} is 19-, then the expression evaluates to false and the false part of #ifexpr is executed. Since there is no false part defined, #ifexpr generates an empty string.
8. After that, {{IO}} takes either the "true" string or the empty string which evaluates to false. ⇒ Faltout (Contribs • Message • Email) 15:38, October 16, 2020 (EDT)

Now please remove the hack and add the proper code in the Template:Named item. Sorry if my style of explanation seems passive-aggressive, but you used bold letters and ">>ALWAYS<<" and you didn't understand what I wrote. Normally I'm very polite with people not knowing technical things, but when half the wiki is admin protected and the administrators don't know how to code properly, I struggle to keep my cool.

Note: The "hack" by itself is not really harmfull. Not implementing the true solution is, because Template:Named Weapon may be called from elsewhere without calling Template:Named item first. And the sentience may be empty instead of undefined. ⇒ Faltout (Contribs • Message • Email) 15:38, October 16, 2020 (EDT)

• If I understand correctly, your proposed code/logic will result in calls to the Named Item template with either (1) "|sentience=" defined or (2) no sentience defined as being treated the same, and the transcluded Named Weapon template will calculate the sentience value based on the formula. The desired behaviour I'm after is if someone defines sentience as the empty string on the base page, this should be treated the same as if the value were statically defined as false. And this behaviour would be the consistent if someone called Named Weapon directly, or if the template was transcluded through Named Item.

It seems like you're targetting a different behaviour than I am. Are you wanting pages where sentience is explicitly defined as an empty string to then have a calulated value when the template is parsed?

If that IS the case, perhaps we should discuss the merits of treating an empty string value the same as an undefined value.

If you're code will allow for |sentience= to be processed the same as when sentience is not defined, then I'm certainly missing something. I've tested on other Mediawiki's I manage, but was unable to reproduce. I'm not infallible though, I will continue testing.

And regarding the criticism, I always appreciate feedback. I meant nothing negative by highlighting the templates and flow. I can be long winded sometimes, so I thought it would be a courtesy to the readers to be able to focus in on the relevant components. ⇒ Joenuts (Contribs • Message • Email) 18:45, October 16, 2020 (EDT)

• I tried to create a concise set of test pages to provide a sample of code paths that can be taken through the Named Item and Named Weapon template. Feel free to review / update Test Cases, Named Item Stub, and Named Weapon Stub. I tried to use the expression you provided, but I am unable to get that code to achieve the desired/expected results of treating the parameter as false when a statically defined empty string value is supplied. I understand your concern that the behaviour be consistent whether the named weapon template is called directly or indirectly, and I would like to point out the the actual solution affords this consistency. If there is a cleaner way to implement the behaviour, by all means, I'm willing to learn, but currently any approach other that what I've implemented escapes me. Thanks in advance, ⇒ Joenuts (Contribs • Message • Email) 03:22, October 17, 2020 (EDT)

• Why does it make sense to treat an empty (but defined) parameter differently than an undefined parameter? I'll tell you the reasons why you shouldn't: What most editors do is copy the templates from another page that works and adjust the fields. If they don't know the value for some field they will leave it empty (but defined). Thus the intention of the editors is to leave the values as undefined and not to take the emptiness as a meaningfull value. What some other editors do (including me) is copy the template's call code from the template page (and that's why most of my templates contain a "preformatted" code for copy-paste) and fill in the blanks. Again, the intention of leaving a parameter empty is to have it undefined. Seeing as this is the expected behavior of parameters and is respected by most template editors, there should be consistence across the wiki.

The above were the valid reasons supporting what I proposed. Now let me list some "funny" reasons why the current way doesn't work like you think.

1. In Template: Named item, you yourself wrote: Default(empty) means calculate based on item level, [-,0,n,no,none,off,f,false] to explicitly define as No, any other value means Yes. Now you say you meant for empty to mean false?
2. In Template: Named item, the "hack" code is | sentience{{#if:{{{sentience|}}}||NULL}}={{{sentience}}}. If sentience is defined but empty, the #if function will still evaluate it as false and execute the NULL part. Which means that this "hack" code still treats an empty parameter as undefined and not as false. Perhaps what you should have used is: | sentience{{#ifeq: {{{sentience|1}} | {{{sentience|2}}} | <!--empty--> | NULL}} = {{{sentience}}} which correctly passes sentience as an empty value if it is defined.
3. In your User:Joenuts/Sandbox/TemplateNamedItemStub you did not copy your code correctly leading to a completely different result. | sentience{{#if:{{{sentience}}}|NULL|}}={{{sentience}}} means: If sentience is defined with any non-empty value (true, false) or if it is left undefined (in which case the value will be the string "{{{sentience}}}", it will pass sentienceNULL. If sentience is defined but empty, it will pass an empty sentience parameter. I've updated your testcases with some sentience=true values to see for yourself.
4. You also copied half of my code. I've changed that as well to print "Yes/No".

Keep in mind, the valid reasons are in the first paragraph. ⇒ Faltout (Contribs • Message • Email) 08:01, October 17, 2020 (EDT)