Template talk:Event infobox/Archive 1

Functionality revamp

Right now I'd say we are in dire need of an event template, but this one just doesn't cut it. The main problem probably is that the current one was created a while ago when we did not have as much info available to do everything correctly. So, for the past few days I have been working on some changes and here they are:

Changes ASAP (see live)

• Params location and region have been renamed to area and zone respectively to follow the new raising consensus.
• Parameter storyline was listed as optional but actually wasn't - fixed.
• Introduced required parameter level, as all/most events seem to have it.
• Parameters start_npc and npc_map are now optional, not all events must be started by an NPC - many of them literally just happen.
• Parameter type is now used for the real in-game type of the event(Group event, Renown Heart...) instead of largely subjective, i.e. "Gathering", "Defense", "Capture".
• You now may list multiple previous/next/fail events, this just had to be added - you can't pick one followup event at random when there are three of them.

Other changes to consider

• Param race could be maybe removed seeing as there are probably no race-specific events aside from tutorial and it can make confusion.
• Param heart should be maybe renamed/removed or just somehow cleared up, right now it seems confusing - even more if the template is used on a heart itself and way more if the influenced event is not even a heart. I have been considering a rename to either influences or simultaneous.
• A slight/unslight design change may also be in order since the event names are absolutely huge, and I even have already thought of some. However, of course I'd like to push functionality first so we can use the template at all.

Are there any objections against the changes? Any input is welcome. ***EAGLEMUT*** TALK 22:12, 17 May 2012 (UTC)

As an update, I have also taken measures to make storyline optional once again. I have also inserted a break between the area and map; these two were never going to sit together on one line and it looks cleaner to simply have the zone on the second. This infobox is very soon going to be used for the heart infobox as well--in terms of information presentation, it serves the purpose quite well--so break the peace now if there are objections/considerations to be brought to light. Redshift 14:23, 12 June 2012 (UTC)

TOC

Why does this include {{TOCright}} at the end? It places the TOC to the immediate left of the infobox, which looks very strange. —Dr Ishmael 15:45, 18 June 2012 (UTC)

I removed it not long ago, but the changes outlined above were later implemented, and that re-introduced it, probably unintentionally. Anyway, I agree, the TOCright shouldn't be there. pling 17:02, 18 June 2012 (UTC)

Ha! I have been wondering where the ToC is coming from. It seems I have copied the template code from before you removed it and overlooked the change afterwards. I have removed the ToC again for now, thanks for pointing this out. ***EAGLEMUT*** TALK 17:14, 18 June 2012 (UTC)

npc_map + text broken

what the title says. when trying to use either, they don't show up. Previously Unsigned 10:52, 1 August 2012 (UTC)

I think I managed to fix it. -- ab.er.rant 11:16, 3 August 2012 (UTC)

You did.Previously Unsigned 09:37, 4 August 2012 (UTC)

Needs support for multiple areas

Many events take place in multiple areas, especially escort events. Could someone please edit the infobox to accept additional areas? Maybe a "area2", "area3", etc parameter. And while I'm here, "elite events" don't exist, they were renamed to group events. Manifold 01:02, 8 September 2012 (UTC)

We need support for multiple everything everywhere. I really wish we'd pushed harder for SMW 4 months ago so we could use #arraymap instead of having to create additional parameters all over the place. —Dr Ishmael 02:03, 8 September 2012 (UTC)

Well, we could just use that one "area" we have as the "starting point". Any other areas it involves can simply be put into the description of the event right? -- ab.er.rant 06:09, 8 September 2012 (UTC)

Is this question still active? Just ran into the issue myself and I'm curious if we can change this somehow. ~ Sanna 11:30, 22 January 2013 (UTC)

Possible info box item event_prev_fail

Its use is obvious I think. Found a couple of instances where it would clear things up. Bernardus 15:03, 24 October 2012 (UTC)

Are you suggesting that we split "event_prev" into "event_prev_success" and "event_prev_failure"? I don't see why "event_prev" is insufficient. Are there cases where different outcomes of different events can end up in the same event? -- ab.er.rant 09:41, 25 October 2012 (UTC)

Yes, that's my suggestion. It jut seems to me that such a distinction might make things clearer for a "newb". Just a thought… Bernardus 15:12, 25 October 2012 (UTC)

Progress bar

← moved to Guild_Wars_2_Wiki_talk:Event_formatting

New event completion

I have been doing a fair amount of work on events. I have noticed many times that the event_success / event_failure fails to be appropriate, there are events that chain regardless of the success/failure state. I wonder if an event_follow or event_complete might be an idea. Thanks Bernardus 20:49, 9 November 2012 (UTC)

Which events are those? Are they part of the meta events chain? -- ab.er.rant 09:11, 10 November 2012 (UTC)

Some may be part of meta-events but others are not. For example Drive off the Inquest before they steal all of the LUM0009 golems always "fails" even when it does not and Recover the stolen LUM0009 golems from the Inquest always follows. Similarly Protect Soundless villagers from the Nightmare Court always "fails" leading to Help Talaith liberate the Soundless prisoners. Defend the Soggorsort quaggans from krait slavers with Free quaggan slaves from Slaver's Deeps. There are a few others but I can not easily recollect them. I have repeated many event several times looking for success/fail chains and was surprised to find this eventuality but it's there. Disclaimer: to the best of my knowledge. Bernardus 02:32, 11 November 2012 (UTC)

When you say "always fails", basically you mean the follow-up event always triggers? Hmm.... that makes a good case for having an extra parameter. -- ab.er.rant 00:54, 13 November 2012 (UTC)

If you use "event_success" without a corresponding "event_failure", the label changes to "Followed by". That would be sufficient wouldn't it? -- ab.er.rant 01:05, 13 November 2012 (UTC)

On a similar note for meta events. These "non-fail" events are almost entirely the start event of meta events. I mapped it like this: User:Relyk/Zone visual#Zone. For events that are a part of meta event chains, the starting event can be denoted with start_event. We can also create an end_event for the final event. It would be some nifty work to generate meta event lists from using the templates like nodes with SMW :P.

If the event always fails, it was intentional design, and rather crafty use of dynamic events imo. I don't think we need to change the infobox to address this, we just leave the success parameter empty. I'd like a section on the Dynamic event page or a similar list noting events that always fail (and not part of a meta event). Once we have a more concise view on "always fail" cases along with the regular cases, I'd address changes in the template. Right now, we can explain these "always fail" or "always succeed" events in the infobox.--Relyk 01:28, 13 November 2012 (UTC)

Well the events that I quoted, and there are quite a few more, are NOT associated with meta-events. The first event end with a Success reward/medallion, not a fail but the effect of the success is the same as if the event had failed. e.g., stop villagers being taken. You stop andy villagers from being taken and the next event pops up to rescue the villagers that have been taken. Defending the water pipes in Queensdale pumping station always fails even if you are rewarded for success, why, because it starts with one pipe being blown up, so, success or failure of the first event, defend the pipes, results in a follow up event of repair the pipes. I could go on and on.

At then end of the day, it all depends on how accurate you want the information to be, if you want to "fudge it" then fine, if you want to be accurate then you need an { {event_follows} }. I'm the newb so...

As for reinvestigating the events, sorry but my brain will explode, I have already plodded through the start area events twice, including multiple 4am episodes to let events fail without people jumping in to help, finding quite a few new ones. Bernardus

I understood the point about "always fails" events as event that can only receive the "failure" event reward. I understand what you're getting at now. For events like the pipes, it's predetermined the event will lead to the next event independent of the success or failure of the event. In that case, the success and failure parameter would be the same. That's equivalent to an event_follows parameter for the next event using existing parameters. The template isn't concerned with the event literally succeeded or failing.--Relyk 03:07, 13 November 2012 (UTC)

The reason we can just leave the event_fail parameter empty in these cases is because we can simply default to the event_succeed value. In the case of no possible failure or if the failure leads to the same event as succeeding, the value for event_fail will be the same as event_succeed. Like you said, it's better practice to define the event_fail value if there is one instead of leaving it empty.--Relyk 03:16, 13 November 2012 (UTC)

My point, not wanting to get much further into this, is that although we could use the event_success and event_failure to point at the same events, would it not be more economical of text and visual clues to have the event_follow as one item in the info box. Seems so logical to me but obviously I am in the minority or others do not care enough to comment so consider this my last asking. Bernardus 06:27, 13 November 2012 (UTC)

Zone link issue

Pages that have double brackets in the zone parameter, such as every page with zoneverbatim=y, are showing categoriies at the top of the page, brokenly. Such as on Defeat the strange foe that came through the haunted door. Manifold 19:44, 26 November 2012 (UTC)

Fixed, there was legacy auto-cat code in there that didn't check zoneverbatim. —Dr Ishmael 22:45, 26 November 2012 (UTC)

Ucfirst

Hello, currently when we use [[Has event type::{{ucfirst: {{{type}}} }}]], ucfirst only uppercases the first letter, it doesn't lowercase any second words, e.g. dynamic Event -> Dynamic Event. We really want it to do dynamic Event -> Dynamic event. Two solutions: could use {{ucfirst: {{lc: {{{type}}} }} }}, or could have a bot run through improper types replacing "type = ___ Event" with "type = ___ event". Personally prefer the bot method, but ucfirst lc will work 100%. --Chieftain Alex 01:34, 26 January 2013 (UTC)

Ucfirst just displays it properly, we want to enforce the practice of using lowercase letters for setting SMW parameters imo. I think the simplest solution is to do [[Has event type::{{lc:{{{type}}}}}|{{{type}}}]], as SMW automatically capitalizes the first letter automatically but we want to display event type in titlecase.--Relyk ~ talk > 01:55, 26 January 2013 (UTC)

We want to display the type so that it matches the name of the type's page, which are not in title case: Meta event, not Meta Event. I think Alex's solution is good for now, but a bot run would be a better solution. —Dr Ishmael 03:02, 26 January 2013 (UTC)

using cnames

for meta_event/storyline and start_npc. With much trepidation I have reverted this as I think the new users will find it better that without. --Claret 19:45, 19 April 2013 (UTC)

Zone Name as font size

Possible to make it smaller than area as it was visually in the past? Please. --Claret (talk) 22:15, 13 May 2013 (UTC)

C'mon, you know it looks better with the enclosing whatever in a smaller font size. I may have to try to learn more than I want to to try to fiddle with it. That's a threat  :) --Claret (talk) 20:31, 15 May 2013 (UTC)

Fixed, both here and template:infobox location —Dr Ishmael 20:40, 15 May 2013 (UTC)

I knew threats worked. Seriously, thanks. Aesthetics (esthetics) made me ask. --Claret (talk) 20:42, 15 May 2013 (UTC)

Loss of "Category:<zonename> event"s

Since a rececnt revision. ie the one that removes the need for zone in the infobox. I am unsure so I will not do anything. --Claret (talk) 22:32, 13 May 2013 (UTC)

relyk's gungho switched the internal location setting things to {{Infobox location}}... which means the categorization line

{{#if:{{{zoneverbatim|}}}
| <!-- Occurs in multiple zones, list each zone manually -->
| {{#if:{{#var:smw_zone}}|[[Category:{{#var:smw_zone}} events]]}}
}}

isn't working since the variable never gets set. idk how to fix this since its got arraymaps in it instead.

zoneverbatim has been removed elsewhere, it shouldn't be there at all. Categories are nice and reassuring, I don't get the same pleasure from seeing properties hiding at the bottom of the show preview of pages. >_>

this reminds me of subtemplates on GWW where people would move stuff into subtemplates, followed by screwing up any categorization. maybe {Infobox location} can have a category parameter to expose the correct cats at the end (call it twice, one at the top of the page, one at the bottom just spitting out category names) -Chieftain Alex 22:59, 13 May 2013 (UTC)

Hopefully, since the zone is extracted to display, it will be not too difficult for those who have been initiated into the arcane mysteries to push that value into categories. --Claret (talk) 00:07, 14 May 2013 (UTC)

Oh cry more alex. Template doesn't use {{infobox location}} anymore, which ideally is suppose to simply display a series of locations. If we want to set properties and categories in the same place, it varies between infoboxes and we can't use a general template. You can generate it no problem with a query ({{#ask:[[Has event type::+]][[Starts in.Located in::Fireheart Rise]]|format=category}}). If we categorize by zone for each area, there would be some redundancy for multiple areas in the same zone. This would be a problem whether or not we were using SMW.--Relyk ~ talk > 03:21, 14 May 2013 (UTC)

Thing is, we DON'T NEED categories like this anymore. They can be replaced by queries: {{#ask:[[Has event type::+]][[Starts in.Located in::<zone>]]}}

Example: Queensdale events: Bring blobs of toxin to Apprentice Jameson, Capture Heartwood Pass Camp from the Tamini centaurs, Clear the orchard of spiders for Farmer Eda, Collect grub remains for Ine, Collect skale eggs for Assistant Chef Victor, Defeat Baron Wycker, Defeat Carnie Jeb the Strong-Man, Defeat Chhk the Windmill King, Defeat Franklin Quickblade and his band of rogues, Defeat the cave troll, Defeat the corrupted veteran oakheart, Defeat the Lady in White, Defeat the shadow behemoth, Defeat the wanted bandit leader (Vic the Iron), Defeat the wanted bandit leader (Zirh the Venomous), Defend Altar Brook Crossing, Defend Altar Brook Trading Post, Defend Barthol on his way to the Old Armory, Defend Farmhand Nevin as he transports his cocooned friend to safety, Defend Mepi from bandits, Defend Shaemoor Garrison from Tamini attackers, Defend the beehives from hungry bears, Defend Tunwatch Redoubt, Defend workers repairing the pumping station, Destroy Holdland Camp's weapon caches before they amass a counter attack, Destroy the roadblock the bandits have constructed to stop Shaemoor traffic, Destroy the wasp queen, Drive back the centaurs before they steal the monastery's ale, Drive back Underworld creatures by destroying portals in Taminn Foothills, Drive back Underworld creatures by destroying portals in the Heartwoods, Drive back Underworld creatures by destroying portals in the monastery, Drive back Underworld creatures by destroying portals in the swamp, Drive the bandits away from the windmill, Drive the bandits from Curtis's ranch, Drive the harpy flock from the dam, Drive the rogue bull back home, and fix any mayhem on the way, Drive the Tamini centaurs from Altar Brook Trading Post, Eliminate the bandit lieutenant, Escort and defend workers sent to rebuild the guard tower, Escort Moa Trainer Kappa and her pygmy moas to Beetletun, Escort the carnival caravan to Beetletun, Escort the trading post caravan to Claypool, Free Mepi's captured moa herd, Gather ruined grapes from Victoria's vineyard, Help Farmhand Paris collect apples for Eda's famous pies, Help Slim Mikhart destroy the skritt cave support, Help the Durmand Priory with their investigations, Herd the pygmy moas into the pen, Hold Heartwood Pass Camp, Hunt and slay the giant boar... further results

Disjunctions like this (things that are in both category A (events) and category B (things in Queensdale)) make for unwieldy category trees (since you have to make 25+ zone-specific categories for events, then the same number for NPCs, then the same for locations...). However, they can be presented elegantly with semantic queries.

In the next wiki update, we will get the Semantic Drilldown extension, which makes this sort of thing easily accessible - a new special page, Special:BrowseData, where you can dynamically filter a master category (e.g. Events) by values of semantic properties. Hopefully this time it won't take a whole year like the last wiki update did. —Dr Ishmael 04:04, 14 May 2013 (UTC)

Please don't take this the wrong way but I am getting the impression that this new/proposed/hoped for functionality is terribly elegant from a programming point of view, but is it user friendly? You know, those casual users. I would not want to have to learn a query syntax to get this kind of info. Maybe I have the wrong impression. Also, removing functionality before the replacement is ready is, ermm, maybe a little premature. Just my opinion, don't get upset. If I don't ask then… --Claret (talk) 04:24, 14 May 2013 (UTC)

You don't need to, we stick the query into a template and on it's own page then link to it. This is how List of hearts in Plains of Ashford works. For example, if you want to duplicate the category page: List of Fireheart Rise events-Relyk ~ talk > 05:42, 14 May 2013 (UTC)

(Edit conflict) Sorry, I didn't mean to imply that I thought this accidental loss of functionality was a good thing. But it does make a good talking point - is this sort of categorization really necessary? No, it's not. And yes, Drilldown will be extremely user-friendly, that's the entire point of the extension: to let the semantic data within the wiki actually drive a reader's wiki experience.

I had set up a very rudimentary Drilldown example on my semantic test wiki that you can see here. It's for skills, not events, and the drilldown is mostly useless since the framework is based on an overhaul of {{skill infobox}} that I never got around to propagating out to the actual skill pages yet (parameter name changes, mostly), but I think you can understand the basic idea of what it can do. —Dr Ishmael 05:46, 14 May 2013 (UTC)

"is this sort of categorization really necessary? No, it's not." - and there lies the problem. You can find a way round it because you and soem others are aware of the way the wiki works. I found the category pages useful. Can I work round it, sure, but why should I have to? Sorry but I suppose it's inevitable that those who can program (I use the term loosely) can dictate what the other lesser mortals can see and do. It's kinda irritating, not a deal breaker. Don't think I and others are not grateful for the work put in but sometimes… --Claret (talk) 07:28, 14 May 2013 (UTC)

Did you even look at the link I provided? Drilldown is so much more useful and easier to navigate than some convoluted static category tree. This isn't "a way around" categories, it's an improvement. —Dr Ishmael 12:30, 14 May 2013 (UTC)

Yes, I looked. Sorry, I just don't get it. Still, hopefully it will become clearer. I can't right now see how this replaces the categories but I suppose I will eventually. You (collectively) have an idea(s) of where you're going and I guess I'll just have to follow. I am not a programmer these days. It was a long time ago when I was interested in programming and now things that seem obvious and clear to you are not to me. All I am aware of is that I had a "useful to me" functionality which has now gone. I am promised something "better" soon. I await it with interest. --Claret (talk) 12:44, 14 May 2013 (UTC)

Ok, so in lieu of a category page, what kind of page/link/whatever would you expect to find? An individual "Queensdale events" page? A generic "Kryta events" with Queensdale events as a section? A link on all events to one of the previous pages? What is your ideal organization? --JonTheMon (talk) 13:15, 14 May 2013 (UTC)

I have no real idea what is to be offered, Ishmael indicated that he had something in the skills department in his reply but, being and feeling dumber by the minute, I couldn't see how that would translate into the functionality of the category page. He obviously can. HGe obviously feels that it will be better, it may well be. I expect to find whatever will be eventually produced. But I have no real concept of what that will be. I suppose that when I see it then it will be real and I can like or dislike it. Honestly, I have no idea what all this vector this, explode that, sujobj, arraymaps means. It's pure and utter gobbledygook to me. I am sure I could come out with stuff from my field which was perfectly understandable to me and my colleagues but pretty meaningless to others. But, going back to the beginning of the section, I merely pointed out that the Category was not working. I thought it may have been an error. Further on, I did say I would miss the Categories but my original note was merely informative. Not every comment is criticism. Some, however, is nostalgia. Most of mine are confusion. --Claret (talk) 14:18, 14 May 2013 (UTC)

That's your impression of Ish's idea. If you had to start from scratch (but w/o categories) what would a good system look like to you? --JonTheMon (talk) 15:50, 14 May 2013 (UTC)

(Reset indent) Ignoring how we will implement category trees semantically in the future and other mental anguish, I implemented what I originally said about zone events.--Relyk ~ talk > 16:29, 14 May 2013 (UTC)

In response to JonTheMon's question. You're missing my point. I have no idea what wiki coding can produce. I pointed out what I though MAY have been an error and, as a side issue, said that I missed categories. I bemoaned that the functionality was gone, was offered a "well it'll be better in the future" and here's an example. Look people. if you don't want people to point out possible errors then say so. If I had known that there had been a determination that Categories would disappear then I would have lived with it. If you don't want my opinion then, again, say so. But please, please don't ask a biologist (as an example) to say exactly what kind of engineering they want to go into a new dam or power station. They will have no real idea. Nor will they have any real idea of the possibilities except in an extremely vague and often misguided way. --Claret (talk) 19:50, 14 May 2013 (UTC)

It's a bit unfair question of Jon to ask. However, if we have a better way to present categories than the category hierarchy, it's worth exploring. The removal of categories makes it a perfect topic. You don't need to know gobbleygook to discuss it in general terms (at least I don't think so)--Relyk ~ talk > 21:53, 14 May 2013 (UTC)

I am sure you don't. However, it's a bit daunting when so many discussions are full of it. Anyway, thanks for the temporary (maybe) reversion of the the functionality of the zone event categories. Hopefully, and I mean that, it will be superseded by new offerings. Now if only I could work out how to filter the historicals and alter the zone name size… :) --Claret (talk) 22:02, 14 May 2013 (UTC)

You mean just the historical events?--Relyk ~ talk > 23:48, 14 May 2013 (UTC)

Yes but if it's more than trivial, leave it if the "Categeories" days are numbered. --Claret (talk) 00:01, 15 May 2013 (UTC)

To clarify, filter out the historicals --Claret (talk) 02:00, 15 May 2013 (UTC)

Maybe I’m a bit late, but I would also prefer if we keep categories. Categories are directly listed at the same position on every single article. Regardless of the article type, I can quickly find related articles by looking at the category. While SMW may offer similar and better methods to find similar pages, it’s not as accessible as I need to go to a page first that does the job. And before I can do that, I need to find it first, as it won’t be there in a consistent way for every article.

It wouldn’t be a problem at all to keep SMW properties and categories. So we could use the SMW style where appropriate to get some awesome results, while still offering the classic and consistent way. Of course categories are not as feature-full as SMW, but they were never meant to be. They are dead simple, and I think that’s a good thing. poke | talk 10:08, 15 May 2013 (UTC)

It's not like we're removing the category altogether. While we're at it, we can discuss how to fix the categories. I'd rather do what we did with renown hearts and not compound the event and area together. Skill challenges have the same tables although they have their own issues. Meta events and group events get clobbered together with dynamic events in zone categories and then get their own categories. There's currently no way to navigate to all the meta events and group events in a zone on the category tree. It's not really a hierarchical category structure in that respect. There are a few ways we can handle categories:

1. We can create a dynamic event, group event, and meta event category for each zone. These would all be categorized into Category:<zone> events. A SMW query would query the category itself. This is similar to skills be divided into each profession among others. This requires subcategories enabled for the query to grab all the subcategories.
2. The current way, which I do not find useful for categories.
3. We don't care if events are group events, then categorize dynamic events and group events into Category:zone events and create a subcategory for meta events.
4. We categorize all events into Category:Events and present all the events in zones in tables or whatever way we desire.

--Relyk ~ talk > 11:56, 15 May 2013 (UTC)

Parameter list

There seems to have been a reduction in the parameters for this infobox. Should I change events if I am editing them anyway or will a bot do that? It may well be discussed elsewhere but I can't immediately see it. --Claret (talk) 20:29, 15 May 2013 (UTC)

Sometimes I just know I am dumb - but I never thought I was that bad. It's my Alzheimer's honestly. --Claret (talk) 20:44, 15 May 2013 (UTC)

But should I change them? Or what? --Claret (talk) 20:48, 15 May 2013 (UTC)

If you're talking about zone/zoneverbatim, yeah, you can remove them if you're already making other edits to the page. —Dr Ishmael 20:53, 15 May 2013 (UTC)

Thanks --Claret (talk) 20:54, 15 May 2013 (UTC)

Historical vs living story vs holiday

Some events get removed from the game entirely. Some were part of a one-time event, e.g. the Karka invasion happened once per overflow. Some are part of a potentially recurring event, e.g. Halloween 2012. Some were part of the living stories, but are no longer in the game, e.g. the molten attacks. Currently, the info box treats each of these as the same. I think we should distinguish among them. Instead of historical = yes, what about historical status = current (default) | removed | recurring | living story or anything along those lines. 75.37.21.148 09:05, 20 May 2013 (UTC)

Agree, I only use "historical" as a catch all. Be nicer to have a breakdown. And I wouldn't be surprised to see the holiday events recur. --Claret (talk) 09:38, 20 May 2013 (UTC)

Names with commas in them - problem

See infobox containing Azabe Qabar, the Royal Tombs on Escort Explorer Loana to the Reliquary Vault in the Royal Tombs. --Claret (talk) 11:06, 27 May 2013 (UTC)

Any solution? Still wanting one. --Claret (talk) 14:51, 8 June 2013 (UTC)

The areaverbatim parameter no longer works, and looking at the code, no longer exists inside that code. --Claret (talk) 14:55, 8 June 2013 (UTC)

Hacked. —Dr Ishmael 15:04, 8 June 2013 (UTC)

Star. --Claret (talk) 15:05, 8 June 2013 (UTC)

Discovered a better solution - use the HTML entity code &#44; for a comma within a location name. Unfortunately, this is neither common knowledge nor obvious, so I'll leave the hack in place. —Dr Ishmael 19:15, 8 June 2013 (UTC)

True. Thanks for a working solution. --Claret (talk) 19:23, 8 June 2013 (UTC)

The delimiter can be a comma or semicolon, the switch to semicolon for the delimiter if it's present in the string.

{{#arraymap: {{#replace:{{#replace:{{#replace:{{{area}}}|[}}|]}}|<br>|;}} | {{#if:{{#pos:{{{area}}}|;}}|;|,}} | @@@

area = Azabe Qabar, the Royal Tombs;

or we could use the <br> tag, which would be obvious since it's used constantly. (Easy to edit in :P)--Relyk ~ talk < 21:59, 8 June 2013 (UTC)

Comma is the most natural punctuation for delimiting lists. Semicolon is the grammatically correct fallback for when the items in a list already contain commas, but that situation comes up very rarely, so I wouldn't expect editors to naturally use it.

Only 1 location in the entire game has a comma in its name. The cost-benefit is too low to change everything for that one location.

Your conditional solution is elegant, but it would fail for the two pages where it would be needed because there's only 1 item in the list on those pages. You could include a no-op trailing semicolon, true, and I suppose that would be about as natural as using the HTML entity code for a comma. (Actually, because of the HTML entity code, the conditional solution would cause the same error as before.) —Dr Ishmael 22:45, 8 June 2013 (UTC)

^I'm happy with the HTML entity code as long as the situation only comes up rarely.--Relyk ~ talk < 23:20, 8 June 2013 (UTC)

More parameters now gone or changed

area now takes comma separated area - example changed areaverbatim appears to be no longer used - removed from list/example --Claret (talk) 19:07, 8 June 2013 (UTC)

More canonical names

Is it possible for all events (previous/success/failure) and metaevents displayed by the infobox to use the canonical name. Thanks.

API usage

I do not know what the "bit" that lists the availability/status of anevent in the servers is called. Problem arises when we use "My event (queensdale)" and "My event (Kessex Hills)". Even if you strip the location, getting it into a format useable by the call to get the list would be tricky. A suggestion might be using the "E838ECDE-2632-49F6-B2D3-83AB1F06C99F" id, an extra parameter. This would also get round the "Skill challenge: Defeat some random guy" naming problem also? Thought, comments. --Claret (talk) 20:54, 12 June 2013 (UTC)

No thoughts? That's unusual. :) --Claret (talk) 21:31, 25 June 2013 (UTC)

Poke or someone needs to run a bot to add ids. Each id corresponds to an area, so it's viable to do so.--Relyk ~ talk < 22:24, 25 June 2013 (UTC)

Yes, and that might handle some but the 5 copies of the skritt burglar in Queensdale alone might need area level handling, or ignoring. I'll wait with bated breath. I added a new event. It is shown in the list from the crude API but has no "bit" on its infobox re: availability. Does that have to be manually added? --Claret (talk) 22:34, 25 June 2013 (UTC)

I’d update the event list, but the API is not behaving atm due to the upcoming patch. I’ll update it as soon as it works again or tomorrow… poke | talk 23:56, 25 June 2013 (UTC)

Updated. poke | talk 00:06, 26 June 2013 (UTC)

:) --Claret (talk) 00:07, 26 June 2013 (UTC)

Triggered by population

With a post in this forum thread we learn that some events are triggered by population of players in the vicinity. Can something be setup on the infobox or something to indicate this for when we figure out which events are triggered by amounts of players? --Musha 01:04, 28 June 2013 (UTC)

start_npc needs comma separated

See Duel with the Queen's Champion - at least two starters. --Claret (talk) 13:07, 6 August 2013 (UTC)

added. -CA 19:33, 6 August 2013 (UTC)

Thnanee, sirrah (or Ms Sirrah) --Claret (talk) 19:38, 6 August 2013 (UTC)

Commander Icons

There are a couple of events in WvW what use the commander icon. {{area events}} doesn't seem to display this. {{event|Report to Commander Siegecrusher}} does not either which is probably why. Obviously, if it's a lot of work, for two events, don't bother. Thanks. --Claret (talk) 14:46, 6 August 2013 (UTC)

fixed. (added to Property:Has event icon to include it) -CA 19:33, 6 August 2013 (UTC)

again, profound and profuse thanks --Claret (talk) 19:38, 6 August 2013 (UTC)

Event IDs

Do we really want 40+ listed for some and 80+ for the skritt burglar? --Claret (talk) 11:43, 7 August 2013 (UTC)

event id

Can we have as just id like the other infoboxes?--Relyk ~ talk < 05:46, 27 August 2013 (UTC)

Guild Missions?

Could someone maybe add support for Guild missions and their icons to this template?

• Guild Bounty =

• Guild Challenge =

• Guild Puzzle =

• Guild Rush =

-Somohexual (talk) 18:10, 8 September 2013 (UTC)

Location canonical names

Please? --Claret (talk) 11:11, 20 December 2013 (UTC)

Sure. MalGalad 11:38, 20 December 2013 (UTC

Thanks. --Claret (talk) 11:49, 20 December 2013 (UTC)

Seems to have broken {{area events}} for Azabe Qabar, the Royal Tombs. --Claret (talk) 12:09, 20 December 2013 (UTC)

Oh yeah, I am awesome. MalGalad 12:41, 20 December 2013 (UTC)

You are, indeed!! --Claret (talk) 12:59, 20 December 2013 (UTC)

Erm (cough), seem to have lost the "small" zone underneath the area in infobox for events. --Claret (talk) 21:37, 20 December 2013 (UTC))

EXCEPT for [Azabe Qabar, the Royal Tombs]], that is. --Claret (talk) 21:41, 20 December 2013 (UTC)

Oops. MalGalad 21:58, 20 December 2013 (UTC)

It's an "Oops" day, we all have them. Well I do. Often. --Claret (talk) 22:51, 20 December 2013 (UTC)

{{infobox location}} is suppose to handle that special case of Azabe Qabar, the Royal Tombs and a parameter to set the correct property, just never implemented.--Relyk ~ talk < 01:21, 21 December 2013 (UTC)

Before Malgalad worked on it, Azabe Qabar was handled fine, he seemed to have broken it in making the canonical names, then he re-fixed it but left out the zone or the area etc or other locations. It seems fine now. Thanks again. --Claret (talk) 01:26, 21 December 2013 (UTC)

{{infobox location}} didn't work since {{event infobox}} requires property Starts in and infobox location has only Located in. MalGalad 10:01, 21 December 2013 (UTC)

Events are no longer categorized

At some stage, a large number - if not all- of events seems to have lost their category "zone event" eg Category:Queensdale event, although {{area events}} still seems to work. I do not know if this is intended but I suspect that it isn't. --Claret (talk) 00:02, 5 January 2014 (UTC)

Quessing here, but I think it might have been the first edit of 20131220. --Claret (talk) 00:12, 5 January 2014 (UTC)

It was this one. Probably from Magalad copypasting code. The categorization was why we weren't using {{infobox location}} (and really we can generate a list with a query anyways).--Relyk ~ talk < 00:43, 5 January 2014 (UTC)

Any chance of it being "fixed"? Losing those events without the queries in place is place leaves a hole in my wiki usage. No problem with there being a newer mechanism but the old one had some utility, or the information that it provided did. --Claret (talk) 03:44, 5 January 2014 (UTC)

I thought you would fix it yourself, venture into the unknown, put on the boots, get your hands dirty, dive into the depths... or another soul could come along and do it, either way works.--Relyk ~ talk < 04:30, 5 January 2014 (UTC)

fixed because I'm not relyk. Chieftain Alex 15:57, 5 January 2014 (UTC)

I'm too old now, Relyk. It comes to us all eventually unless we're unlucky :) --Claret (talk) 16:51, 5 January 2014 (UTC)

refined the code to get it to only categorize into parent location if the parent is a zone rather than a region (previously getting some "Category:<region> events") -Chieftain Alex 17:49, 5 January 2014 (UTC)

Event prev/success/failure

Event prev/success/failure - could these use canonical names also, please. --Claret (talk) 10:54, 13 January 2014 (UTC)

Thanks Alex. --Claret (talk) 11:25, 13 January 2014 (UTC)

Evacuate Lion's Arch Citizens

The events associated with Evacuate Lion's Arch Citizens seem to be categorized by their area, not their zone. I have no idea why. --Claret (talk) 00:27, 25 February 2014 (UTC)

Fixed. It was because Lion's Arch is a city, not a zone, and the infobox only categorized into parent zones. —Dr Ishmael 00:45, 25 February 2014 (UTC)

Thanks. --Claret (talk) 09:19, 25 February 2014 (UTC)