Fallout Wiki
Register
Advertisement
Fallout Wiki
Forums: Index > Wiki discussion > Transposing template parameters from a separate "stats" page

I finally found a way to do something I'd been wanting to do for quite some time. I found a way to transpose template parameters from a page different than a given page into templates on that page.

Say what? Yeah. Kinda confusing huh? Let's backtrack a bit. This is how we use templates like infoboxes now:

  • Make template.
  • Make article.
  • Place infobox template on article and fill in all the template parameters.

Doing this puts all the stats and stuff for infoboxes on the article page itself. This can be problematic for two reasons: one, it makes the page long as heck in the editor with all those parameters listed; two, it makes the data vulnerable to people who don't check the geck or the game right and alter stuff that's already been thoroughly checked and verified.

What does this new way do different? It allows for a third page to bring those parameters into the templates:

  • Make template.
  • Make article "stats" page and put all template parameters there instead of the article.
  • Make article.
  • Place infobox template on article and transpose the "stats" page into the template.

Still not following me? Take a look at this example:

  • [[User:The Gunny/sandbox3|Template page]] That's the item infobox I altered.
  • [[User:The Gunny/sandbox4|Stats page]] That's the stats page with all the infobox parameters on it. You can't see them, because it's a template itself, just filled with some defined variables mediawiki gobbledygook.
  • [[User:The Gunny/sandbox2|Article page]] See the infobox with all the parameters listed in it? The only thing actually written on that page is: {{User:The Gunny/sandbox3{{User:The Gunny/sandbox4}}}}. That's it.

What would we gain? Like I said, it will make the pages much less cluttered in source mode in the editing window. It won't change a thing when the page is viewed, though. The biggest gain is that we could protect the "stats" page, once all the GECK data is verified. We could protect it to registered users only, for stuff that still may need to be changed a bit, like with new images or whatnot. We could protect it to admin only for stuff that is completely done, good image, all stats GECK checked and true.

This could probably be done to all templates that use stats that we might want to protect. I'm not sure, though, if that's something that everyone would want to do. So, what do you think about this method? Is there any benefit of using it? Are there any disadvantages? Before I go testing a bunch of the other templates, I wanted to get an idea if this was even something we should consider. Let me know in the comments below, please. The Gunny  UserGunny chevrons 02:48, April 1, 2014 (UTC)

Comments/suggestions/questions[]

Anything that we can do to make things more 'perfect' and put an indefinite protection on them is fine by me. Saves us from having to fix mistakes. I have one concern though. Transposing = more bandwidth = slower page loading times. Can we test to make sure this isn't going to a problem? FollowersApocalypseLogo A Follower  Talk  04:21, April 1, 2014 (UTC)

Maybe something for the future, if all infoboxes are really complete. Right now I'm still adding things just about every day and changing it on a seperate page I'd feel hampered. I only consider some character pages' infoboxes a bit long that have the extended stats (with head details, AI attributes) on them. All other pages that use different infoboxes are still fine (in general). I'm not in favor of it right now. Jspoel Speech Jspoel 18:42, April 1, 2014 (UTC)
I've seen some discussion of transposing vs. parsing. From what I can gather, it doesn't really add too much, if any, to the page load time. Certainly not as much as parsing all those template parameters through the 10 or so templates each infobox parses though. The actual transposed stats page will have a very light byte load and should load much more quickly than any of the sub-templates that parse the variables. In the example, granted it's a small template, I saw no noticeable load time difference.
As far as have to load a separate page to edit, that's the kind of input that'll help out ironing out the kinks. I could probably put a tiny little edit link in the corner of the infobox, kinda like the edit links on navboxes, that opens the stats page in the edit window. Good observation j and maybe a way to deal with that issue. The Gunny  UserGunny chevrons 19:35, April 1, 2014 (UTC)
That's funny. That was exactly what I was thinking about last night. A small edit button like we have for the navboxes on the left side, but I didn't think it would be possible. Looks a difficult task to me but you can try that then. What kind of page will the stats page be? A normal article page or template page? And what kind of name and place to put it do you have in mind? Maybe you can create an example for for real. Like now I see vardefine coding in your sandbox page; will it be like that on a real stat page? Jspoel Speech Jspoel 19:45, April 1, 2014 (UTC)
I think I can probably use the edit link template to add that little "e" in the infobox header. I'll play with it and see if I can. As for structure, I'm thinking the stats page would be a subpage of the article. I can play with variations of the pagename magic word to help with the coding that way. For example, the article [[.357 magnum revolver]] would have a page named [[.357 magnum revolver/stats]] that would hold the variables. And the stats page would look just like the one in my example. Everything would be listed as {{#vardefine:<parameter name>|<parameter value>}} etc., instead of |<parameter> =<parameter value>. For the most part, I should be able to keep all the parameter names the same. This will help immensely because I'm pretty sure a bot can be used to make those changes. The Gunny  UserGunny chevrons 20:13, April 1, 2014 (UTC)

( I don't know Gunny. Most infoboxes aren't that long that I would want them moved to another page. I also wouldn't want it as a subpage because it ruins the search bar. We only have 5 entries for a search term and when you would search for Plasma rifle, you wouldn't get 5 game versions anymore but only 2 or 3 + the /Stats page. So naming should be differently, like every Fallout: New Vegas stat page starting with FNV ([FNV plasma rifle infobox stats]) for an FNV weapon) and Fo3 .. for Fallout 3 pages. That way only FNV... and Fo3... will be used, which is ok. If you want to try it, go with a weapon page and see if you can include the weapon comparison table as well. That one can be even longer than the infobox. I was also thinking, perhaps a large stat page adding all specific Skill weapons together, with anchors to each for to link to in an weapon infobox could be an option. Jspoel Speech Jspoel 22:29, April 1, 2014 (UTC)

I'm in agreement with J on this one, assuming that the stats would be transposed from a separate and unique page. It would ruin the search bar and does seem unnecessary for the majority of infoboxes. In the interest of completion and simplicity, however, I'm in favor of moving this forward, but with a potential caveat: Is there a way that we would be able to transpose separate infoboxes from one large page containing the weapon stats for a group of weapons? This would make the search bar issue null and void, and it would allow mass protection and verification of GECK data, which would be a good thing. Is this something that would be possible? FollowersApocalypseLogo A Follower  Talk  23:16, April 1, 2014 (UTC)

Hm. Interesting points. I had not thought of link suggest/search suggest. That could easily be solved by placing the stats pages in the template space. That would reduce the flexibility I would gain using the pagename magic words, but it would solve the link suggest/search suggest issue. As for creating one large page to define the variables, I would have to look at that. Currently, I replaced the named template parameter, eg {{{base id}}} with a variable, eg {{#var:base id}}, which is then filled by the defined variable on the stats page, eg. {{#vardefine:base id|<value>}} and gets parsed by the template on the article. I could possibly change the structure to {{#var:{{PAGENAME}} base id}} and {{#vardefine:<pagename> base id|<value>}}, where the template parses the variable checking for a variable including the article pagename and the parameter, and the stats page supplies that parameter including the pagename. A defined variable on the stats page would then look like: {{#vardefine:.357 magnum revolver base id|<value>}} and the next one on the stats page might be:{{#vardefine:.44 magnum revolver base id|<value>}}. In this way the template, when placed on the .357 magnum page would only return the variable named .357 magnum revolver base id, and not any other. There are two problems I see with this approach:

  1. One, we've already talked about page load times. If every page here needs to load a huge stats page listing all the defined variables for, say, all FNV weapons, that might just increase load times enough to be a problem.
  2. We've also talked about being able to easily place an edit link to the stats page. With this method, that edit link would go to this huge page with all the variables on it. We may be able to link it to heading anchors that are enclosed in<noinclude> tags. We'd have to do something so that the stats page, when transposed, only brings the variables and not the edit link anchors.

Considering these two issues, I think it far easier to make the stats page in the template space. Good points brought up, though. I'm sure we're missing other things. Any more things we can think of? The Gunny  UserGunny chevrons 20:08, April 2, 2014 (UTC)

I see great benefits in this kinda reuse. It could allow us to pull comparison page stats from one source, and allow us to experiment with slimmed down pages that have cut down infoboxes for mobile users. Great work Gunny, I was thinking this wasnt possible. Agent c (talk) 20:16, April 2, 2014 (UTC)

The mobile skin issue (infoboxes too large on mobile) may be able to be addressed, but that'll probably take some coding that's beyond me. I'll ask Rarity her opinion. The Gunny  UserGunny chevrons 20:49, April 2, 2014 (UTC)

I like everything you said, except about the Administrative protections. As 69 proved to us back when he was simply the G.E.C.K. Anon, even technical information we have thought was correct for years turned out to have been interpreted wrong by even our most veteran users. Having the stats on a separate page is enough to turn back those looking for a cheap thrill, and it is already simple enough with more and more G.E.C.K. users here to keep the recent changes safe from those that would actually go out of their way to find the stat pages and vandalize them. But do we really want to risk demotivating the anonymous/newer users because when they attempt to change information, they consistently run into Administrative protections?

And yes, it will demotivate users. During my time at TES wiki, I have been dismayed at the fact that the Administration there tends to lock down any page of importance, and you constantly see users (including myself) complain about it. Hell, there was a user I had to actually convince to stand up for themselves, because they found information that was incorrect, but did not have the confidence to confront the one who put a protection on the page.

I like the idea here. I just think it would be best that we leave page protections off unless they are absolutely needed for specific cases that call for them. ForGaroux Some Assembly Required! 21:07, April 2, 2014 (UTC)

I think this whole thing should be held off for a few weeks. This way we can wait until Lua templating is enabled. This way we can store all the data on the /stats page and then parse it out using a custom Lua module. Something similar to {{#invoke:CSV|getVal|{{/stats}}|row,col}}.

Lil' Miss Rarity (message)Saturday, June 21th 2014, 08:39

Headers are you friend[]

I went ahead and tested using one stats page to supply the variables for more than one article. It works. I also checked load times with a ton of variables defined on the test stats page. I put about 100 page's worth of them and saw no measurable difference in load times using a page load timer. Also, using noinclude tags on section headers worked so we can probably anchor the edit link to the correct edit section for the correct page. So "one big (or few large) stats pages idea would work. The Gunny  UserGunny chevrons 01:28, April 3, 2014 (UTC)

OK. I don't know if anyone's keeping up with this, but I made an editlink template that will open the stats page (large version with many article's stats on one page) up in the editor to the correct section for that article's stats. Right now, the link shows as a small "e" in the lower left hand of the infobox header. Don't really like that, but I've got some ideas to improve that. So, after thinking about all this, here's where we're at:
  • Using a stats page to transpose template parameters works fully.
  • This can be done with a single stats page for each article, or a single stats page for many like articles, eg all FNV energy weapons.
  • At some point during all this, I realized we could simply move the infoboxes and tables themselves to template pages and transpose them into the article in a similar fashion. Pros: Easier to edit, since most folks are more familiar with those templates as they are. Cons: Still have to write out the full infobox and other templates in full and there may (or may not) be many overlapping parameters that could be reduced using the other method.
  • Before I do much more, I want more input. Should I attempt to do an entire weapon page, infobox, comparison and ammo tables for a better example?
Speak now folks. I want to have more than just a few editor's input on this. The Gunny  UserGunny chevrons 20:12, April 4, 2014 (UTC)

Sounds like fine plan to me. Agent c (talk) 20:25, April 4, 2014 (UTC)

( You can attempt to make an example. Think best to give it a go with a group stat page (for example FNV Energy Guns skill weapons). Besides that, I'm not that fond of the vardefine coding when you'd edit an infobox, so I'd be better to have the original coding. Don't like the e when editing an infobox either, looks like a programming error. Should be smaller like in the navbox. Best to make a few pages with the different options. Jspoel Speech Jspoel 20:36, April 4, 2014 (UTC)

You can't have both. You either have variables and a big group stats page or regular parameters and simply moving the infoboxes to their own pages. Pick one. The Gunny  UserGunny chevrons 01:06, April 5, 2014 (UTC)
Advertisement