4,748 Pages

• As some of you are aware User:Jens Ingels recently posted a blog about adding a script that would let you see the at-level values of a champion's stats. A minor thing/discussion came up, something that has been going on since before even I joined the wiki, which is our use of level 0 stats and the fact that one of those stats is not like the other and that stat is Attack Speed.

Attack speed on our site is shown at a level 1 value, different from the rest of the stats, for a reason I honestly don't quite know. I'm here asking for input/objections to changing it from a level 1 value to a level 0 value.

• I'd support changing the display of attack speed to a level 0 value if the resulting numbers wouldn't be too fiddly. The advantage to showing attack speed at level 1 is that it's the only point on its whole progression where its value can be resumed to three decimal paces. At any other point, even though we could always round the numbers down (or up) the values we'd get would be less accurate. However, that's the only reason I think would go against indicating the value of attack speed at level 0, and making the change would be great in terms of consistency and clarity, assuming this supersedes the potential loss in precision brought by the adjustment.

• It's easy to do this.
`{{#expr: 0.625 / (1 + {{{as_delay}}}) * (1 + {{{as_lvl}}} / 100 * ({{{lvl}}} - 1)) round3 }}`
But, would level 0 attack speed make sense from an equation point of view, though? For example, Sona's AS_0 will be
`{{#expr: 0.625 / (1 + {{data Sona|pst2|attack_delay}}) * (1 + {{data Sona|pst2|as_lvl}} / 100 * (0 - 1)) }}`
. You'd have to modify the formula to
`AS_1 = AS_0 * 100 / (100 - AS_lvl)`
• Another thing while we're on the subject:

• Health and mana regen values should be normalized to either /second or /5second values
• Attack speed should be normalized to either % or d.ecimals
• Willbachbakal wrote: I'd support changing the display of attack speed to a level 0 value if the resulting numbers wouldn't be too fiddly. The advantage to showing attack speed at level 1 is that it's the only point on its whole progression where its value can be resumed to three decimal paces. At any other point, even though we could always round the numbers down (or up) the values we'd get would be less accurate. However, that's the only reason I think would go against indicating the value of attack speed at level 0, and making the change would be great in terms of consistency and clarity, assuming this supersedes the potential loss in precision brought by the adjustment.

I'd like you to meet my friend Attack Speed Offset. He is used internally by Riot, at least in the JSON department. Take Teemo for example:

• attack speed offset = {{data Teemo|pst2|attack_delay}} = '
• attack speed per level = {{data Teemo|pst2|as_lvl}} = '
• attack speed at level 1 = {{#expr: 0.625/(1 + {{data Teemo|pst2|attack_delay}}) * (1 + {{data Teemo|pst2|as_lvl}} / 100 * (1 - 1)) }} =
`{{#expr: 0.625/(1 + {{data Teemo|pst2|attack_delay}}) * (1 + {{data Teemo|pst2|as_lvl}} / 100 * (1 - 1)) }}`

Here's Riot's member showing us a long-winded formula for the same thing: https://developer.riotgames.com/discussion/riot-games-api/show/kVfcVE9B

• it's always best to be as consistant as possible, in my opinion

• BryghtShadow wrote: I'd like you to meet my friend Attack Speed Offset. He is used internally by Riot, at least in the JSON department. Take Teemo for example:

• attack speed offset = {{data Teemo|pst2|attack_delay}} = '
• attack speed per level = {{data Teemo|pst2|as_lvl}} = '
• attack speed at level 1 = {{#expr: 0.625/(1 + {{data Teemo|pst2|attack_delay}}) * (1 + {{data Teemo|pst2|as_lvl}} / 100 * (1 - 1)) }} =
`{{#expr: 0.625/(1 + {{data Teemo|pst2|attack_delay}}) * (1 + {{data Teemo|pst2|as_lvl}} / 100 * (1 - 1)) }}`

Here's Riot's member showing us a long-winded formula for the same thing: https://developer.riotgames.com/discussion/riot-games-api/show/kVfcVE9B

In that case, bringing attack speed down to a level 0 value would thus produce the same results as for a level 1 value, thereby eliminating any potential weirdness. That's good. On the other hand, the data you produced also suggests attack speed is calculated in a manner that is fundamentally different to every other stat, and loses sense when being set at level 0 since there is no level 0 value to account for. We could always simply use the attack speed offset to give a level 0 value, but since that's not how the game calculates the stat this would boil down to clarity on the wiki versus faithfulness to the in-game system. I'd be happy either way.

• Attack speed has to be shown as the level 1 value, doesn't it? All sources of bonus attack speed are relative to a champion's attack speed at level 1, including the per-level.

Attack speed is also the only statistic where the per-level is considered "bonus" (per level armor is considered base armor, for example). Attack speed is an exception to a lot of things.

A champion's attack speed is, for example, BASE: 0.638 + BONUS: (3% * level)(other sources). You cannot change that base value.

It would be better if we changed our statistics section to have buttons that flick between N, 1 and 18, with level 1 as the default (and on N list AS as N/A). Or, change the smallprint to say "excluding level 1, on attack speed" (much like Tristana's passive).

• Willbachbakal wrote: In that case, bringing attack speed down to a level 0 value would thus produce the same results as for a level 1 value, thereby eliminating any potential weirdness. That's good. On the other hand, the data you produced also suggests attack speed is calculated in a manner that is fundamentally different to every other stat, and loses sense when being set at level 0 since there is no level 0 value to account for. We could always simply use the attack speed offset to give a level 0 value, but since that's not how the game calculates the stat this would boil down to clarity on the wiki versus faithfulness to the in-game system. I'd be happy either way.

Not quite sure what you mean by "loses sense when being set at level 0 since there is no level 0 value to account for".
And in regard to "since that's not how the game calculates the stat", I'm fairly certain in-game derives stats using offset via the formula
`1/(1.6 * (1 + stats.attackspeedoffset)) * (1 + aspdbonuses + stats.aspdperlevel * (level - 1) / 100)`
(I'll need to check whether it's displayed rounded or truncated) Anyway, I'm all for consistency, whether we go with 0 or 1. Note that AS_0 will need a note that to obtain AS_1~18, you have to use the formula above, or if you haven't got the offset, it's
`AS_0 * 100 / (100 - stats.aspdperlevel) * (1 + aspdbonuses + stats.aspdperlevel * (level - 1) / 100)`
• Why you don't change all values to level 1.

• I too am of the opinion that it should be standardized all to level 1 values, and not just because attack speed can't be represented at level 0. Level 0 is an abstract concept which the user never sees in the game.

• The Level 1 problem then becomes obvious, Rune's mess with said factor, and make it better to calculate from Level 0.

I personally think the current system isn't nessecarilly all that bad, because it helps to calculate the stats from where they actually sit, rather then from a point where they don't really exist (Level 0 Attack speed)

• I personally think that we should remain inconsistent. Attack speed is an exception.

• It is not feasible to use level 1 for everything because X + (Y * level) is logical maths. I suppose we could do X + (Y per level-up), to distinguish that gains are only on level-up.
• It is also not feasible to use level 0 for attack speed because the number given is meaningless. Ashe gains 4% bonus attack speed per level; 4% of 0.658. Theoretically, 0.6318 is her attack speed at level 0 - her bonus attack speed remains 4% of 0.658. 0.658 is the number that users need. Level 0 for all the other stats is meaningful because 12 + (3 * level) remains accurate - although as stated above, you could theoretically do 15 + (3 per level-up).

And you can't just change Ashe's attack speed to 0.6318 (+4.0056%), which is accurate factoring only her innate attack speed to 2DP: it doesn't hold-up when it comes to purchasing items. A Phantom Dancer would remain 50% of 0.658.

• Even though I'm in favour of level 1 standard, X + (Y per level-up) would have some problems on Crystal Scar and Howling Abyss where you start at level 3 (since you can only level up 15 times there). Perhaps do X + (Y  ×  [level - 1]) instead?

• Or X + ([Y x level] - Y]... but how do you cleanly represent that in the stats summary? At the moment it's just X (+Y).

• X + (Y × [level - 1]) is what I currently use to calculate the attackspeed in the tool. It's actualy more correct since: Level 1: X + (Y x [1 - 1]) ; X + (Y x 0) ; X + 0 = X

This formule only works if the level 0 value never ever get displayed anymore However you can still do something like this:

```if (level == 0) {
result = X - Y
}
else {
X + (Y  × [level - 1])
}
```
• Im against showing level 0 values. No user needs to see them. In any case its only useful internally for us.

How about showing X and as tooltip (x+y*level)? Or using tooltip in some other way.

• Stats should in fact be normalized but i think it's important to understand why they are how they currently are.

All stats are written at level 0 because that's how they are handled by the game client. When we datamine the stats, they are listed at level 0. AS is at lvl 1 for the same reasion. Additionally, patch notes generally speak of stat changes in their level 0 values (barring some patch note inconsistencies on riot's, which have happened in the past).

• Sydeyc wrote: (barring some patch note inconsistencies on riot's, which have happened in the past)

Between several and many, more like. Also the fact that they've changed formatting more than a couple of times in known history.

• While true, they've been fairly consistent in the recent past. My post wasn't to argue the validity of standardazing how the wiki displays stats, it was merely to explain why the stats are how they are.

Another point I just now thought of is that putting all stats as level 1 will create some disparity between the wiki's stat displays and the champions stats listed on their profiles on the official website, which are level 0 (level 1 for AS). This is unlikely to be an actual issue though, provided the difference is explained somehow.

• Further reason we should stick to level-0 base values (except AS) is because this happens when people try to extrapolate based on a level-1 base.

• Regarding someone's request to have level-1 and level-18 values present in the infobox, as well as other requests: User:Emptylord/Template:Champion info|Xerath|patch=V4.1

User:Emptylord/Template:Champion info|Zed|patch=V3.13

P.S. I would ideally add the Show/Hide button.

• @Empty, there's a couple of issues I have with that template.

• The right side of the heading looks cluttered. Having no space between Cost, Primary role, Secondary role, Resource mechanic, Release date and latest changes, makes it a big wall of text. Reordering several segments or dropping some from the template might make it look even better
• Isn't it a bit small, as in shouldn't it be wider?
• Can't we make the level part of the template dynamic? Where we'd have: [--] Lvl1 [++], and users could click the buttons to increase or decrease the level to get the respective stats? (maybe asking for a lot here)
• I like 3mptylord's template.  One thing that is confusing anyways when reading these things is how %AS per level is really bonus %AS.  An easily seen note there solves all our problems.  Level 18 stats are always convenient, too.

As for Deshiba's first point, what about reordering the roles and secondary bar information to below his stat bars or below his name?

I'm good with anything though.  Most of the suggestions in this thread I think look reasonable.

• I don't think it's an good idea to make the template higher:

• Currenty the existing template takes 295px space + 32px for the nav + 16 px for the side text. That's 343px
• Your template is 613px + 32px + 16px. That's 661px!

Not only will give your template problems to view properly on 1024x600 laptops. It also gives an terrible mobile support. I really wouldn't recommand to expand the template in height.

Their are better solutions. Like why do whe need this content for mobile devices. Just design an script for it. Something what I actualy was working on here. An lot more data can be implemented that way. Mobile devices can even work with this kind of system when they go to the full site.

• I said it would have a Show/Hide option, so it would occupy less space unless people want to see the stats.

• Show/Hide is not supported in the Wikiamobile skin.

See here.

Current version: here.

________________

It's not that mobile support is an priority and has to display all data. But the data that is actualy available for these kind of visitors need to be clear and usefull.

• Jens Ingels wrote:

If you're going to bring up mobile interfacing, show/hide is trivial compared to simply being able to display champion pages with acceptable formatting.

• If you want to use collapsing. I believe it's now possible with the details tag. You could use 2 mediawikia pages to import both part of the code. I believe if the code is spaced correctly you could generate the effect that is desired.

The default css will remain active on the mobile version. However the css can fully be adjust on the wikiaskin.

Btw now you are released the now infobox. I believe you didn't respect the script changes properly from the visual stats script. The delay is massive right now.

This is what I suggest what should be done:

• You update the infobox but you didn't include the wrap tags. Why?, this is the primary loading problem from the script.
• Use localStorage to remember the last setting that has been set. This allows players to navigate a lot easyer to these pages. JSON conversion is supported to read lists of data without any problem to one variable.
• You redo the script. If you need some help with that just let me known. You didn't setup the script correctly and it provide a lot of unhealthy function problems.
• Btw if you really don't want to include the tags to the template. Just implement the function in the local storage. The allows you to remember the action before the action really happends.

• Jens Ingels wrote: I don't think it's an good idea to make the template higher
I agree. From the 1000*450 pixels there are barley 15,3% of the area is filled with worth while context, rest is just space (and I counter the champion image as context).
• @Jens - The delay is unrelated. While trying to get a different script to work I changed to call order to window.load instead document.ready, which means the javascript is being added last instead of during. I should be able to fix that.

I didn't write the script and, while I understand what it's doing, I could not make any major revisions beyond fixing the mathematics/adding elements to the list. If there's a way to improve it - then by all means go ahead.

@Black Smith - Your maths is either seriously off or you are not viewing it on the minimum resolution. Yes, I'm aware there is a large amount of white space on large screens - but there was on the old one too. This is not something that can readily be fixed nor something the new template tried to.

• Well I was the one that started that script in the first place so I probaly can help you with that. I originaly start to build it to pratice my js. Now I'm already coding into javascript games so I might known a little bit more right now. I was still planning to improve my original script anyway.

If you want to use the window.load function than you will have to move the tag wraps to the template. The current script use the document to locate areas to wrap his content. Content that's only available after the document is loaded. So even if you use document.load the script will still not function until the document is ready.

I assume this is the current version: User:Emptylord/common.js/levelselect.js.

What I would do to start with is removing the old version. O boy that's why it loads that slow or just a if(true/fase) code between the 2.

• Btw here is the JSON localStorage system:

```<body>

<div role="main">
<h2></h2>
<input name="test"></input>
</div>
<footer>

</footer>
</body>```
```//Storage Database
data = { 'mytitle' : 'Welcome','name' : '<myname>', 'email' : '<myemail>' }
localStorage.setItem("data",JSON.stringify(data));

//Get Database
var retrievedObject = localStorage.getItem('data');

//Console Check
console.log('retrievedObject: ', JSON.parse(retrievedObject).name);

//Use Database
if(localStorage.getItem('data')){
document.querySelector('h2').innerHTML=JSON.parse(retrievedObject).name;
}```
• I didn't want to use window.load, I was just trying to discern the source of the bug with another script (turns out the bug was with how the wiki populates the article) - I just forgot to revert it.

Yes, that is the current version. Feel free to make any adjustments (although you'd have to do it elsewhere and link me to the changes, since only I can edit that page).

• Alright fine by me, I will see when I find the time. I will see if I can include the template changes with it. Than it will be easyer in the future to further expand the script.

• BlackSmith wrote:

Jens Ingels wrote: I don't think it's an good idea to make the template higher
I agree. From the 1000*450 pixels there are barley 15,3% of the area is filled with worth while context, rest is just space (and I counter the champion image as context).
• What about something like this:

Since the gradbars doesn't work on the mobile version. It might be intressting to remove them from that version. And implement it on image hover/onclick so the data remains available on the infobox.

• I think if you're going to do an column-box: you might as well just have all the stats in one line. (Particularly since the font size is attrociously small trying to fit in a four-column-table like that, and four columns look bad on mobiles anyway). :P

• On mobile it uses the default css so it actualy wouldn't change a thing in the wikia mobile skin. If you want small this is it:

Xerath the Magus Ascendant COST 4800 or 880 PRIMARY ROLE Mage SECONDARY ROLE Assassin SECONDARY BAR Mana RELEASE DATE 2011-10-05 LAST CHANGED N/A
• Empty lord wrote: @Black Smith - Your maths is either seriously off or you are not viewing it on the minimum resolution. Yes, I'm aware there is a large amount of white space on large screens - but there was on the old one too. This is not something that can readily be fixed nor something the new template tried to.
My math is quite correct and the area I was talking was already pointed out, 1000*450.

If the old one had white space problems, why keep repeating the same mistakes? Mebbe try to improve, grow, do better? You are aiming to make it nicely compact for a mobile viewer, yet you force people with real screen resolutions to watch 100% width tables? Makes no sense as the nice compact box could be floated and reader could be let to the articles 'meat' sooner. Most readers are not going to shed tears of joy when reading when Xerath was released or is he mana based or not or having one page of stuff that is not what they came to read about. They want to know what he can and can not do and whats the hidden tricks. After that they might or might not be interested what his secondary role is and it could be indicated with one nice icon in his infobox.

I don't see any space saved... More like more wasted. Lead in is one sentence and does not intro about the article, something that it really should do. Lore is before abilities and abilitys and their tricks are what people are coming to read. Ability boxes are not warped around the notes or the short notes create huge white spaces around the ability. Ability boxes should be free breathing to allow longer descriptions to make it wider. Fixed boxes do their job well when the content is fixed, otherwise it is good to let the 'live'. I would still include patch notes to the ability's own article as reference entries. (removes the need of patch note box and keeps things neatly automaticly organized)

• Your perspective on the issue is self-centered and not very understanding of the platform.

Reasons why we cannot fill the space:

• The majority of web users use a resolution 1366x768 - so small screens have to be catered to.
• The identified minimum width is ~650px, (due to all the fluff we're not allowed to remove like the rail on the right) - any template has to shrink to this size.
• The MediaWiki platform is very limited in terms of how the appearance can be customized, short of using javascript - which isn't compatible with all browsers, and even then many people has it disabled (as it's associated with poor internet security).
• HTML does not have a lot of innate support for making content fit between large and small resolutions (websites that do this use javascript and similar scripts, which we cannot use). On large resolutions, you will see two columns of information in the Ability Details sections - this was my first successful attempt at making content fit on small screens and "fill" on big screens. But it is hacked. People with middle-sized monitors will see large margins.
• White space is good. I come from a design background and white space is not only good: but actively encouraged. The more the better. Documents (or walls of text) are incredibly bad on the internet/any wide-screen view-port.

• So condensing three long pages of information into one page isn't considered space saved - roger that.
• Lore before abilities is of no consequence. I prefer it. It's how the League of Legend's website does it. Abilities are never going to be visible one the first "page" - so what does it matter if you need to scroll.
• Perhaps Mutiny was a bad example page, since I did not finish his overview. [Yaga] has a good sized intro.
• There is no need to expand the abilities when there are no notes and the very existence of the notes means there's no reason to have stupidly long ability descriptions. It's all there and visible - condensed yet detailed. Making the text fill the page is completely undesirable and would look ugly as fart.

All-in-all: I now understand where your coming from. At first I assumed your issue was "use of space" - but it seems that you just have an issue with "whitespace". However, whitespace is not an issue. Use of space could definitely be improved (unnecessary whitespace still exists) - but filling every nook and cranny is not desirable, and there isn't a whole lot of unnecessary whitespace.

• I took four days to shape up a nice answer to you but the javascripted reply box ate it so this is going to be a short and swift summary out of memory.

Why are your driving this agenda for width=100% elements (plural) when you know such elements are troublesome? It has noted to you earlier in the wikias community already and you didn't address the question then either.

If you compared the Yaga and present champion structure, Yaga presents the static info in nice neat box and has real intro but then it starts to crumble. As the infobox is not hoovered, the lore wont get to warp around. Also the lore is placed before abilities, lore that is static and hardly every read more than once. Its the abilities people come to read, over and over again. Or when have you last time heard patches changing the lore or people asking how lore synergies with black shield? I mean, just look how much space the present 'infobox' has filled with nothing compared to the Yaga one. Amount of info given is exactly the same. As extra bonus, I circled something that should ring a bell if you compare the two templates.

For the ability section parts, why you want to force a element with highly dynamic content that is fixed to take 50% of the article width? Some abilities have zero notes/info/whatnot, others have tiny ability description and tons of notes. Yet, you want to place them side by side instead of beneath each other when they would be displayed nicely no matter what the screen resolution without having huge empty gaps in any where, thanks to thing called magical text wrapping.

For the white space part, as you yourself noted, there is unnecessary whitespace and thats what I am reffering here. As you push these width=100% elements (again, plural) it creates stuff around them that makes them look airy, granted, but also gives nothing and pushes the things people have came to read future down. Three pages of white space [1][2] is not cool or a design thing, its just job done badly.

• Sorry to "revive" this thread again after a couple months, but...

Apparently Pwyff visits the wiki and he found a bug in the stat things in the pages. It seems the lvl1 stats are off, if not more? I'll quote what he said was up on twitter:

"At level 1 you're actually PURE base stats - there is no growth stat added. We did a +168% pass so base stats are super janky."

"In other words, at no point does Azir ever have 47 base AD (his level 1 AD = base stat). It's kind of semantics if you think about it"

I double checked it on Azir's page and it seems that Azir's page does indeed show his lvl0 AD as his lvl1 AD

I'm not sure if this is something already being looked into, but i'd like to know if this is intentional?

(btw, i can link the tweets if needed/wanted)