May 2019

May 8

Eira has been fun, and I will probably still be pulled back into the game a fair bit this month, to recover my gold after buying a Nature's Breeze set and crafting a new Dullahan Revolver for Eira, since the freebie isn't worth reforging.

Yesterday marked my continued work on the Armory, and another look at the icon problem that has been bugging me. Fair warning, I've made the realization since April that I've been holding back too much on actual technical details of what I've been doing, and will be making an effort to correct this in future.

As I resumed trying to correct icons, I continued calibrating values on my code, trying to pretty much blindly stumble into something passable enough. After a while at this, in stepped Florrick, and eventually the answer was found. My original implementation was based off the code HeroesDB published when they went offline, and I was far from experienced enough at graphics code to make major changes to it myself.

Basically, the HeroesDB method decided which color to apply per pixel, based on the dominant shade of Red, Green, or Blue there originally. My changes from there stemmed on boosting the brightness multiplier it used to generate color, resulting in my icons being brighter and more vivid, thus slightly closer to reality. This implementation was apparently completely off the mark on how to actually do it.

The actual method seems to be to treat every pixel as at least partially every color on the item, with values based on the strength of the original Red/Green/Blue shades there. I admit that I still don't understand why this fixes the brightness for solidly colored areas, but it seems to, so I am not going to question it.

I setup a comparison image based on my last Dev Log image, to show off how significant the difference is:





The image on the left is the color corrected version, and the image on the right is cropped from that Dev Log's image.

As an added bonus, here is an image of equipment my Lann will never have:





(Bracelets are not included because the sockets cannot actually be defined client-side yet, please conveniently ignore that for now.)

With this resolved, the server-side portion of icons is now fully stable and accurate. The client-side is still very much questionable though. In particular, items like Wings, Tails, and locked color vanity items are still erroneously showing they can be dyed, causing visual bugs. There is also a separate issue where some items are showing the incorrect amount of color boxes, for some reason.

My next work will be to correct those issues to fully smooth out all color handling, finishing this part of the Armory completely.

May 9

Ok, I've figured out the inconsistency issues with color boxes and item coloring. Back/Tail slot items failed for one reason, and outfits failed for an entirely separate reason. So far, I have fixed neither issue. Back/Tail slot items are erroneously showing as grayscale because I need to implement a way to force-set their color boxes to the colors Nexon uses. Outfit items failed because of missing data, essentially. I will need to build a server-side mechanism that will override my main database to set these values on fixed-color items.

Today isn't wholly a defeat though. I previously mentioned that I finished the server-side part of item icons. As of today, there isn't one. To massively reduce load on the server, I have moved icon recoloring to the client-side. This will also reduce bandwidth usage in general. Your browser will cache the base copy of the icon, and then no matter how many times you recolor it, it will never need to retrieve another copy of the icon.

In the process of testing all of this color box stuff over the last while, it has made me realize that my current setup for handling color box inputs is actually pretty inconvenient. It also happens to not support the Dress Skill ability to have multiple sets of color boxes on individual avatar items.

To address these issues, I will be taking the color box inputs and splitting them off from the Properties tab of the Gear Parameters Prompt to their own Colors tab. This will allow tabbing between inputs to go smoothly, and also allow me to add a "Favorite Colors" section below them. Through the "Favorite Colors" section, you will be able to more quickly select colors for item color boxes. The exact means I will make this work is yet to be determined, it will need experimentation.

I will likely be working on this while trying to gather color data from the community for the Back and Tail slot items. I will probably make a Google Sheets file to gather these in a few hours.

May 10

Today had a few minor fixes, as I corrected some things that were bothering me while working on icon issues. The width of item tooltips have been reduced, to more closely match ingame. Eira no longer shows up as Miul on character requirements. Kitty brooches now correctly say "Can use all forms of trade"; apparently only NX tab items are affected by the MP-only restriction?

On the main focus, item icons, I have good news. I have filled in the default color data for every avatar item, back, and tail slot item (I believe). In implementing these default colors, I have achieved no less than three things. First, no items have color boxes erroneously saying "No dye" anymore. Second, Back and Tail slot items do not have bugged icon colors anymore. Finally, it looks quite a bit more impressive on all of the Outfitter sets. Check it out:





When equipping these items, instead of defaulting to full gray, they will continue to use these colors until manually changed.

My next task is the one I thought would be first; I need to overhaul the UI for inputting colors.

May 12

I've been working on the Colors tab of the Gear Params Prompt, mostly on the "Favorite Colors" feature. Moving Color boxes to their own tab surprisingly only took about 15 minutes, complete with designing and adding the Favorite Colors block. Unfortunately, this only included design, not functionality. While the color boxes continued to work immediately after being moved, due to the nature of the Armory v4 code, working out how favorites should work hasn't been so easy.

Mentally I have been thinking of it as a three piece problem:
1: Users need to be able to add colors to favorites, by some means.
2: Users need to be able to quickly set any color box to one from favorites, by some means.
3: Users need to be able to delete colors from favorites, by some means.

The challenge is how to do these things in a way that is intuitive or otherwise clearly indicated. Following my feelings on this, I decided to make the control method for this a drag and drop functionality. I will probably redundantly add a single click to activate, then click to apply, functionality after I get the current parts smoothed out. Thus far, the design looks like this:





Of note from previous, including an iteration between Dev Logs:
* An item icon was added to the Gear Params Prompt; it updates in real time as you adjust the color box values
* Hovering on color boxes now switches your cursor to the pointing hand icon, to hint you can interact with them
* A blue text info line was added to "Favorite Colors" to hint to the user to try dragging color boxes
* The favorites block will glow when dragging a color box, to indicate you can drop it there
* The color boxes beside the inputs will glow when dragging a favorited color, to indicate you can drop it there

I have yet to figure out what means I want to implement for users to delete favorited colors. I also have yet to implement the ability to sort favorited colors via dragging them around. For the former, I have absolutely no leads on an ideal way to do this. For the latter, I am waiting until I solve the former; I don't want to increase the complexity of this until then.

In regards to saving favorited colors, this has actually arisen a separate large challenge. Currently, saving works via localStorage, a rather fancy browser feature that has been around for a few years now. The intention is for this to save server-side to your account, but the exact method to do this eludes me.

Most of the complexity in this comes from the possibility of a scenario such as a user using the Armory as a guest for a long time, and then making an account. I don't have a way to sync over localStorage settings, so this user would find that upon registering and logging in, all of his saved data is no longer being loaded.

Conversely, a problem arises in a scenario such as someone not logging in for a week or two, and then they log in. Their localStorage data is now newer than their account data, but directly writing it could cause large amounts of data loss. These problems are on my mind, and I don't think I have the experience to solve this at the moment.

This problem, and the lesser problem of figuring out how to delete saved favorite colors, remain my focuses to work on.

May 15

As of now, I now feel fairly confident that favorite colors are fully functional and working. I've thought about possible trade-offs of the current implementation, and I feel like they are currently acceptable. So, to go down the list on things since the last Dev Log, let's start with an image of the tab in its current state:





To add a color to the Favorite Colors list, just drag the color box into the space, it will light up when you start to drag the color box. Additionally, color boxes change the cursor to a pointing hand when hovering, to hint they are interact-able. To apply a favorite color, you drag it from that block and onto the color box of the slot you want to change. This is where I left off on the 12th.

To delete a color from the Favorite Colors list, drag the color box off onto the main page, and drop it. To sort and rearrange your favorite colors, drag them into place, and this order will be remembered. A delete button or icon would have felt too out of place on the prompt, so I am making an effort to not add one unless it proves necessary for usability. Sorting has no cue that it is possible, but I would suspect/hope that people might just try to do it without thinking about it and find out that it works.

As well, visible in the image, you can see a hover tooltip for what color the box is representing. This actually ended up needing a refactor of the tooltip code, embarrassing as that was. I had a function that was going renegade due to events bubbling up the DOM (default behavior), so hovering on the color boxes hid the tooltip at exactly the same time it was shown; rather annoying. Between that and my tooltip being designed only for items, it was a headache.

First, my ToolTip class now gets to exclusively own two tooltip elements, instead of just one. Hopefully this doesn't become three later. Each element that can be hovered now reports what type of tooltip it is requesting, so that it can be served the proper one. Separately, for future possibilities, I have refactored the code that aligns tooltips to be part of my general toolkit of functions. I have a feeling the ability to align elements based on others will prove useful for several things. Especially with that ridiculous code I wrote for v2 to align tooltips to any of 16 positions based on the item icon's location.

With colors completely done, I now want to fully finish off my item icons. I haven't fully ported everything from when they were server-side, which will hopefully prove to be not too challenging. Alongside that, I will also be creating apparently ALL of the code handling item fusion. I was surprised to discover today that while I have notes in places that code needed to be wrote, there wasn't a single line of actual code for it anywhere. This probably isn't going to be a one day job, given how much data fusion items need to be able to tack onto items.

May 16

The me of yesterday underestimated the me of today. ...And of the convenience of the current v4 Armory code setup in general, mostly. Item Fusion is complete and stable.

The biggest challenge turned out to be the method of selecting an item to fuse your base item to. I *really* didn't want to have to make a special prompt to drag and drop items in to fuse, and I had no sane way to do it with the tools I had. So I made a new one: Enter the AutoComplete class. It loads off a copy of the items from the Item List module, filtered down to only items compatible for fusion.





After each character typed, the AutoComplete input will search for all matching items, and show them in a list, so long as there either are results, or are less than 16 results (for list height reasons). Then you just click the item and it's set.

The work on tooltips has already been done for the requirements text to correctly merge the requirements of the stat item and the appearance item, plus one other convenience change:





I have removed the redundant rarity label, and replaced it with an indicator of if the item is fused or not. If it is fused, it will say what item it is fused to the appearance of.

As it so happens, nothing else on the Properties tab actually works, so rigging these up is my next objective. From there, it's on to making bracelet sockets work.

May 18

As has been usual, I forgot something I needed to do before moving on. Slightly less usual, I also encountered a roadblock. I forgot that I have absolutely no handling for items changing icons/properties between male and female chars, but I can't work on that for just a little longer yet. The roadblock I hit was that the code for the Gear Parameters Prompt had gotten quite messy. To an extreme extent.

Most of the work since the last Dev Log has been refactoring the prompt's code. The param prompt alone is a third the size of the entire Armory currently, so this wasn't exactly a small task. It is done though.

Refactoring is the process of taking existing code, and rewriting it or reorganizing it to be cleaner, clearer, or more efficient. This job was a little of all three. The params prompt had one function that told it to update all of the pages, and four subfunctions that updated each page. Those 5 functions have now become 23. The number is higher, but editing any individual part is now profoundly easier. The other 23 functions on the prompt also received significant tidying up and streamlining.

Setting durability on items now works, and items that do not have durability no longer display it. I also fixed a bug where colors would hide when the item could not be dyed, but would never return again after. I haven't gotten around to coding bind status or unbind count yet, but those will be my next tasks. I have created a stub to fill in for bracelet sockets later, but it does nothing yet.

I really want to be able to mark off item icons as done, so once I get bind stuff done and settled, I am going to go back and fill in functionality for the gender differences. I also need to port over some of the server-side functionality icons previously had, such as showing text on the icon, and using non-default backgrounds.

May 20

In the process of adding functionality for trade states/unbind counts/failstacks, I hit yet another roadblock. The code for item tooltips need to be refactored, just as the Gear Parameters Prompt needed it. The reasoning is pretty much exactly the same, so I won't waste post length rehashing it again. It didn't take as long this time around though, this class was significantly smaller code-wise.

The work on trade states, unbind counts, and failstacks is completely finished, as well. When an item is unbound or bound, you will be able to set its remaining Unbind Count. When an item is restored or reforged, you will be able to set its Failstack Count. Unbind Count displays as it does ingame, so I won't bother showing it, but I did make a format change to the display of Failstacks:





I didn't like it taking up a third line of text, or the overly lengthy confusing way it was worded, so I replaced it with my own text. It also happens to show the progress toward guaranteed success, just because I could.

With those done, it's time to work on the ability for gear to recognize the character's gender and swap icons appropriately...is what I would say if I had not already done it. Behold:





With that, I am getting very close to completely done on icons. Color boxes continue to be a troublesome thing though, as you can actually see in the first image. The Dullahan Battleshade's box 3 is not being shown as present, for some reason. I need to go through every weapon and shield and fix these on a case by case basis, but I have already done the job for armor, as part of getting icon swapping stable.

Once that is fixed, I will begin efforts to port over the parts of code from the server-side icon generator that haven't moved to client-side yet, such as non-default backgrounds. Once that is ported, icons should be 100%, unless I have forgotten something.

If icons indeed hit 100%, I can finally start working on bracelet sockets. I purposely included them in the first image to show how nonfunctional they currently are; even the icons don't work right due to it (though if the sockets existed in the data, the icon would include them already).

May 22

As of fairly early yesterday, icons were completely finished off. All of the functionality the Armory uses now and might need later is now there and works. From there I begin coding in the Sockets tab on the Gear Params Prompt. I posted numerous images in the unofficial discord while finalizing designs, but as of today, it is done. Bracelets now work.





Here is an example of a default rolls Gold Bracelet, exactly as it is when you open the prompt and immediately apply changes. Before getting into the Sockets tab itself, I want to call out one other change that happened during this time. This bracelet tooltip shows that the item is "Rare". A few logs ago, I showed off where I had replaced that space with a label for what the item is fused to. As of now, if the item does not go into a weapon/armor/shield/focus slot, it will show rarity as it did before.

With that callout done, let's look at the Sockets tab:





When the prompt is open, it will default fill sockets in the order of "Diamond, Ruby, Emerald", until it runs out of sockets. Gold Bracelets always pre-define theirs as "Diamond, Sapphire, Ruby, Emerald", since it never changes.

Additionally, all gems will be pre-defined as the highest applicable tier on the bracelet. As seen in this image, it has chosen Superior gems, although I changed the Diamond socket to Fine, to show off another feature. The left-side tabs reflect the gem type and tier of each socket, and update in real time as the settings are changed. The item icon itself does too, incidentally.

At the time of that image, I had never actually left that tab, but you can see that it is showing stat differences. All gems with unspecified stats will default to their average rolls in all stats. This should make it very fast to approximate stats with bracelets you don't yet own; or just to get close enough for someone not caring about exact to the individual point stats.

Moving on to the tabs to edit the rolls of the gems...





There's nothing actually special about this one, if you've seen the rest of the prompt. Each stat gets an input block with a label and a display for its minimum and maximum value. If you enter a value outside of the valid range, it will be corrected to be within bounds. When you click out of an input, the changes will be applied to the temporary copy of the item, and the stat differences with that new roll will be displayed.

With bracelets now done, the prompt itself is actually nearing 100% completion. Some functions still need tidying up work in places, but the only real remaining job is support for additional dye sets on Outfitter items. This is going to be my next job, just to completely finish off the prompt and move on to the other Armory modules.

May 23

Today's log is less action packed, but I didn't want another Dev Log of actual stuff being done to have to open off with explaining how plans changed. Tentatively, for now, I have axed plans to support extra color box sets on outfits as beyond the scope of the Armory. I am still very much on the fence about this, so I may well decide later that I *do* want to implement them.

In this case, the problem actually isn't in the implementation. Like with setting composite materials between blue, purple, and orange mats, the primary complication is the interface to do it on. Most of adding the extra color box sets would be quite trivial. I'd change the Colors tab to have sub-tabs like Materials and Sockets use, with one set of boxes per tab, numbering the tabs 1-3. The problem comes in at selecting the active set of colors. There isn't any place to do it, short of making a fourth tab for that one single option; I do not like the thought of this.

Instead, I've decided to drop plans to do it. What this now means is that equipment is 100% complete, the Gear Params Prompt is 100% complete, and item tooltips are 100% complete. This is a significant milestone for the v4 Armory. Equipment working can be considered the core, most critical, piece of the whole project. From here, I can now begin adding the actual functionality that people recognize as the Armory. ...Almost.

My next module that I had set my eyes on was the ability to save Character profiles. As I went to manually edit my save data to add the tab to my page, I realized that I had a more immediate feature to implement. The Settings Prompt.

On the original v2 Armory, settings were all over the place, in a disorganized jumble. On the v4 Armory, aside from the Titles module for rapid access, you can see in all of the Dev Log pics that there are no options on any of the tab's pages. This is because from the beginning the plan was to have a centralized window to manage all settings for the Armory. This includes a tab to add and remove other tabs from your current Armory view.

Currently, you can move tabs already on your Armory view from one window to another, or even to its own new window. But in a case like this, where the tab isn't on your current view, you cannot reach it at all. Enter the Settings Prompt, where you just go to the page of all Armory modules, click the button representing one, and its summoned to right beside the button (or removed from its current window if it was already present).

It is looking promising that I might actually have something to show regarding this new prompt as early as tomorrow, even if it's mostly empty on every other tab. The tab to manage Armory modules is already half done.

May 26

Obviously, the 23rd's Dev Log proved to be overly optimistic. I slacked off on the 24th, and to my credit did get the functionality I mentioned working on the 25th. However, it was unable to save due to the outdated way v4 is handling window data. I set out to fix that...and ran into an extremely complex problem. All of my UI and save data code is incompatible with each other, which means I need to refactor and unify three objects/classes that work in totally different ways.

At this time I still have no idea how to go about this, so ETA unknown, hopefully soon.