Template talk:Event infobox

From Guild Wars 2 Wiki
Jump to navigationJump to search

Vista-file-manager.png
Archive


With the megaservers now....[edit]

We probably can (read as: probably have to) ditch the "Worlds currently active on" bit. - Tanetris (talk) 05:44, 30 April 2014 (UTC)

I bet someone will find it marginally useful.--Relyk ~ talk < 06:22, 30 April 2014 (UTC)
Yeah, you’re probably right Tanetris. Also, the functionality won’t be gone (you can still use the widget), but it really doesn’t make much sense to keep it in the infobox. poke | talk 11:10, 30 April 2014 (UTC)
Is there an update or a new way to find what events are active on the megaservers now? --MushaUser Musha Sigc.png 00:05, 6 May 2014 (UTC)
Apart for world boss events, nope. Finding out active events on a megaserver is useless anyways since you can't choose your megaserver.--Relyk ~ talk < 00:11, 6 May 2014 (UTC)
Just for sake of documentation, I removed the widget from the template + from the common.js since it was mentioned by dr ishmael (and confirmed by myself by link clicking) that the events api is totally broken / blank. -Chieftain AlexUser Chieftain Alex sig.png 00:27, 6 May 2014 (UTC)
(Edit conflict) Anet would first have to externalize a way of identifying which instance of a map you're in, then they'd have to reconfigure the events API to work off of these instance IDs rather than world IDs. And that's not something they'll be able to get out soon. —Dr Ishmael User Dr ishmael Diablo the chicken.png 00:27, 6 May 2014 (UTC)

More changes proposed by me see live[edit]

I don't know is User:***EAGLEMUT*** ever did implement those changes. It looks like he did based upon the history. I was working on the {{living world infobox}} and I realized that it was basically a duplicate of {{event infobox}}. So I decided to merge the differences of the two and add some additional cool auto-categorization features. The following are the changes I made most of the changes help with auto-categorization:

  • Added a Living world parameter to indicate if the event was/is part of a living world release.
  • Added a chapter parameter so that one can specify what living world chapter the event is part of.
  • As some chapters contain multiple parts for example fame and frost. I added a part parameter to indicate what part in the chapter that event was part of. This is for the use in auto-categorization
  • Added a other-release parameter to be used in the auto-categorization.
  • Added a seasonal event parameter. This will display if a event is seasonal what special event it is part of. See User:Anzenketh/Sandbox/Page/3 for a example of this.
  • Added temporary-image parameter for use in the auto-categorization feature.
  • Greatly improved the historical parameter. If the event is part of the living story and flagged as historical. It will use the {{temporary}} template to mark it as such with when it was available. It also marks the event as historical so it does not show up in any systematic queries and auto-categorizations. (Additional verification may be required to ensure that it does do that as that was the main goal of the update. ) See User:Anzenketh/Sandbox/Page/2

Feedback is welcome. Anzenketh (talk) 01:42, 16 May 2014 (UTC)

Here you go, might be discussion elsewhere too. I'd suggest discussion take place on {{living world infobox}} if you want to add your input and see if we want to make changes.--Relyk ~ talk < 19:55, 16 May 2014 (UTC)
Ok I have put any possible changes to this infobox on hold. The discussion will be also put on hold until clarification on how the {{living world}} infobox is to be used further discussion on this topic in relation to the {{living world}} infobox will happen here Anzenketh (talk) 20:40, 16 May 2014 (UTC)
It looks like there is some work going on User:Chieftain_Alex/sandbox3 to solve the problem. Anzenketh (talk) 17:47, 4 June 2014 (UTC)

Default map1 is gone[edit]

Since the latest(?) change, maps that were automatically embedded into the infobox because they had the same name as the page are not displayed anymore. Tyndel (talk) 01:07, 3 August 2015 (UTC)

Yep, sorry about that - functionality should now be restored. -Chieftain AlexUser Chieftain Alex sig.png 08:37, 3 August 2015 (UTC)
I don't see a difference atm, Donate to Heal-o-tron's cause doesn't display File:Donate to Heal-o-tron's cause.jpg for example. My try didn't do anything either. Tyndel (talk) 08:44, 3 August 2015 (UTC)
Damned symbols. Now using #titleparts too. -Chieftain AlexUser Chieftain Alex sig.png 08:59, 3 August 2015 (UTC)

Guild Event Indicators[edit]

moved from User talk:Chieftain Alex#Guild Event Indicators

Apparently the only icon that works in the Event infobox for guild events is Guild Bounty (map icon).png(and that icon is out of date, though I think Darqam is working on that), Guild Challenge (map icon).png and Guild Race (map icon).png don't seem to be valid options. Can you add those two in? And after I'm done with quaggans, the Kodan are getting some love too, same thing with the models(that and most of the kodan images I've found are as dark as sin). - Doodleplex 20:44, 29 March 2016 (UTC)

Why is this not being posted on the talk page of the infobox? :<--Relyk ~ talk < 21:18, 29 March 2016 (UTC)
Because I thought it was something an admin had to do, as when I tried to use those icons it popped up as an error so I thought it was back end code stuff. (That and he needed to know I was going to be hugging a lot of polar bear people). - Doodleplex 21:27, 29 March 2016 (UTC)
Maybe I'm missing something, but are they not all ok now? I just re-uploaded the bounty image due to a problem I didn't notice on my end, but the other two seemed to be working prior to this comment. -Darqam (talk) 21:29, 29 March 2016 (UTC)
If you go to Southsun Crab Toss I can't put Guild Challenge (map icon).png as the indicator icon in the event box. Or any guild challenge really, only Guild Bounty (map icon).png works as an indicator icon for event infoboxes. - Doodleplex 21:33, 29 March 2016 (UTC)
Property:Has event icon needed to allow those values.--Relyk ~ talk < 21:47, 29 March 2016 (UTC)
Ok, seems to work with those changes, additionally I think I caught the last missing icons to update. Call out if they are still some missing. -Darqam (talk) 22:03, 29 March 2016 (UTC)

Adding Scout[edit]

Was wondering if anybody objected to adding "Scout" in the infobox for meta events to use, similar to how the renown heart infobox has it. Nearly all of the Scouts in HoT scout meta events, as well as a decent chunk of the scouts in Orr, so I was thinking it might be helpful. - Doodleplex 03:27, 16 October 2016 (UTC)

Can we directly correlate scouts to the meta events? The reason we have scouts in heart infobox is because it's 1-1 relation. Scounts for meta events is way more ambiguous.--Relyk ~ talk < 05:00, 16 October 2016 (UTC)
For the ones in HoT, I'd say so, as their scouting report changes based on where the meta event is, for example Agent Ossi's scouting reports change based on where Outpost: The Ordnance Corps is at the moment or if completed. As for the ones in Orr, I'm not 100% sure, I'll look into it. - Doodleplex 05:33, 16 October 2016 (UTC)

Indicators: event ui vs map[edit]

I had a look at Fight Cooroo's Crab earlier - the event helper panel in the UI uses the "hero" indicator as expected, but the mini map had the "fist" icon. Which do we write down in the infobox? (I assume all hero points get "hero"?) -Chieftain AlexUser Chieftain Alex sig.png 11:42, 12 March 2017 (UTC)

Fist gets my vote. I think that map icons outweigh the UI ones in term of importance. —Ventriloquist 11:50, 12 March 2017 (UTC)

Regarding the way multiple events are specified[edit]

Is there anything that would speak against replacing the multiple parameters with underscores ending in numbers with single parameters without underscores with values separated by semicolons (or at least adding them as alternative) that i'm not aware of? Nightsky (talk) 19:29, 14 January 2023 (UTC)

I'd endorse the suggestion to remove the underscores. We could just use next, prev, success, failure, meta, start npc (I would even prefer "previous" to "prev" if we are changing the name anyway) - the "event_" suffix is superfluous in an event infobox. Also, why are we using separate numbered parameters? - we could separate multiple events with a semi-colon. -Chieftain AlexUser Chieftain Alex sig.png 20:27, 14 January 2023 (UTC)
I'm not sure how removing the "event" bit from the parameters will go. For what it's worth, all i would have done to their names would have been to remove the underscores from all of the ones parameters with number variations (with event_prev..5, event_success..5, event_failure..5 keept functional, but deprecated and not to be used in forthcoming template uses, for looking at past revisions in the history due to them having ten years worth of revisions which is probably a good thing to support looking at).
If you intend to go through with the renaming, i'd be on board with previous, would endorse on success, on failure, id and keep meta event as is, due to that being how the type of event's named.
As to why it's separate numbered parameters, i was guessing it might be because they were introduced at a time when #arraymap perhaps wasn't well known and simply no one had brought changing the parameters to use it up; untill recently. But i'm not sure how accurate that is, hence why i was asking to see if that might apply or if there's something to it that i'm not aware of. Nightsky (talk) 01:11, 15 January 2023 (UTC)
Should we maybe do a vote on the names for all of the parameters (or only those with underscores at the moment, or something?), or is dropping the event from every parameter (and or adding -ious) the general consensus? Nightsky (talk) 16:53, 25 January 2023 (UTC)
No vote needed in my opinion as the name scheme implied by our current wiki standard is pretty obivious.
old parameter name new parameter name notes
meta_event meta event per meta event
start_npc start npc -
event_prev previous full parameter name, per Alex' suggestion
event_success success no prefix ("on") or suffix ("event") needed, keep it simple
event_failure failure as above
event id id it's the event infobox, per Nightsky's suggestion
Page history preservation would be nice though, maybe limited to 5 parameters, for example by using {{{previous|{{{event_prev|}}};{{{event_prev2|}}};{{{event_prev3|}}};{{{event_prev4|}}};{{{event_prev5|}}}}}} (Edit: seperator).
--Tolkyria (talk) 15:26, 26 January 2023 (UTC)
Draft modifications over at User:Chieftain Alex/sandbox2 (diff ). I think there's few enough examples of multiple start npcs and event_ higher than 5 that my current proposal provides sufficient backwards compatibility for using the history function. -Chieftain AlexUser Chieftain Alex sig.png 18:12, 26 January 2023 (UTC)
Your changes are looking good. Just keeping all this deprecated parameters looks kinda messy but with 10+ years of event documentation we simply can't get rid of them; we have to deal with it. Supporting five old parameters should be enough, which was also the default until 2020.
Several remarks:
  • We could add some comments in front of the outdated parameters to indicate their purpose.
  • There's no need to use the outdated parameters in SMW property declarations (e.g. Has game guid), only visible infobox values needs them.
  • We could remove/modify redundant/questionable code, e.g. what's the reason to keep "data-guid" in <div class="infobox quest" {{#if:{{{event id|}}}|data-guid="{{{event id}}}" }}> (added in July 2013).
--Tolkyria (talk) 18:51, 26 January 2023 (UTC)
Buffs caught an error (thanks!). Fair points Tolkria, please feel free to edit further. -Chieftain AlexUser Chieftain Alex sig.png 21:12, 26 January 2023 (UTC)
Failing anything else, I'll have a go at this on Sunday (straightforward renames are easy, the one i'll probably trip up on will be combining the ones with multiple event_prev/success/fail parameters). -Chieftain AlexUser Chieftain Alex sig.png 22:49, 26 January 2023 (UTC)
Few things.
Since this will change the start_npc parameter either way, woudn't it make sense to also change it to be separated by semicolons; since NPCs may have commas in their names?
Also, since it's being edited either way, would it make sense to change the paramter descriptions to consistently state they're Required and or Optional?
Additionally, from a search through all the then current revisions, from when i did the left-to-right mark removal, i've found the following amount of pages, grouped by and only counted against the total of the highest parameter number used (Meaning, if a page uses e.g. event_failure and event_failure2, it will only count as one page towards event_failure2. So the total number of pages using a parameter are the number listed at the side of it (or zero, if not listed) plus the sum of all the numbers on the side of the parameters with a (higher) number.), with the pages listed where this value's less than 10 (although efectively less than 14):
Parameter list
Thus i'd suggest it'd be at least six parameters, perhaps even more as for past revisions might contain uses of higher numbered parameters, though i guess those may be added in later, so should the need for them ever arise, too. Nightsky (talk) 16:16, 27 January 2023 (UTC)
That makes sense, I changed start npc to semicolon seperator. Currently, in Alex' version comma and semicolon are supported, later only the legacy parameter should support comma.
Based on your numbers I would still limit it to 5 legacy parameters, restrict the "unnecessary" code to a minimum. --Tolkyria (talk) 17:07, 27 January 2023 (UTC)
Wouldn't applying the replace expression around the NPC name replace any deliberate commas with a semi-colon in their name? I would suggest backwards-support for comma separation isn't really necessary, there are very few pages with multiple start npcs (and the legacy code is only for previewing right?). -Chieftain AlexUser Chieftain Alex sig.png 17:27, 27 January 2023 (UTC)
If we want to restrict the uneccessary code to a minimum we could also do an all new (in terms of parameters and their functionality at least (though that would require changing all the parameters/values where functionallity changes but the name remains the same in the current revisions with a bot)) template, moving the current one to another name, perhaps a subpage, and then manually replacing the name in the historical code with the new name given to the old template if previewing's neccessary.
I would have thought it would be more about keeping the history viewable as it appears now, which would mean supporting any comma separators possibly in use (Looking through the then current revisions again, there don't seem to be any, but no idea whether there's any in past revisions.) and parameter numbers, without requiring any changes to current revisions. Nightsky (talk) 18:33, 27 January 2023 (UTC)
Alex, I don't see the problem. If currently we would be using a NPC with with a comma as parameter then the arraymap would split this already and create two most likely non-exisiting page links; also that's why I said "later only the legacy parameter should support comma" such that in the future we actually can use NPC names with commas. However, true, the ~5 occurences can be fixed easily by hand, I removed the #replace.
Regarding legacy support: yes, in my opinion that's for previewing old page version histories, and it's sufficient if it applies to 99.5% of the pages, so in order to keep the template code somehow clean I'm okay that <0.5% of the pages may appear broken in some way. This applies to the legacy parameters >6 (for example 2 pages out of ~3600) but also to the #replace comma for the parameter start npc (~5 pages out of 3600). I'm fine with the current code in Alex' sandbox, more legacy support is not needed in my opinion. --Tolkyria (talk) 18:56, 27 January 2023 (UTC)
Please consider the following, possibly again, beforehand:
  • Supporting more than one meta event.
  • Adding the "Is part of meta event" setting code.
  • Keeping the numbered parameters inside of the value for when the new parameter does not exist.
  • Adding the switch between "Upon success" and "Followed by".
  • Adding an equals sign for "meta event".
And additionally possibly setting properties using |+sep= outside of the loops; if that's possible. I don't know whether that would end up setting empty values. Nightsky (talk) 20:57, 27 January 2023 (UTC)
(1) Has been done (multiple meta event already supported), (2) "is part of meta event" has been added, (3) this has been done but I don't think it makes any difference other than making it harder to read, (4) + (5) no idea what you mean by these, (6) seems of no benefit since we're already using the arraymap, and will need us to specify all the legacy parameters in the input to it again.
I think the template is probably ready to go as-is. -Chieftain AlexUser Chieftain Alex sig.png 16:49, 28 January 2023 (UTC)
1) Sorry, i wasn't clear enough on that. I mean more than one historical meta event, meta_event2...6.
4) With that i mean an updated version of the ;{{#if: {{{event_failure|}}}|Upon success|Followed by}}-code found in the current version of the "Event infobox"-template.
5) That's me suggesting to add a missing equals sign after "meta event" in the "Usage"-section, which Tolkyria already added; before i even managed to suggest it with the above too, according to the timestamps.
At least four would seem great to have, or rather, keep. Nightsky (talk) 00:01, 29 January 2023 (UTC)
(1) there's only 10 pages of 3664 which use multiple meta event pages it really seems like clutter to put this in, (4) huh never noticed that, done.
I think the objective should be "when viewing pages from history, the page doesn't appear horribly broken", missing off a few extra meta events on 0.3% of event pages seems OK to me. -Chieftain AlexUser Chieftain Alex sig.png 09:33, 29 January 2023 (UTC)