June 2022

June 1

Progress continues. Here are the checklist items I have resolved since the last post:

Overall Site:

• Check over the functions that handle rescaling the Armory, and remove obsolete code that was used to rescale dynamic icons. The Armory only has static icons now.
  
• Investigate the code that calculates the height of the Armory page.
  
• (NEW) Fix bugs in the code related to changing the icons of armor by char gender.
  

Base Stats module:

• Some ongoing weirdness with base stat conversion needs to be addressed.
  

Gear Module:

• There is no feature to copy an entire set to another Set tab.
  
• (NEW) There is no feature to delete an entire set all at once.
  

Gear Params prompt:

• Code needs to be added to control where this appears when opened, and a toggle needs to be added to Settings to either always appear where it last was, or to always align to the item right clicked.
  
• A spacing check needs to be performed when changing tabs, since its height can change. It needs to relocate itself to not go off the top or bottom edge of the screen when this happens.
  
• (NEW) All select lists need to be forcibly closed when the prompt is closed.
  

---

Firstly, as you can see, new things keep popping up as I go. I expected this, but so far everything coming up has been minor. To comment a bit about some of what I've been fixing:

The issue with calculating the height of the Armory page was a curious one. If you are familiar with CSS or web design, you might be wondering why I even have to do this manually in the first place, since this is handled for you. In the case of the Armory, every window is set as position absolute. Due to this, the page lays everything out as if they aren't there; as far as it is concerned, the page is empty. This sounds inconvenient but it is actually necessary for the page to not go insane when you drag windows around. This lets them be their own little islands that don't influence anything else, so that when you drag one it doesn't move any other window.

Unfortunately, it has the tradeoff of needing some extra maintenance when working with an entire page full of elements set as absolute. For the page body to have any height at all, I have to calculate how tall the page should be every time the UI is interacted with. I have to determine how far down the page the lowest window's edge is, and then set its height to be just a bit more than that for spacing purposes. In the case of this calculation bug, the issue was that the Storage window starts off showing no slots until it loads your saved data from the server. This means when that bottom edge check is performed, the window is a lot shorter than it should be, which throws off the final result if it happened to be the window furthest down on the page. It was the only tab that didn't reserve space for its contents so to speak, but it does now.

While a more concerning error, the Base Stat module's issues turned out to be some code I missed converting, so it wasn't filtering out Critical Damage gained from STR/INT, and etc. This was trivial enough to fix.

As a general update, these modules are 100% (or so I believe right now) and need no further work:

• Gear Params menu
  
• Item List
  
• Item Storage
  

---

Here is the remaining to do list as of today, since this is a new thread:

Overall Site:

• The site is account-based, yet there is no method to create an account currently. I have help on this one that will probably resolve this for me. I can't say more right now.
  
• Another pass needs to be ran to make sure all references to outdated code from pre-rework have been removed.
  
• Another pass needs to be made on every gear category for every character, to make sure nothing is missing. At minimum a LOT of outfits are.
  
• The server-side still has some placeholder functions that are terrifyingly insecure and need to be replaced with safe sensible code.
  
• Obsolete files/images need to be removed from the site directories.
  
• Attempting to drag scroll bars with your mouse does nothing right now, the functionality is missing and needs to be implemented.
  
• I don't have a name for the site. I will not be continuing to use the old one.
  
• The Settings window exists but is very incomplete/placeholder-ish.
  
• A notifications tab exists on the main nav bar, but it currently does nothing.
  
• Overall polish is needed to make sure the user isn't overwhelmed with windows and tabs at first sight.
  

Tooltips:

• These currently don't support displaying expire dates or expiration times on items.
  

Base Stats module:

• (NEW) Base stats are starting fully undefined, which makes stat calculation wonky in regards to Stone Skin and things like it. They need to have default values.
  

Gear module:

• There is no feature to copy a single item fron one set to another.
  

Overview module:

• The level input doesn't blend in properly with the rest of the block, and needs some HTML/CSS work on redesigning it.
  

Battles module:

• The functionality of selecting battles is shaky and not distinct at the moment; Pre-rework you opened a battle and then selected an enemy from it. The UI was designed for that, and needs to adapt.
  
• The list of battles needs to be moved to be inside of a scrollable panel. The height of the tab is currently inconsistent depending on which group of battles you are looking at. Not ideal.
  

Power module (Concept phase at the moment):

• Counterforce damage % is displayed but isn't calculated currently.
  
• "Relative Damage" between your set vs a comparison set currently uses an animated meter to show the difference, but its animation needs work or removal.
  
• The tab needs to display which battle is being used for the comparisons. This is set in the Battles tab and can be seen there, but the Power module should also show it.
  
• I need to do another pass on deciding which stats are worth displaying on this.
  
• It was planned to be able to compare your current stats vs either another numbered set on the Gear tab, or with a pre-defined Baseline set of stats, of varying gear progression. I've decided against this to streamline it. Instead of arbitrary baselines, the pre-defined options will now be QB minimum stats, capped stats, fully maxed Milletian, and fully maxed Ardri.
  
• There is a UI display for which Baseline you are comparing against (whether pre-defined or a numbered set on the Gear tab), but it currently doesn't actually do anything.
  

Profiles module:

• The Filter/Sort buttons exist on the tab, but they don't do anything.
  

Loadouts module:

• The Filter/Sort buttons exist on the tab, but they don't do anything.
  
• I need to update the sprite image that has all of the icons used when viewing Loadouts on the main list, it has nothing newer than Belle's axe.
  

Missing content:

• There is no module to handle creating shareable links for others to see/use.
  

June 1 #2

So I've decided that instead of just listing stuff broadly without going into detail, I'd post more frequently and give changes more detail, so that interesting stories don't get lost.

Here is what I've completed since the last post:

Gear module:

• There is no feature to copy a single item from one set to another.
  
• (NEW) Add hover tooltips to the Delete and Clone icons, to explain what they do and how they work.
  

This brings the Gear module to 100% completion*, and the fourth to reach this point. That asterisk is because I'm a bit unhappy about the spacing of the text for the 10 page tabs, so might fiddle with the CSS to fix it at some point, but it is extremely minor.



Like in v2, there is a button to delete everything in the set, and a button to copy everything in the set to another set tab. A primary concern here was avoiding consequences for accidentally clicking either of these, and being forced into an unwanted effect. As such, both have methods to cancel out of the action, and the Delete button effectively requires confirmation.

You can see in the pic what the setup is for the Clone button, so I won't go over that one. For the Delete button, I had to be a bit more inventive. Functionally, you can just double click the button and it will clear immediately, no problem. However, if you just accidentally click it once it will change to a red color to indicate that it is active. Clicking it while it is red will clear the entire set. If it sits active and unclicked for 5 seconds, it deactivates itself as if you never clicked it.

Surprisingly, the hardest feature to add to the tab was the ability to clone an individual item from the current set to another. The process is exactly the same as in v2, just drag the item ontop of the tab and drop it. For the code to actually handle doing it is another matter entirely though.

Each set also stores a copy of its own full stats so that it can be more quickly referenced by itself and other modules when running calculations. For this reason, the Armory internally does not support equipping items to sets that aren't the currently "active" visible set. As such, both cloning features do some rather funny workarounds where they change the active set briefly until the item(s) are cloned and the stats for the set recalculated. It is designed so that all of this is invisible to the user, so that the user isn't surprised by their stats or damage meter briefly flickering to a different value. As a benefit of this weird functionality, if you are currently comparing to that set, the stats will update instantly without having to swap to it and back.

My next focus will be on the single remaining issues on the Base Stats module and the Overview module. Bringing these to 100% will finish off all of the most important modules, ensuring my base code is solid as I move outward to the less essential modules.

I've also noticed only as I uploaded the image for this update that Paint is doing something strange to the colors of my images, and making them look desaturated. I have no idea why it is doing this, or what I could really do to avoid it.

June 3

Here is what I've completed since the last post:

Base Stats module:

• Base stats are starting fully undefined, which makes stat calculation wonky in regards to Stone Skin and things like it. They need to have default values.
  

This turned out to be a more annoying thing to fix properly than I expected. I figured I would hammer out this one and the CSS on the Overview tab in around 20 minutes and be moving on. This turned out to be a simple problem with some unexpected wrinkles.

So the gist of it was that Base Stats would start with all values pre-filled as 0. So as you started filling in values, starting with STR (as it is top-left), you'd put in something like 1388 STR and tab over to ATT to fill it in. But if you looked at the Overview tab while doing this, you'd see that you have 1388 STR and 0 ATT. This is because the Armory is doing some processing to the base stats you enter to get the actual base stats (HP without the effect of WIL, etc). For lack of the detail that Simulation mode on the Armory would offer, it has to blindly trust your entered base stats. This means that 0 ATT base must mean that your actual ATT is 0 with whatever amount of STR you entered, so it would contrive a negative actual base ATT to get there.

This would be highly confusing to users, and likely result in lots of bug reports, so I definitely had to solve this. I knew that I needed to have some form of pre-defined base stats that would be automatically loaded on page load, but I needed to make sure that this didn't lead to any kind of confusion either. I spent a few hours yesterday while doing other things debating possible routes and the needs of each to make them work right, if they could.

The solution I landed on was to go with an imaginary set of base stats for a Lv. 110 character with all skills maxed and 0 titles/Redeemers/etc. Just something to be vaguely in the ballpark of plausible. To ensure that the user couldn't lose track of stats they had entered vs stats they hadn't, I edited the code that builds the HTML for the Base Stats tab to no longer auto-fill the inputs. Instead, it sets the default stats as placeholder text. On inputs, this is the text it shows before you start typing anything, and vanishes once you've typed something into it. This allowed them to be visually distinct, but still informative as to what was going on stat-wise.

The final result looks like this:


Balance is a field I have filled in myself with a 0, the others are the defaults. As you can see, it is pretty easy to tell them apart. With this, I'm happy with the Base Stats module and it joins the list of completed modules. Next is the visual adjustments to the Overview tab, hopefully nothing weird surprises me on that one.

As a last note, it turns out the image desaturation is imgur's fault, not Microsoft Paint. I checked the file size and the hosted image appears to be the same size in KB, so I still have no idea why it is happening.

June 4

Here is what I've completed since the last post:

Overview module:

• The level input doesn't blend in properly with the rest of the block, and needs some HTML/CSS work on redesigning it.
  

Power module:

• Counterforce damage % is displayed but isn't calculated currently.
  
• The tab needs to display which battle is being used for the comparisons. This is set in the Battles tab and can be seen there, but the Power module should also show it.
  
• I need to do another pass on deciding which stats are worth displaying on this.
  

Miscellaneous small things:

• Fixed an index off by 1 issue on Loadouts
  
• Realized battle selection on the Battles module was fine
  
• Changed the CSS for radio inputs slightly
  
• Split tooltip alignment settings to have a separate one for item tooltips
  
• Adjusted the code that aligns popups to handle any element, not just those pre-made for tooltips/main windows; this was done by providing args for parent position offsets
  

As you can see, working on the Power Module has sent me on no small amount of detours. The options grid for selecting baselines turned out to be enormously larger than my initial hopes, which actually necessitated new functionality to ensure that this gigantic pop up didn't go off the side of the screen when opened. I couldn't just reuse the code tooltips and the Gear Params prompt used as it was since the circumstances were different. Those were directly in the main content body of the page, with nothing inbetween. This grid is inside of a movable window, so its reference point is different. I had to add support to the align function to allow it to be told an amount of X/Y to compensate placement by, to basically subtract away a parent window's position and have a neutral reference point again.

In testing errors on this as I wrote it, I realized it didn't make sense for item tooltips to share an alignment setting with the rest of the things on the site. Tooltips are usually tall but not very wide, so they are well suited to appearing to the left or right of an element. Most all other tooltips are not very tall or wide, and so they can align in any positioning. So those are now split. Item tooltips will remain in their default orientation of ESE (East-southeast), and all other tooltips will now default to EC (East, centered). My ridiculous aligning function now has 20 possible positions, with the inclusion of centered versions of N/E/S/W.

In cases of particularly large windows opening, such as this options grid, user settings will have to be disregarded, as the likelihood of being able to honor it without overlapping the hovered element is very low. Instead, the code will check possible positions one by one until it finds one the block can open in without significant disruption, and will open it there. EX: If you have the Power tab open at the bottom of your page, it will open above the button. If you have it toward the top of your page, it will open below the button. If it cannot fit vertically, it will open to the left or right of the button. If it can't fit in any direction please buy a modern monitor, but it will fallback to opening below the button.

Here is the current state of the Power module, possibly still pending changes:



The baseline options are still almost completely nonfunctional. The options can open and close, and you can click the buttons to toggle which ES/infusion slot set you are using on the set, but you can't change your selected baseline, nor would it know how to handle that even if you could at the moment.

The radio buttons to toggle slot set are for a feature that I still need to implement to the Armory. In concept, since you can have three gear sets in Vindictus, each with its own slot configuration, I wanted the Armory to be able to match support for that. It is a very high priority to me that the Armory be able to allow you to min/max an enchant/infusion slots configuration for more than one battle at once, if you wanted to do so. With that said, no trace of this system exists at the moment nor have I even drafted a plan to how this could work. Problems for later, finishing the Power module comes first.

On a very tiny, in comparison, note on the Power module itself: I did decide to make one change to the shown stats. "Action Duration" has been cut in favor of a placeholder for "Taken Damage". Action Duration will likely be shown in the hover info for "Damage Rating", but the primary reason it was cut was that getting info for exception cases that don't use normal speed scaling will be very different from here on. Not impossible, but I won't put a value in prominent view that might be wrong for later characters. "Taken Damage" is taking its place since this is still very much a calculation I want to solve, it is so close. For now it is nonfunctional and will be on release, but it will be a high priority thing for me to solve once the Armory is online and stable.

June 6

Here is what I've completed since the last post:

Miscellaneous small patches

• Set up the page events so that whatever window you are interacting with will have a higher Z-index than the other windows, and thus appear above them. Mostly for cases where they have pop out options, such as the Power tab.
  
• Fixed an issue with profile loading where Base Stats were not visually loaded into the base stat inputs.
  
• Fixed an instance where the spacer on the Gear Params prompt would appear on artifacts. This would break the alignment of enchants, the exact opposite of what it is supposed to do.
  
• Fixed a clash between old server-side data validation and the new save formats that made it impossible to save changes to Loadouts.
  
• Removed Luck from Base Stats, I have no idea why this survived the recent pass where I removed PVP ATT/etc.
  
• Fixed an inconsistency where the inactive infusion slot would show a "None" infusion in the positive infusion bonus color.
  
• Changed the display of Critical Resistance infusions to appear as "Critical Res" in infusion slots, so that it fits without getting clipped.
  

The path of detours for polish and fixes continues. All of these are things I ran into while testing the Power module, and it is usually my policy to fix discovered bugs/issues before adding more to the Armory.

I am currently in a full pause on development until I can draft out a good enough plan for how to properly support multiple enchant/infusion slots. They work fine as is sure, but the Armory is a gear planner and it would be a massive loss to not support such a useful feature. I want it to be possible to compare one set against multiple battles at once, using different configurations of the enchant/infusion slots. The main challenge is that the Armory is coded around the idea of just one selected battle, and one set of gear stats.

Gear stats are properly isolated, so that one shouldn't be too hard to solve. Multiple selected battles is another matter entirely. The visual look of that tab doesn't even make sense when you throw in the concept of having 2+ battles selected at once. That's without considering the code to allow it to happen. The Power module also needs an overhaul to support this, but pretty much purely an HTML/CSS overhaul rather than any massive code change.

My current very early draft idea is to allow selecting up to six battles that will each have a results block on the Power module, vertically listed. Your equipment sets on the Gear tab will each be able to store up to three configurations of enchant/infusion slots, and for each battle on the Power tab you'd be able to set one of those three for it to look at. This plan may change, I'm going to possibly spend more than a full day purely on thinking about ways to properly support slots.

June 27

There is no need to panic, the long gap wasn't from a crisis or mental block or anything. I just ended up taking a break and got dragged into playing a game with some friends. That spanned from the 8th to the 25th. By the 8th I had already done enough to be worth posting about, but I was going to wait to post until I had fully sorted out toggling enchant and infusion slots. That has now been done.

Here is what I've completed since the last post:

• Split the Gear tab's data into storing three variants of each item in each slot, with a stored set of final stats for each "set variant".
  
• Reduced the number of sets the Gear tab supports to 7, and changed the labels from text to SVG icons.
  
• Added a third option button to each Set tab, to open a manager for enchant/infusion slots.
  
• Reworked the CSS for the gear set options to always auto-center under the NX slots, so that I don't have to mess with it anymore.
  
• Drafted a design for the Power module to display your effective stats in multiple conditions. Either the same stats in multiple battles, the same battle with multiple stats, or any mix between.
  
• Created a Slot Settings Manager, that allows you to switch between three slot presets, and individually toggle active slots on each item.
  
• Added the Lode slot and its corresponding items, as well as the Dark Belt and Rage of the Rift ring.
  

The main things I had to think about when adding the ability to switch slots were how to make it convenient and useful, and how to make it efficient to run. Previously, the Armory worked under the concept that one set had a single set of total stats, for obvious reasons. So for the sake of efficiency, when you change anything on your gear, it updated that full total once and stored it to reuse from then on.

But when you add the ability to toggle slots on the items, suddenly there is variation. The compromise I chose to resolve this might seem obvious enough after the fact, but it was a weird decision to come upon. Instead of one set having one set of items, it would now have three sets. One full set for each possible preset. They would be completely identical except for their active scrolls. This way, the Armory could just loop the set object to total up stats like before, and not have to do anything crazy. Most importantly, it could continue to pre-calculate and store the final stats. The Armory will invisibly manage this for the user, so as far as the user is concerned it will still appear to be just one set to them.

Supporting presets also required adding new data to Loadouts, which has already been completed. A single Loadout now saves one entire set, and all three of its preset configurations. To avoid having to store a huge bulk of text for this, I did a handy trick and compressed it down to bit values for each property and converted that in turn to hexadecimal. I can do this because each prefix/suffix/infusion has two slots (0 and 1). Read as a normal int, this would give me a value between 0 and 7. Reserving a spot just for the heck of it, I now store a value between 0 and 15. Converting to hexadecimal, this becomes 0 to F, which conveniently fits as one character of a string. Thus the full data for a preset on equipment becomes a mere 15 characters. Much better than storing 45 values or 45 characters.

To actually enable a user to switch between them, the first thing you would need is of course a display on the tooltip to show the slots in the first place, along with which slot is active. Updating the tooltip for this wasn't too hard, the biggest complication was a minor task of separating the enchant blocks into two pieces; one for the slots display and one for the stats of the active scrolls. They now look like this:



The next step was to allow the Gear Params prompt to recognize the existence of multiple slots and to allow the user to modify each, as well as to display which slots are the active slots. After some iteration and feedback on Discord, this was ironed out. From the inactive slots, there is a button to switch to them as the active slot right from the prompt itself. As a bonus, the prompt was rigged up so that if the item could be enhanced or quality boosted, but not both, it would insert a blank space to keep the rows for enchants and infusion lined up evenly. The current result looks like this:



Finally, since that would be a really inconvenient way to edit a bunch of slots at once, I needed a Gear Slot Settings Manager prompt to centralize adjusting all of them, and to switch between presets themselves. The obvious design choice was to just copy the ingame one since it is what players are used to. I didn't want to just immediately do this though, because of two reasons. First, there might be a better way, and I'd prefer to do it the better way if so. Secondly, I don't want to just copy the ingame stuff just because; I only want to do so if there is no more sensible way to approach the feature.

In this case, the final design does massively resemble the ingame version. Any alternative layout was simply inferior, objectively. This isn't something highly sophisticated, and Nexon can't claim to own the rights to common sense design here. I could either make each row represent a gear slot, as they did, or I could make each row represent the property to be edited (Prefix 1, Prefix 2, Suffix 1, etc) with the contents of the column being the gear slots. This would somewhat be tidy, but it becomes change for the sake of change just to not match Nexon. It is not an intuitive layout a user could get used to.

I could also have chosen to go in a completely different direction, and create either separate pages for each property (Prefix, Suffix, Infusion) or separate groups for each property. This would keep the capability to quickly edit any specific property in mass, but lose the ability to do bulk adjustment of many properties quickly. It would potentially save space but again wouldn't make any sense to actually choose to do. So instead, each row represents an item and each column represents a property. This allows quick navigation through individual item properties within the item, or to quickly toggle a property across all items just by going down a column. It is the only sensible route I could think of, and just happens to be what they use, likely for the same reasons. It's current design looks like this:



The choice was made to recognize presets as A, B, and C instead of 1, 2, and 3 because the gear sets themselves are already numbered 1-7. Something like 1A or 4C is a lot easier to keep up with than 1-1 or 4-3. As for why there are three presets, and not any other number? The game only offers three set tabs, thus it will only track three configurations for you. As such, I figure that any larger amount would be too much hassle for anyone to want to deal with, so there was no need to support it.

Unfortunately, I decided on this rename after creating the CSS for the multi-view Power module, so it needs adjustment again. 'Preset A' takes up more space than 'Slot 1' and so on. Fortunately though, this will likely only need a width adjustment to how big each block of data is set to be, and it is still in early design to be easily reworked. The tentative idea is something like this, allowing up to six blocks:



All comparisons would be with the same set, but you would be able to change which slot preset is used for each comparison. This feature is intended to allow you to min/max a set's multiple possible slot configurations to a wide selection of battles. Rather than having to go back and forth between battles and also between presets, you can simply edit on the fly and watch the numbers update in real time. Given the capability that multiple enchant/infusion slots allows, I consider the ability to manage them well to be an essential part of a modern Armory.

Finally, on the least significant note, the change of the Gear tab from 10 sets to 7. This was not done due to any kind of data limit due to the slot preset changes. I could easily carry 1000 sets in the Gear tab with full functionality. It purely comes down to a tradeoff of how many sets are actually useful to a user vs how much space they take up on the page by existing.

In this case, the change both reduces the total size taken up by the set tabs, and fixes a past annoyance of mine. I don't recall if I mentioned it in Discord or in a previous Dev Log, but with the old design of 'Set 1' etc through 'Set 10' there was actually a size inconsistency where Set 10's tab was wider than the other nine. This resulted in the second row not lining up with the first. Fixing this required widening the other nine to be just as wide as the tenth. However, to keep the display to two rows of five tabs, I would then have to widen the entire Gear tab to fit this new width, otherwise it would become rows of 4, 4, 2.

That didn't look good, so I looked into a way to remove the text component entirely. Numbers on their own looked a bit strange and resulted in tabs that were potentially too small, so I investigated icon options. An icon would keep the tabs to a reasonable size to click/tap, and also retain some indication that they are tabs between different sets, not just floating numbers. After trying a few public domain SVGs, I settled on a helmet icon that coincidentally enough quite resembles the Helm slot's icon when empty. It allowed me to have my two rows of five again, but there was a lot of empty space between the tabs now. After a bit of debate and talk in Discord, the empty space between them was compressed, and any tabs that remained on the second row got cut. Thus the new total became 7. The new design:



Being SVGs, they are still fully customizable within the user defined color themes, and no work was required to make them compatible. SVGs are quite amazing, and v4 has been leaning on them heavily for that reason. They even have the benefit of scaling to any size cleanly, which is useful as well, since the entire Armory can be scaled up/down depending on needs.

Wall of text on previous work aside, my next task will likely be to make multi-view mode on the Power module fully functional. The Battle module has no concept for the possibility of selecting more than one battle, and I will also have to figure out how to visually display this, as well as allow the user to individually add/remove battles from their selections. The UX design of this will be far harder than the functionality of it, amusingly enough. I have no idea how long this will take, so the next post will be whenever it is dealt with.

---

On a side note, I figured out the image color nonsense that was going on. The images themselves are 100% fine and always were. The culprits were Windows 10 Photo Viewer and Firefox. Both fail to clamp images to the SRGB color space if you have a wide color gamut monitor. Firefox was most baffling about it because it isn't even on my wide gamut monitor. If you own a modern monitor made in the last few years, check the background color of the Gear Slot Settings Manager in my pic via Print Screen. If it is not 6/13/14 but instead a more desaturated lighter shade, your browser is trolling you. In Firefox I had to go to about:config and set gfx.color_management.force_srgb to true to correct the issue. I have no idea if Chrome does it or how to fix it if so. For Windows 10, naturally, you can't fix it. Enjoy.

...I am very surprised I was allowed to put this many chars into one post.