Template talk:Moveheader/Level

Usage

Parameters:

1. : The type of the move. If it has changed, use the current type.
2. : The generation the move was introduced in.
3. : The level(s) the move was learned in Gen I. use "no" if not learned by level in that generation.
4. : The level(s) the move was learned in Gen II. use "no" if not learned by level in that generation.
5. : The level(s) the move was learned in Gen III. use "no" if not learned by level in that generation.
6. : The level(s) the move was learned in Gen IV. use "no" if not learned by level in that generation.
7. : The level(s) the move was learned in Gen V. use "no" if not learned by level in that generation.

If anything else needs to be added or you have questions, feel free to ask them here. Werdnae (talk) 04:36, 25 May 2011 (UTC)

Level - Set Width Adjustments?

From a consistency standpoint, we have very inconsistent sizing of columns using this template. Let's look at several separate tables here.

First, I present Confusion. Six columns. Very crunched up. Notably, in the last column, text wraps between lines, which inadvertantly increases the size of the row.

Second, I present Nasty Plot, a Generation IV move. Lots more room. In fact, too much room. Look at the last column, at least twice the size of the previous two.

Third, look at Belch. Wow, that one column is absolutely huge.

We should have a consistent look. We already have different templates adding the I, II, V, etc. as necessary. We need to do one of two things:

1. In each template, have the width of the "Level" column based on how many generation columns exist; for instance, if each column was deemed to require 75 pixels, a move from Gen. III has four columns, so 300 pixels would be needed.
2. Remove the sizing from "Level" and apply the sizing to each generation column. That way, if a generation column is not needed, it shrinks the size of the table automatically for tables not requiring the extra size.

However it's done, we cannot fit an eventual seventh generation in the current template for the original moves from Generation I. We need to address the size of the table now. CycloneGU (talk) 01:20, 19 November 2013 (UTC)

As an afterthought to the above, I think setting the size on each column would be a more consistent and clean look. Right now, the width of the tables for Confusion and Belch are exactly the same; however, Confusion looks like a colossal disaster. The Level width could be expanded overall, but that would in fact also increase the one huge column in cases such as Belch. I think applying size to each smaller column and making the smaller columns the same width is a MUCH cleaner look, allowing for the width of the actual table to be smaller in numerous cases. CycloneGU (talk) 01:41, 19 November 2013 (UTC)

It's set as an overall width because I couldn't get the widths to function on the columns when I was first building it. I'll have another look at it, I've learned a lot since then from working on other templates, and I might be able to get it to work now. Werdnae (talk) 21:27, 10 December 2013 (UTC)

I'm not sure why it needs a width at all. It seems to look alright (or definitely better than currently, at least) without any width. For example:

#	Pokémon		Type		Level
					I		II		III		IV		V		VI
012		Butterfree	Bug	Flying	12	10	--, 10			--, 10			--, 10				10			--, 10
048		Venonat	Bug	Poison		19	17			17			11				11			11
049		Venomoth	Bug	Poison		--	17			17			11				11			11
375		Metang	Steel	Psychic							20			20				20	--, 20	--, 20

There's nothing especially wrong with most of that table. The only thing that might merit improvement is Metang's B2W2 column wrapping, but unless you want every column about twice as wide as above, I don't think that's really "solvable". But maybe you do want that. It should be easy enough...

#	Pokémon		Type		Level
					I		II		III		IV		V		VI
012		Butterfree	Bug	Flying	12	10	--, 10			--, 10			--, 10				10			--, 10
048		Venonat	Bug	Poison		19	17			17			11				11			11
049		Venomoth	Bug	Poison		--	17			17			11				11			11
375		Metang	Steel	Psychic							20			20				20	--, 20	--, 20

The biggest problems with this look is that you'll just run into problems much sooner if you have to add many more generations... Tiddlywinks (talk) 21:54, 10 December 2013 (UTC)

The reason I like the idea of width on each "generation" column (which can include two games) is because it allows space for two games to appear - such as R/S/E and FR/LG (or some combination as such). If there turns out to be a case where three different data occur in the same generation (R/S, then FR/LG, then E for instance), we can revisit the width again. However, I think having all columns the same width is best. It just looks cleaner IMO. CycloneGU (talk) 01:26, 24 December 2013 (UTC)

As an afterthought, the problem with having too many generations is already proving to be a problem. The only way around that is to recycle older generations or have different tables that show each generation. But this would become incredibly messy. We might someday have to go to a listing setup where a Pokémon name is listed, then each change in level-up learned goes on the right prior to the name being colspaned. For instance, on Confusion, Venonat would get three rows this way and each of the three rows would note, for instance, "Level 19 (starting in Yellow)" on the first row, then "Level 17 (starting in Gold/Silver)", and finally "Level 11 (starting in Diamond/Pearl) on the final line. Sure it's not as beautiful as the table format in use now, and would require a complete rewrite of the template, but with a seventh of eighth generation the table will already be a big large. On some monitors, it's ALREADY too large. CycloneGU (talk) 01:36, 24 December 2013 (UTC)

On the other hand, Gen I & II isn't terribly relevant most of the time since there's a trade discontinuity between Gen II & III. They're only relevant if you're actually (re)playing those games, which is definitely not going to be the case for most people. It would be possible to shorten the table a bit (in all sorts of tables, not just here) by removing Gen I & II data to a subpage or something. (But if we assume that Pokemon will continue forever, then that's still only a temporary solution.) Tiddlywinks (talk) 01:47, 24 December 2013 (UTC)

I would support eliminating Gen. I and Gen. II data from the main tables since they cannot possibly apply to any Pokémon received in trade. Adding to this, it would allow for simplification of move pages with TM data exclusive to the first two generations; in cases like Skull Bash, it would remove the table entirely. CycloneGU (talk) 05:13, 24 December 2013 (UTC)

Another afterthought. We can note in the Gen. III column (in cases like level-up move tables, which this template handles) any differences in the first two generations as a little asterisk note, as in other places around the Wiki. That way all of the data is still handled in the main table. This would be something to implement in Gen. VII is announced (if? Let's say "when"), however, as that is when we may be removing data. Also, I'm all right with word wrap, my intention is bringing consistency to the columns instead of the table width (which is fine for tables that the data fits into properly, but too big or too small in exampled cases). CycloneGU (talk) 05:21, 24 December 2013 (UTC)

OR/AS Section

This template needs to be updated to contain OR/AS updates as a separate column. Trainer Yusuf (talk) 06:35, 24 May 2015 (UTC)

Agreed; especially since the Chinese-language wiki already has this feature inplamented. Superjustinbros. (talk) 02:17, 13 September 2015 (UTC)