FANDOM

DarthKitty

  • I was born on February 16
  • My occupation is Human Being
  • I am Male
"I have awaited this - the day you would come..."
Welcome to the Final Fantasy Wiki, DarthKitty!
FF4PSP Paladin Cecil Portrait We hope you will enjoy your stay here and help improve the Wiki -- all your help will be greatly appreciated! First off, why don't you try looking though these links as a guide to get started around here.

When you're ready to start editing, there are plenty of ways you can help the wiki here. If you have any questions regarding the wiki, ask one of our staff members.

--Magicite-ffvi-ios Technobliterator TC 00:25, July 7, 2015 (UTC)

Dummied Content Edit

Ideally, that, and some of the other categories, should be renamed to the lowercase. At the moment, it hasn't been, but that's mainly because I've been too busy with other stuff to get the bot to move that. So while you're free to fix "Dummied content" to "Dummied Content" for now, be warned that it'll eventually get reverted back.--Magicite-ffvi-ios Technobliterator TC 18:51, December 8, 2015 (UTC)

Okay, that makes sense. I was just moving some pages from a "red" category to one that already existed, since I figured you guys don't want duplicates. Thanks for letting me know! DarthKitty (talk) 19:06, December 8, 2015 (UTC)

Main page portal Edit

Feel free to make whatever changes to the code you want now that it's up! I just didn't want it to be changed yet while we were still messing with it to make sure it worked.--Magicite-ffvi-ios Technobliterator TC 04:04, December 30, 2015 (UTC)

Thanks for fixing all the wrong side icons Edit

Didn't think there were so many!Keltainentoukokuu (talk) 16:47, November 4, 2016 (UTC)

Thanks from me too, was something I was going to do by myself little by little. I hope you checked if those already working were correct them too, sometimes for a given game was placed the wrong sideicon. Anyway, good job!
TTFan from JP (talk) 07:10, November 5, 2016 (UTC)

Portability Edit

If something is not regarded as portable even though it uses PI syntax, it's better to Special:Contact/bug and link to them than to change the formatting (which is only a temporary solution). Thanks for trying to fix that, though!--Magicite-ffvi-ios Technobliterator TC 12:03, May 19, 2017 (UTC)

Module:Codename Edit

Hey, just curious what you're testing with the Codename module in the sandbox?--Magicite-ffvi-ios Technobliterator TC 18:27, June 15, 2017 (UTC)

Nothing in particular, just trying to make it more clear/readable for future editors, with a few quality-of-life improvements along the way. For example, I added a non-frame version of Codename.artinf() to make testing easier, and a more helpful error message if you give an invalid codename to the fame'd version. I realize that Codename is one of the most heavily-used modules on the wiki, so I'm being very careful to avoid major screw-ups.
I can drop it if that's N not okay, though...
DarthKitty (talk) 18:47, June 15, 2017 (UTC)
No it's perfectly fine, feel free to continue if the more readable code works as well/is as or more efficient. In fact making the code more readable can only be a good thing.
Only thing I wanted to let you know is that we're trying to make the cssgen generate something like what's on MediaWiki:Releases.css than the current Custom-releases.css. I just haven't gotten around to it (though if you could edit the cssgen to do that, that'd be great).--Magicite-ffvi-ios Technobliterator TC 18:53, June 15, 2017 (UTC)

Cssgen Edit

Hey man, thanks loads for your help so far with the module namespace and with the Codename work. I think with how much you've made it more readable (and probably more efficient) we might not need to split the rest after all, though I still moved the Codename/Logger to Module:Cssgen as I thought that made more sense anyway. Problem with that module though: right now, the background images aren't working. As you can see in the history, I've tried a few things but I still can't get them to appear, sometimes it just throws a script error instead. Any way around that? Though mind you, even when I tested those CSS variables with the background images in, the navbox background images weren't working...something to do with #FFVII-nav?--Magicite-ffvi-ios Technobliterator TC 11:40, June 21, 2017 (UTC)

Also, Module:Navbox has an error - Template:navbox FFXIV shows a script error in one of the cells. Not sure if that's because of your edit removing module:FFwiki?--Magicite-ffvi-ios Technobliterator TC 16:01, June 21, 2017 (UTC)

The reason for this is that Module:FFWiki replaced string with Module:String, and so any module that required Module:FFWiki would get the functions of Module:String without having to import it themselves. That's not the desired effect and other modules that use it should be requiring it separately.
I have replaced Module:String's contains with the regular string's find, which if it is the only example of a Module:String function should have resolved the issue. JBed (talk) 16:15, June 21, 2017 (UTC)
Figured out the other thing as well...not sure navbox titles are working properly yet, but those can be fixed later.--Magicite-ffvi-ios Technobliterator TC 16:45, June 21, 2017 (UTC)
I think your most recent edit broke classes like FFVa and FFVb. A bunch of colors vanished, but I was able to fix sideicons by converting ${codename}a${codename} and a. I've reverted it, but Releases.css still needs to be updated.
btw, is it safe to call FFVa et. al. "legacy" classes? In other words, .FFV.a is the preferred format, right? DarthKitty (talk) 22:07, June 21, 2017 (UTC)
I've never really thought about it, but I'd say it's safe to consider them as such. Navboxes rely on them, but they could probably be converted to FFV a too. Also, if that did break them, then I'm not sure how to deal with another problem - #WikiaArticle [class$="b"] also targets #WikiaArticle stub which it shouldn't.
Also, any idea why the background of navboxes (like FFXIV which I just linked) isn't working?--Magicite-ffvi-ios Technobliterator TC 22:18, June 21, 2017 (UTC)
Looking into the navboxes right now. Preliminary guess: the --navbox-background-image variable isn't being applied to anything, so there're no images. Also seeing this: http://imgur.com/a/9xVY2. At least it's not completely gray, like before! :p
DarthKitty (talk) 22:28, June 21, 2017 (UTC)
Wow, it also hits .lua and .source-lua. O_o DarthKitty (talk) 22:32, June 21, 2017 (UTC)
Hm, it should be being applied to .navbox .mainttile #FFVII-nav? Don't see why it's not. Also, not sure what to do about the FFVa classes if we can't use #WikiaArticle [class$="b"].--Magicite-ffvi-ios Technobliterator TC 23:39, June 21, 2017 (UTC)
Also, do you reckon it'd be possible to use cssgen to create another piece of code just above Series and Releases? Basically, I want to create "full-width" versions of all the classes. So it'd be like, .pi-theme-FFI-full-width, .pi-theme-FFII-full-width, .pi-theme-FFIII-full-width, .pi-theme-FFIV-full-width, etc { width: 100%; }. Do you think you could do that? Sorry that I'm getting you to do the Lua stuff instead of doing it myself, but I figured you'd understand your own code better. :P--Magicite-ffvi-ios Technobliterator TC 23:57, June 21, 2017 (UTC)
Nevermind...fixed the navbox maintitle thing myself. Would still like help on the full-width themes if possible at some point though, but I may be able to do it myself (should just be a for loop?)--Magicite-ffvi-ios Technobliterator TC 15:00, June 23, 2017 (UTC)
Sorry about that, the full-width code is up.
Since [class$="a"] and [class$="b"] are targeting so many things that we don't want, I think the best course of action is to remove 'em. Like you said, that's a problem for classes like FFVa... unless we stop using CSS variables. Between those two unattractive options, I think it's better to ditch the classes.
That sounds like a monumental undertaking, but we don't know how many pages actually use those legacy classes. To help us make an informed decision, I've been working on a script to track them down. It sort of works, but it takes forever and all-but-freezes my computer because it eats up memory like crazy. I haven't actually gotten any results yet, because there are so many pages to search through! (-_-)
In unrelated news, Template:SL adds a background-color if it has a class, which makes navboxes look a little weird: actual, expected.
DarthKitty (talk) 05:22, June 24, 2017 (UTC)
To be honest, navboxes should not be using SL, the .maintitle class should simply color the link in properly. I could probably fix that myself.
And I agree ultimately with ditching the legacy classes. Interesting you made JS that could find them, normally when I do it I just run the bot and hope it finds them all.--Magicite-ffvi-ios Technobliterator TC 10:26, June 24, 2017 (UTC)
EDIT: and of course, for some weird reason, .maintitle a:link and .maintitle a:visited are not applying anything...--Magicite-ffvi-ios Technobliterator TC 12:13, June 24, 2017 (UTC)

(Reset.) Looks like a specificity thing, because it works fine if you remove the #WikiaArticle [class$="a"] a:link bit. !important will fix it, or we can just wait. DarthKitty (talk) 12:21, June 24, 2017 (UTC)

EDIT: huh, then vde and [show] break. http://imgur.com/a/2JLKU DarthKitty (talk) 12:24, June 24, 2017 (UTC)

Better to just wait then, and changing .maintitle to .titletext should fix vde.--Magicite-ffvi-ios Technobliterator TC 13:34, June 24, 2017 (UTC)

FFIII Enemy Stats Edit

Just wondering if you'll be able to convert the FFIII enemy pages to use that? We have a bunch of JS code that does (part of) that when you enter in into the console if you want to give it a look. However, you seem really good at manipulating the MW API and at using JS so you may not need help there, hahaha.--Magicite-ffvi-ios Technobliterator TC 00:17, July 15, 2017 (UTC)

Enemy Stats infoboxes Edit

Hey man, I don't want to mess you around too much, but I just thought I'd let you know that the enemy stats infobox style in templates like FFVI Enemy Stats/data, FFXII Enemy Stats/data etc are styles that the wiki may have to change again. While we'll still be using Portable Infoboxes, and still full-width tables, I've been informed that the specific style being used in those templates is not as sustainable as I'd hoped.

I'm hoping instead to switch to a new Portable Infobox style that looks more similar to what's on w:c:es.pokemon:EP001, with a full-width flexbox div that contains different PIs, ordered in CSS (there will likely be a Fandom-supported native solution for this eventually). Possible examples:

HTML:
<div data-layout="infobox-panel">
<infobox />
<infobox />
<infobox />
</div>
CSS:
*[data-layout*="infobox-panel"] { display: flex }
*[data-layout*="infobox-panel"] .portable-infobox:first-of-type { order: 2 }

I was wondering if you'd be interested in making a draft for this kind of infobox with FFXII and FFVI to help figure this out? I wouldn't want to keep you working on FFI/FFIII enemy stats templates only to undo all your work later. Thanks for all the hard work once again!--Magicite-ffvi-ios Technobliterator TC 01:05, August 27, 2017 (UTC)

I'd be happy to help. Could you go into a little more detail about why the current design is unsustainable? That will probably make it easier to write and test the draft. DarthKitty (talk) 02:03, August 27, 2017 (UTC)
Essentially, if you look at a page using this design, like Behemoth (Final Fantasy XII) or one of the FFIX enemy pages, in Mercury (mobile skin), you'll find that you can't read the Immunities and a few other sections.--Magicite-ffvi-ios Technobliterator TC 08:30, August 27, 2017 (UTC)
Woah, no kidding—almost the entire infobox is unreadable at 325px! I've started work at User:DarthKitty/New enemy stats, but I'm pretty tired now, so there's nothing substantial there yet. Lemme know if I've wildly misinterpreted you! :p DarthKitty (talk) 13:21, August 27, 2017 (UTC)
Nope, it looks like you've got the right idea so far. There's no huge rush, looking forward to see what you can come up with!--Magicite-ffvi-ios Technobliterator TC 13:34, August 27, 2017 (UTC)
Just a few things to note for the final design...
  1. It's imperative that extra classes are not added. So while <div data-layout="infobox-panel"><infobox/></div> is fine, adding divs with classes does not work. That said, you can just use selectors like [data-layout*="infobox-panel"] .portable-infobox:first-of-type { order: 2 } which does not make the solution non-portable.
  2. The Portable Infoboxes themselves need to be 270px wide, while the container can (and should) be.
  3. Regarding handling multiple versions in the new format: presumably, we would put things specific to new versions on a separate row. So let's say we have a row with two infoboxes containing items and abilities for FFVI's GBA version, we would have a row below that containing the identical thing for the SNES/PS versions
Basically, the below may be possbile:
<div data-layout="infobox-panel-outer">
<div data-layout="infobox-panel-inner">
<infobox />
<infobox />
<infobox />
</div>{{#if:{{{GBA|}}}|
<div data-layout="infobox-panel-inner">
<infobox />
<infobox />
<infobox />
</div>}}
</div>
if that makes sense.--Magicite-ffvi-ios Technobliterator TC 15:43, August 27, 2017 (UTC)
Okay, I got something working. Screenshots:
This feels a little too spacious for my liking: I would probably reduce the gutters to 50px, tops. Aside from that, I'm pretty happy with this. Wrapper divs like <div data-size="1/3"> prevent thememageddon, by letting infoboxes always be full width inside of panels. Although... are all of those extra <div>s going to impact portability? DarthKitty (talk) 06:29, August 28, 2017 (UTC)
Looks great on first glance. I'll check if this is viable first, but I don't think that the divs impact portability provided they have no classes. As for being species, what could help is having the panel's max-width be 990px (min-width 660 and normal width 100%), like our current full-width class for tables etc.--Magicite-ffvi-ios Technobliterator TC 10:12, August 28, 2017 (UTC)
Huh? Yeah, I definitely did the 990px ≥ 100% ≥ 660px thing. I was referring to the amount of whitespace between infoboxes. For comparison, here's what happens when I set --gutter to 90px (same as before), 50px, and 1em. It's your call, but I think the latter will look much nicer once we add data. DarthKitty (talk) 11:01, August 28, 2017 (UTC)
Ah, got it. I agree, the 1em guttter is the nicest by far, I'll check back whether this works and then we can make a proper FFXII enemy stats box? After that I'd focus on the FFVI one and then do the rest when that one is done.--Magicite-ffvi-ios Technobliterator TC 12:32, August 28, 2017 (UTC)
Alright I've just checked. This design is good, only thing is we won't be needing Top nor Bottom infoboxes (the section headers will be enough, can surround the stats template with a border though) and individual infoboxes don't need resizing, 270px should be max for all to get it to appear best on mobile. Also, flex-basis should be enough to sort out the problem of space between infoboxes, but your third example with the gutter change is fine.
As for what each of the infoboxes should do: the first one should contain bestiary and location/species/aggression etc listed vertically (perhaps using the title Info?), second infobox contains Stats which either lists the stats vertically or uses a row-items="3" horizontal smart group, third infobox could be titled Affinities and contain both Elemental and Status affinities with a row-items="4" horizontal smart group, fourth infobox contains Items listed vertically, fifth contains Abilities also listed veritcally. This should work, we can always shuffle around if it's unbalanced?--Magicite-ffvi-ios Technobliterator TC 14:41, August 28, 2017 (UTC)
You know, if you're using flexbox, you don't even really need to adjust those gutters manually. https://css-tricks.com/snippets/css/a-guide-to-flexbox/ -- FishTank @fandom (wall) 16:48, August 28, 2017 (UTC)

(reset) Okay, that should address all of your concerns. I didn't bother with infobox-panel-wrapper this time—if you need multiple infobox-panels, you can just add them consecutively:

<div data-layout="infobox-panel">...</div>
<div data-layout="infobox-panel">...</div>
...

I'll start on FFXII once this design is approved. DarthKitty (talk) 10:09, August 30, 2017 (UTC)

Since there were no additional comments on my layout test, I went ahead with the FFXII Enemy Stats rewrite. Aside from what you described above, I added a few extra titles and headers, and added text labels to the various affinities to improve UX. Speaking of which, that section is reaaaaaaaally long, which creates some awkward gaps. Any suggestions? DarthKitty (talk) 17:28, September 1, 2017 (UTC)

From what I've seen, it looks great. I'll check with the Fandom folks first but this looks really good.--Magicite-ffvi-ios Technobliterator TC 17:50, September 1, 2017 (UTC)
Yep, we made a few changes and now we're really happy with it. Pushed it live. Awesome work! Just wondering if you have any ideas for the FFVI one (or could come up with a draft for that)? After that I should be able to redo all the remaining enemy stats infoboxes and make them like this.--Magicite-ffvi-ios Technobliterator TC 18:22, September 1, 2017 (UTC)
Cool, glad I could help! I'll take a stab at FFVI in a bit. DarthKitty (talk) 18:36, September 1, 2017 (UTC)
The FFVI draft is ready now! DarthKitty (talk) 20:39, September 1, 2017 (UTC)
Hmm. On the one hand, I feel like the SNES info should be in a separate box, but on the other I think that doing that would add too many infoboxes. Do you think it would make sense to put SNES abilities below GBA abilities, and then GBA items below SNES items and see how that looks?--Magicite-ffvi-ios Technobliterator TC 20:46, September 1, 2017 (UTC)
I'm a little confused. Do you mean (GBA abilities → SNES abilities → SNES items → GBA items), or something else? Because sandwiching the SNES stuff between the GBA stuff doesn't sound very useful to me. DarthKitty (talk) 20:57, September 1, 2017 (UTC)
GBA abilities → SNES abilities → GBA items → SNES items, so like how Bestiary works right now.--Magicite-ffvi-ios Technobliterator TC 21:00, September 1, 2017 (UTC)
Done! We could also remove the "(GBA/Mobile/PC)" bits, since that's presumably the "default" version now. DarthKitty (talk) 21:08, September 1, 2017 (UTC)
It's the default version we use, but I like to include them in just for added clarity.
Pushed it live. Thanks again for the great work! I can probably work on moving the other enemy stats templates to this design now. I'll keep the /data/draft page because I want to test it more, ie test just wrapping the SNES/PS infoboxes in {{#if:{{{snes|}}}{{{ps|}}}}} to see if it breaks, but other than that I think we're good for now, you can update other enemy stats templates to this design. Did you have any quick way of tidying indentation before you tested the draft though? Because that'd probably help me when I do the rest.--Magicite-ffvi-ios Technobliterator TC 21:17, September 1, 2017 (UTC)
I did most of that by hand, because I don't trust linters/beautifiers to handle wikitext correctly. One thing I did figure out, though: the built-in editor really doesn't like tab characters (\t). Replacing those with four spaces makes things a lot easier. Other than that... use multiple cursors? Or try a regex?? ¯\_(ツ)_/¯ DarthKitty (talk) 22:09, September 1, 2017 (UTC)

FFI/II/III enemy page updater Edit

Hey! Just checking to see if you ever made any progress on that script that updates pages with FFI-III Enemies to use the new format? Have a couple weeks off and looking to get back to editing; wasn't sure if you had those games covered or not.--Magicite-ffvi-ios Technobliterator TC 02:56, December 18, 2017 (UTC)

Ah... not really, no. I got a little burned out on that project, so I've been working on other stuff. I think I was almost done with the enemy page updater, though... I'll take a look in a few hours. DarthKitty (talk) 03:32, December 18, 2017 (UTC)
I forgot just how clean that code was. The enemy page updater is almost done, but it's not quite ready:
  • I need to make the script copy data from the old templates to the new ones. I can access that data really easily, it's just a matter of slotting the right pieces into place. The most difficult part will be handling images, but I think I already wrote a script for that. Should take maybe three or four hours?
  • I need to manually go through each enemy page in the set, looking for the atypical ones: multiple forms, that sort of thing. The script isn't built for corner cases, so I'm going to have to update those by hand. Probably won't take more than two-and-a-half hours.
A lot of that is "grunt work", which explains why I wasn't very excited about it. :p (Then again, I built an item database in the meantime, so... ¯\_(ツ)_/¯) I'll be pretty busy tomorrow, but I'll try to take care of this on Tuesday. Sorry for the crazy six-month delay! DarthKitty (talk) 10:37, December 18, 2017 (UTC)
Hey, just checking if you were able to make any progress on this?--Magicite-ffvi-ios Technobliterator TC 19:59, January 11, 2018 (UTC)
Sorry for not getting back to you right away, I was a "little" distracted by AGDQ. Anyway, I started fixing the 13–17 pages that need manual work. Gonna try to do it in small bursts, so I don't get burned out. DarthKitty (talk) 22:50, January 14, 2018 (UTC)

Hey man, two things:

  1. Just asking, with regards to the enemy updater, if there's any way I (or someone else) can actually use the updater on pages if the JS for it is done? If it's basically the busywork putting you off?
  2. Seems like your speciality, so: Module:Navbox, is there any benefit to removing its dependency on HF.lettersequence (asking because it may be useful on dev wiki and/or copied to other wikis)?--Magicite-ffvi-ios Technobliterator TC 23:16, February 16, 2018 (UTC)
Yeah, the updater is about as done as it's going to get. I'll go ahead and run it in a few minutes. I've also got a sandbox for every page that needs to be fixed manually for whatever reason; most are finished. I didn't get to Roundworm, Zombie Borghen, Black Knight (Final Fantasy II), or Phrekyos, though. Those four enemies have multiple forms, but the titles aren't based on the bestiary like I expected, so Template:infobox enemy stats FFII will need to be updated. (This is what led me to poke at Module:Multi-section template the other day.) The updater will ignore 'em, fortunately, because they use Template:FFII multi Enemies instead of Template:FFII Enemies.
I'm really sorry for dawdling so much on this project. When I first started, I was just going to update the FFIII enemy pages, but then I thought "Well FFI and FFII should be simple enough, since they were released so early. Why don't I take care of them, too?" What I didn't consider was how many versions I'd have to juggle to get things right. This ended up being the single largest automation job I'd ever undertaken—I definitely bit off more than I could chew! Thank you for being so patient with me throughout this, I learned a lot! ^_^
As for Module:Navbox, I'm not sure how useful it'd be on another wiki right now. It uses a lot of custom CSS, and it looks like it interfaces with Module:Codename via MediaWiki:Releases.css. HF.lettersequence is only used in one place, though, so it should be easy enough to inline if you really want.
DarthKitty (talk) 05:31, February 18, 2018 (UTC)
Aaaand, done! Everything worked out fine, aside from one minor, idiocy-induced snag. The following templates are now effectively unused, and should be safe to delete:
  • Template:FFI Enemies
  • Template:FFI Enemy/stats
  • Template:FFI multi Enemies
  • Template:FFII Enemies
  • Template:FFII Enemy/stats
  • Template:FFII multi Enemies (aside from the four articles I mentioned earlier)
  • Template:FFIII Enemies
DarthKitty (talk) 07:47, February 18, 2018 (UTC)
Really great work. Love it! No worries on taking a while to finish the project; it is mostly busy work and like you said there are millions of versions. I promise you that the only game with that many release versions is FFIV, and that game's already been/being handled. Would be nice if this could be done with other games, I know FFVIII needs it.
Never really knew how JS bots worked until recently, when I suddenly heard they're not uncommon. I'd love to learn how to do something like that, would be easier than having to install pywikibot all the time. FFII multi Enemies I'll keep undeleted for the time being until those pages can be fixed though.
Yeah I know that Module:Navbox on this wiki interferes with Module:Codename and Releases.css, mostly for its class parameter, however it was actually originally based on the w:c:jakanddaxter:Template:Navbox from J&D wiki, imported here, "FFWiki-fied" and made into a module. I kind of want to import the module version back to J&D wiki to make things run faster, and also potentially use on the R&C wiki. Obviously will credit the person who turned it into a module when imported to the respective wikis.
Great stuff, and thanks loads for helping with this!--Magicite-ffvi-ios Technobliterator TC 15:40, February 18, 2018 (UTC)

Navboxes Edit

(Cont. from above.)

Hey, just checking again if the Module:Navbox stuff can be done?--Magicite-ffvi-ios Technobliterator TC 20:55, February 22, 2018 (UTC) Hi again, just saying I've been seeing progress on the new Navbox and it looks like you're doing a good job so far. While you're at it, don't suppose you can change "collapsible" to use "mw-collapsible" instead? Aside from making it easier to port to other wikis, that could potentially allow us to remove the custom collapsible JS from our own wiki. Thanks again for all the help so far, really sorry I've been so useless with helping out myself, have just had too much on my plate at university to program on the wiki lately...--Magicite-ffvi-ios Technobliterator TC 16:03, March 5, 2018 (UTC)

It's no trouble, really. I like helping where I'm able, and I like working on challenging puzzles like these. If anything, I feel a little guilty for not doing more! Anyway, since it's been a few days, here's a status update:
What's done so far
After inlining HF.lettersequence and removing a bunch of useless or broken code, I realized what it was really supposed to do: take a number, and convert it to a zeroless, base-26 form. Although Lua has some capacity for base conversion (tonumber(str, radix) for base → number, and string.format("%x", num) for number → hexadecimal), there's nothing in the standard or Scribunto libraries to handle this particular situation. I couldn't find any libraries for this purpose online, either, so I had to write my own.
What still needs to happen
Dev:Number systems still doesn't have any tests or documentation, but I decided to punt on that for a couple of days, to give myself perspective. I'll probably also rename it to Dev:Base converter, since there's there's already a module for Roman numerals, and I doubt there's much demand for other number systems. After that, my plan was to merge the sandbox and call it good, buuuut...
Collapsing
Migrating to .mw-collapsible et. al. is trickier because it gives us no control over where the toggle button goes. If you use a table, then the toggle is appended to the last cell on the first row; otherwise, it becomes the first element of its parent. Although I haven't looked into the JavaScript side of things, it looks like .collapsible works a little differently:
Comparison of toggle button placements
Before (.collapsible) After (.mw-collapsible)
<div class="collapsible">
    <div>
        <!-- toggle is inserted here -->
        <div><!-- v.e.d --></div>
        <div><!-- title --></div>
    </div>
    <div><!-- contents --></div>
</div>
<div class="mw-collapsible">
    <!-- toggle is inserted here -->
    <div>
        <div><!-- v.e.d --></div>
        <div><!-- title --></div>
    </div>
    <div><!-- contents --></div>
</div>
As you can see, simply replacing .collapsible with .mw-collapsible will move the toggle button outside of the header—making the whole thing harder to style. I think I've found a solution to the CSS problem (spoiler: it's flexbox), but the downside is that the HTML needs to change. I'll do some more testing and see if that's viable.
DarthKitty (talk) 04:38, March 6, 2018 (UTC)
Sounds great so far! Regarding the collapsible part, we could do something similar to how Team Ico's navboxes do it (those were where our navbox designs were inspired from, btw) as to how to do it. I believe you just place .mw-collapsible-content somewhere below the title header works (i.e. in the table where the contents class is, or in the div that the table is wrapped in?) to fix it.
If you'd like other things to do, I have two ideas on my plate if you're willing, the main thing after Navboxes would for me be allowing me to create my own enemy page converter similar to yours? I'd basically just need someone to check I have the right idea.--Magicite-ffvi-ios Technobliterator TC 09:45, March 6, 2018 (UTC)
How attached are you to the double border effect? I ask because it uses a lot of empty elements (e.g. <td class="space-h" rowspan="1"></td>), and removing them would make navboxes faster. I don't think it's possible to replicate with just CSS, though—at least, not without drastically rewriting the entire HTML structure. Here's what Template:navbox FFIII looks like before and after the proposed change.
DarthKitty (talk) 04:35, March 8, 2018 (UTC)
Not very, feel free to remove the empty elements.--Magicite-ffvi-ios Technobliterator TC 07:05, March 8, 2018 (UTC)
Just to clarify, are you planning on converting the navboxes to use the Dev Wiki navboxbuilder? If so, I'd rather not do that, for a couple reasons. Firstly, outsourcing to Dev in this instance basically gives up any control over the features it has, and will probably be difficult with things like our class system. Secondly, people weren't too happy with learning the current navbox syntax as it was, and I'd rather not make them re-learn a syntax. Basically overall this would mean losing control over the navbox and converting to another system, and the only time I'd really be willing to do that would be if FANDOM came up with a Portable Navboxes system (sadly unlikely) where there are more obvious/immediate benefits.--Magicite-ffvi-ios Technobliterator TC 14:23, March 9, 2018 (UTC)
Hey, are you still okay to work on this, or have you just been busy? Hoping I didn't scare you off the project!--Magicite-ffvi-ios Technobliterator TC 12:40, April 1, 2018 (UTC)
Technobliterator
Technobliterator

Hello. I don't actually have any opinion either way, but something caught my eye. You claim the pro of speed when its "Lua time usage: 0.060s" v. "Lua time usage: 0.070s". Doesn't that mean it's .01s slower? Is there something I don't understand? JBed (talk) 03:53, April 4, 2018 (UTC)

Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator
Technobliterator

Since you've been making automated edits and you're a trusted user, I'd like to give you access to User:Intangir Bot. Since this is a registered bot account, you'll be able to make mass edits as Intangir Bot that won't flood the RecentChanges. If you have a Discord account, I can PM you the password via the wiki discord (my username is @catuse, ping me when you log on), or else I can send you the password via another means if you'd prefer. You should also add yourself as an operator. Cat (meowhunt) 21:35, April 25, 2018 (UTC)

Technobliterator
Technobliterator

JS for FFVIII enemy pages Edit

Technobliterator
Technobliterator
Technobliterator
Technobliterator

Module:Talk/test Edit

Hey, we were wonder if you were still working on this? If so, is it possible to replace our Module:Color with the dev wiki version a w:c:dev:Module:Color?--Magicite-ffvi-ios Technobliterator TC 17:50, June 15, 2018 (UTC)

(I assume you meant Dev:Colors?)
Module:Color isn't used for much, so replacing it should be easy enough. We can swap Module:Color.new() with Dev:Colors.parse(), but there's one caveat: the latter has access to FANDOM's Sass variables (e.g. $color-body), which will let users make theme-dependent talk bubbles. Probably not a big deal, but worth mentioning.
The real blocker is color:textcolor(), which looks like this:
p.textcolor = function(self)
  return (self.r^2 * 0.299 + self.g^2 * 0.587 + self.b^2 * 0.114)^(1/2) < 130 and p.colors.white or p.colors.black
end
I'm not entirely sure what this does, because of all the magic numbers. The function appears to use Rec. 601 to calculate the luma value of a given RGB tuple. It then returns either white or black depending on whether the luma value is over... 130? I dunno why 130. ¯\_(ツ)_/¯
Regardless, there isn't a direct analogue in Dev:Colors. The best we've got is color:bright(), which compares the color's lightness with a given value. It's conceptually simpler, but might give worse results. What do you think? DarthKitty (talk) 04:47, June 18, 2018 (UTC)
It's a function I took somewhere from the internet.
Dev:Colors has c.text, which uses :bright, but it's a function for invoking. :bright(51)'s what they use. It would be interesting to know what Wikia uses because they have some method of determining light and dark text colours when dealing with skins.
Although note that Dev:Colors currently isn't working perfectly yet. Colors of "black" and "white" won't parse. JBed (talk) 15:34, June 18, 2018 (UTC)
Shouldn't be a problem using bright() as I imagine it'll be close enough, and yeah I meant Dev:Colors, whoops. In worst case scenario, I know the author of Dev:Colors so I can always ask him to implement anything we need.--Magicite-ffvi-ios Technobliterator TC 17:07, June 18, 2018 (UTC)
It looks like FANDOM uses Sass' built-in lightness() function, which does the same thing as color:bright(). But yeah, Dev:Colors doesn't seem stable yet:
= require("Dev:Colors").parse("black")
Lua error in Dev:Colors at line 306: attempt to concatenate field '?' (a nil value).
= require("Dev:Colors").parse("$background-image-height")
Lua error in Dev:Colors at line 340: cannot parse "800".
DarthKitty (talk) 02:48, June 19, 2018 (UTC)
Sorry, forgot about this. I just messaged the author of the script and he said it's fixed now. Does that work?--Magicite-ffvi-ios Technobliterator TC 21:47, July 2, 2018 (UTC)
Hey, just seen the edits on Dev. Is it safe to merge your sandbox with the main one? Even if it's not a complete version of what you intended to do, it'd still be great to merge so we can clear a couple module dependencies from the wiki for the time being.--Magicite-ffvi-ios Technobliterator TC 10:23, July 4, 2018 (UTC)
It should be safe, but I'm having second thoughts about some of those changes. A more conservative edit would probably be better right now, one that only updates the dependencies. I'll take care of it. DarthKitty (talk) 18:47, July 4, 2018 (UTC)
Ahh that's fair enough. Yeah feel free, long as the dependency's down, I'd like to get rid of/cut down on those if possible. The other main thing is for Module:WikiFunctions. I feel like the code in that should be kept, somehow reorganized (possibly?), removed dependencies, and moved to Dev Wiki so others can benefit from it. Was wondering if you had any specific ideas/requests for reorganization of that module?--Magicite-ffvi-ios Technobliterator TC 22:06, July 4, 2018 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.