User talk:Tennessee Ernie Ford/Archive 02

Talk

Suggestions

Builds

Rants

Tools

Guides

Market watch

Projects

---

Previously on TEF

---

• Join – May 2012
• June 2012 – Dec 2012
• Jan 2013 – Dec 2014

---

Drop Rates

I seem to recall you as having some energy around drop rates. I've a number of drop rate tasks that I need to chase down and finish... Preferably before the game goes live. Would you be interested in helping? I suspect that you could make good use of my obscenely generic drop rate reporting template - perfect for low rate occurrence box items like dyes, as with it all you need to draw up is a summary template. Torrenal 05:04, 14 June 2012 (UTC)

Thanks for asking. I am probably not the best person to ask at the moment. I am involved in several guild and RL projects and seem to have less time for wiki contributions atm. That might change as we get closer to release. Tell me what you are looking for and I can let you know if I can promise you the proper amount of attention. (I noticed during BWE #2 I didn't even take time to screenshot new recipes...and I'm regretting it since no one here seems to have discovered the same ones).

I like what you've done with the dye seeds — colorful and accurate (although: be careful about applying stats with small sample sizes — not sure that it makes sense to discuss confidence ranges if you have less than 20-40 dyes per bin). – Tennessee Ernie Ford (TEF) 05:32, 14 June 2012 (UTC)

the dye seeds use formulas that are auto-bounding. For example, Frosting, with a grand total of 0 drops, has rates recorded of between 0% and 26%. Which is to say, it might never drop, and it might drop nas commonly as one time in four, for it's dye set. There's a ton of room between 'never' and 'one in four'

Todo items:

• compile a list of dye names and colors, compiled by hue and rarity. (don't build into a completed summary template until nearer the release - I plan to write a program to generate this page.)
• prepare templates and a sample page for recording mystic box drops. This will likely want a modified version of the obscenely generic template which takes a quantity.
• prepare templates and a sample page for recording gathering results. If possible, include 'Magic Find' in the gathered input. For something simple, this may be fiendishly complex.
• identify any place the obscenely generic template can be put to use, and have drops tracking pages ready by go-live.
• generate an x±c result template, for use in item pages.
• if SMW becomes available before go-live, exploit it to its fullest.... (fear this)

--Torrenal 06:37, 14 June 2012 (UTC)

So, let's pretend I have some time (or that when I do, I won't get distracted). What specifically can I do that would help you the most? Do you want someone else to mock up data collection pages? If so, is there a model (e.g. at GWW) that you liked (or hated)?

Off hand, some other things the OBDRRT could be used for:

• Mystic furnace: there's some randomness to what pops out of a given recipe, but I didn't get any closer than realizing I didn't have the right combos of items.
• Gathering rates from nodes, notably comparing the amount/quality of mats found. I believe that sometimes I got pebbles/stones from silver mines (but not others).
• The various bags that drop from foes (double-click for junk or some mats).

– Tennessee Ernie Ford (TEF) 05:10, 15 June 2012 (UTC)

I'm still not sure what to make of the mystic forge (I'm in a 'more data needed' state).

For nodes, I think there's two questions, I was considering combining tables for them, but perhaps two more generic tables would do.

One pretains directly to the # of ore lumps & other drops you get for using various types of pick on a particular type of resource node.

Another pretains to the type and rate of those special drops when harvesting.

Both are going to be influenced by WvW modifiers, which makes them a tiny bit more complex. :S At least, from a compiling results view.

I have dyes sorted except for the actual colors and how to break them down, but the template is generic enough to let us gather data for dyes we don't know about, so there's no time-pressure there.

I think the good focus would be the harvesting materials, tables and templates. I went into this weekend intending to work on them, but.... I've been sidetracked, you could say... Torrenal 02:07, 17 June 2012 (UTC)

Width parameter

Hey TEF, I wanted to discuss your objection to setting widths on tables of the same type (per example, the list of wikis). Your objection mentioned smaller resolutions, but it is to my understanding that the width parameter is overridden by resolution-limitations; any specified width (that is not min-width) will scale according to resolutions it can't be displayed on as specified. Therefore the width parameter will not "break" smaller resolutions, whilst allowing perfect alignment on resolutions where it can be fully displayed. I'd like your elaborate opinion on this matter, and would like to know if you had other issues with the width parameter I should be aware of. - Infinite - talk 14:26, 14 June 2012 (UTC)

Specifying width is generally a bad practice, whether it's by percent or by pixels, especially when the content is dynamic (as it is in the early days of documenting an unpublished game). It mixes content with style and needs to be revisited each time that a line is added or rephrased. (As with any style rule, there are plenty of exceptions.) I just pulled up Influence, which now has only two column widths specified, and shrunk my browser window...and it's easy to see that the name column remains the same size, no matter how small a window I used, making the table harder to read than necessary. Although the entire table is proportionally scaled when viewing from my phone, the table becomes hard to read because the name column remains at a fixed fraction of the table width.

On the whole, we're designing articles (including tables on them) to look pleasing to one type of reader and ignoring how it looks to others. Maybe I should have stated the criterion that we need to ensure that tables are legible when viewed from any frequently-used resolution. I happen to think that means using width-specification infrequently in favor of no-line-break spans for specific phrases, but I'm happy if there's an easier solution, too.

Please try some comparisons yourself. It's likely that we'll disagree about what looks good/not, but you should see the effects of specifying width on variably-sized windows and resolutions. – Tennessee Ernie Ford (TEF) 16:04, 14 June 2012 (UTC)

I'd think that viewing something like a skills list table (whether this or this) would be horrible on small resolutions regardless of width settings. —Dr Ishmael 16:20, 14 June 2012 (UTC)

Yes, some tables are just never going to look good (although I think skills tables are already mostly hard-to-read at high res). As noted above, there are exceptions (lots of them) when we should must specify proportion of pixel width. But as a general practice, I think it's a mistake at this stage in the wiki's evolution. – Tennessee Ernie Ford (TEF) 16:24, 14 June 2012 (UTC)

(Edit conflict) _x2 Trust me, I have tried a lot of ways to do tables (and I am a user who prefers efficient aesthetic over simple efficiency any time). Influence, as you used as an example; looks terrible. There is simply no solid argument that can justify not having;

• meta-columns – listing the same information of separate tables in one page-long "meta-table." It improves (instead of reduces) legibility vastly.
• a set (max-)width – alignment is not a pre. Alignment is a must. If we want to look like we know how to display information, we need alignment. This is an extra incentive to strive for meta-columns.

I'm not saying fix widths for all tables, everywhere. I'm just saying that edits as this one will remove the meta-columns on this article.

Members of this community (and unfortunately on IRC, which I can't link to) agree on the fixed width practise. It improves our aesthetic (especially on armor galleries, if they are going to be tables). Bottomline is that alignment of tables is not a pre, but a must on articles of the same type, where multiple tables display the same types of information individually on an article. The linked diff you created is merely an example of why it is an unwanted practise not to do so. - Infinite - talk 16:38, 14 June 2012 (UTC)

I strongly disagree with you. I think Influence and the List of fansites both look worse for trying to make the tables look the same size. (Galleries are an obvious exception; nearly every thing about them has to be manually specified.) Skill and trait lists are two other exceptions, although personally I think we should break those tables up into more manageable chunks; I find them so difficult to use to compare traits that I now just copy the data into a spreadsheet so I can see what's going on.

Obviously, we have different tastes about what looks good. So far, you haven't convinced me that it's a universal good or even that there's a widespread consensus. (There's a narrow consensus among editors whose judgment I trust, but that's not quite the same.)

However, let's just go back to the first principle: let's make sure that the vast majority of tables are usable/readable from a mobile phone. Right now, I think Influence is harder to read than it needs to be and I think that's because of width-specification. But if a consensus of others (narrow or otherwise) feels differently, I'm can live with that (for Influence and for the idea generally). i.e. since it seems unlikely that I'm going to believe that width-specification is a good default choice (rather than an infrequent exception), I'd rather you (and Ish et al) keep focused on other concerns, including content, consistent, data collection/presentation, etc. For example, I'd much rather we have enough to e.g. implement SMW to e.g. make it easier to link mats to components to recipes to products. – Tennessee Ernie Ford (TEF) 16:58, 14 June 2012 (UTC)

I feel that that argument is a little too convenient (not enough users agreed, thus I can change it as I see fit is really not an argument to remove what some users agreed on; you should open discussion anew to make those changes). If you feel tables don't work that way, then you should be the one listing examples and screenshots as to why that is the case. Influence as it is now is jumping across the page (as I showed you). My eyes will have to do the same to read the content. On mobile phone, however, all content is perfectly aligned. - Infinite - talk 17:02, 14 June 2012 (UTC)

To clarify, see here; User:Infinite/Sandbox#Testing_space - Infinite - talk 17:18, 14 June 2012 (UTC)

I just gave you two examples of things that look bad imo — style is entirely a matter of taste and, since you I don't share an aesthetic, we are never going to completely agree about what looks good. Even so, as I said above, I'm willing to live with your recommendation. I'm not sure what else you are asking of me.

I didn't intend to reopen a conversation because I didn't think we had an established practice; I thought this was an aspect of design that was still evolving. In particular, you linked above to discussions about a narrow usage: the skill lists. If you think there's a general consensus about column-width specification, then please document it in the style guide. – Tennessee Ernie Ford (TEF) 17:18, 14 June 2012 (UTC)

My apologies, I get rather fierce when discussing my wiki forte (which is design). I'll try and formulate a solid proposal for the style guide and submit it when it's ready. - Infinite - talk 17:21, 14 June 2012 (UTC)

No problem. I suspected you were on a roll and just didn't notice when I stopped resisting. – Tennessee Ernie Ford (TEF) 17:30, 14 June 2012 (UTC)

Resisting is a harsh term, but reading back it is unfortunately rather applicable. Again, my apologies. I do not mean to bulldoze (but I do mean to not follow GWW's ways with tables for the same reasons as specified earlier). - Infinite - talk 17:32, 14 June 2012 (UTC)

My apologies also, I thought you would get the Borg reference (I didn't mean it literally). I don't feel bulldozed — I think this is an interesting issue, but imo it's not as important as other things...e.g. it shouldn't slow down a decision on whether we formally plan for presenting the wiki on mobile devices. – Tennessee Ernie Ford (TEF) 17:44, 14 June 2012 (UTC)

That it won't. I am convinced aesthetical changes should never have priority over essential changes. Only if they can happen at the same time, all the power to it. - Infinite - talk 17:52, 14 June 2012 (UTC)

The Bad

"Guild Size cap of 100 is primitive, pre-Factions silliness." All guilds and characters will be wiped upon launch. And ANet is strongly considering increasing the cap or removing the member cap altogether. —The preceding unsigned comment was added by OneLegend (talk • contribs) at 18:23, 16 July 2012 (UTC).

A guild-size cap of 100 is still primitive. I'm involved in three alliances, one of which will hit the 100-account limit during the first week and the other two will hit it before headstart. The fact that ANet is merely considering an increase at this point means that they aren't worrying enough about helping 'current organizations plan for launch. – Tennessee Ernie Ford (TEF) 21:21, 23 July 2012 (UTC)

How does 500 sound? —Dr Ishmael 21:40, 23 July 2012 (UTC)

Better. However, I think any limit is ANet artificially imposing their idea of "social" structure on players. (Perhaps they have not been creative enough to figure out how to balance influence and size and other factors.)

Case in point: GW1 already allows up to 1,000 players to band together — why should GW2 start with a smaller number? Makes no sense to me. – Tennessee Ernie Ford (TEF) 21:45, 23 July 2012 (UTC)

Re:Notes in Character_creation

A character's starting equipment depends only on the chosen profession and Bio Question 1(The first question determines a profession-dependent aesthetic aspect of your character, the choice of the TYPE AND/OR appearance of one piece of your armor (or an accessory in the case of the engineer); ) and includes basic town clothing, an Aqua Breather, and a Starter Backpack (that holds up to 20 items). Thank you for your vigilance Rudhraighe 19:10, 28 July 2012 (UTC)

Italian unofficial Guild Wars 2 Wiki project

Hi, thank for you suggestion to fix issues on our wikim but I have just some question about:

1) I looked at Guild Wars 2 Wiki:Copyrights, then I look to our wiki page [1], the content are the same, just different languages. Do you means that we have to wrote also that content in english? Or you simply not recognize it was the same since it's in a different language? I thought that italian language could be enough since who will use our wiki are only italian-speaking people, but I have no problem on writing it also in english, just need to know if it's mandatory.

2) Looking at other pages you linked (MediaWiki:Copyrightwarning, MediaWiki:Uploadtext, MediaWiki:Licenses, MediaWiki:Copyright), yes they are a bit different and has no ANet credits on that. Sorry o didn't know their existence. I will fix them as soos as possible. Not fixed yes, due to my question 1 (I mean, shoudl i fix them in english language or is italian enough?

3) Before posting on Fansite talk page I e-mailed Anet Community support for some license information, they kindly guide me to creating properly credits to ANet and also to this wiki. They suggest me to add a link on each page that will lead to the official wiki. I do that, in each page there's a bottom-right square with GW2Wiki logo explaning that content on the page has been taken and translated from GW2Wiki (with link to both origianl page and Main Page). Another time, this is in italian language.

Thank you for your help —The preceding unsigned comment was added by Zyll (talk • contribs) at 17:50, 8 August 2012 (UTC).

Thanks for getting back to me. In answer to your questions:

1. Italian is fine as long as every page links back to the "About" (or directly to the copyright). Your community also specifically has to agree with the GFDL when they make an edit. And it looks like that is working now (I didn't see it when I looked before, but ...since I don't speak Italian, there's a good chance I missed it).
2. The reason for setting up the other articles in the MediaWiki space is simply to make it easy to link to different text for different situations. Some wikis use just one lengthy version (so it works for everything). And again, Italian is fine.
3. I'm glad that ANet got back to you so quickly! And I like the translation note (for when it's a temporary copy/paste or copy/translate). And, again, Italian is fine (you don't need to use any English in the wiki at all, unless you'd like to leave a note for non-Italian speaking visitors).

You should keep working on the details, but I think you've got everything covered sufficiently so that this wiki can link to you from the main article. I will go ahead and do that when I do my next update, in the next 2-3 days. – Tennessee Ernie Ford (TEF) 22:10, 8 August 2012 (UTC)

changing other peoples' posts

To me, this revert looks like the changes were simple link corrections - from the testing version of the map to the actual public version. I would think that qualifies as an exception to the "don't modify others' comments" rule. —Dr Ishmael 15:33, 9 August 2012 (UTC)

There was no typo: I visited the URL that was original posted on another site, which was the link I provided. Later on, the creators provided a different link, but I never tested it; my recommendation was based on the so-called testing version and the edit implied something else.

So, it would both have been more accurate and better advertising for the site if the person had done what everyone else does in such a situation: added their own comment pointing out that things had changed. – Tennessee Ernie Ford (TEF) 01:50, 12 August 2012 (UTC)