User talk:Chieftain Alex/Archive 8

potato skins

What would you think about having Justin create a Skin: namespace for us? I've been considering this for a while, and I think it could work out very well. Every skin would have its own page in that namespace, with an infobox and a semantically-queried list of items that use it. On the other end, every item that uses the skin would lookup the skin's icon (overridable) and a screenshot.

I could go into more detail, but I just wanted to bounce this off of you before making a more formal proposal on the CP. —Dr Ishmael 20:53, 7 August 2014 (UTC)

didn't I suggest this before?... This is a brilliant idea. Get it done. -Chieftain Alex 21:26, 7 August 2014 (UTC)

k it was a sandbox for that bit. Namespace idea sounds familiar but can't place where. Edit: oh. next sandbox revision. -Chieftain Alex 21:28, 7 August 2014 (UTC)

I think I remember seeing that... of course, if you linked it anywhere it would've been with external formatting, so WhatLinksHere is no help. It may have even been the inspiration for this idea of mine. Feedback loop!

A possible argument against this is having to type the namespace prefix in order to find the skin page. Whereas Viridian Antique Warhammer is right there, [[Skin:Viridian Antique Warhammer]] is... well, 5 more keystrokes. Obviously, we can automate this in a lot of templates, and MediaWiki:ChatLinkSearch.js will "just work." I don't see this as much of a drawback, really. —Dr Ishmael 22:01, 7 August 2014 (UTC)

I’m not sure about that actually. Creating a namespace is like creating a disambiguation rule where one kind takes precendence over the other. And I’m not convinced that individual items are of more interest than skins all the time (actually I would say the opposite). Having a Skin:Some name is like having Some name (skin) where Some name already is an item article. There is literally no difference except that—by introducing a new namespace—we force all skins to have that prefix even if there are multiple skins that don’t need this, e.g. Crimson Antique Spire. I’m not too sure if there are actually any benefits apart from making the article titles “more clear” (mostly to please ourselves).

A new namespace introduces a completely separated level of content, and I don’t see skins—being a normal part of the game—like that. poke | talk 22:36, 7 August 2014 (UTC)

so basically you don't want to document a key part of the game. .... or you want to have skin info mixed up with weapons. Or you want qualifiers everywhere. -Chieftain Alex 00:02, 8 August 2014 (UTC)

plus we can roll out automated page content across an entire namespace without worrying about fixing links. -Chieftain Alex 00:04, 8 August 2014 (UTC)

"I could go into more detail" Welp, looks like I'm gonna have to. :)

Poke is right - it is a lot like making a strict disambiguation rule. But in my eyes, that's a good thing because it systematizes the rule, and that's the entire point of my proposal. I also don't see it as saying "skins are less interesting than items," but again, I see the opposite: "skins are so important we made a whole namespace just for them!"

• If we continue with the current system, we will have a hodgepodge of skin pages at the skin name, skin pages with a "(skin)" suffix, and even combined skin/item pages. A reader won't know ahead of time whether the page at Chainmail Helm will have the information on the skin or information on the items (or both), nor would they know where else to look for the skin information. Even when they do find the info on that skin (for the sake of argument) on that page, that knowledge won't necessarily help them in the future when they look up a different skin - the info for that skin may be on the "(skin)" qualified page, because there's no systemic rule saying where the skin info is.
• On the other hand, if we systematize skins by placing all of them together in the "Skin:" namespace, then once readers find out about it (after their first skin-info search, say, or if we feature it on the main page), then they'll know exactly where to find info on every other skin. We can even create a [[Skin:Portal]] page to serve as an index of the namespace - I guarantee that if we made that page awesome, a LOT of players would bookmark it as their entry point to the wiki.

To go on a short tangent, if I were building a game wiki from the ground up today, I would create multiple namespaces like this in order to compartmentalize the documentation of different types of game content, because I can see now that it would make a lot of things so much simpler - decreasing the frequency of page qualifiers being the most obvious. Here, I'd basically replace {{Property:Has game context}} with namespaces: Item, Skin, NPC, Location, Skill, Trait, etc.

There are a few technical benefits to a namespace: a reader searching for skins and only skins can restrict a wiki search to the namespace; filtering semantic queries by namespace is much more efficient than filtering by a property value; you can write CSS styles on a per-namespace basis. —Dr Ishmael 01:13, 8 August 2014 (UTC)

anti- chatlink creation from gamelink

bwahaha.. I'm so embarassed that I've wanted this for months but not been able to formulate how to do it. -Chieftain Alex 20:38, 8 August 2014 (UTC)

No idea what you’re even doing there, but this doesn’t do what you think it does:

var itemid = tags; // Initialise same size array

It’s neither an array, nor creating a new one… :/ poke | talk 22:34, 8 August 2014 (UTC)

Greatsword Alex

Uh, why is image 18 in the Gallery of greatswords linked to you? Or rather, a non-existent page. Is this some sick joke!? --Ventriloquist 16:44, 10 August 2014 (UTC)

[1] —Dr Ishmael 19:30, 10 August 2014 (UTC)

Begs the question: why doesn't the game have an Alexander the Greatsword (to be used in a "jumping puzzle" or mini-dungeon to untangle the Gordian Ecker, a mess of tangled threads). (The first reference should be obvious; the second will only make complete sense to followers of the GW1 wiki, who are familiar with the gw1:User:Gordon Ecker and a particular bit of history.) – Tennessee Ernie Ford (TEF) 20:40, 10 August 2014 (UTC)

I teehee'ed. - Tanetris (talk) 22:43, 10 August 2014 (UTC)

Blanked the offending page. smw in the userspace is always a mistake.. -Chieftain Alex 00:13, 11 August 2014 (UTC)

5 minutes

Is not long enough for a response. Be patient more. - Tanetris (talk) 20:10, 15 August 2014 (UTC)

I don't think I've never had a single useful comment from IRC dwellers, and 5 minutes is way beyond the amount of time I'm willing to wait in silence for answers. -Chieftain Alex 20:11, 15 August 2014 (UTC)

Your two statements here are highly interrelated. - Tanetris (talk) 20:13, 15 August 2014 (UTC)

You have to ping people with their name. Spamming "Tanetris" every thirty seconds tends to work.--Relyk ~ talk < 00:30, 16 August 2014 (UTC)

Interesting

Just got an email from the wiki-en.stage version of this wiki telling me that a page on my watchlist got changed (by stephane). That is the test wiki for the upgrade yes? In that case so much stuff is borked in vector :( Plus the collapsible side menus look awful. -Chieftain Alex 18:05, 21 August 2014 (UTC)

It's the step before test, actually. Dev is where Justin runs through installing extensions or upgrading stuff to make sure there are no issues with the build. Once he has the procedure figured out and any bugs squashed, he goes and does the same thing on the Test server, which is where the QA people do some thorough testing of the wiki software itself.

A couple months ago I worked out some kinks in the Monobook CSS for MW 1.23, and it looks like Justin has carried them forward to the current iteration of Dev. If you'd like to play around and fix the Vector CSS, that would make things smoother when we finally get around to implementing the upgrade. —Dr Ishmael 18:12, 21 August 2014 (UTC)

Thanks for explaining. The updated internally generated MW html has been cleaned up quite a bit, no more random comment blocks identifying logos etc. Unfortunately the vector menus have inline css... reckon any chance of us getting Justin to break the collapsibleness of them? :P -Chieftain Alex 18:34, 21 August 2014 (UTC)

I doubt it, because that would require a change to MW core files which would have to be documented and then propagated through any future upgrades. He's always been reluctant to do anything like that in the past, and I agree with him. —Dr Ishmael 18:42, 21 August 2014 (UTC)

Derp. Gonna have to kludge some javascript together to "fix"/break that functionality then. Core edit is addition of a # sign. -Chieftain Alex 19:13, 21 August 2014 (UTC)

Question about Semantic MediaWiki form

Hi Chieftain Alex,

Left a question about a Semantic MediaWiki form that you may have worked on: Form_talk:Vendor_query

Thanks!

--Stephane Lo Presti talk 22:20, 5 September 2014 (UTC)

armor table

I'm tempted to remove all that code for the offset calculations. I'm not sure what it's doing or why it's needed. The coding should look like vendor table unless it's missing something.--Relyk ~ talk < 19:21, 6 September 2014 (UTC)

I was thinking about adding the offset calculation code to the vendor table. If we're pretending that smw is any good at all for searching (like Special:Search, Google or gw2db etc), then we should have some kind of indicator about how many results there are, and how many the user is viewing. -Chieftain Alex 19:25, 6 September 2014 (UTC)

Then use the semantic search? If your query has more than 250 results, using the form loses its value for any general user and users should switch to the semantic search function. It's not worth complicating the code. Even having an offset in the form isn't helpful for most people.--Relyk ~ talk < 19:50, 6 September 2014 (UTC)

On an unrelated note: "The reply to your comment was a subtle hint that you like to suggest projects of epic proportions and then let someone else do them." is a dick statement to say when I've already worked on projects of epic proportions, while being unreasonable and uncalled for.--Relyk ~ talk < 20:09, 6 September 2014 (UTC)

No its me being a prick and anticipating the complete lack of help implementing stuff (such as the Vendor Table Row template) that you've designed. -Chieftain Alex 20:10, 6 September 2014 (UTC)

I wasn't ready to implement it yet, you went ahead and did so on your own. I had plans to rewrite {{inventory}} at the same time :(--Relyk ~ talk < 21:02, 6 September 2014 (UTC)

weapons and containers

Take a look at Handspar and let me know what you think. I know it's somewhat odd to put different item types on the same page, but there's absolutely nothing interesting about the containers. If there were an easy way of finding out which specific container can contain which specific weapons, then it would make sense to document that info on a separate page. But they're all account bound and very rare drops, so it seems unlikely we'll ever get a sufficient level of info. Thus, to keep things simple, I figured we may as well toss them in with the weapons just so that the IDs are annotated for chat link search.

Also if you can improve the spaghetti code nature of it any, go ahead. —Dr Ishmael 21:13, 19 September 2014 (UTC)

Looks fine. We had this thing about containers being boring before when we covered the costume pages didn't we. -Chieftain Alex 21:30, 19 September 2014 (UTC)

Heh, yeah - at least in that case it was 1 container = 1 item.

The main thing that bothers me is redefining the variables for the container listing. I suppose I could encapsulate that in its own template. —Dr Ishmael 21:34, 19 September 2014 (UTC)

pvx

wish i was an admin >.>--Relyk ~ talk < 21:17, 26 September 2014 (UTC)

wish curse would get off their arse and send me the current pvxrate source code so i can roll it into one score to rule them all. -Chieftain Alex 21:20, 26 September 2014 (UTC)

offer them money or bribe them with some nude photos of yourself.--Relyk ~ talk < 21:24, 26 September 2014 (UTC)

hey you can just prod Auron! -Chieftain Alex 21:26, 26 September 2014 (UTC)

MediaWiki:Vector.js

Over on the test wiki, you had written a new function uncollapsibleSidepanel(). Do we really want to implement that? It feels like something that should require an opt-in, since it's a significant modification to the skin's default functionality. I don't use Vector, so I'll leave it up to you and anyone else who does use it. —Dr Ishmael 18:58, 1 October 2014 (UTC)

Its super hideous as collapsible, but I reckon I could work around it by writing display:block to them instead.. -Chieftain Alex 21:19, 1 October 2014 (UTC)

Wierd, you didn't implement the uncollapsible stuff, but its not collapsed by default anymore.. it caches the expand/collapse logic? -Chieftain Alex 21:41, 1 October 2014 (UTC)

I think it stores the state in a cookie, same as the TOC state. —Dr Ishmael 21:44, 1 October 2014 (UTC)

Then there is no need to do anything since once I banish the menu I can no longer see the collapsible arrows :p -Chieftain Alex 21:46, 1 October 2014 (UTC)

Blocks

I haate you for giving unbearably long blocks!!!!! —The preceding unsigned comment was added by Awdawdawd (talk • contribs) at 01:49, 3 October 2014‎ (UTC).

Hello 216.176. -Chieftain Alex 07:07, 3 October 2014 (UTC)

This is pleasing. --Ventriloquist 07:44, 3 October 2014 (UTC)

Job queue and SMW rebuild

Note that the rebuild is not done via the job queue now but directly from the command line. So the job queue has nothing to do with it. poke | talk 15:50, 4 October 2014 (UTC)

shouldnt it be done by now, it's been longer than 24 hours >.> -Auron 17:51, 4 October 2014 (UTC)

Yeah, the rebuild is done (hence the site notice being removed). However, many pages are still being processed as part of the job queue, so some lists will still display old content until they are purged. I’m working on getting that done. poke | talk 17:55, 4 October 2014 (UTC)

Ah so command line enters the wiki processing queue before the job queue.. hence why the queue had been stuck and is now going down? -Chieftain Alex 18:32, 4 October 2014 (UTC)

The SMW rebuild is not actually done as “jobs”, it just hooks itself into the job queue work mechanism, so it is progressed at the same time (when being used). As that is dependent on page views however and takes a while, we decided to run the rebuild directly. That’s done now, so all SMW data is up to date. The jobs were created for those pages that used outdated SMW data (i.e. all those SMW lists for example recipes). Since that would have again taken forever, we are running the job queue now also as a separate process. That’s why it’s shrinking so quickly now. Once it’s down to zero, hopefully all pages will display all information.

As for why the job queue was “stuck”, it’s probably just very slow when triggered by page views. poke | talk 18:41, 4 October 2014 (UTC)

Rig

DVI to VGA? Did you get it from a museum? :D — snograt 02:09, 16 October 2014 (UTC)

Heh the monitor is only 3 years old. Kinda pissed after spending 470 on it and its basically unusable until I can fix the monitor problem... I should probably test it using someone else's monitor/tv before then, otherwise I'm screwed if it turns out that the card is blown. -Chieftain Alex 07:16, 16 October 2014 (UTC)

I'm still a bit confused. I haven't seen a monitor with VGA-only input for many, many years. Was it particularly cheap, or is it something special they only sell to scientists? — snograt 12:13, 16 October 2014 (UTC)

Seriously, though, DVI-VGA adaptors are a piece of shit, in general. A piece of dumb hardware trying to suck analogue from a digital pipe is never going to end well. There are such things as active converters (see here for starters), but it's all a bit trouble-shooty. — snograt 16:12, 16 October 2014 (UTC)

£120 or something. It was pretty much the last one Argos sold nearby - an identical one that I'd bought of a more recent model # had a dvi, but it also had purple lines on the monitor... needless to say that one went back and I was happy with the normal-coloured vga.

Now that I think about it, there is an active DVI to VGA adaptor on the back of my monitor at work and I could "borrow" that to see if that'd work -Chieftain Alex 17:39, 16 October 2014 (UTC)

verify template

I didn't know what you were trying to fix in that template. Now that you've pointed that out, yes, I see the same thing in that revision of that page. Clearly this template should not be used within section headers - or anything superscripted, really. —Dr Ishmael

Template:Item table

Help me get it formatted correctly at some point before someone tries using it and decides to update a bunch of pages.--Relyk ~ talk < 07:52, 22 October 2014 (UTC)

I hate SMW. poke | talk 13:06, 22 October 2014 (UTC)

Ah yes the good old days of gww:Template:Skill table + gww:Template:Skill infobox/concise row format.

Apart from the buggy as shit #ifeq: that we all just observed with {{item table result format}}, SMW is alright. Workable in many cases. -Chieftain Alex 18:52, 22 October 2014 (UTC)

It’s not ifeq’s fault; parser functions remove whitespace around arguments, that’s normal. It’s that SMW apparently handles whitespace different in some situations. If you put a {{#tag:pre| … }} around the SMW call, you get the wikitext output it produces. If you use that output, the table is rendered perfectly fine. Yet, when not using the #tag parser function, apparently whitespace is gone so SMW can’t render the table. It’s so weird. poke | talk 19:03, 22 October 2014 (UTC)

Drop research

So, people are opening crazy amounts (like 90,000) of Trick-or-Treat Bags, without documenting their results on the wiki. While I blame part of that on pure laziness or not knowing that we document these things, I also think that our documentation process is far too complicated. If I just look at the SDRL template at Trick-or-Treat Bag/Drop rate, I’m already confused and don’t know where to start. And we probably haven’t even found out everything that can drop out of the bags. It also doesn’t help that the current drop research mechanics require individual item results (e.g. if I get 5 candy corn at once, I still have to only add 1). It’s just very impractical, especially considering that each bag drops 4 items of varying quantity each. That’s why I have been an advocate of Trick-or-Treat Bag/Drop rate/archive#Batch Data (discussion).

So, I was thinking how we could simplify all this. I know that you have been working on having a form input for some drop researches, but I don’t know how far you went with them. Are they usuable? Otherwise, I’m thinking about creating some magic widget that does all the work for users, but I’m not so sure how to do it yet. poke | talk 16:57, 23 October 2014 (UTC)

looks like I forgot to set manual totals. Fixed on the drop rate page. Effectively that IS now batch data.

I considered making a form (edit summary on the drop page history: "remind me why I never produced a form for these?") but it takes a bit of effort and I wasn't seeing any need for it. I can generate one fairly quickly. My concern yesterday was that theres too many items to copy the form layout that I used for Glob of Ectoplasm/salvage research. The layout on Trick-or-Treat_Bag/Drop_rate/archive#Batch_Data_(alternative_format) might be viable - we could only display the entry that they're working on, and just show the results of the rest (I'm sure thats possible somehow!)

alternative: embed a google spreadsheet using one of the widgets found via google. -Chieftain Alex 17:37, 23 October 2014 (UTC)

the alternative_format link I gave above was before i saw your sandbox. I'll put some effort in and see how this turns out. -Chieftain Alex 17:38, 23 October 2014 (UTC)

Don’t invest too much effort though, I’m actually trying to build some JavaScript thingy now that makes it a bit easier.. Maybe that works, or maybe it doesn’t. poke | talk 17:49, 23 October 2014 (UTC)

Wow, that looks pretty good already! Good job! poke | talk 18:32, 23 October 2014 (UTC)

20 minutes to make the forms + templates. An hour to debug the forms + templates. Half an hour mucking about with the formatting. The final result seems to be a working template.

It does take a while for the template to load - perhaps quicker to embed the file names instead of doing smw ask for the icon and cname each time (given that I'm hiding previously saved edits). -Chieftain Alex 20:10, 23 October 2014 (UTC)

It works now for heights down to 200px at which the red background at the top will go above the bottom background, which will still only end up in some weird shadows from the red background. So, I win. poke | talk 22:32, 23 October 2014 (UTC)

Miniature Template

Your miniatures template (User:Chieftain_Alex/Templates/Miniatures) is not showing Zuzu correctly, it got splitted into 2 minis... -- Maplemist (talk) 22:11, 24 October 2014 (UTC)

fixed, thanks for reporting the issue. -Chieftain Alex 09:22, 25 October 2014 (UTC)

I noticed that the count of special minis is not reflecting the actual amount of special minis. The count states 141 in total, but there are only 138 icons. --Maplemist 18:41, 16 February 2015 (UTC)

I've tracked down the problem, its down to relyk's last changes to {{infobox status}}. Working on it. -Chieftain Alex 20:32, 16 February 2015 (UTC)

There were 3 minis with bad historical status annotation, so once those clear up (job queue still at 3000), we'll need someone to purge the template page. -Chieftain Alex 21:47, 16 February 2015 (UTC)

Personalized Trick-or-Treat Bag form

Would you be able to create a variation of the Trick-or-Treat Bag/research form for [[Personalized Trick-or-Treat Bag/Drop rate]] (which should probably be renamed to "Personalized Trick-or-Treat Bag/research" for consistency)? I would attempt to do it myself, but I don't know if it's really as simple as just copying + pasting it and adding "Personalized" to the name. x.x Thanks. :P

-Somohexual (talk) 17:25, 1 November 2014 (UTC)

It really is as simple as that. I've started the templates for you, but you'll have to go through and remove items that are irrelevant to personalised bags. Edit these three before starting...

• Form:Personalized Trick-or-Treat Bag research - item names are listed twice, so be sure to fix both. first generates icons for later usage, latter is presenting the entry form.
• Template:Personalized Trick-or-Treat Bag research summary - you'll need to edit the table rows.
• Template:Personalized Trick-or-Treat Bag research line - you'll need to edit the list at the top.

Then you just go to the form page, and follow the links which will then create the research page for you. Don't worry about data from previous years, ignore it for the moment. -Chieftain Alex 18:21, 1 November 2014 (UTC)

I guess if they are exactly the same loot table then we could make them use the same templates. -Chieftain Alex 18:31, 1 November 2014 (UTC)

Ok attempt #2. Assuming the possible loot (in terms of items) is exactly the same, they now share {{Trick-or-Treat Bag research header}} + {{Trick-or-Treat Bag research summary}}. Because the form doesn't like parameters changing names, I've created {{Personalized Trick-or-Treat Bag research line}} (which uses Personalized Trick-or-Treat Bag instead of Trick-or-Treat Bag). Edit the form via [[Form:Personalized Trick-or-Treat Bag research]]. -Chieftain Alex 18:59, 1 November 2014 (UTC)

Thanks so much. :D -Somohexual (talk) 19:53, 1 November 2014 (UTC)

Icons from .dat

I saw you added the Determined.png file from the .dat. How did you do? I'd like to extract the Trample icon the Elite Harathi Tramplers have during the second phase of Prevent the centaurs from capturing Nebo Terrace. It's not uploaded yet, it's a bull knocking something. 17:49, 13 November 2014 (UTC)

Download the icons at User:Dr ishmael#Icon archives.--Relyk ~ talk < 18:27, 13 November 2014 (UTC)

Template:Lore discrepancy

Perhaps you could shed some light on what I'm doing wrong? Titus The Third 20:04, 14 December 2014 (UTC)

Giant Wintersday Research

As you got the drop research for the Trick-or-Treat Bag running, I request you to do the same for the wintersday gifts, especially the giant ones. --Soulblydd (talk) 17:50, 19 December 2014 (UTC)

Done, but only for Giant Wintersday Gift/research. The drops are slightly different for each gift so no way am I burning my entire evening making all of those :p

Each item has its own

• research page (e.g. Giant Wintersday Gift/research)
• form (e.g. [[Form:Giant Wintersday Gift research]])
• line template (e.g. Template:Giant Wintersday Gift research line)
• summary template (e.g. Template:Giant Wintersday Gift research summary)

Multi-purpose templates:

• [[Template:Container research header]]
• [[Template:Container research icon]]

If you want to set up more research pages, you'll need to create the "research page, form, line + summary templates" for each page. -Chieftain Alex 18:55, 19 December 2014 (UTC)

Is for profession

Maybe you could discuss it instead of a double revert? You will never use the Is for profession::!Any in a query. In addition, I'm not sure what you mean as the query is working for me. The Any value invalidates the values being pages, so we might change it to String if it interferes with queries. Adding profession as a value is not a solution.--Relyk ~ talk < 20:23, 24 January 2015 (UTC)

Evening. The query I was having problems with was on Help:Ask a wiki question#String comparison for #ask criterion?.

If you try to filter specifically to remove options that aren't the 8 main professions, then you need to remove the "Any" values. Unfortunately because Any redirects to Profession, the query will only work if you ask it to avoid "Profession" as an option... but then it throws a semantic error and says "Profession" isn't on the list of expected options. So that's why I added it.

Compare the following queries:

Query 1 code

{{#ask: [[Has game context::Skill]][[Has game icon::~*(*)*]][[Is for profession::!Any]] | limit = 10 | offset = 5 | format = ul }}

Query 1 result

Query 2 code

{{#ask: [[Has game context::Skill]][[Has game icon::~*(*)*]][[Is for profession::!Profession]] | limit = 10 | offset = 5 | format = ul }}

Query 2 result

Only query 2 has worked correctly - there are no non-profession only skills in this list. The items in query 1 list include pages where "Is for profession::Any".

You're right that making it a string property instead would fix this problem. I admit that the existence of "Any" as an option irks me (Any is not a profession!) but I guess otherwise we can't query for it. -Chieftain Alex 22:15, 24 January 2015 (UTC)

Semantically, "Any" means any of the professions so any skills with that value is for a profession. If you want skills that require any specific profession, you would do {{#ask:[[Has game context::Skill]][[Is for profession::Warrior||Guardian||Elementalist||Necromancer||Mesmer||Engineer||Thief]]}}. What you are asking is give me in page with a skill context, a game icon with disambiguiation, and is for a profession that is not for any profession. It doesn't make sense to negate the Any value here, you would want the value to represent null/unknown the way you are trying to use it. I'm not sure why you're are saying query 2 works correctly when it's showing Burning Retreat (Lava Axe skill), a skill any profession can use from the bundle. Because the professions can use skills to create bundles, trying to filter out skills that any profession can use in the first place is questionable. The [[Is for profession::!Profession]] doesn't make any sense simply looking at it. I don't like that approach nor think it's useful for us.--Relyk ~ talk < 23:17, 24 January 2015 (UTC)

"I'm not sure why you're are saying query 2 works correctly when it's showing Burning Retreat (Lava Axe skill), a skill any profession can use from the bundle." It is correct according to that skill's data on the wiki.

The problem arises from the failure of SMW to allow querying for a "null" value. If that were possible, then we wouldn't set Is for profession at all on generic non-profession skills. Since SMW can't do that, we have to set something, so we decided to set it to "Any". Would it make more sense to you if we set it to "None" instead? Either way, "Any" or "None" has to be a page in the wiki (or we change the property from page to text). —Dr Ishmael 02:07, 25 January 2015 (UTC)

I think we're all agreed that setting it to text would avoid future upsets. -Chieftain Alex 02:10, 25 January 2015 (UTC)

Then we'll potentially have to modify all templates that display that property in a query to make sure it gets linked. —Dr Ishmael 02:12, 25 January 2015 (UTC)

Most times that we use queries we set link=none anyway, so I'll change it now + we'll address problems when they turn up. -Chieftain Alex 02:13, 25 January 2015 (UTC)

It also means we can't do subqueries, we have other ways to form those queries I think.--Relyk ~ talk < 06:40, 25 January 2015 (UTC)

What sort of subqueries would you do against profession? —Dr Ishmael 14:48, 25 January 2015 (UTC)

@Alex, another thing I forgot - text properties are case-sensitive for allowed values. —Dr Ishmael 15:52, 25 January 2015 (UTC)

The professions categories, but that's simply using disjunctions of professions.--Relyk ~ talk < 17:34, 25 January 2015 (UTC)

@ ish, balls. Sorry for breaking stuff >.> And now queries will be case sensitive too... *can of wurms* -Chieftain Alex 17:41, 25 January 2015 (UTC)

I've run a bot to convert all of the pages using {{trait table}} to the format [[Is for profession::<uppercase first profession>|<lowercase first letter profession>]]... so they should all be using the uppercase profession for the property now.

However, now that I see that this property seems to be frequently invoked on those pages directly, I now see why they were defined as type:page. I'll run back through the pages + change it to a wiki-link at the top with a #set at the bottom. -Chieftain Alex 18:39, 25 January 2015 (UTC)

All the values should be uppercase and handled by the templates anyways.--Relyk ~ talk < 19:29, 25 January 2015 (UTC)

Alex's point is that trait line pages like Domination set it directly without a template. It doesn't make sense to write an infobox for those pages. —Dr Ishmael 21:10, 25 January 2015 (UTC)

Ah yes, I was confused with how he phrased.--Relyk ~ talk < 22:22, 25 January 2015 (UTC)

On a side note, this slightly fucks up forms. I doubt having professions as strings will be useful in any queries the wiki uses. I remain of the opinion this is a terrible change and simply creates more work for us.--Relyk ~ talk < 22:58, 6 February 2015 (UTC)

Do you mean the lowercase + uppercase options? -Chieftain Alex 20:46, 10 February 2015 (UTC)

I get insane sometimes...

I didn't expect you to change so quick lol... I was experimenting with traits and then, all of a sudden, facts were there, and I thought it was a bug. o.o – Valento ^msg 20:18, 10 February 2015 (UTC)

Oh, and btw, I call them "facts". Agree with you this parameter should be renamed at some point. – Valento ^msg 20:23, 10 February 2015 (UTC)

I meant renaming the property from "Has skill facts" to "Has facts"... not the parameter. I guess this would be good to do before usage spreads. -Chieftain Alex 20:47, 10 February 2015 (UTC)

Although, "Has facts" seems a bit ambiguous. The alternative would be to go for "Has trait facts". -Chieftain Alex 20:54, 10 February 2015 (UTC)

infobox status

{{infobox status|{{{status|{{#ifeq:{{{historical|n}}}|y|historical}} }}} }}

Does that make more sense? I think so. The backwards-compatible historical parameter just seems confusing. —Dr Ishmael 20:52, 16 February 2015 (UTC)

Yes it makes much more sense. I'm still going to remove the historical variable >.> -Chieftain Alex 20:54, 16 February 2015 (UTC)

Looks like I broke it + you fixed it again. -Chieftain Alex 08:05, 17 February 2015 (UTC)