Guild Wars 2 Wiki talk:Projects/Cartography

Older discussions

---

• 2012 Sep 2nd - 14th
• 2012 Sep 16th - 19th
• 2012 Sep 21st - 28th
• 2012 Sep 28st - Nov 18th

Documenting idle chatter

With a lot of the formatting ironed out, and more and more pages are filled with NPCs, objects, and other more obvious stuff, I felt the need to bring up how we wish to document the ambient idle chatter between NPCs. It's fairly simple when it's just one NPC talking - then the text can go on said NPC's page, e.g., the Mad King's Tower Dock's NPCs' chatter. However, when its between multiple characters - and generic characters at that - I feel that putting it on the NPCs' pages is not a good idea, especially when its generic NPCs. Otherwise Villager will probably have about a hundred different dialogue scripts on its page. As such, I would say it should go into area and instance articles - e.g., what I did for Blood Tribune Quarters. Issue I have is the section title. For that article, I just put it under "idle chatter" but I feel this is a poor section title. But on the other hand "Quotes" feels out of place and "Dialogue" makes me think of NPC articles too much. Maybe I'm overthinking it, but want some ideas here. Konig/talk 19:19, 2 December 2012 (UTC)

Hi, I am late to this request for comments. In my opinion, the chat between the "irrelevant" NPCS is irrelevant. It's part of the scenery, auditory rather than visual. You may as well write down how many bricks there are in a wall as the various comments, grunts, shouts and other noises. There's just no function in recording them. They don't help anyone find out how and where things are. But then, that's just my opinion… Bernardus 23:06, 24 December 2012 (UTC)

It might be irrelevant on the long run, but it's far different than how many bricks there are in a wall. The idle chatter is "ambient lore" - some actually are relevant to lore, for instance there's idle chatter in Zone Blue (Under Construction) between two Inquest agents about how they have a dragon minion ready to be placed in said area, and that it is large. There's some in Gendarran Fields between centaurs explaining the nature that War Beasts are trained to devour human flesh and that said creatures make the Tamini uneasy. Without these "irrelevant" idle chatter, we'd never learn these things.

So they're not all irrelevant. They're all part of what makes the game, and they're far above the number of bricks in the Ebonhawke wall. Konig/talk 23:40, 24 December 2012 (UTC)

Sorry, I didn't mean the relevant stuff should be left out, just the irrelevant. "Aaahgh" "aaagh" "ehhyup" "waaah" and completely trivial words and noises pervade Divinity's Reach to name but one. I am pretty sure you know that there is a large amount of "noise". It doesn't all need recording. Or at least I don't think so. I am aware of the "hints" that seemingly random NPCs give out. I actually listen to them and "talk" with them. That's the opposite end of the spectrum. Anyway, I'm sure you'll come up with something. Bernardus 07:18, 25 December 2012 (UTC)

Yes, well, that's not what I meant anyways - noises != idle chatter. By idle chatter I meant what is seen in quote boxes above NPCs - e.g., the LA conversation "Today's a bad day to drink wine." "But a great day to drink it!" is what I'm talking about, which would be documented in Trader's Forum ideally. Konig/talk 20:41, 25 December 2012 (UTC)

Just an opinion to Area format

Hi, I have edit like all Gendarran Fields area to the format we use according to the templates. When I first read it the area stating as a standard, Quetzal_Bay was having the first two sections named Locations and Events. Consulting the template at that time revealed that we should be using Locations and objectives instead. Now to my point in this. The area has a certain key locations to be vistited and sometimes renown hearts to be done before that area is completed. Events is not neccessary for that. Therefore it also should have its own section. I had recently had this little discussion with Konig. See thread here. --Hencovic 22:22, 24 December 2012 (UTC)

Hi, as far as I know, for explorable zones, you use a "Locations" table and then an "Events" list. Sub zones might use "Objectives" but I am always told to refer to Caledon Forest as the "normal" zone. The locations table should include all the hearts, skill points and vistas necessary to "complete" the zone. Bernardus 22:31, 24 December 2012 (UTC)

Caledon Forest is an Explorable zone, the sub-zones you might refer to is the Area I mean. I agree with you in how an Explorable zone should look like. A quick look in a few areas in Caledon Forest (The Verdence) reaveals the format I want to use. I.e. "Locations" and then "Events". By the look, this feels the best and see my first entry to see more arguments. --Hencovic 22:53, 24 December 2012 (UTC)

I would stick with that format. As I am frequently told, the templates and the explanations that go with them are never up to date. Whatever is written, someone will alter your work whatever you do. In little ways. But, looking at Gendarran Fields, you have made an excellent job of it. I always feel it's kind to leave some minor stuff for the more obsessive compulsive among us to fiddle with. Bernardus 22:59, 24 December 2012 (UTC)

wvw input

so I have a comment and a question about the wvw pages:

• first is that I would love it if I could get some help making them. on that point eb should be done first with one borderland done second then have the names changed (from what i can tell all the borderlands are the exact same)
• second is dose anyone else think that the poi points should be the main pages for keeps and towers and supply camps (every keep, tower, and camp has a point of interest) and then leave the areas as an overview of each of the areas?- Zesbeer 01:46, 2 January 2013 (UTC)

Makes some examples, I would think they can be treated like any other zone with areas having only pois, skill challenges, and jumping puzzles.--Relyk ~ talk > 03:35, 2 January 2013 (UTC)

Your second point was discussed somewhere before, and as I stated then, I think the PoI page should be used to describe the camp/tower/keep. As for areas, they would be concerned with things around the PoI, like the local wildlife. @Relyk: They have also have waypoints and vistas, the only normal thing lacking is hearts, so they're basically like zones in Orr. —Dr Ishmael 03:47, 2 January 2013 (UTC)

Treat them as Orr zones!--Relyk ~ talk > 04:07, 2 January 2013 (UTC)

ok can you link me to said discussion?- Zesbeer 04:36, 2 January 2013 (UTC)

Guild Wars 2 Wiki talk:Projects/Cartography/Archive 4#Borderlands and battlegrounds?--Relyk ~ talk > 07:25, 2 January 2013 (UTC)

just read thew that and its really only talking about the nav for wvw which is another topic i think the borderlands and eb need a nave for each area and i am really bad with using the premade nav template nor do i know how it would be formatted. - Zesbeer 10:02, 2 January 2013 (UTC)

denoting skill challenges w/event on zone/area pages

This is specific to "combat" skill challenges, those that trigger an event. When we list them on a zone or area page, should we be listing the event or the object/NPC that triggers the event? I think it makes more sense to list the object/NPC, since that's what anyone walking around in the area is going to see (unless the event is currently active). In comparison to "consumable" skill challenges, it is the object/NPC that initiates the challenge in both cases - the event and the item serve the same purpose in being the method for completing the challenge. It seems odd that we would, in one case, list the initiator and in the other case list the method.

I understand that this is a major change to consensus, and that we'd have to edit all zone/area pages to change the skill challenge listings, but it makes enough sense that I think we should. I've just started a campaign to standardize and stub out all location pages anyway, so I would take on this task as part of that. —Dr Ishmael 17:34, 2 February 2013 (UTC)

As I understood it, we always list the method - but in 2 versions of skill challenges, the method is found in the object/npc itself, and making a second page results in the Commune with... articles and the like. Ergo, in those, the initiator and the method are one in the same. We're still working on cleaning out the Commune with skill articles, slowly (slowly because I don't want to remove the text of the object that's there before the object has an article).

If we want to go with initiator instead, that's equally fine. Konig/talk 22:54, 2 February 2013 (UTC)

That's right, "commune" and "dialogue" skill challenges don't have or require this distinction, so we always list an object/NPC for them. And since we already list the object/NPC for "consumable" challenges, I think we have a very strong argument in favor of achieving consistency by changing the "combat" challenges. —Dr Ishmael 00:14, 3 February 2013 (UTC)

You see, I've always thought we list the item for the consumable challenges, rather than the object/NPC which gives the item to consume. And that's what I recall at least a few articles doing - though of the cases I remember having such, it seems I am wrong. Though of the six non-WvW cases I recall, one's still using the non-exist "Eat..." name, one uses the item, two have shared names for item/object (one of which - Morgan's Orchid recently split), and the other two use the object.

In the end, it doesn't matter which way we go, so long as it's all consistent - so either it's taking the consumable challenges to mark the item, or the event challenges to mark the initiator. Konig/talk 00:26, 3 February 2013 (UTC)

I prefer identifying the activity that gives the skill point as the "skill challenge", which would be the method. This isn't very comfortable because people are tagging the initiator for the skill challenge as well. I wanted to avoid duplication of the skill challenges, but that's what you end up with when you need to associate the "initiator" with the "method". It will be much simpler to identify the initiator as the skill challenge, and then have to event or consumable given the skill challenge type (already done) and categorizing them as subcategories of skill challenge and subcategory of consumables/events to avoid that duplication in the skill challenge category. The initiator is the one identified on the map like Ishmael said.--Relyk ~ talk > 00:48, 3 February 2013 (UTC)

The challenge itself is, in fact, the method by which it is completed. Ergo, the act of communing, consuming, reading dialogue, or fighting. Unfortunately, we can only document the last of those directly without making things up (treating the consumable as the challenge would be close, but still not semantically accurate), thus we are forced to document the others on the initiator.

I was already wanting to change the event/item to categorize into [[:Category:Skill challenge events]]/[[:Category:Skill challenge items]]. The first would bring the events in parallel with other event types, e.g. Category:Meta events. The second is making up yet another subtype of consumables, but I don't feel bad about making those up since we have such a strong precedent of doing so.

I think we're in agreement? Then I'll go ahead and start modifying the "combat" challenge listings. —Dr Ishmael 01:58, 3 February 2013 (UTC)

No opposition to table change or the categories you proposed. Konig/talk 02:02, 3 February 2013 (UTC)

(Reset indent) Just want to bring up something - since we're going to denote by initiator (object/NPC) and not the method (event/item), should we denote the skill challenge events in the Events section of articles - and similarly, NPCs part of said events should, I presume, get such mentioned? If so, we may want to make a {{event skill}} or some such, to use the icon. Konig/talk 03:17, 10 February 2013 (UTC)

I'm not really sure why we have all those individual "event x" templates, when we have {{event icon}}, but yes, that would make sense. I'm not sure what you mean by "NPCs part of said events" though. —Dr Ishmael 03:35, 10 February 2013 (UTC)

Basically, what I mean is what I did on Devotee of Owl and Ghostly Owl earlier today. Konig/talk 03:41, 10 February 2013 (UTC)

Ah, of course. Yep, that makes sense too. —Dr Ishmael 03:44, 10 February 2013 (UTC)

documentation of PoIs

For points of interest, should we be documenting NPCs/events/etc. that happen near the PoI? That stuff should already be documented on the area page that contains the point, so it seems like a duplication of effort. I'd think that the point's page should document the point itself, and leave the area page to document things that appear/happen in the area around the point. What does anyone else think? —Dr Ishmael 21:09, 7 February 2013 (UTC)

I can agree that some NPCs and events can be left out. It depends really on which ones are in fact part of the PoI and which doesn't. A owner of a lodge for example should be included. A nearby scout not. Some other question, should we add the area nav to the PoIs? Hencovic 21:40, 7 February 2013 (UTC)

We often specify the location of NPCs in terms of Points of interest and waypoints as naming the area the NPC is in isn't sufficient. We don't actually say the NPC is in the point of interest. The only use of a PoI is to describe a portion of the area it resides in, but the lore is summarized on the area article. You do refer to the point of interest when described what portion of the area the lore you are talking about is in. It is still useful to replicate the information from the area page if you need to be very specific about where a certain NPC or landmark resides. As far as events, they are listed on the area page, encompasses a large enough area, and have their own page that it's pointless to document on the PoI article. Of course, the "area" encompassed by a PoI is arbitrary, they are more significant for lore and defining a certain portion of an area than what resides in the PoI itself. If that makes any sense.--Relyk ~ talk > 22:03, 7 February 2013 (UTC)

I can live with this. Mostly I just wanted to make sure there were good reasons to have the things listed on multiple pages. To me, a point is still a point (albeit a very large point in some cases) and doesn't contain anything, but listing things like NPCs that are associated with the point lore-wise makes perfect sense. —Dr Ishmael 22:27, 7 February 2013 (UTC)

I think my stance is alongside Relyk's (but not entirely sure as I may be misunderstanding him...). Events cover a wide area so, imo, there's no need to really denote them - as there would be few events that are contained solely to a PoI. NPCs and objects on the other hand could provide more interest when viewing PoI pages (and it gives us some more context to use up the whitespace created by the infobox('s map and image)). I'd argue the same for waypoint. And it seems like you take the wording a bit too literally in this with "point" - a point of interest is a location that holds value (or an object, in rare cases). My classification for what NPCs are at landmarks/PoI or not is different than Relyk's though - give, for example, Skarti's Steading - by Rylek's argument only Skarti and the wolfborn there should be denoted, however there are some non-worlfborn clearly within the building. Since they're clearly within what's obviously denoted as the PoI (the steading), they should imo be placed there. But the main reason for for denoting NPCs/objects in PoI/small landmark pages is as Relyk says - it gives a narrower point of reference for where the NPCs are (however, trying to denote all the NPCs/objects in the Dragonbrand on said article is lolyeahright). Konig/talk 03:24, 10 February 2013 (UTC)

locator maps

Inspired by the locator maps used on Wikipedia, I have created locator maps for the areas in Queensdale and added them to their infoboxes. I think these provide an important piece of context that can't be conveyed by the cropped map image by showing how the area fits into the larger zone.

Feedback requested:

• Is the location/size in the infobox good? Or should we rearrange the infobox?
• What about the captions? I used small+italic based on the existing captions for screenshots in the same infobox.
• How about the SVGs? Should the lines be thicker/thinner? Is red good for marking the pertinent area?

Feel free to share any other thoughts you may have. —Dr Ishmael 05:14, 10 February 2013 (UTC)

Interesting thought, but it feels relatively redundant with just the standard zone maps you're making - might as well be less work to just highlight the zone image in a transparent color (red or yellow is my suggestion). If every area is going to have two maps though, I think I'd prefer the maps being below the other information. Thus the image order remains the same, but all four (map, location, loading screen, screenshot) are all adjacent. Konig/talk 06:59, 10 February 2013 (UTC)

In a similar notion, I have three thoughts regarding maps:

1. Should we make locator images for zones? Regions?
2. Regarding Category:Maps, I think we need to devise a sub-category system. There's two ways I see to go about this - either sort by location names (e.g., Category:Maps->Category:Kryta maps->Category:Queensdale maps) or by location types (e.g., Category:Area maps, Category:Zone maps, etc. all within the same parent of Category:Maps). The latter would be easier, but the area/poi/etc. map cats would be rather large. Overall, I think I'd prefer the latter of location type categories.
3. For things smaller than areas (PoI, certain landmarks), should we just use the area map, or upload its own map? The latter seems rather redundant to me, except for landmarks that encompass more than 1 area (e.g., Dragonbrand), but its harder to have maps of landmarks show stuff unless its obvious on the map (e.g., Wizard's Tower, Dragonbrand, etc.). I think I'd just rather re-use the area maps, given how, for example, File:Barradin's Vaults map.jpg is almost all of what Old Duke's Estate cover, but altered. And in the same notion: do we want to alter maps to show the WP/PoI/landmark names? Konig/talk 07:04, 10 February 2013 (UTC)

Was excited for these. For the primary area map, I'd prefer to have a clean map without area boundaries added. You don't need to see the area boundary when you are looking at the cropped area and can see the names of connected areas; the svg provides enough context on its boundaries and where it resides in the zone (we often talk about which portion of the zone an area is in). I'd also like to keep a clean map for areas and zones because it simply looks cleaner and people don't need to see the boundaries every time they view the zone. That's implying that the zone map with boundaries get placed in the same area as the SVGs for areas are as they serve the same purpose and context. As for the SVGs themselves, I don't mind them that large but they should go below the text no matter the size because the text gets pushed too far down.--Relyk ~ talk > 07:52, 10 February 2013 (UTC)

I disagree on not needing to see the area boundary for two reasons;. 1) the svq doesn't provide context on its own, especially in pairing with a clean area image - for example, you know the shape, you know the location in the zone, but you don't know where the placement of the boundaries around the name is - or size comparison. I can see making do without the bordering area's boundaries, however I think the area of focus' boundaries must be kept to provide absolute context - with or without the svg.

As to clean maps - I agree that one could be kept (named "<Location> clean map.jpg") and placed on the article via moving both images under the text lines, and having the following line under the maps: Map of <location> with boundaries ([[<:File:<Location> clean map.jpg|without]]). Konig/talk 08:11, 10 February 2013 (UTC)

@Konig:

• The SVGs are 25 kB, while the zone map is a relatively giant 5 MB. I wouldn't want to put ~20-30 copies of all 25 zone maps on the wiki. Also, the SVG creates good, clear thumbnails that can be understood directly in the infobox, whereas a highlighted JPG thumbnail could be difficult to interpret without opening the file page.
• If we move the maps below the data, should we move the screenshot above the data? Or just leave the data above all images?
• Locators for zones/regions are possible, but I'll have to complete an entire region/Tyria before I can do them. I'm drawing all the boundaries in a single SVG file, with each zone in a separate layer, then exporting each layer into GIMP to create the JPG images. Eventually I'll have the equivalent of w:File:USA Counties.svg, from which I can create any derivative you can think of.
• You want to figure out the categories, go ahead - I don't have any particular opinion. I didn't even think about them when I was uploading the images last night, so all the Queensdale ones are uncategorized.
• Reusing area maps for locations is a problem when you have somewhere like Shaemoor Fields - 4 hearts, 4 pois, and 2 waypoints. Those are going to need individual maps to highlight them, so we should do that for all locations.

@Relyk: I agree with Konig, the boundaries are important, otherwise you have no idea how tiny Windloss Delves is, or that Western Divinity Dam doesn't actually contain Farmer Eda despite her proximity to the name on the map, or the same for Vale Waypoint not being in Altar's Windings. And there are areas in other zones that are even worse. Having an additional clean map is a possibility, but it would require even more work (maybe I should learn how to write GIMP macros...), introduce a third map-type image to the infobox, and be of uncertain value. —Dr Ishmael 16:43, 10 February 2013 (UTC)

Progress!

I haven't forgotten about this project - in fact, it's been taking up all my free time after work and daily/monthly stuff. I'm currently 50% complete (13 of 26 zones), and at my current rate, it should take me less than 2 weeks to finish. —Dr Ishmael 03:06, 26 February 2013 (UTC)

I'm getting used to the boundary lines, but I do hope we have clean copies somewhere if people want to use or download them for whatever reason although we may not use them. I don't think I can get use to the size of the svg maps when I have to scroll down to see the rest of the information.--Relyk ~ talk > 05:04, 15 March 2013 (UTC)

Would a clean copy of the zone maps be sufficient? Because even though I was able to semi-automate the area maps with keyboard macros, I still don't want to go back and run those macros an additional 600+ times to generate clean versions. —Dr Ishmael 15:29, 15 March 2013 (UTC)

Of course, people can crop those all they want. No one likes your fancy, clean-cut, and perfectly cropped area images anyways.--Relyk ~ talk > 11:26, 20 March 2013 (UTC)

Lists of hearts/events

I finished the {{heart table}} template, so these lists can be generated automatically. They still need all the description moved into the template along with the other new formatting. For the lists of hearts pages (You can see them on Renown Heart), the region pages really aren't necessary as the navbar on each page and sidebar on the renown heart page is more than enough. There have been complaints about not being intuitive, but it's pretty damn hard to easily navigate to and between these lists currently. The same approach and presentation can be used with events, which would be infeasible to create manually. The event lists would be much more useful than heart lists by the way.--Relyk ~ talk > 05:00, 15 March 2013 (UTC)

The problem with events is event chains, especially those where multiple events feed into a single event, like Champion of the Sun. The outline format from Semantic Result Formats is almost a solution, except that it can't handle that special case - the following event gets listed multiple times, under each of the preceding events (I tested this on Anet's test wiki just now). —Dr Ishmael 15:27, 15 March 2013 (UTC)

Some thoughts on possible templates

I hope this is the correct place to put this suggestion.

I have been doing a fair amount of wiki-work in trimming event/hearts of extraneous material, trimming Location and objective lists and adding events that are missing and similar stuff. I occurred to me that the wiki, by its nature, has poor data integrity between different views of that data. I have found moderate discrepancies between the zone Locations table and the hearts/waypoints/pois/etc that it includes and the area listings of the same data. The discrepancies are even worse when events are considered.

{{area hearts}} and {{area events}} have made a degree of automation work and indeed they do so well within their limitations. I don't know if it's possible but I would like to see a template to return a "-" if there were no "bits" in an area but otherwise return a list of hearts/pois/skill points etc for each area mentioned in the zone list. i.e. {{area stuff|<zone name}}. This could be added to the zone's table. There is are two problems that arise here, which I will mention below.

Similarly, for use in area pages, another version of the above template could return a similar list for the Locations and objectives with headers and other formatting built in, so that all an area's page would require is a {{area stuff type 2}} to provide the whole L&O section.

Is this ambitious, yes, maybe it's not possible. But then I am not a coder so all I can do is ask/suggest.

There are two problems that I can see. Firstly that Waypoints and Vistas are non-linked items. It may be time to revisit this a they are, in fact, named for waypoints and are both IDed in the https://api.guildwars2.com/v1/map_floor.json?continent_id=1&floor=0.

The second problem is skills. I know there are a couple of weird cases but there are basically two types, the commune/consume type and the event type. The first of this does not need special handling. It can be picked up as easily as events or hearts by a "simple" template. The second type is harder but could be picked up by eliminating events of type skill from the lists which would allow just the initiator to be included.

Comments, thoughts please. --Claret (talk) 11:26, 21 June 2013 (UTC)

Turning locations into true subcategories

Right now we have a hierarchy of locations by convention - region>zone>area>location. This can make consolidating information into queries problematic. For example, how do I query for how many champions exist in Kryta? The champions themselves may be listed as being in a location, Modniir Gorge for example, but there is no automatic way to relate that to Kryta.

I would like to suggest a hierarchy of location properties. Located_in would be the lowest tier and would remain in the infobox. Located_in would be defined as a subproperty of Within_area. Within_area would be defined as a subproperty of Within_zone, which would be defined as a subproperty of Within_region.

Example concepts:

• Champion_Enraged_Spider_Queen Located_in::Almuden_Mansion
• Almuden_Mansion Within_area::Almuden_Estates
• Almuden_Estates Within_region::Gendarran_Fields
• Gendaren_Fields Within_zone::Kryta

Example properties:

• Located_in subproperty of::Property:Within_area
• Within_area subproperty of::Property:Within_region
• Within_region subproperty of::Property:Within_Zone

The following query should then properly show all the champions with a location anywhere in Kryta {{#ask: [[Has_NPC_rank::Champion]] [[Located_in::Kryta]]}}

Tsafran (talk) 17:20, 27 July 2013 (UTC)

Subproperties don't work that way, unfortunately. (I know, I've tried.) Instead, you have to use property chains: {{#ask: [[Has NPC rank::Champion]][[Located in.Located in.Located in::Kryta]]}} —Dr Ishmael 17:22, 27 July 2013 (UTC)

Documentation of Waypoints

While trying to write a step-by-step about a train using the /wiki command in game I always ended on the page about chat codes for each Waypoint I tried to search about. I noted they aren't links and there's not an article for them. So I thought about making it and I went to look for guidelines about how to document them and I found a page saying they shouldn't have their own page. I have been wondering why do not Waypoints have their own pages? Is it because it could lack info to be put in the pages or possible duplicate content (that could be same contents of Point of Interest pages)? If so, what about pointing/redirecting the search for them to the page about the area where they are in instead to the page with chat codes? From my point of view, the current way it works is making the search for Waypoints useless if you are looking for something else but their chat code. Even so, the way it's redirected when searching Waypoint doesn't work too as it doesn't point to exactly where that Waypoint is on that page (it always takes you to the top of the page).

Summarizing, I just wonder why Waypoints can't have their own article and, if they really don't need it, could not they have another way to redirect the search for them? Thanks for considering. - Txon Atana (talk) 15:38, 5 January 2014 (UTC)

Well all a waypoint article would have would be a map really.. and you should be able to get that information from the area article. Except that on the chat link format pages, it doesn't currently link to the area articles. Would it be useful to add a link in those tables to the area articles? (e.g. Chat link format/0x04 codes/Kryta#Nightguard Waypoint could have a link in the following column to Nightguard Beach) -Chieftain Alex 16:12, 5 January 2014 (UTC)

Yes, that was the point I suggested. Either it would have their own article page (but I believe it would have too few info or duplicated info, as they could be the same content from area articles) or making them to point to the area articles as you suggested. IMO, a page about chat codes has a very different objective from a page about a location or game item. I take as example someone trying to search for it using /wiki in game, the most of times they wouldn't be looking for its chat code only but maybe expecting for something more. - Txon Atana (talk) 18:00, 5 January 2014 (UTC)

(my bad skim reading as usual) I fixed the {{map link table}} template such that the links from the search so that it should now move to the right bit of the page (or at least, not the top). I wasn't really suggesting redirecting to the area page, though that could be done if we were to convert all area articles to use something like {{Waypoint|<name>|id}}, which could output a line along the lines of:

Nightguard Waypoint —

and then we'd have to remove the #subobject setting the id on the chat links page. (quite a large job) -Chieftain Alex 18:20, 5 January 2014 (UTC)

{{Area waypoint}} moo--Relyk ~ talk < 19:18, 5 January 2014 (UTC)

reckon this could be botted with regexp (match lines on only area pages that match the pattern:

;{{map icon|wp}} <text>

+ lookup from existing data with smw?

{{subst:#ask: [[Has canonical name::<text from regexp match>]][[Has game id::+]] | ?Has game id# | headers = hide | mainlabel = - | limit = 1 | default = | searchlabel= }}

(needs pro GW2W:BOTS..) -Chieftain Alex 20:53, 5 January 2014 (UTC)

got it I think.

Find:
\:\s\{\{(map icon)\|(wp)\}\}\s(.+)

Replace with:
{{area waypoint|$3|{{subst:#ask: [[Has canonical name::$3]][[Has game id::+]] | ?Has game id# | headers = hide | mainlabel = - | limit = 1 | default = | searchlabel= }}}}

we could do that easily, except some of the waypoints aren't formatted like that :( -Chieftain Alex 21:19, 5 January 2014 (UTC)

Generic NPCs

Is it important to list extremely generic npcs that have no real purpose? For example I'm in Lion's Arch and there's a huge amount of "locals", "citizens", "residents", "soldiers", "lionguards", and other people with generic names that do nothing. There's also "crabs", "tropical birds", "coho salmon", and other generic creatures you can't interact with either. If these were to be documented, then for every one important or interesting npc, there would be 10 that have no useful information. My approach, and I can change it if its important, is that I've only listed interactable NPCs, or non interactable npcs that have some specific function or noteworthy trait, like leader. Psycho Robot (talk) 21:17, 14 February 2014 (UTC)

Yeah, I also think those "common" NPCs which you get nothing more than a "Greet" when interacting with isn't needed to be documented (although some of their greet may be bit funny). Maybe just mention their existence would be enough, similar what you did on your post here, just a small list with what type of NPCs there are around and no further detail about them. However, if the NPC is interactive and you get some dialog or something like so it worths to have some documentation about them, even if they do nothing more than say some words and no other rule in the environment or anything else around. Some of these NPCs has interesting info about the game. Maybe I have just repeated what you are doing, but that are my thoughts about it. --Txon Atana - (talk) 22:11, 14 February 2014 (UTC)

Well, I don't think there should be articles about them, but I don't think its really worth it to document them at all. Take a look at this version of western ward. The allies list is almost 100% non interactive npcs. Players aren't interested in any of them, and there's nothing to say about any of them, except ambient dialogue, which I am currently documenting. In contrast, check out Sanctum Harbor. There, only interesting or noteworthy npcs are listed. It is my belief that all area articles should omit uninteresting generic npcs, as its just clutter that isn't useful to anyone. Psycho Robot (talk) 23:11, 14 February 2014 (UTC)

Articles on them already exist, no point in deleting them. As for listing them - I think it's important to denote the ambience of an area. Konig 01:44, 15 February 2014 (UTC)

I disagree that it gives you a sense of ambiance. For example, noting that an area contains "citizen", "locals", "travelers", and "patrons" conveys no useful info, since all of those npc types come in all races. Its literally as useless as saying it contains "people". Psycho Robot (talk) 02:07, 15 February 2014 (UTC)

Which is more useful than denoting nothing which can give people the false sense of "there's no one but these listed NPCs here." Furthermore, unlike most game wikis, the Guild Wars Wikis have always been fully-documentative wiki. Konig 03:28, 15 February 2014 (UTC)

How about a compromise then, we have a section for notable NPCs up at the top... maybe something like:

==NPCs==
===Allies===
*important npcs
*that don't offer services
====Services====
*service npcs
====Ambient====
*every type
*of generic
*npc that
*is in the area

Psycho Robot (talk) 03:48, 15 February 2014 (UTC)

(Reset indent) Eh... "Ambient" to me when talking about NPCs has always meant "cannot click on" - such as the cranes seen in Halacon Cataracts. Or at best, things like critters.

I'm really not seeing an issue with listing them though. Or with, well, any of the three(+?) issues you've brought up while doing this. Konig 10:23, 15 February 2014 (UTC)

Edit: Either way, I think we can focus on the "how" later, and right now should focus on getting the information down. These guys will disappear Tuesday! Only 3 days left to finish documenting Lion's Arch! Konig 10:24, 15 February 2014 (UTC)

You're right, its three: 1. documenting useless npcs, 2. having race names in ambient dialogue, and 3. your sassy 'tude, mister. Oh and don't you worry about me! I've got 50 clients open now covering every square inch of this city! I'm the best there ever was! The fourth issue is 4. that you doubt me. The reason why I think this is worth discussing is because nobody cares, really, that western ward has green moas and mosquitos and coho salmon and not one, not two, but more than that generic names for people. But they do care about npcs that have something useful or interesting to say, and having them jammed together in a big ol list just obfuscates important info with trivial minutiae, especially with everyone's unshakable affinity for alphabetical order. Seriously what is it with you guys? Psycho Robot (talk) 16:40, 15 February 2014 (UTC)

1) This; 2) here; and 3) there is what I meant. But anywho. As I just mentioned elsewhere - let's first focus on ensuring we have all the information, ja? Format can change later. And I suggest keeping all these names up, and together - people can easily separate unique names from common names. We aren't dealing with 2 year olds who's hands we must hold constantly. Konig 22:08, 15 February 2014 (UTC)

Sector boundaries in the API

Hey, i just wanted to let you know that sector boundaries for each map are now in the API (in case you missed it yet). I made a wiki compatible proof-of-concept which also allows you to display multiple maps on a single page - see it in action over here. You like it? :D --Smiley™ de: user | talk 19:36, 8 June 2016 (UTC)

Yeah, impressive. (Tanetris highlighted the twitter post to me). I've borrowed a tiny bit of your code with regard to chatlinking, but I haven't made any other heavy modifications to [[Widget:Zone map v2]]. I don't think the sector boundaries are necessary for the interactive maps, though the sector names would probably be a good addition. However sector boundaries might be useful to produce a separate widget to help updating the static maps.

Whats up with the "override L.TileLayer.getTileUrl() and add a custom tile getter" line by the way? Is that just to use blank.png if the tile doesn't exist? -Chieftain Alex 22:41, 8 June 2016 (UTC)

Also, any ideas if there is a lookup table to convert "coordinates of hero challenges" to "Names of hero challenges" (wiki article names) anywhere on the web? If not I might work on that. -Chieftain Alex 22:48, 8 June 2016 (UTC)

That's a cool addition indeed and your proof-of-concept looks nice. I don't see much use for it on interactive maps here either, however maybe it could be used to limit those maps, like not allowing it to be scrolled far from that area? I'm not so familiar with how that map API used here works though, but I believe there is a way to limit the scrolling. Map names (with level) are useful too. --Txon Atana - (talk) 01:53, 9 June 2016 (UTC)

Alex: the tile getter lets me specify exactly which tiles to load and prevents 404 spam (leaflet displays the errortile only after a tile could not be loaded), so the custom tile getter speeds up loading, too. I opened an issue on that once but they found it wasn't necessary.

re your Widget: just one thing - please include leaflet from cloudflare cdnjs. The leaflet CDN doesn't support https.

re maps display: my idea was to use interactive maps for the zone/poi pages - a link in the infobox opens an overlay with the map. This way it doesn't break anything and there's enough space to display a map in usable size. Limited scrolling is essential and built in in each map - note how you can't scroll far over Queensdale's borders in the first map or the WvW region in the second (there's a 10% padding around the map's continent_rect), you could basically limit the scrolling to zero (plus leaflet rubberband effect) so that you can drag the map just around and it flips back to its initial position. I made some silly examples and templates (german) ca 3 years ago just to check out how an interactive map in an info box would work, also some _ test articles, all of which were based on the first version of my widget (for those who haven't seen it yet).

re more cool stuff: region boundaries for heart tasks, "reverse geocoding" (PR required), file_id and chat_link for wvw objectives, regions metadata, GeoJSON (maybe), event metadata in the maps response

So there's that :) Mind to grant me Widget editor rights? It's asically what i asked poke and ish back when i made the widget for the de-wiki, was redirected to some page in the depths of this wiki, and then noone felt responsible to do something. I'd glue together a proof of concept over here, so that you have a better visible examples and the users can comment on it, too. --Smiley™ de: user | talk 13:39, 9 June 2016 (UTC)

@Txon Atana: Yeah that would be a possible use.

@Smiley: Despite my being omni-present on the wiki as of late, I am not a bureaucrat so I can't administer user rights, you'd have to ask Tanetris or Poke (use either user talk page). It looks like you've been using the maps api for a while so no wonder everything appears so fluent...

I'm halfway through matching hero challenges coordinates with articles, might have a first draft later today. -Chieftain Alex 17:43, 9 June 2016 (UTC)

Oh thanks, working with maps is basically part of my job, where i work with stuff like the TomTom Business API and Gmaps, so GW2 maps are a nice playground - and i really wanna see interactive maps in articles one day ;). Tanetris just granted me widget editor rights and i'm going to add a POC widget for testing and comments as soon as i get time on my hands. Since i'm not familiar with your wiki's templates, i'll start off with a clean basic implementation which then can be implemented in your templates. --Smiley™ de: user | talk 22:57, 9 June 2016 (UTC)

Okay after a careful prod around your well laid out code, it was like 2 lines to get the sectors added to the test widget.

Interestingly we could now produce maps with sectors for cities too. Plus we can check the HoT/wastes ones as mentioned previously. I'll get around to pasting it into inkscape tomorrow.-Chieftain Alex 01:02, 11 June 2016 (UTC)

PoI Stub List Addition: Zone Column

I'm slowly working through the stub articles, but it takes a while. If possible, it would be helpful to expand the PoI stub table to also include the Zone in which the Area is located. Eg: Caer Aval is in Fort Trinity, which is in Straits of Devastation. Right now it just lists Caer Aval and Fort Trinity. I don't always remember what Zone each Area is in, which makes it difficult to tell if there's one nearby. Generally, I'll look at them if I'm close by, but sometimes I can't tell. I'm not sure how to edit the table, so it's a bit tricky for me. I may experiment in my sandbox, but if anyone else knows how to add the Zone to the table, that would help a lot. AnastashaRomanov (talk) 23:01, 25 October 2019 (UTC)

I'm no good at this. I found out you can add | ?Located in tree=Within to show all parent zones/regions/continents, but I dont know how to just show the next higher zone above an area. —Kvothe (talk) 20:10, 26 October 2019 (UTC)