Template talk:Standard prerequisites

• Tyrian (Prophecies) or Elonian (Nightfall) character wait whatt? AA mission not active? don't break something not broken.— Balistic 22:17, 14 November 2009 (UTC)

Now we have to have both |campaign = Factions and |nationality = non-canthan for Canthan quests that are Tyrian and elonian only. — Balistic 22:18, 14 November 2009 (UTC)

{{Standard prerequisites|nationality = non-canthan}}

• Tyrian (Prophecies) or Elonian (Nightfall) character

{{Standard prerequisites|nationality = non-canthan|campaign=factions}}

• Tyrian (Prophecies) or Elonian (Nightfall) character

— Balistic 22:19, 14 November 2009 (UTC)

I wasn't aware that any but myself was using this template, so my apologies if my changes tripped you up. --DryHumour 22:22, 14 November 2009 (UTC)

Prerequisites, non-prerequisites, and sandboxes

Mainspace templates are not sandboxes: please develop in your own user space and submit a link to a proposed version here and/or GWWT:QUESTS#Prerequisites for community discussion — a discussion which is not yet over and has not arrived at any conclusions. --DryHumour 23:46, 16 April 2010 (UTC)

Problem with eton nationality

The normalize changes borked EotN nationality (e.g. Fire and Pain). I've reverted for the time being as I don't have the time to fiddle with it right now. --DryHumour 02:03, 23 April 2010 (UTC)

Point taken. Would listing all the nationalities be an acceptable solution? --Max 2 07:43, 23 April 2010 (UTC)

Would be kinda redundant since it's hard to make a character that is not Canthan, Elonian or Tyrian, but if no better option is found, it should still be fine.

I guess you could try adding an extra #ifeq check prior to the character line, so that if eotn is selected, then a different text is displayed and the campaign selection ommited?

Another option could be creating a separate parameter for expansions (since technically EotN is not a campaign). That would leave room for any future BMP-like content and could allow you to use the entry "any" on nationality.--Fighterdoken 08:40, 23 April 2010 (UTC)

Yet another option would be to make 'normalize' return a single word rather than having it do all the heavy formatting. I think I got a little too fancy here. In the mean time, I'll put the rest of the 'normalize' stuff back. --Max 2 09:31, 23 April 2010 (UTC)

I've simplified {{Normalize}} and have this template working in my sandbox. (That version also includes the skill test not, which is still under discussion elsewhere and I will not be including that change quite yet. Please comment on that on the quest formatting page.) Please check it out. --Max 2 16:57, 24 April 2010 (UTC)

lookup

The template allows a more flexible list of values than an embedded list and includes the Bonus Mission Pack. It also allows the alternate designation 'gwen' for Guild Wars: Eye of the North.

Jon, get over this vendetta please...

--Max 2 12:09, 4 May 2010 (UTC)

For nearly the same amount of code on this page, you're instead invoking a page that is about the size of this page. Doesn't seem that efficient to me. And since when are you "transfered" to the bonus mission pack? And adding 'gwen' to this list is trivial. --JonTheMon 12:43, 4 May 2010 (UTC)

True so far, but {{ lookup }} can be used elsewhere. --Max 2 16:33, 4 May 2010 (UTC)

As has been said before, don't just come up with a need for the lookup template. This page isn't overly complex unless you add your template. In addition, why are you making one catch-all template when individual templates would be cleaner and smaller? --JonTheMon 17:20, 4 May 2010 (UTC)

"This page isn't overly complex unless you add your template." REALLY?!? --Max 2 18:53, 4 May 2010 (UTC)

Yes, really. Honestly, there's no need for the added complexity. --DryHumour 00:07, 5 May 2010 (UTC)

Exactly what is a 'transfer'?

There are currently exactly two uses of the 'transfer' parameter in all the quests that use 'Standard prerequisites' and those are both in 'factions'. On the other hand, all the BMP quests/mission require specific product installations. By separating the installation requirement from level and locking requirements, this template becomes more useful. (It would be even more useful if I could find a good way to separate the 'secondary profession specified' component, but I'm not there yet.) --Max 2 16:45, 10 May 2010 (UTC)

Jon: What's this thing you have with the stuff I do. You seem to follow me around, messing up stuff I've done just because I've done it. Maybe you should look a little deeper before you land on something with both feet like you are currently doing. In particular you seem to be violating the GWW:AGF rule. --Max 2 16:45, 10 May 2010 (UTC)

The transfer parameter was added relatively recently. The motivation was to provide a means for reducing the amount of typing required (and thereby improving the consistency) when documenting the quests which allow characters to move between campaigns. Not all of the applicable quests have yet been updated, but it is expected that they will eventually be. The BMP quests were not considered for the purposes of the transfer parameter — but there is no particular reason it could not be extended or re-purposed I suppose. It might (or might not) be clearer to add a new parameter, though. —The preceding unsigned comment was added by DryHumour (talk • contribs) at 17:26, 10 May 2010 (UTC).

The typing saved is fairly small and the standard formatting can be done with 'minimum' and 'locked' parameters, which are also recent additions. Using the explicit parameters should make it easier to search for things. --Max 2 18:45, 10 May 2010 (UTC)

First off, like the IP said, those quests aren't updated yet. Second, how doe the BMP quests/missions require a specific product? You can get to them from any campaign. Third, I don't have a problem with the "locked" and "minimum" parameters, but if those are only used for transfer quests, I don't see why they should be separated out (I can see the level parameters having some use like with festival quests)

As to why I'm "following" you, it's because I take extra care to look at changes made in the Template namespace, which you tend to make many of your edits in. --JonTheMon 19:54, 10 May 2010 (UTC)

OK. I'm reviewing the applications of this template and making changes when appropriate. How the BMP quests are called out will make a difference in how they need to be documented. In most cases I think they will be called out at a particular location from some campaign in which case the fact that they require a separate product (The Bonus Mission Pack) installation will be significant. The same goes for the other cross-product quests. --Max 2 21:37, 10 May 2010 (UTC)

Pre/AA Changes should be discussed

There was still ongoing debate on User talk:Mtew#Pre and Ascalon Academy; changes to any mainspace template ought to be discussed, particularly ones which have large impact. As I have said there, and repeat here, there is no good reason to move a common criterion from a central location to all of the points of reference. --DryHumour 02:39, 15 May 2010 (UTC)

Proposal to allow both minimal duplication and efficient DPL

Given the recent brouhaha (to which I was, I am sorry to say, a central contributor) I felt I might be able to best make amends by attempting to find a solution which embraces both sets of requirements. In the process of experimenting, it dawned on me that there may be a solution which is both trivial and elegant: surrogate templates.

The operating principle here is that the DPL would then not directly process the original template arguments, but rather use the surrogate to provide any extra processing necessary. This has the dual advantages of meeting both sets of requirements while also allowing both templates (the original and the surrogate) to remain extremely simple, focused, and entirely separate — the decoupling provides excellent ease of maintenance and considerable independence of change. It also, of course, opens the DPL results up to a much richer set of potential transformations, which might be even more useful to the query writer.

I have mocked up an example in User:DryHumour/Sandbox/Standard prerequisites/metadata.dpl with a sample query at User:DryHumour/Sandbox/Prerequisite metadata (which queries User:DryHumour/Sandbox/Standard prerequisites#Examples). This is just a proof of concept: obviously all of the low-level details can be varied according to actual needs.

I also tried a couple of other approaches: having sets of "associate" and "associate state" parameters; or an embedded dummy template; but the surrogate template approach seemed superior to both. (Keep in mind that these were abandoned efforts, so the linked snapshots do not reflect complete functionality. I mention them here only in case they should appeal more.) --DryHumour 21:22, 16 May 2010 (UTC)

I forgot to mention that this approach would requires only minor changes to the template itself, and to two articles (Mhenlo's Request and Plague in Cantha) so the editing impact would be extremely minimal. Also, for those who don't want to wade through the code: the key trick which is being exploited is that the surrogate template can access, transform, and otherwise manipulate the parameters in any way it likes. The example illustrates this by conflating the started and unstarted quest lists with the active, inactive, complete, and incomplete lists, just by way of demonstration. --DryHumour 21:36, 16 May 2010 (UTC)

The basic idea should be two layers of template:

The base layer

should be uncomplicated formatting only. No special condition checking. Each parameter produces a single bullet.

This layer is the one that is most useful when doing DPL reports since each parameter provides specific information.

The over-layer

which is only needed for special (although quire common) situations and provides parameter consolidation. The following special cases are known at the moment:

• {{Pre-Searing prerequisites}}

It would have one special parameter, 'test = <y|n>' for the primary profession tests and it passes all other known parameters through to {{Standard prerequisites}}.

• {{Transfer prerequisites}}

It adds different things for the different campaigns. The main change here would be adding a 'installed = <product>' paraneter to {{Standard prerequisites}} and a simple way to specify that a secondary profession selection is required. Again, all other known parameters should be passed through.

Problems that remain:

• Everything in Eye of the North requires that one of the base campaigns be installed. They all have minimum level and secondary profession selection requirements for all quests and missions. There should probably be a seperate {{GWEN prerequisites}} template.
• Everything in the Bonus Mission Pack requires that one of the base campaigns be installed, but has no level or secondary professon selection requirements IIRC. Maybe a {{BMP prerequisites}} template? Are there problems with the list of 'givers'? I have not really looked at these but vaguely recall that their prerequisites were odd in a minimalist way.
• Lists are difficult to handle, especially when it comes to DPL. The LoopFunctions mediawiki extension (which is not about programming!) might be helpful.

--Max 2 11:55, 23 May 2010 (UTC)

Couple things. I'm not really sure what the gist of this proposal is supposed to be. Does it have a semi-complicated base template, and then surrogate templates that simplify using that base template? And as to the EotN/BMP needing another campaign, since the former is an expansion and the latter is a bonus pack, I think the basics of game design would properly indicate that you need a base game (chapter). --JonTheMon 13:52, 23 May 2010 (UTC)

Depends on how you measure complexity. If you count the number of parameters and the amount of output, it would be 'complex'. If you look at a each little section, it would simply test if the parameter was supplied and then produce a bullet item based on that parameter.

GWEN and BMP: That's a big 'Gee, Duh? You expected something different?' Of course they're bonus/expansions. That means they require a base campaign. Just like the transfer quests require different base campaigns.

--Max 2 15:25, 23 May 2010 (UTC)

Not to be rude, but I was hoping for Dry's thoughts, since the original section is his. As to EotN and BMP, transfer quests and such make a point to mention the other campaigns because they are transitory quests. When you're in Old Ascalon, you don't care about getting to other content, but when you're in LA and see a Dervish, you might want to know how to get to other content. Hence, stating explicitly that certain campaigns are required. --JonTheMon 16:28, 23 May 2010 (UTC)

(Reset indent) @User:JonTheMon: My original proposal (at the start of this section) was to keep {{Standard prerequisites}} virtually identical to how it stands now, extending as needed for BMP etc. To accommodate DPL needs, I suggested the use of surrogate templates since they are, in essence, "base layers" which do not have to appear explicitly in the template implementation. That would provide excellent decoupling, both physical and conceptual. Also, multiple surrogates could coexist if different query needs should arise (and also that the {{Standard prerequisites}} template would likely not need to be changed for each). Further, the physical decoupling would allow for DPL experimentation to be entirely independent of the main template (meaning that problems or mistakes during development would not effect the mainspace).

The "layering" proposal by User:Mtew (always presuming I understand it correctly, which I may not) is very similar, but not identical, in nature. It casts the "base layer" in much the same roll as the "surrogate template", but calls it explicitly from the "over-layer" templates. Both approaches offer various tradeoffs. --DryHumour 22:42, 23 May 2010 (UTC)

@User:Mtew: For my part, although it is by no means a show stopper, I would slightly prefer that the "over-layer" interface not be fragmented into several templates: I feel that a single interface point is a good way to promote familiarity and, therefore reuse — although a category and good documentation that ties everything together would probably remedy that. The effective name change at the "over-layer" would also mean revisiting every existing {{Standard prerequisites}} instantiation, which strikes me as unnecessary work, but of course that is not a big deal either.

So assuming I understood correctly — that we retain the ability to specify the minimum number of parameters and allow the templates to fill in as much information as possible (which sounds like the case either way) — I'm equally comfortable casting my one vote for either proposal, or some combination of the two (or, indeed, neither). --DryHumour 22:42, 23 May 2010 (UTC)

Sorry for Wall Of Text™ --DryHumour 22:42, 23 May 2010 (UTC)

Yes, it would be a bit of work to put it in place, but I'd be willing to do it myself. (Let's not get into THAT again.)

The process would maybe be to add the 'installed =' parameter first with an example to make sure it is working. If you could figure an acceptable modification to the 'profession =', 'primary =' and 'secondary =' coding to specify that a secondary profession selection is required, that would finish the first phase.

The next thing would be to build the specific situation templates, with examples. After it is agreed that they do what is intended, I and whoever wants to help would change the pre-Searing and transfer quests to use the specific situation templates.

After that, the special case handling in {{Standard prerequisites}} could be removed.

At the same time all quests would be up for review and revision to use the prerequisite templates.

Discussion of other specific situation templates, like GW:EN and GW:BMP would proceed and could be applied where appropriate. That probably should be done in a new section here.

Inclusion of additional information to the requirements section would then be open. This is not where that discussion belongs.

--Max 2 01:18, 24 May 2010 (UTC)

I'm still not sure what you're getting at. would you be able to make a diagram or something like that to show what the head templates would be, and the surrogates would be? --JonTheMon 01:30, 24 May 2010 (UTC)

@User:Mtew: What are your opinions concerning a) use of surrogates; and b) a single "over-over-layer" template. I feel that there are benefits to be had in both cases, with few (if any) drawbacks. --DryHumour 01:30, 24 May 2010 (UTC)

Jon

The base template would be {{Standard prerequisites}} as it is now. Surrogates usually have the same name as the base template but are either in a different name space or a prefix or suffix is provided. The technical mechanism allows any substitution but that full capability can lead to confusion and is seldom used.

DryHumor

a)

Surrogates have a definite place in report generators. Having the base template uncomplicated by special case logic makes writing them and their surrogates easier. They work best if all the information that is to be display goes through a single straight-forward template. That is the reason to have a base layer of templates. (Technically, surrogates are alternate templates in the base layer.)

b)

A single template with special case coding requires extra parameters and coding the split out the special cases. Separate special case templates do not require any extra parameters. The name of the template is what indicates which case it is. There may be a few more templates, but choosing good names can more than make up for the complication. (over-over-layer?)

--Max 2 04:31, 24 May 2010 (UTC)

Yes, clearly the use of surrogates would be simplest and most beneficial in conjunction some sort of aggregate template — i.e. one which takes all of the possible arguments — which is what I advocated (perhaps unclearly) in my original proposal. My thought was that the original/current {{Standard prerequisites}} already meets that set of requirements quite admirably. In that sense, it could actually be the so-called "over-over-layer" and at the same time also the only layer, thus keeping things relatively simple with the added benefit would require virtually no tedious re-editing of existing pages. Since the report generation would take place relative to the lowest level in either case, it seems to me that there might not be all that much to be gained having upper layer(s) which consist only of a massaged call to the common lower layer. (I may perhaps be missing some crucial point here, but my reasoning is that any auxiliary processing performed by an upper layer might just as easily be done in the surrogate itself.) --DryHumour 06:32, 24 May 2010 (UTC)

In passing, note also that surrogates are often implemented as sub-pages of the template to which they apply, thereby in some degree ameliorating any naming confusion. That would probably be eminently appropriate here, particularly since the installed version of DPL (1.8.8) does not support the alternate surrogate template syntax (1.8.9). --DryHumour 06:32, 24 May 2010 (UTC)

The problems with the current implementation are:

• There is no way to specify product installation requirements independent of 'transfer ='
• There is no way to specify that a secondary profession must be selected independent of 'transfer ='
• To get a complete list of unstarted activity requirements, you have to look at the 'campaign =' parameter as well as the 'unstarted =' parameter. You should only have to look at the 'unstarted =' parameter value.
• To get a complete list of locked area requirements, you have to look at the 'transfer =' parameter as well as the 'locked =' parameter. You should only have to look at the 'locked =' parameter value.
• To get a complete list of unlocked area requirements, you have to look at the 'transfer =' parameter as well as the 'unlocked =' parameter. You should only have to look at the 'unlocked =' parameter value. (There is also an interaction with a quest infobox parameter, but that is another issue and needs to be discussed elsewhere.)
• To get the minimum level requirement, you have to look at the 'transfer =' parameter as well as the 'minimum =' parameter. You should only have to look at the 'minimum =' parameter value.
• To get a list of completed quest requirements, you have to look at the 'campaign =' and the 'test =' parameters as well as the 'completed =' parameter. You should only have to look athe the 'completed =' parameter value. (There is also interaction with a quest infobox parameter, but that is another issue and needs to be discussed elsewhere.)
• GW:EN has common product installation and level requirements. I believe it also has a secondary profession requirement, but I could be wrong.
• GW:BMP has common product installation requirements. There may be other requirements as well.

That is a fairly substantial list of issues. The current implementation is just too complicated. The complications should not be in the base template. Special case templates should be used to isolate the complexity.

Please do not worry over-much about the amount of work involved in making the changes. I am willing to do (and did do at one point) most of the editing required if no-one else cares to do it.

--Max 2 07:33, 24 May 2010 (UTC)

I believe that all of those can be addressed through a surrogate (e.g. see the example I cooked up which demonstrates boiling down the (in)active/(in)complete). I think it only comes down to whether the extra manipulation is done via the base in the one case, or the surrogate in the other (i.e. I believe over-plus-base layer is roughly functionally equivalent to single-plus-surrogate). I don't think there are any items on the list which cannot be accommodated either way (excepting perhaps the quest infobox item which you mention too briefly for me to provide useful comment on). --DryHumour 07:55, 24 May 2010 (UTC)

Interesting. I think a link to the 'metadata.dpl' template would be a useful addition. It took a bit of rummaging to find it.

The extra code to handle 'transfer' and 'campaign' special logic is what I find objectionable. Without it, the DPL 'using' clause could be used to get the information without the complication of a suroggate. Also, you can not specify that some products should be installed independent of the 'transfer' parameter. That is a serious problem since 'transfer' forces a number of other items into the requirements list. Similarly, how can the requirement for having a secondary profession be denoted without 'transfer'?

--Max 2 15:05, 24 May 2010 (UTC)

So, I think you're getting way past the scope of this template. In short, it seems like you're trying to make this into an infobox, when the original intent was to just standardize some of the requirements text. --JonTheMon 18:42, 25 May 2010 (UTC)

(Reset indent)

Jon

What the fuck are you doing? An infobox is a thing that summarizes and is a right aligned table. This is a section format standardizer. The changes I just made are in line with the discussion so far and did not disturb any of the existing function. You pulled it before any discussion. You are being a vandal. Stop it! --Max 2 18:53, 25 May 2010 (UTC)

Like I said above, saying you need the base game to play an expansion or bonus pack is highly redundant. --JonTheMon 18:56, 25 May 2010 (UTC)

Also discussion isn't enough to make changes to an important template. You need consensus. Unless I'm blind and I can't read I don't really see any kind of consensus for what you tried to do. +It's just plain redundant anyway... --Lania Elderfire 19:00, 25 May 2010 (UTC)

The problem was discussed. The solution was fairly obvious. No alternates were proposed, nor were objections raised. The change did not break anything.

Having an 'all' option for nationality is not redundant. It may be useful in documenting Eye of the North and Bonus Mission Pack requirements. It does not have to be used if it is inappropriate. Removing it without additional discussion is vandalism on your part.

--Max 2 19:12, 25 May 2010 (UTC)

You know, calling someone a vandal for reverting redundant/useless template entries can be construed as a personal attack. In any case, there are voices of opposition here, and Dry's idea was to use a surrogate template and keep this template alone. Just because it doesn't "break" anything yet doesn't mean that you should be able to do whatever you feel like doing. --Lania Elderfire 19:22, 25 May 2010 (UTC)

First, it is only 'redundant' in Jon's opinion. At least one potential use for it has been mentioned.

What I said was a description of his action, not a description of his person. I've a fairly negative opinion of his person at this point, but I have not expressed it because that would be a personal attack.

There is no approved policy against changing 'major templates'. It is only Jon's personal policy. By enforcing it, he is being a vandal. In fact that policy would be completely at odds with 'the wiki spirit'. It also violates GWW:AGF.

And why the 'yet' qualifier? The change either breaks something now or it does not.

--Max 2 19:59, 25 May 2010 (UTC)

(Reset indent) I thought we were agreed that all changes would be discussed (and ideally in a calm, respectful fashion). The best way to avoid drama and disruption is to have a plan which has been fully hashed out among the key shareholders. I had been under the impression that genuine, constructive debate was achieving results. I strongly suggest that we return to that model: cursing, name-calling, and acrimony are counter-productive, achieving nothing. --DryHumour 20:17, 25 May 2010 (UTC)

I feel compelled to add that I do not recall seeing any discussion of the addition of the new parameters or nationality value. For the record, it is my opinion also that the "all"/"any" nationality value is redundant (as I mentioned below, earlier). --DryHumour 20:17, 25 May 2010 (UTC)

Mtew, the thing I don't think you are getting here is that EVERY time you make any change to this template, it jumps the job queue because every page that contains this template is then changed. That is why we are so insistent on discussion UNTIL consensus is reached before any changes are made. While you might not see your change as "breaking" something, it is in fact putting an unnecessary load on the server. -- Wyn talk 20:52, 25 May 2010 (UTC)

I get that. Your use of 'unnecessary' is perjorative. I also get that reversions have the same impact which is something you are ignoring. --Max 2 22:49, 25 May 2010 (UTC)

Wild Idea: A quest availability page

(If there is a better place for this, by all means move it there!)

This would not be a template. It would be a Form with interactive input.

It starts with a selector for one of the 'regions' in all the campaigns. It would also have selectors for originating campaign, primary and secondary profession, and level. Possibly a checklist of campaigns completed. Once these are filled in, A list of quests and missions for the region would be shown.

Each quest and basic mission would have a 'status' radio button with 'not started/failed/abandon', 'in progress', and 'completed' options. Mission bonuses would have seperate entries with different status selectors that depended on the campaign.

The lists would be separated into groups for each area or zone in the region. There would also be lists for stuff unavailable due to primary and secondary profession selections, campaign of origin, and missed oportunitiies.

Unavailable (deactivated) entries would be 'grayed out' in the usual fashion.

Changing the status on a quest, level or profession would activate (or deactivate) other quests, missions and areas.

The state of the page could be saved to (and reloaded from) a 'cookie' with a specific user specified name. (This is to allow several different character's status to be saved for each user.)

Possibly running totals on experience and gold available for all the available selections.

--Max 2 12:38, 23 May 2010 (UTC)

First off, that seems more like a user template (like Wyn's Mission Progression template), just instead of for missions, for quests. --JonTheMon 13:03, 23 May 2010 (UTC)

Yes, I've got a set of templates like that in my user space already. The problem is the interface is crumby, and they have to be hand tuned. Their data is taken from an auxiliary page for each character. This would be different because it stores the information in a 'cookie' so you would not have to register to be able to use it. Also, the user does not have to use an editor to make changes.

--Max 2 15:25, 23 May 2010 (UTC)

This is a wiki, not a generic fan website. Having something available like that requiring cookies and all is way out of the scope of this wiki. --JonTheMon 16:24, 23 May 2010 (UTC)

Jon

I've been asked to discuss ideas before doing anything with them. Your 'out of scope' argument is complete bull. It may or may not be possible, but until someone has investigated, it is just an idea to be discussed. Further, what the hell does being or not being a 'fan website' have to do with this? It would be a service to game users to have such a tool and would definitely add to the usefulness of this site if it can be done.

--Max 2 01:31, 24 May 2010 (UTC)

Jon's 'out of scope' argument is not 'complete bull.' The scope of this wiki is to document the game. While one can track their individual progress within the game to some extent in the user space, the wiki is not meant for developing tools for such purposes. And even if for some reason it was determined that it is a suitable project for this wiki, it would be impossible to code with the current wiki framework. One cannot create forms with wikicode, or at least not with the version (i.e. sans extensions) used on this wiki. Datrulegend 13:15, 24 May 2010 (UTC)

Jon's argument as a reason for not doing it is bull. A tool for determining which quests are available to a character in a given situation would be a way of documenting the game and would therefore be 'in scope'. However, if forms can not be done with the currently installed extensions, that is a reason for not doing this (at least for now). Some form of data entry exists to implement the editor, search, login and various special pages. Cookies are used to manage login. From what you are saying, those functions are in some way special and are normally inaccessible. Is that correct?

--Max 2 14:29, 24 May 2010 (UTC)

Let me clarify: The purpose of the mainspace of this wiki is to document the game in a way that is not specific to each user. In regards to the question, yes. The Preferences page, for example, is in the 'Special' namespace for a reason, as I understand it. Datrulegend 15:15, 24 May 2010 (UTC)

Also... when discussions occur, a positive outcome isn't guaranteed. Just because someone disagrees, it doesn't make their argument "bull", unless they are saying the equivalent of 1+1 =43.... which Jon Isn't. Just as Datrulegend and Jon said, it is out of the scope of the wiki. Documenting accomplishments should only stay in the user space... If you want to code something for your user page then go for it, but don't bring it into the main space. --Lania Elderfire 15:58, 24 May 2010 (UTC)

Datrulegend

While a reader of this wiki might be interested in his or her specific character from the games, this tool would document what is available in a particular situation. As such, it would be of 'main space' interest, not just some particular user's interest. And yes, I am aware that 'Preferences' is one of the special pages that has form entry ability and probably uses cookies as well. Can those capabilities be used on other pages?

Lanai

True, but the outcome should be based on the real issues, not on some off the wall mis-characterization of what is 'in scope'. I believe I understand what Jon is saying, but he is flat out wrong. He seems to be saying that it would be only for users of this wiki. If it works the way I envision it, any reader (not just registered users) could use it to explore what options are available in a situation. This idea is unusual only because it presents dynamic content that depends on the readers input

--Max 2 16:26, 24 May 2010 (UTC)

You just answered your own question. By dynamically generating content that depends on a reader's input, it is out of the scope of a wiki in general. As for whether or not 'those capabilities [can] be used on other pages,' no. As I understand it, the only forms on this wiki are in the Special namespace, and are thus created by the MediaWiki framework. The only way to create additional forms in this wiki would be to either 1) add another Special page by editing the wiki's architecture or 2) convince the higher-ups of this wiki to add a MediaWiki extension that allows users to create forms, which probably doesn't exist in the first place. I'm fairly certain that won't happen, considering how the last discussion I observed regarding MediaWiki extensions on this wiki went... Datrulegend 16:53, 24 May 2010 (UTC)

Still, that is not a reason for not trying to do it. You are saying that you do not think it can be done. None of you give a reason why it should not be done. --Max 2 18:13, 25 May 2010 (UTC)

i'm not sure how to be more clearer... User generated content is not compatible with GWW's mission. Read Guild_Wars_Wiki:About. Pay attention to where it says, ""the purpose of this site is to document Guild Wars". User specific information or possibly user generated content belongs in the user space, not the main space. I'll say it again. User generated content does not document the game. --Lania Elderfire 18:27, 25 May 2010 (UTC)

You are not clear because you are confused. The proposal is NOT to have users generate content, even if almost ALL of the content of ANY wiki is user generated. The proposal is for a tool that would mimic a fairly complex and confusing aspect of the games. (BTW more clearer is neither more clear nor clearer. it is confusing. 8Þ ) So what you are saying is plain bull. Get your act together. --Max 2 20:44, 25 May 2010 (UTC)

If it does not contribute to the purpose of a wiki, it's user content. Scripted quest availability/completion code is outside the purpose of this wiki. --JonTheMon 20:53, 25 May 2010 (UTC)

This is something you should investigate on some website somewhere. It would require creation of a database of all quests in Guild Wars and their prerequisite requirements, and then each user would have to indicate what quests they have completed, and then it could generate some "quest availability list" for that character. These are all things that are not part of the purpose of this wiki. If a user here wishes to do such a thing for themselves, a template such as has already been mentioned would be possible, though a lot of work (that I'm not going to do). There is no way to carry any character files from the game over to the wiki for comparison as those files live on the Anet server, and are inaccessible to users. You are going way beyond what the purpose and scope of this wiki is with this "idea". -- Wyn talk 20:58, 25 May 2010 (UTC)

(Reset indent)

1. There is a 'database' for all the quests and missions RIGHT HERE. There is no need to create another one. What 'may' be needed is tags on the information so it can be found easily. Those tags could take the form of parameters to this template. That is why I proposed it here.
2. This is NOT intended for use only by users. It is for anyone who wants to explore the interdependence of the quests, missions, profession choices and so on. Because such exploration is expected to be fairly lengthy, it would be helpful to be able save the current state of that exploration. However, that state should NOT be saved on the wiki server. There is a specific mechanism already in place for saving such state information for each reader. It is called a cookie.
3. The 'content' of the pages would be the relation between the quests, missions and all the factors that determine when the quest or mission is available. It would be user generated only in the sense that all wiki content is user generated. It is distinct from the exploration state information.
4. No direct tie to the state of a specific character in the games is contemplated. At best, the state of interaction exploration could be set close to some character's state in-game. Having the state locked to a characters actual state would make the tool useless for explorating possibilities.
5. The stated purpose of this wiki is to document the games. Having a page of available quests and missions for every possible state of the game would document the game. The problem is that the number of possible states is unmanageably large. Having a tool that would allow the browser to calculate that information from site content and user input is what is being proposed. Such a tool is not specifically a wiki capability, but it is not something that should be forever banded from this site, unless a good reason for such a ban is given. No valid objections have been given so far.
6. The insistence by some people that the state information has to be stored on the wiki server is disgusting. It is NOT what is being proposed. It is a strawman and a heinous way of arguing. All the arguments based on that assumption are BOGUS.

--Max 2 22:09, 25 May 2010 (UTC)

Once again Mtew, your proposal is outside the scope and purpose of this wiki. We are not here to provide users a way to generate this information. If you wish to take the information stored here, to create a website to do what you are proposing is fine as long as you follow GFDL requirements of attribution, and don't charge anyone anything for the service. I guess what you are missing is that this is NOT wanted here. No one else wants it to be developed here, or for that matter on GW2W (If you had any ideas of expanding). It is NOT documenting the game. The VALID objection is that everyone is objecting. The server load alone for the kind of thing you are talking about is unnecessary. Just drop it, and move on. -- Wyn talk 03:15, 26 May 2010 (UTC)

I'll admit that this is at the margins of what is usually done with a wiki. You may not think you personally can do this kind of thing, but I think it may be possible. Please do not impose your personal limitations on me.

A fairly big problem is that a good deal of the information is owned by ArenaNet or NCsoft, particularly the images that would make this attractive. If it is done in the context of this wiki, that is not a problem. Doing it elsewhere makes it a big issue. Doing it elsewhere would also mean having to track updates made here.

In spite of what you say, this WOULD document the games. It would present the interaction between quests, missions, level and many other things in a form that should be easy to deal with. The information is here, but difficult to dig out. There is no question that it would present information about the games.

Your 'server load' argument is completely off the wall at this point. While I have no idea at the moment of exactly what is involved, if done right, the load should be on the browser, not the server.

So I see objections based on mis-representations and false assumptions. I see a small group of people pretending to speak for everybody. I object to that kind of tactic. I particularly object to your mis-representation of my motives and your ad homium attacks.

--Max 2 21:24, 27 May 2010 (UTC)

I know I've suggested this to you before and it went unheeded, but I'll try again.

Create something in your sandbox, do your testing there. Create 50 test quests in your sandbox and create your prototype for what you want there. If you need help with it, ask others to do so, if they want to help/feel it is useful, they will, if not they won't. You may need to change some parameters in your coding since it will be in your userspace/sandbox to keep all current mainspace categories/lists clean, but that should be it. As it stands now, you're the only person who is arguing for this and if that is the case, it will never happen.

If you truly feel this is a good thing, do it in your userspace, because at this point, I don't think you will form a consensus here without a working example... But keep the example in your userspace. --Rainith 21:39, 27 May 2010 (UTC)

I am trying to follow your suggestion. I've been asked to discuss my ideas before implementing them. That is what I am trying to do here.

If and when, I'll be developing this in my 'projects' sub-pages. I try to keep my 'sandbox' for short term testing of things I feel no obligation to keep around. However, I'm not quite ready to do that yet. I'm here to head off the inevitable hoard that will attack that project because 'it has not been discussed first.' The usual crew is behaving more or less as expected – badly.

--Max 2 22:08, 27 May 2010 (UTC)

It's not whether it can be done or not, but rather it shouldn't be done. There is already information about how the quests interact with each other on quest pages. If doing it at a fan site, then don't use images. Adding a program on top of that to parse information out doesn't add more information about the quests. If it's written on the wiki the request will be parsed by the server running GWW, and due to the large number of quests available, the load to the server isn't going to be small. You are the only one that wants to do something like this, and everyone is basically saying the same thing. No one is committing ad hominem attacks on you. No one is belittling you or insulting you to try to make your proposal seem stupid. Your proposal just isn't what the wiki needs regardless of you. --Lania Elderfire 21:45, 27 May 2010 (UTC)

See what I mean.

You are assuming that the code must be executed on the server. I do not think that will be necessary. In fact, having tried something like that already, I think that would be a bad idea. I intend that any state information stay on the browser and be stored in cookies.

It is that kind of straw-man that I find so distasteful. That kind of deliberate mis-representation is degrading. Your insertion of your own preconception into the proposal is at the root of the issues raised and makes all the arguments against bogus. This is something I have stated several times. You keep ignoring my objection.

You also keep turning this into arguments about me and the 'consensus'. Since your 'consensus' is based on a misrepresentation of the proposal, your 'consensus' is not real.

--Max 2 22:46, 27 May 2010 (UTC)

Well if you feel that strongly about it, then why don't you start coding up an example on your userspace instead of arguing with us? You can do whatever you want in your userspace (within reason). --Lania Elderfire 23:23, 27 May 2010 (UTC)

Simply because I was asked to discuss such ideas first by several people. --Max 2 23:48, 27 May 2010 (UTC)

"Well if you feel that strongly about it, then why don't you start coding up an example on your userspace instead of arguing with us?"

I've quoted Lania because I believe it bears repeating. I'm willing to repeat it as many times as is necessary. Let me correct what may be some confusion on what I said. I did not mean to imply that you will need to discuss and gain a consensus to try a project in your user space. I believe that if you can make your idea(s) work there first, that will add some weight to your argument and so that would be an excellent place to start. As for what you call that/those pages (sandbox vs. project page), I don't care. I generally use the term sandbox for any place that you are testing stuff out, no matter how long you leave it there. I apologize if my use of the term didn't match yours and caused some confusion. As long as your "sandbox/project pages" don't interfere with the mainspace, cause problems for the server or break any of the wiki's rules (which I believe actually takes care of point 1, and maybe point 2 but I don't know if that is specifically spelled out anywhere) you can do pretty much what you want there. Also, avoid breaking any laws on them (criminal or physical or any other laws as well please), that should go without saying, but I'll err on the side of caution. --Rainith 23:50, 27 May 2010 (UTC)

Thank you for clarifying your own stand on the issue. You are being completely reasonable and what you propose is in line with what I more or less planned to do. However, I've run into opposition before when limitations of MediaWiki have made development dependent on saving each change on the wiki necessary. Further, at some point it will likely be necessary to add or modify details of how information in the main space is presented. That has also caused disputes in the past. Having discussed this project will provide the context for later developments.

You should also notice how dogmatic the current opposition is. By discussing this without having concrete code for them to attack, I believe I have exposed the irrationality of their arguments. By exposing the disruptive and destructive nature of the opposition, I hope to under-cut their future support. I am basically a technical person and am not particularly good at anticipating political issues. I am trying to learn how to do this kind of thing. By choosing to have this fight now, I hope that some of the abuses by others that I foresee will be thwarted. I hope you understand.

If I manage to break some physical law with this, I'd be very happy. Other kinds of 'legal' breakage are much more serious and I respect those laws to the best of my ability. >8D.

--Max 2 00:34, 28 May 2010 (UTC)

The reason we are against this at this point in time is due to our experience with the wikimedia software and how we see the purpose of this wiki in relation to other fansites. For example, we don't have a template decoder because that's handled by PvX.

As to having code ready before presenting it, yeah, that helps. Granted, we don't want the RC entries while you're testing it, but if you can bring completed (or at least alpha) code to show, it might pass. I'd still likely be against it due to the above reasons, but I also have to follow consensus. --JonTheMon 00:55, 28 May 2010 (UTC)

I'd also likely be against it, as I don't believe it belongs here for the reasons I have already stated. I also believe that doing something like this where you know in advance it will likely be necessary to add or modify details of how information in the main space is presented on several hundreds of pages is also something I'm not really fond of. -- Wyn talk 01:17, 28 May 2010 (UTC)

(Reset indent) Thank you both for your moderate tone. I really have no idea at this point how much RC noise this will generate. I'm going to have to pull the MediaWiki source and dissect it. If it's like most open source code I've seen, the comments will be sparse and there will not be much, if any, high level documentation. (I have also seen a lot of proprietary code (NOT Unix) and the fact that good managers want to be able to keep their arse free of tooth marks meant meaningful high level descriptions were de regure. The worst proprietary code was the early DEC SMB server code which was done by a couple of 'oh so smart' guys. Buggy and very difficult to support.) I'll submit my notes to the MediaWiki developers if they amount to anything.

Similarly, I may have to take a look at the Apache and Fire-Fox methods for handling cookies and forms. Again I may submit any notes to those developers as well. They will all be filed here as part of the project design documentation. If anybody can point me at GOOD developer's documents for any of these, I'd appreciate it.

Since I've broken the bottleneck, back in October, that kept me from doing software upgrades on my home systems, I can run feasibility tests without a lot of hacking here. My first inclination is to put the design docs here where others can help. If that doesn't work out, I'll just have to start yet another project on SourceForge.

--Max 2 04:01, 28 May 2010 (UTC)

Rather than noting all your project progress here, I would suggest you go to the MediaWiki site and talk with their developers. This appears to be more that you are trying to create an extension for MediaWiki, than something that is strictly GW oriented. (You can access MediaWiki through the icon in the bottom right corner of any GWW page.) -- Wyn talk 04:07, 28 May 2010 (UTC)

Wyn, the project will be driven by the need to present Guild Wars information. There may well be a part of the project that belongs on the MediaWiki site. However it is not just a MediaWiki project. And I have been to the MediaWiki site many times, so your snide remarks are a rather obvious attempt to be insulting. You are not being helpful. Please stop. --Max 2 04:48, 28 May 2010 (UTC)

This proposal of your's is likely on the same level as the template decoder for PvX, so I'd like to know why you think this project would be appropriate for GWW when we don't even have that? --JonTheMon 21:09, 28 May 2010 (UTC)

Simply because I will not touch PvX with a 10' pole arm... --Max 2 05:20, 29 May 2010 (UTC)

Learn to read. He's not asking you to touch PvX. -Auron 05:48, 29 May 2010 (UTC)

All nationalities value redundant?

I'm not really sure that documenting an "all" nationality for BMP adds any particular value, but does add rather a lot of distracting text and icons. (In passing, if retained the value should probably really be "any" vice "all".) Really the key requirement is ownership of the BMP, if anything (although that should be clear from the infobox itself). --DryHumour 19:57, 25 May 2010 (UTC)

For 'old hands' such a list is redundant, but there will be new-comers who will understand the situation better if the complete list is given.

'Any' is sort of the alternative default value to the campaign specific defaults. By 'default' the complete list of nationalities should not be displayed. It is also what should not be displayed for core quests. That means some other designation should be used to indicate that the complete list is wanted. I chose 'all' because it was specifically distinct from 'any'. Change it if you like. Maybe it should be 'none' and 'any', but that doesn't seem quite right either.

Also, the result produced is subject to revision. If the icons are too much, remove them.

--Max 2 20:27, 25 May 2010 (UTC)

I would tend to say that if it isn't necessary for core quests, it is probably also unnecessary for BMP quests. It also seems to me that anyone who has purchased the BMP and who has adventured long enough to gain access to them is probably not really a newcomer. --DryHumour 20:46, 25 May 2010 (UTC)

This site is not restricted to people who actually own the games, expansions and so on. The core quests are available to all campaigns, all nationalities, and thus a specification of nationality is inherent. One of the base games will have to be purchased to get to the core. EotN is different. It can be purchased separately retail, without having bought one of the base games. This is a mistake of course, but that is precisely what a complete list of nationalities would point out. I am not familiar enough with NCsoft policy to be sure that you can not purchase BMP without purchasing a base game first (it is not available retail IIRC). So the assumption you make about newcomers, while probably true, can fail. --Max 2 22:29, 25 May 2010 (UTC)

So somebody is planning on buying EotN, but they come here first and from looking at the quest pages see that you need another campaign. That seems a bit far-fetched to me. --JonTheMon 22:51, 25 May 2010 (UTC)

Ever hear of Murphy's law? --Max 2 22:57, 25 May 2010 (UTC)

However, we don't note ownership requirements for the main campaign quests either since they are clear from context. By the same token, this is probably also sufficiently obvious. After all, it is tantamount to saying that one must have a character in order to participate. --DryHumour 23:06, 25 May 2010 (UTC)

But you can specify a nationality requirement if it is appropriate. You can specify no nationality requirement too. You can specify any two nationality requirements. This just completes the set. --Max 2 01:39, 26 May 2010 (UTC)

If by "completes the set" you mean "explicitly specifies the most obvious requirement" then yes, you would be right. --JonTheMon 05:05, 26 May 2010 (UTC)

Except for your use of opinionated pejoratives, that is correct. --Max 2 21:31, 27 May 2010 (UTC)

Usage Report

I've added a usage report [[Template talk:Standard prerequisites/Usage|here]]. It lists all the quests and missions that use this template and all the quests and missions that do not, in separate sections. It may help to track which pages need to be updated. --Max 2 10:23, 4 June 2010 (UTC)

Apparently the mentioned page as well as the link in Template:Standard prerequisites#Also See have been removed some time ago. I'd suggest to delete that section from this template as well. --109.252.109.9 13:53, 15 November 2018 (UTC)

Thanks. I did some adjustment to enable removal of a few garbage parameters whilst i was here. If you still want to know where it's used, you can preview the following somewhere

{{Parameter check|Standard prerequisites|campaign:nationality:profession:primary:secondary:test:minimum:complete:hero:unstarted:transfer:active}}

-Chieftain Alex 17:37, 17 November 2018 (UTC)