A gathering place for Vindictus players of any region or server to get together and discuss the game.


    May 2019

    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty May 2019

    Post by Shippuu on Wed May 08, 2019 2:48 am

    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:


    May 2019 Yu2W3HR


    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:


    May 2019 LTawpdA


    (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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu on Thu May 09, 2019 4:26 am

    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 Nexon was apparently very lazy about assigning their boxes, and a large amount of them are missing box declarations. I will need to build a server-side mechanism that will override my main database to set these values.

    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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu on Fri May 10, 2019 8:45 pm

    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. On my venture to Agrabah, I happened to stumble upon the default color data for every avatar item, back, and tail slot item. 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:


    May 2019 NFp0csC


    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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu on Sun May 12, 2019 8:16 am

    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:


    May 2019 Alg3TB0


    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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu on Wed May 15, 2019 8:53 am

    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:


    May 2019 57N0F8b


    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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu on Thu May 16, 2019 6:51 am

    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.


    May 2019 HquPzcY


    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:


    May 2019 MIZpkmK


    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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu on Sat May 18, 2019 4:05 am

    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.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

    IGN : Shippuu
    Posts : 269
    Joined : 2015-12-17

    May 2019 Empty Re: May 2019

    Post by Shippuu Today at 8:47 am

    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:


    May 2019 FDyBjcN


    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:


    May 2019 0laL3Kz


    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).
    Sponsored content

    May 2019 Empty Re: May 2019

    Post by Sponsored content


      Current date/time is Mon May 20, 2019 3:24 pm