Talk: SBEyes

Media Queries[]

Hello OOeyes, I hope it's possible to contact you through this Wiki. Are media queries supported on Gamepedia? We have a few set-up over at MediaWiki:September.css, mainly intended to make certain elements smaller below a set resolution, but they're not applying. I'm sure these work as I've tested them personally, but maybe Gamepedia applies them differently or is more strict in the way it does? —KidaJiwo (talk) 10:05, 3 September 2019 (UTC)

To my knowledge, the wiki software does not affect or sanitize media queries in any way. I use them regularly without any issue, and I see it's being dynamically added with a script anyway.

Okay, the media queries are invalid. The condition is being evaluated as "not all" because there's some funky invisible character(s) between the "1462" and the "px". I've removed them from the September CSS, but I don't know if that problem is lurking elsewhere. OOeyes (talk) 14:32, 3 September 2019 (UTC)

Oh my goodness sorry for the notification but thank you so much, it would have been years before I was able to notice it was that. As far as I'm aware, only that page had them not work and it was probably due to me noting down units in Notepad. Everything works beautifully now! —KidaJiwo (talk) 10:34, 4 September 2019 (UTC)

Better CharacterRoster and ChT[]

Greetings OOeyes, we have not been acquainted before, so I will simply introduce myself as the former leader of the OJ wiki until I stepped down. That said, I still try to see to the further development of the wiki's styling. That said I recently contacted Pcj and he redirected me to you as apparently you are apparently my wiki manager (really wish they had told us the hierarchy of people we should contact for help when we moved from fandom as widow usually redirects but I digress). So here is the message I sent to him which is now the question I have for you which I believe actually relates to a similar convo above with Kida:

"Currently, I have been trying to fix the fact that that many of the customized items on the wiki cannot flex and proceed to overflow off the screen when the screen is smashed to a small size, which looks awful, especially as most wikis don't have this problem. One of the key offenders of this is Template:FP-CharacterRoster which has its elements manually positioned and inside MediaWiki:October.css we use code like

@media screen and (max-width: 1000px) {
	.frontpagecharacterwrapper{
		left:0; 
		transform: scale(.6);
		top: -20px; /* Just having it fit better vertically */
	}
}

to fix Template:FP-CharacterRoster inability to flex, but this is little more than a patch to a much larger problem with the code itself. I know it's a tall order, but is there any way you can make something like this but one that works properly when compressed: codepen attempt. I wasted many hours trying to get it to work and also to have the right distancing but it's simply way over my head and I don't think I really know what I'm doing. I have little training in code everything I have made is self-taught. I can't seem to adapt any diamond grid codes I have found, and I don't know who to ask since StackOverflow didn't solve my problem either.

Secondly, I was wondering if you could look into why Template:ChT bleeds over oddly on mobile. It has a tooltip that shows the card, but unlike the other tooltips, it shows the card picture shown in the tooltip when in mobile and blocks the text instead of staying in word form. It seems to be the only tooltip that has this issue from what I can tell. This is used on the card-co-op section for the boss cards.

I know this is a lot of stuff and I apologize. If there is any way you can help us I would be very grateful, as we really don't have many editors nor one with expert coding experience. We kinda throw crap at the wall until it sticks and these are the consequences."
Hopefully you can provide assistance and if not, all I can ask is if not you than who...
Shockbowlocke (talk)

I'll try to look at this over the weekend, but I'm not too optimistic. Game widow often tossed requests like this for this wiki my way before I was finally assigned to be the new wiki manager, and I've already considered the character roster problem a few times and couldn't think of a way to make it flex that didn't have a critical flaw, so I may not be much help on that. OOeyes (talk) 22:03, 30 October 2019 (UTC)

Thank you for the response, and, I see, so this is a tougher nut to crack. At the very least the template ChT problem should at least be easier. If we cannot find a flex fix, perhaps we can add even more @media screens to fix the problem. Here is another code that may be less weird than mine that was an attempt to make the table with code. I could perhaps ask the developer how they make the grid, but given its probably in c++ it probably wouldn't be all that useful. Ultimate, I would like to fix all our botched templates and then add an alternate main page on mobile like the Fire Emblem Heroes Wiki, but one miracle at a time. I wish I was a better coder, but hey, I'm trying. Please keep me posted as to the outcomes of these 2 issues. Thanks for your help. Shockbowlocke (talk) 22:44, 30 October 2019 (UTC)

I'm gonna butt in as always to mention that I created ChT for Co-op cards to prevent having to create a page for every single Co-op boss card to have them display with our current tooltip, as there were many and it would take a bunch of time; because of it, it uses a different type of tooltip which is technically embedded on the site, just hidden. Seems however that Zomoroko has taken his time to create a page for all of them, so the template can be replaced by the normal Ci template wherever needed. —KidaJiwo (talk) 04:24, 31 October 2019 (UTC)

Alright, I misunderstood what you meant when you said flex. This is scaling, so the only problem was in not scaling the padding on the shorter rows. You need to be able to use a percentage for that, so you need to use actual padding, not transparent borders, and in this case, the correct size is 55 divided by 786, which gives you this:

.flex-container.s-row {
    padding: 0 6.997455%;
}

And that's a pretty elegant solution compared to what I was thinking, but it still fails to solve one big problem: mobile view. There are a few options I can think of for this:

Just hide the character roster entirely using the nomobile class and make the Characters page mobile friendly. Changing from table to flexbox would be one option; there's no reason that page needs a fixed number of characters per row.
Hide the current main page character roster on mobile with nomobile, but provide alternate mobile navigation using a block with the mobileonly class. It's important to remember you can't rely on the tooltips to identify the character names on mobile; hover isn't a thing on touchscreen devices.
Setting the divs for the rows and icons to inline or inline-block might work fine on mobile, though it'd still be a good idea to do something to fix the names.

I think option 1 might be best. That's a lot of characters for the main page on mobile. OOeyes (talk) 20:27, 3 November 2019 (UTC)

New Issues[]

Hello OOeyes,
I hope your holidays were nice. To cut the small talk, as per usual there are some problems we don't know how to fix so I was hoping you could help with your expertise. So we have both a mobile issue and Tooltip issue.

In mobile, our Template:CiT and Template:Ci3 tooltip is glitching pretty hard. For instance, if you got to a boss page like Star Devourer on mobile and check the "Cards" tab, all cards using Ci3 like Nap will display a big and small version of the card, blocking the entire screen. In this case, the big image is actually quite nice since it makes the card readable but it blocks most of the screen text. If we could have the big image, and not the small one in mobile somehow, it would be ideal.
Likewise, Template:CiT also has this issue, where it also displays the card. This can be seen in the Extra notes section of the page President's Privilege in mobile where Ransome Note is huge.
Unrelated to mobile, an issue we noticed a weird thing with our tooltips. We use tooltips like Pa and Ca to create: Heal and Suguri which display a stylized tooltip box. We noticed however that things using Template:Fe like Freeze which have not been designed more have the special ability to make the extra hover box disappear using the class tttemplatelink. (What I mean is if you hover over Heal you will get the stylized box and a small yellow box that says "Board Panels" You don't get a box with Freeze) We tried adding class tttemplatelink to make the extra box not appear on Template:Ca and Template:Pa but it won't work...In short, how can we have nice looking tooltips and no extra box telling the player where the links goes to. Please Advise.
Shockbowlocke (talk) 03:39, 29 January 2020 (UTC) P.S. Sorry for extra edits to bog ur email.

I'll try to take a look at this ASAP, but unfortunately, I'm fairly backlogged this week. I apologize, but I might have to look at this next week. OOeyes (talk) 01:09, 30 January 2020 (UTC)

No worries, OOeyes. If it has to wait until next week, that's alright. I only ever ask that you don't forget about it/go totally silent and disappear for months. Take a look when you have the opportunity to do so- no need to rush and needlessly stress yourself out.
Shockbowlocke (talk) 01:45, 30 January 2020 (UTC)

I looked in the problem, and I went up with the solution is to completely delete .stooltiptext on mobile by detecting the with via @media only screen and (max-width: px). I tested on personal CSS, the result's pretty fine there, the picture completely disappeared. But when I change to mobile view it completely doesn't load at all. So I edited the class via console and it turned out to works good too. (note I didn't destylize .stooltiptext so it's quite badly rendered, but when destylized it just shows as normal). I think you could get an easier workaround with this said. Pretty lightningreed (talk) 16:47, 31 January 2020 (UTC)

I think I need a little more clarity. Are we talking the mobile view on mobile devices or desktop view on mobile devices? If it's the latter, then yeah, max-width media queries are basically the best you can do detecting mobile in CSS. But if you're talking about eliminating them in mobile view, you'd just put display: none; on those classes in the mobile CSS. And if this is being CSS being loaded on both, then you can prepend .skin-hydra (for desktop) and .skin-minerva (for mobile) to selectively apply rules to only one or the other.

For the tooltip issues, I switched the tttemplatelink to use .find instead of .children, and that seems to have worked, though it seems like .children should have worked as long it was on the same span with character-icon and panel-icon, so, uh, it seems to be fixed, but I don't know why that worked unless that's not where you were putting tttemplatelink. (Note that .children will only search direct children, while .find will search all tags inside. So if you were putting it in a tag higher in the hierarchy, or the link itself somehow, it wouldn't work.) OOeyes (talk) 09:59, 6 February 2020 (UTC)

Alright, good news and bad news. Good news, the display:none does the trick so that's fine. Now the main issue is that the ca pa fix does not work. You did successfully get rid of the floating box but, it added a new one inside the tooltip that we don't want. Here are 2 examples of the issue now: example 1 and example 2. It seems to grab onto whatever it feels like now and put it as a title in left corner. If that can be removed, then then it will be as we desire. Shockbowlocke (talk) 22:09, 6 February 2020 (UTC)

So, that's not intentional? It's being added explicitly by the template/modules as class="ajaxttlink -whatever" on a span inside the link, and a script on the wiki is showing it. I have no idea why it's there, but Template:Pa and Module:Ca are explicitly adding it for some reason. OOeyes (talk) 03:28, 7 February 2020 (UTC)

It is not intended. I'm going to guess ajaxttlink is some kind of remnant from our younger fandom days. At that time I discovered tooltip and since I can't code well and just throw crap at the fan, I probably added it by accident because it came from some other wiki's code. Yes, we do want that gone, please. Shockbowlocke (talk) 03:53, 7 February 2020 (UTC)

Okay, I misunderstood what was happening. ajaxttlink is necessary to show the proper tooltip, and adding tttemplatelink caused the additional box. So what I've done is remove that from the two templates and instead made span.ajaxttlink and img.ajaxttimg remove the title attribute from the links the same way tttemplatelink does. That seems to have done the trick. OOeyes (talk) 07:55, 7 February 2020 (UTC)

Actually sadly OOeyes, you've made a complete circle back to the beginning. Now the weird box inside the tooltip is gone but now the floating box with the name of the link destination is back...Ex: Suguri and

Draw Shockbowlocke (talk) 15:54, 7 February 2020 (UTC)

Hello, I'm here to intervene, maybe to clarify a bit; we have three templates we use: Template:Ca, Template:Pa and Template:Fe. What we basically want is for the templates Ca and Pa to not show the browser native tooltip as well as Fe which already hides it, and for Fe to have the same styling as Pa (solid background, colored rounded borders which support our monthly CSS) as seen in

Heal, while currently it looks like in Freeze. This would be all, and it'd be great if it were to be possible. KidaJiwo (talk) 16:18, 7 February 2020 (UTC)

I understand. That was just me herp-derping and removing title from spans which didn't have it instead of the links, because I forgot those classes aren't actually on the links. So, with a correct selector, it seems to be working. OOeyes (talk) 18:38, 7 February 2020 (UTC)

Adding a Custom Calculator[]

Hello OOeyes, I hope you're doing well given the current world situation with Coronavirus and what not. Anyway, we now have a new idea we would like to implement if possible but we don't have the knowledge to do so. Thus we are hoping either you are someone else might be able to install the code we hope to add. We recently added this page and we were hoping we could add a simple calculator for the users like this example. It would just need those 5 switches and then it would be able to spit out the answer to the user. If this is possible please let me know. The Reward Modifier page details it pretty well, but I can explain it if need be.
Shockbowlocke (talk) 19:32, 19 March 2020 (UTC)

I have a functional widget version at User:OOeyes/sandbox. I made some different UI choices because I thought the radio buttons and number input would be more friendly than a bunch of dropdowns. Let me know if you would like any changes. OOeyes (talk) 08:29, 20 March 2020 (UTC)

Hey OOeyes. I've got good news and bad news. The good news I like what you have done with it and that it looks great. Now the bad news. It actually doesn't calculate correctly but it nearly does. An easy way to see that is to test casual and extreme win with 3 positives. It comes out incorrectly as 4 and 8 instead of 5 and 9. Although I can't fix it myself because I can make sense of code but can't code, I realize it's actually my fault after looking through it. The section I wrote on the Difficulty Modifier is bs the way it's written. The top table on Difficulty Modifier section is not reliable- don't use it. The code does not use 4, 6, 7, or 9 for difficulty because the loss modifier is applied first and we didn't know that originally.

Let me explain the error. You need to use the formula listed here: Co-op Reward Modifier#Full Oranges Calculation. This is the proper equation and a table you can use to test your calculator's results. This makes your modified_base variable wrong. The values for the difficulty are -25%, 0% (or nothing), 25%, 50%. The base value is 6. So your modified_base = 6*outcome_modifier. Then that value is multiplied to (100% + difficulty + mixer_modifier). Once that is fixed the 2 things I would like added are a button before the mixers that the person can flip to set mixers to "on" or "off" the latter which would grey out the mixers. (In the code, "off" would just make them all positive since its 0% anyway). And the second thing I would like is to make it calculate exp under oranges as it uses the same formula which is listed in the next section (Co-op Reward Modifier#Full EXP Calculation). One step at a time though.
Shockbowlocke (talk) 14:21, 20 March 2020 (UTC)

Okay, I believe everything is correct. There may be an issue, though, and it depends on what step the game rounds at. The calculator is currently getting slightly different values for role XP in the loss examples because it does not round the loss modifier. (I'm actually using 0.1 / 3 to get that three and one-third percent value, so it's as precise as a Javascript float is capable.) If the game rounds only after finishing the whole calculation, the calculator should be correct as is. But if it's rounding at the loss modifier (which I would find surprising), I'll need to make another adjustment. OOeyes (talk) 00:25, 21 March 2020 (UTC)

New Clock Module[]

Hello OOeyes. You've been a big help in the past so I was hoping you could create a module if possible or perhaps provide one if it already exists. As you know the wiki has the server time and event countdown timers. However, what we need now is a repeating countdown timer that doesn't need to be reset. Recently the developers added a new system that happens weekly starting on Thursday. So every Thursday, it needs to reset to a 7-day countdown. It also needs to not conflict with the clock that already exists on the main page (and ideally it needs to be adjustable for daylight savings time). In short, it needs to combine the concepts of the 2 clock systems we have. I know this is a rather big order. So please let me know if you can do it, and I will do my best to wait patiently for your work. The calculator you made was excellent so I am hopeful. Shockbowlocke (talk) 16:27, 11 May 2020 (UTC)

I'm sure there has to be something out there for this that can be adapted to work on the wiki. I'll take a look over the weekend when I'll have time to find something and give it a test run. OOeyes (talk) 05:43, 13 May 2020 (UTC)

So instead of finding an outright pre-written widget to adapt for the wiki, I instead chose a date library that makes some of the DST bull easier to deal with. As long as you can identify the reset time's correct timezone, any daylight savings time crap should be handled automatically by the widget when converting to the user's local timezone, including accounting for those two oddball days that are not actually 24 hours where DST is observed. I also have not yet done any fancy formatting with it yet, and it will also reset the countdown immediately when the event starts, and I'm not sure if we'd rather have it doing something different while the event is actually active, so it may need some refinement yet. Anyway, it's over at Widget:Repeating weekly countdown. OOeyes (talk) 13:44, 16 May 2020 (UTC)

Very cool, thanks for the hard work. I think your current build actually does exactly what was desired. Basically it is for use here and I have integrated your widget:Template:FrontFreeChar which is used for: Template:FP-FreeCharacter. Every week the devs are giving free characters, so the purpose of the widget is that once it expires it restarts. As a result, I don't think any other refinement is needed because nothing different happens while it is active. It's just a repeating clock. I mainly wanted it so that the editors wouldn't need to reset it each week and instead can just put the character names in and the clock takes care of itself. That said I find these clock modules strange as they never seem to line up perfectly. For whatever reason, it's roughly 2 seconds fast compared to the in-game clock, but I don't think it's noticeable. The only other weird thing is perhaps the class part. The span I put it in has no class, so I simply added class="example" as a dummy to make it take the proper span. That seems fine though and a smart addition if we use it somewhere else. I also really do like the fact that the clock will adjust itself for daily light savings time. Guess the only way to tell how well it works is to wait for next week. If you feel it needs more and if there are issues I don't see, please feel free to adjust it. Shockbowlocke (talk) 16:27, 16 May 2020 (UTC)

It may be the in-game clock is showing server time instead of the local clock time, so there would be ordinary clock drift involved, and automatic time synchronization with a time server will be affected by ordinary network latency. Basically, good synchronization is hard to do. OOeyes (talk) 22:52, 16 May 2020 (UTC)

Actually, I'm glad you brought up the time difference. I did a bit of research and found a problem with the widget's timing of ticks, namely that JavaScript is only so accurate with running code on timeouts and intervals and is more likely to be wrong on the long side than the short side. I can't really do anything about that imprecision, but I've added self-correction that should prevent any of the error from accumulating between ticks. OOeyes (talk) 12:29, 17 May 2020 (UTC)

Very cool. Thanks, for the effort, OOeyes. It's basically exactly what I was hoping for. Shockbowlocke (talk) 18:02, 18 May 2020 (UTC)

Hello OOeyes!! I wanted to thank you as your work with the clock module has been a big help so far and is exactly what we needed. I have one more request with regards to clock modules that I'm hoping you could help with. It seems the current one only does weekly countdowns; would it be possible to have another module that does the exact same thing, only it resets daily instead of weekly? Hopefully this is a simple request as I'd assume it would be mostly the same as the weekly module but with a few tweaks. Zomoroko (talk) 19:35, 18 May 2020 (UTC)

Yeah, that should be pretty easy. I have a wiki to finish up today, so I might not get to it until tomorrow, but I think this should be pretty quick. OOeyes (talk) 09:01, 20 May 2020 (UTC)

Widget:Repeating daily countdown is now available. OOeyes (talk) 12:43, 21 May 2020 (UTC)

Broken Image[]

Hello!! Hope you are doing well. I am writing because we seem to have a very fickle image on our hands. File:Extra Motivated.jpg It refuses to load properly, and we have tried fixing it to no avail by re-uploading the image and deleting the page, but for some reason, the current version is always invisible. The previous revisions have only become visible after they were replaced by a new version. Please help; we need Gamepedia intervention right now!! Thank you very much.~ Zomoroko (talk) 22:47, 29 June 2020 (UTC)

I think the Extra Motivated.jpg entry in the image cache has gotten borked somehow. I have to bump it up to the dev team for an actual fix as I don't have access to that, but temp moving the file bypasses the broken cache entry, so this should hopefully work until I can get this properly looked at. OOeyes (talk) 08:10, 30 June 2020 (UTC)

I filed a ticket here if you want to keep an eye on progress or add additional information. OOeyes (talk) 08:43, 30 June 2020 (UTC)

Module:Ca edits[]

Hello!! I was wondering if you could add a new exception to Module:Ca. Currently, there are some special cases for Ca, specifically how Tomato & Mimyuu pulls the cards for both Tomato and Mimyuu, and Tomomo (Casual & Sweet Eater) pulls the cards for both Tomomo (Casual) and Tomomo (Sweet Eater). Could you implement a new exception in this same fashion named NoName (Normal & Head) which pulls the cards for both NoName and NoName (Head)? Thank you very much. Zomoroko (talk) 02:00, 15 December 2020 (UTC)

I've added a ttname parameter to {tl|Character}} to handle such cases. IMO, adding such a specific exception would be pretty awkward, and this provides an easier way to handle any such cases in the future. SBEyes (talk) 05:20, 20 December 2020 (UTC)

Thank you!! Zomoroko (talk) 08:00, 20 December 2020 (UTC)

Hello SBEyes, it turns out there is a new problem. I'm not sure what changes you made, but it seems the double-card hovers are no longer working for Template:CCi. This is the other template we use for character cards along with Ca. My bad for not mentioning it before, haha. Here is an example of how the CCi template is used for character cards on the wiki. As you can see, the CCi's for Tomato & Mimyuu, Tomomo (Casual & Sweet Eater), and NoName (Normal & Head) are no longer displaying double-card hover tooltips as they did before, in the same way Ca currently does. Zomoroko (talk) 09:18, 20 December 2020 (UTC)

Honestly, I have no idea how they were working before. the template wasn't using the logic in Module:Ca to figure out which links needed to show multiple cards, so unless suppressing the redirects somehow broke it, I don't know what happened. So, I expanded Module:Ca to output a format that works like Template:CCi. I wasn't able to use the exact same output for reasons I couldn't figure out tonight. I think it should work equivalently, but I'm not 100% sure it won't have an unintended effect somewhere. Also, the other templates have the same problem, except for Ca itself. The quickest fix I could do is the same approach, unifying everything through Module:Ca. SBEyes (talk) 13:10, 20 December 2020 (UTC)

Turns out there was an unintended effect; CCi can no longer be resized. Here is an example of CCi failing to be resized. An example of the syntax being used here is {{CCi|{{{unit}}}|40px}}. It seems the "40px" isn't being applied anymore. Zomoroko (talk) 10:10, 26 December 2020 (UTC)

Ah, so that was the point of the second parameter. It's easy to guess wrong with these cryptic template names and lack of documentation. Anyway, I believe I have it fixed now. SBEyes (talk) 06:25, 30 December 2020 (UTC)

Template:Ci edits[]

Hello SBEyes, I realize that I just posted a new topic here but there is an additional issue which is much bigger that we have been dealing with for some time. This would be regarding our "hover tooltip" templates used to link cards, namely Template:Ci, Template:Ch, Template:Ci2, and Template:CCi. This issue is specifically the fact that if the linked page is a redirect, it will pull the wrong card image in the hover tooltip. This issue has already been partially fixed but only for Hyper cards. Here is an example of the intended behavior after the partial fix: Intelligence Officer As you can see, the hover tooltip pulls the image of the linked card, despite the linked page being a redirect. However, this is only working with Hyper cards linked to a character page, and does not work with cards such as Red & Blue, Ultimate Weapon in the Sun (Original), Doze, or Brown Mushroom. This issue applies to all four of the hover templates I mentioned, not just Ci. If you could help us solve this long-standing conundrum, it would be greatly appreciated. For more examples of each of these hover templates, you can see my sandbox page. Zomoroko (talk) 02:38, 15 December 2020 (UTC)

I'll look into these within the next few days. I'm pretty sure I can sort these out when I get a day when my brain is more functional. (Just been feeling rough the last few days, or I would look at this sooner.) SBEyes (talk) 22:58, 16 December 2020 (UTC)

No problem, thank you for agreeing to look into it!! Hope you feel better soon! <3 Zomoroko (talk) 08:35, 17 December 2020 (UTC)

There were two problems here. The first was just the script following the redirect when retrieving the image, which I've now suppressed. The second is that images on the redirects couldn't be found by the script when they were just bare on the page. I've created {{RedirectTooltipImage}} for adding these images to the redirect page instead, which adds what the script needs to find the image. This is a lot less likely to have unintended effects than trying to set up different cases for redirects and regular pages in the script itself, which I honestly prefer not to touch more than necessary. SBEyes (talk) 05:20, 20 December 2020 (UTC)

The issues were fixed perfectly, and I agree that the implementation of a new template to handle this was a good idea for the reasons you listed. Thank you very much!! Hope you are feeling better. Zomoroko (talk) 08:00, 20 December 2020 (UTC)