User talk:Tvol

Hello there :)

Can you please check if your bot is working as intended? The abilities are getting all full of error messages. Thanks :) Hobbes (talk) 18:33, 27 January 2017 (UTC)

It is, or rather I am (the bot did the heavy lifting but I wouldn't dream of letting such a complicated regex loose on a wiki :o ). The parse errors weren't caused by the replacement text, but by the calls on the skills pages being "bad". I've cleaned those up. Now I just have to fiddle with the actual template itself more to get it working. (If I can't I'll just regex the crap out of things and fix them. I won't leave stuff broken. :) ) --Tvol (talk) 18:39, 27 January 2017 (UTC)

No worries, the issue was that I'm currently using the info on all the class pages for a mod project and all of sudden everything started turning red. Thanks for the work :) Hobbes (talk) 18:58, 27 January 2017 (UTC)

Class Tree

10-4. I put the current mediocre rank icons up this morning, I think. Certainly looking forward to them being upgraded. I'm so glad you made the Template:Ability (LW2). The old one was atrocious to add to. I just need to learn how to page break properly in the b-info pop-up window.
This is my first wiki edit ever, so I learned a bunch watching your updates. I never would've thought about putting the extra info on a mouse-over, or how to do it. BTW, if you think your question mark is poor, check out what I uploaded, lol.
I'll be filling out more text info for now, and working on the Psi Operative Tree.
Oh, and I just learned about '~~~~'. <Phew>. --HubrisBliss (talk) 23:30, 27 January 2017 (UTC)

Glad I could teach by doing. :) (Though regexes and Pywikibot helped a lot in sorting those ability templates.) As for the info pop-up, I've never been able to get title text to respect breaks on a wiki. I think it's still possible, but would require tweaking the CSS used by the wiki to add a new class for these images specifically. --Tvol (talk) 23:59, 27 January 2017 (UTC)

Oh, and I forgot to mention, that this line-break issue is part of the reason I moved the info bits to their own sub-pages. (Or will be moving them.) That way it's easy to transclude those lists elsewhere, in-case there's need of a stop-gap of some sort. --Tvol (talk) 00:12, 28 January 2017 (UTC)

Specifically, where are you moving the info bits? Not the individual perk templates? i.e. Template:Alpha Mike Foxtrot (LW2), after | s_info =. If somewhere else, please point me there. --HubrisBliss (talk) 00:37, 28 January 2017 (UTC)

Ah, okay. Here goes my explanation. I'm moving the lists of extra/extended info to sub-pages of their respective templates. This means that for Template:Alpha Mike Foxtrot (LW2), the info text (and just the info text) would be on the page Template:Alpha Mike Foxtrot (LW2)/Info. Note the /Info part. Then the template itself should be edited so that it reads {{ {{subst:FULLPAGENAME}}/Info }} and saved. When it is saved, the subst: part will convert the FULLPAGENAME magic word into raw text, and the result will be, in this example,

• You do 4 additional points of base damage and 2 additional points of crit damage with your primary weapon.. This will make sure that it references its own Info sub-page correctly no matter where it is used on the wiki. You can see an example at Template:Heavy_Weapons_(LW2) and Template:Heavy_Weapons_(LW2)/Info, as well as more info about transclusion here.

The payoff here is that should anyone want to reference the perk's extra info text somewhere else, they don't need to duplicate it, just use transclusion to refer to it, keeping things DRY (a software engineering principle, "Don't Repeat Yourself", but it applies equally well to wikis). This could be used, for example, to display all the info text underneath the ability icon, or next to it, or in a different cell in a table, etc. It's a just-in-case thing but could save headache later. --Tvol (talk) 01:01, 28 January 2017 (UTC)

All makes sense. Just wanted to avoid adding text in the wrong spot. For now, I'm finding new things to do, but I will plan on adding text later after you have created the respective */Info pages.
Expect a simple unit navbar at the bottom of the class pages fairly soon. I'm already frustrated trying to jump between them. --HubrisBliss (talk) 01:16, 28 January 2017 (UTC)

Those are some cleeeeean rank icons. Nice! Short-but-sweet unit navbars are in. --HubrisBliss (talk) 02:08, 28 January 2017 (UTC)

Possible issue with the LW2 Abilities template

Use of the Abilities template you designed appears to generate a lot of vertical whitespace, usually 3-4 lines worth (this can be seen for instance in the Perk List page). This makes it very difficult to embed abilities properly in a table - I tried embedding perks into the Dark Events page in much the same way that the LW1 Aliens page does it but the whitespace made the formatting nigh impossible. Interestingly enough, this issue doesn't appear to crop up in the class tables, which is why I'm confused. Can you clarify whether this is an issue with the template itself or explain the intended way to use the template to avoid the whitespace? Thank you. DjinnFor (talk) 02:28, 3 February 2017 (UTC)

It's not {{Ability_(LW2)}} causing the excess whitespace, it's actually the intermediary ability templates. I set up the Ability template with tight-fitting includeonly tags to guard against exactly this issue. I think the reason that this isn't an issue for the Class Trees is because the individual perk templates are being called as parameters. MediaWiki implicitly removes whitespace before the first character and after the last character of a parameter. For example, this:

{{Some template
  | variable = value



  | other variable = other value
}}

...should behave the same as this:

{{Some template
  | variable = value
  | other variable = other value
}}

The individual perk templates have excess whitespace before their noinclude tags, so when you call them directly the whitespace is parsed and makes it to the page generation intact. When it is called as a parameter for another template, the whitespace at the end gets removed first before the HTML is generated. (Again, all implicit, so it's annoyingly hidden.)

The fix for this is to run over all the ability templates and restructure the noincludes so they more tightly fit the template code. I'll run a bot over them tonight. As for usage of the template, I know the documentation needs work. It also needs updating to provide default inline display but toggleable support for table display (which is just a fancy way of saying I need to convert spans to divs). I still have work to do on it so I won't finish documentation until I think it's in a finished state. As a side note, I'll be uploading the images for Dark Events and a whole host of other stuff soon, so hopefully you'll have more media to work with by tomorrow (late tomorrow if I don't get the uploads done tonight). --Tvol (talk) 06:32, 3 February 2017 (UTC)

Appreciate the details, thanks. DjinnFor (talk) 08:13, 3 February 2017 (UTC)

Templates

As for the defaults on ability templates, may I ask your reasoning as to setting them all to be visible? -Tvol

No particular good reason. I was primarily trying to make the b_info show up on the individual class perks. Your method makes much more sense in context of using the templates elsewhere. Also, I was trying to make a list of which perks still need info, mostly assault, gunner, and grenadier, as I was working up the alphabetical class list backwards. The changes in the perk templates was a temporary fix seeing as I was already checking other things on the edit page. Now I realize I should've just changed the class page (is that what you were saying?), but I was unclear what you were trying to do when you last edited those. When you set b_descr=1 and left the others blank, the ? no longer showed up, and my immediate thought was change the perk template to show, only if the info was in place.

I knew my work was next to worthless, except that the class pages at least looked finished for those using them. For now I'll keep away from editing the perk templates until you've solidified the best method. Hopefully I can get the last of the b_info in today.

I realize there are much better ways to do what I'm doing, which I don't really know how to execute, but I don't mind some tedious work. For now, this is more about learning than efficiency. Trying to bot things is a bit more than I wanted to bite off, but is high up on my list of things to learn. Don't hesitate to call me out for something stupid I've done, or fix it. My first principle has been "don't fuck with stuff too much" and the second "make it look good on the user end." I knew I wasn't violating the first too much (easy to fix, if worthless), and I definitely executed the second.

--HubrisBliss (talk) 15:26, 3 February 2017 (UTC)

"Now I realize I should've just changed the class page (is that what you were saying?), but I was unclear what you were trying to do when you last edited those."

That's entirely my fault for not being clearer. I've been doing this very slap-dash so I haven't been updating the documentation (it's a pain since I've been refactoring the template often; I will make the documentation better once I think I'm done). Unfortunately, the default values have to be explicitly set as their intended defaults in each ability template as well as the base {{|tl|Ability (LW2)}} template, otherwise what happens is the parser tries to pass {{{b_whatever}}} to the base template instead of an empty string, which is what would be expected behaviour. And for some damn reason if you use {{{b_whatever|}}} so it defaults to an empty string, the parser considers that to be an actual value passed to the next template, so the checks fail. Edit: Actually, I've found a way to safely passthrough parameters based on whether or not they are used in the template call, so I will be implementing that tonight. (I think if I used #if instead if #ifexpr this wouldn't be an issue, but I would rather enforce explicit use of parameters, because MediaWiki provides no type checking. It also allows for explicitly turning off some part of the template during normal use without risking the behaviour changing if the default values are updated later.)

"When you set b_descr=1 and left the others blank, the ? no longer showed up"

I think that was a bug in how I was doing things previously. It should be gone now, I hope.

"I knew my work was next to worthless, except that the class pages at least looked finished for those using them."

Nah don't be too hard on yourself.

"My first principle has been "don't fuck with stuff too much" and the second 'make it look good on the user end.'"

That's my end goal as well (though I really need access to the site's CSS before I can really make headway, or at least what I would consider headway, on that last point). And seriously don't worry about making any mistakes. I made tons of them when I first started dealing with MediaWiki years ago (and back then parser functions weren't even a thing), and I still make them if my continuous re-jigging of that Ability template this week is anything to go by. :P --Tvol (talk) 01:13, 4 February 2017 (UTC)