Home
December 1
I expected to make this post several days ago, but tooltips came out of nowhere to deal a devastating blow. I'm quite happy with the end product, but I didn't realize their issues were so intricate. Here is what has been done since the last Dev Log:
Overall Site
- Completely refactored the code for how tooltips are placed onto the page.
- Implemented a possibly final background image for the site. This took a surprising amount of trial and error.
- Made some CSS adjustments so that the background image can now be tinted by the user's color theme.
- Reverted the background texture pattern to CSS instead of the more efficient image; it wasn't workable to make the image compatible with user color themes. The texture will now take on the color of your border color.
- Adjusted the color options available to user customizable color themes, and recategorized them a bit. A new color value was added, to set the tint of the background image.
- Adjusted the scaling code that calculates the width of the main page content body to take into account the aspect ratio of the viewport, so that it is not excessively wide on ultrawides/super ultrawides.
- The Settings prompt now has a constant size, so that it doesn't shift every time you change tabs.
- Added a setting to change item tooltip alignment to the hovered element; I didn't originally expect this to be available on release, but now it is.
- Fixed an oversight where the labels for inactive tabs in windows were using the wrong color value for their text shadow, causing color themes to not change them correctly.
Gear Params Prompt:
- Selecting the "Default Stats" preset with Milletian will now use the mid stats they drop at, and min stats for Ardri.
Profile and Loadout modules:
- Unified the CSS of the Profiles and Loadouts tabs, as much as possible. This ensures that both look the same, and that editing them is faster. The CSS file is also slightly smaller now (by about ~7%).
First some notes on the smaller things, before getting into tooltips:
The backgrounds on the site were actually something I had left unchanged from v2 up until now, for the most part. I switched the CSS pattern on the center column to a tiled image since that seemed to load faster, and I switched to a placeholder background image for the sides to better support more resolutions. As the site approaches the point where it can go online, it was time to finally deal with these, and make sure they were compatible with the color themes. I expected this to be particularly challenging for the images on the sides, but it actually wasn't.
Regarding the center column texture, it just wasn't possible to recolor an image at all. I tried background deletion and some other tricks, but it just couldn't produce a good result. As a result I have reverted it back to CSS as it was on v2, which instantly made it compatible with themes. I was able to do something a bit fancier for the images on the sides.
The first noticeable improvement is the resolutions the new images can fit. Anything up to 5120x1440 will be covered with no issues whatsoever. It hasn't been tested on 4k yet, but I expect the result to be acceptable. To incorporate color themes, its actually a pretty simple trick. The image is grayscale and has no color of its own initially. I am then using a CSS property called mix-blend-mode to tint it with the color set in your color theme. Due to how the color applies you will need to use a brighter shade than on the rest of your theme, so it now has its own color selection when editing your theme. The result looks pretty good.
As an additional matter, I can respect the opinion of those who do not want either the center column texture pattern, or the background image at all. In Site Settings, you will be able to individually turn off either or both of them. Each option has also reserved space for alternate textures or alternate background images to be selected, but none will be offered on the initial release.
The real monster that had to be tackled this week was tooltips though. It started with a simple note in my list, that if you set your text tooltips to appear above the hovered element, they would appear below the element. I identified it to be a hard-coded preference for appearing below or to the right of the hovered element, and expected it to be an easy fix. That was several days ago.
As I investigated the issue with text tooltips, I became aware that item tooltips had their own (different) alignment issues. They could get pretty tall, and easily clipped off the top or bottom of the page. Rudimentary code to keep them inside the page bounds often resulted in them overlapping the hovered item, which was not ideal. At the same time, I knew that text tooltips had code that handled this exact issue much better, so I began a refactoring project to merge the two code blocks into one and unify them.
As it turns out, this is hard to do when there are 16 available positions the item tooltip can align to, rather than the 4 that text tooltips use. I initially started with defining a list of fallback positions for every tooltip alignment to use, and it would try them one by one until one fit. This was a carefully ordered list of 15 fallbacks for each of the 16 positions. It felt so obviously wrong to be doing that I didn't even finish this, and started to refactor the unified code again.
The end result is that the new tooltip code is not unified, and that there are still two separate code paths for them. This is because they function too differently to make sense to unify. The alignment options have unified now, and text tooltips can now be set to any of the 16 available alignments. Previously, text tooltips had four alignment options (North Centered, East Centered, South Centered, and West Centered), and item tooltips had 16 options (N/E/S/W non-centered, NE/SE/SW/NW, and the 8 positions between those, NNE and etc). The non-centered versions of N/E/S/W have been replaced with their centered versions, for reasons that don't make sense without before/after images. Unfortunately I don't have any, so all I can do is assure that they were redundant in the new setup.
The centered options have their own set of code that works like this: The default option for text tooltips is East Centered, so when you hover on one, it will appear to the right of the hovered element, and centered to it so that the center line of both the element and tooltip would be in a straight line across the page. If it cannot appear to the right, it will first try to appear to the left. If it cannot do this, it will appear below the element. If it fails that too, it will then try above.
For the 12 non-centered alignments, the code is far more intricate. You can imagine that there is an invisible ellipse drawn on top of every element on the page. Your alignment setting chooses where on this ellipse your tooltip would appear to hang from it at. For example, if your alignment is Southeast, your tooltip would appear to the bottom-right of the hovered element, with its top-left corner touching this invisible ellipse at the Southeast "edge" of it. If the tooltip cannot fit here, it will slide itself around the ellipse until it finds a location it can fit in, and it will appear there instead.
In the rare situation that no point on this ellipse is workable, such as for very tall tooltips appearing in the center of the page, a fallback is engaged. The code takes the position on the ellipse where the least clipping occurred, and places the tooltip there. Then some extra checks occur to push the tooltip fully onto the page, so that none of it is off-screen. Finally, a check is done to make sure the hovered element and the tooltip are not overlapping. If they are, the tooltip will be pushed right or left of the element so that neither are obstructed; the tooltip will go right if it can fit there, and left if going right would send it off the edge of the page.
...It may have sounded like I nerded out a bit there on tooltip code, but I can assure you, there is actually even more going on that I haven't mentioned to keep it somewhat simplified.
With regards to what I still need to do, lots of things exist in the code but still aren't actually connected into Site Settings to be adjustable, so that is what I will be working on next. I've also become aware that I forgot to add the effect text for artifacts, and I need to make the Armory save your selected character instead of defaulting to Fiona on every page load.
I am mulling over the possibility of re-implementing a "resume" feature like the v2 Armory had with #last, but I am not sure how viable it is with the way v4 works. It is something I want to do, but it may not be part of the initial release of v4.
