November 2016

November 1

The derailment that I mentioned previously actually happened, to my surprise.

For those that keep up with the Game Mechanics forum section, or regularly talk with me, they will be aware of my interest in figuring out the Random Dye system. I've made threads like this http://forums.vindictusmanual.com/t100-random-dye-colors about it, trying to piece together how it functions, and piece together complete records of what colors each thing can become.

Due to an extremely unexpected boon, I have now achieved my goal in this regard. I have now mapped (I believe) every material_type with 100% coverage. In other words, for any given material_type, I can directly lookup what colors it can roll. Any and all of them. The catch was that the format the data was in was not compatible with my site, to say the least. However, after much issue about it, and a very good suggestion from a friend, I have converted the data into a format I can use.

I've decided that due to the huge potential benefit of this information, I am better served working on this small subsection of the Archives and getting it online on its own, rather than continuing on v3, for the next few days to a week or so.

A problem I have ran into is that the js file holding this data is massive, clocking in at an estimated final size of 2.1 MB. This is too big to risk hosting on my main host and crippling it, so my current plan is to host it as a standalone page of these forums. This isn't ideal, as it will isolate it from my other files, such as the item icons, but I can't plan for a perfect alternative and then have it not happen.

Even on it's own, the tool would be able to search items as Item Compare allows, resulting in a display of some amount of item data, plus its color boxes (by material_type name). When clicking a color box, you will be shown as a large block all of the colors the material_type offers, unless it has over 2000 possible colors. In these cases, you will be prompted to use search parameters such as colors with a Red value above 200, or Blue below 150, etc. When hovering on one of these sample colors, a tooltip will display showing its RGB value.

An alternative feature will be to search by an RGB color, and list every material_type that can roll it. This type of search will offer a "tolerance" setting, to find near exact colors instead of only exact matches. EX: With tolerance set to 3, 255/255/255 would find 252/252/252.

As a last search type, you will be able to search material_types and list out, in three columns (one per box number) all of the items that use that material_type. You can then either skim through the list, or use ctrl+f to search for specific items. With these three search methods, it should become trivial to plan out color matching sets, even for random dye exclusive colors.

---

There is one bit of issue I am facing at the moment, design-wise, that I would like to briefly mention. Sorting the color results. Sorting involves using one value to organize the data into a specific order. However, colors have three distinct values (Red, Green, and Blue). So how is this resolved? Hell if I'd know, I'm stumped. If you happen to have experience with this challenge, please contact me. cloth_bright needs your help badly.

For an example of this, let's look at the cloth material_type. It has 1264 unique RGB values, with quite a wide variety of shades and colors among them. My first step has been to strip out the pure/nearly pure Black/White/Gray shades, and display them separately. Everything beyond that step becomes very difficult. Let's look at two example sort orders I am using at the moment:



On the left, it is sorting with an equation involving Saturation and Lightness, formed by basically throwing out random equations and seeing what works. On the right, it is sorting by Hue. As you can see, neither actually performs all that well, and both have their own emphasis on which colors are sorted to the top. Ideally, all vibrant colors would sit at the top, and all dull colors would be below them. However, I don't know how to actually manage this sort order.

It's probably not that significant for most of the material_types, since they don't have an outrageous amount of colors, but some do. cloth_bright in particular has 33,918 values, and so it obviously becomes far more important to correctly organize it.

This issue will probably continue to stump me even past the public release of this Archives piece.

November 7

I've filled in a chunk of the item color box data so far, probably a fifth, but the main focus has been trying to resolve the issues I mentioned in the last Dev Log regarding sorting and displaying the colors in a meaningful way.

I've been looking into Delta-E equations, which are FAR out of my league. I need to find a copy of it that has already been converted to JavaScript for public use, or pester a friend into writing it out in JS for me. And that is just to *try it out*. I have no idea if this is the correct way to go. For reference of the kind of stuff I am reading through on the subject: http://zschuessler.github.io/DeltaE/learn/. Ideally I'd test out the Delta E 2000 formula since this praises it, but I can't even read it, unfortunately.

The issue with the formula notwithstanding, I have managed to blow away a large chunk of the size from the data file. It should be 1.2 MB or 1.3 MB when fully filled in, which is far more plausible for running on the main site. Once I minify it down, it should tip closer to 1.2 MB, maybe even below if I'm lucky.

Given the exact issue I'm having at the moment, I can't realistically give an ETA on finishing it. If the issue walls me off enough, I will release it without proper sorting. The poor sorting is not a crippling defect to the overall concept, and it would still be fully usable. The more time I spend on this, the more V3 is delayed, which I don't like.

November 12

I dedicated all development time to color organizing, since the last Dev Log. Of the 107 material types, 70 are organized now. You will notice I'm not using the word sort; this is because I gave up on using functions to sort the output. Instead, I am manually re-arranging the data so that its stored format is already in order.

For color boxes with manageable amounts of colors, this isn't so bad. 200 and less I can deal with. For the ones that have too many to realistically do manually (about 34 of the remaining 37), I will need to work out some way to brute force them into submission. The current rough idea is to sort by hue and then try to filter out the various noisy results to place them at the "end" of the results. From this point, I should be able to nudge the results into some form vaguely resembling tidy. Maybe.

The next Dev Log will be with all 107 material types organized and ready to go, regardless of how many shortcuts are required to finish the last ~34. Once the color data is ready to go, it will just need me to fill in the color box data for items, and then code the UI. Dealing with the challenge of ordering these colors is a nice break from the pain of data entry, at least.

November 19

All color tables are sorted and ready for use. Actual color box data on items, not so much yet.

I found a more useful sort function for the >2k color tables, and made no manual adjustments to those, as well as the last 20 tables I sorted, for the sake of abbreviating the workload (and saving my sanity). They are still absolutely usable, but not as tidy as the manually ordered tables.

I've set up a process for handling color box data recording, despite the absurd amount of space it takes up on my monitors. I had a good flow going today infact, but a power flash demotivated me for the day.

This week will be converting over color box data on items, manually done to not use their inefficient format. It will be a bit slow going, since numerous items nowadays have two (or more) sets of color boxes, depending on what char is wearing the item. Due to their wacky format, I have to double/triple check these extra values to confirm that they don't mismatch with the actual gear, which will slow me down.

Another thing I need to decide, over the course of this week, is if I want to include extra items that are not currently on the site, to this. The file containing this data is gargantuan, so I really don't want to edit it often, never at all preferably. I will likely decide to add all of the Lv.1 vanity gear, but all of the missing low level stuff appearing is very unlikely, I would say.

To end with a curious bit of trivia:

Nighthawk is the most variable armor set, having three different sets of color boxes, depending on who wears it. Evie and Arisha get one set, Fiona, Vella, Lynn, and Delia get the second, and Lann, Karok, Kai, Hurk, and Sylas get the third. Coding around this was a royal pain, since I previously assumed that only Male/Female determined it.

November 25

This might be disappointing, but predictable. The current running events are very compelling, and so I am spending more time playing the game, rather than working on site features.

So far, I am about a fifth(?) approx through all existing Vindictus Manual item IDs. The makeshift solution I've setup for the color tables is interesting, and I may look into converting the values for who can equip what to use it also.

Currently, data for who can equip what item is declared on a per-item basis, as an array of character IDs (1-11, at the moment). The system I have made for color tables essentially uses variables. For example, M represents all male character IDs, and AVM represents the male characters with normal body models (Lann, Kai, and Sylas). When a new character is added, rather than update every item ID and every color table entry, I could just update these variables. This would save both file size and time, so it is very likely I will go for it, as part of the v3.0 code cleanup/optimizations.

Back on the subject of the color tables tool, I've decided that though this will cause it to take more development time, I do plan to include all low level vanity items on the initial release. Given the intent of this feature, it makes no sense to not include them, due to their prevalence in fashion sets. Lower level gear also applies to this, but the sheer amount of it that exists...

The way this will work is that if item data exists for color tables of an item that is not on the main Vindictus Manual databases, it will only show the name, icon, and color boxes of that item. Any other properties, if I decide to include them in the final design, will be blank or not present at all on the UI for these.

---

An interesting challenge I will have to face in the implementation of these items is how to handle the Bunny Ear Headband. An ancient vanity item, but more unique than you would think. Five or six variations of it exist, with two or three actually different versions. Some of them simply have lower Critical Resistance, while one particular one actually has a different material_type, one that can roll 255 White (unlike the others).

Since it has both stat and color variations, despite having the same name and look, it will be tricky to figure out how to represent them. No coding exists, even in 3.0, to have variations of a single item in this way; not without declaring one entire unique item for each version, anyway.

Two possible solutions I've had come to mind so far are "shadow" items, and actually full on creating a sub-items class.

"Shadow" items would be items that are declared normally, but are marked to not display on searches and on things such as the Item List on the Armory. Their intent would be to appear only on "Related item" groups when viewing item data on the Archives. The result of this would be that I could have four instances of the Bunny Ear Headband, but only a single one would appear on Item Lists and item searches. However, when viewing that single one, its "Related items" group would include the other three variants. The issue that arises here is that this does not meaningfully represent the differences in what makes that variant different from the original. Especially for something less visible like material_type; you would have to actually open the item data to see if it is different or not. This is not efficient.

A full sub-items class setup would be initially similar, in that these would not appear on search results. The first difference would be that the Armory and Item Compare would incorporate this functionally, adding a Variations option to the right click menu. This would allow you to change the Bunny Ear Headband to its 10 Critical Resistance variant, or vice versa. When viewing Archives info, a Variations block would list each variant and *only* what differences it has from the original. The downside of this option is that it would be much more involved to create, and would potentially require rebuilding sections of the core code handling item data.

...Or the best solution may turn out to be neither of these, in favor of an elegant solution that has not come to mind yet. I tend to do best coming up with these ideas at incredibly odd times, so we will see what happens over the course of the next few days or the week.

December 3rd

No progress was made. My monitors are spread across two tables, and one of those tables needed to be rebuilt, to fit a replacement monitor for one that was dying. Instead of a two day job, this ended up taking a week. The monitor arrangement I had was too cramped to do any kind of ingame raiding/site work on, so I held off.

I didn't want to start off the December log thread by saying "Nothing happened", so this log is here under November.

The order of the work queue for the next week will be roughly to fill in the remaining color data for individual items (obviously), and then the creation of a full sub-items class. It has come to my attention that this is now relevant to stat calculation as well, such as with the Level 80 event armor that does not have a set bonus. For this reason, I'll take the full on solution, despite the possible complexity increase.