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


    February 2019

    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

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

    February 2019 Empty February 2019

    Post by Shippuu on Sun Feb 03, 2019 8:07 am

    February 3


    Kingdom Hearts 3 released on January 29th, so delays occurred.

    I've decided that now is a good time to detour from what I was doing and continue filling in a piece that is only half-ready: the data. The Armory does not load items from the game database file, but it is certainly used to generate my own data. And the data I have a custom build of is old now; Teide is the newest thing on it; no Battleshades, let alone Miul.

    Normally, as a regular thing, fansites will use client files such as images and data to make their tools or info pages work and be accurate. It is probably more unusual that a convenient database exists but *won't* itself be used. The problem here is that Vindictus has a great many duplicates of the same items, that would effectively be spam on search results and listings. Every r7 and up scroll exists twice, due to the 100% success variants, and there are something like 20 copies of each early ivory weapon.

    One of the first undertakings of starting v4 was to begin the process of assembling a "clean" database. One that only contains the items relevant to our region, only one copy of each, and only the bits of data that the Armory would use. At the time, I finished probably around 40% of the work. It was just enough to allow me to test the Item List tab and the Gear tab. All duplicates of Avatar items and consumable items still exist, and need to be dealt with.

    In addition, I have been puzzling over how to associate items and item types to each other. If you are familiar with a wiki such as the RuneScape wiki, this is the internal mechanism that makes the box at the bottom of the page work, linking to other items. A Regina Helm would show a block for all of the other Regina equipment, a Godly Iron Ore would show a block for all of the Iron Ore tiers, and so on.

    Some of these relations are easy, such as sets, but others are more complex than you might initially think. To a player, it is obvious that Godly Iron Ore and Iron Ore are related, but nothing in the data actually directly says this. As far as it is concerned, they are no more similar than Godly Iron Ore and an Exquisite Enchant Rune. This means I need to create my own linking data associating items, that accounts for all of the possible ways that items can be grouped.

    I've got nothing on that front so far, and I doubt the work of deleting duplicates would be all that interesting to read about.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

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

    February 2019 Empty Re: February 2019

    Post by Shippuu on Fri Feb 08, 2019 11:26 am

    February 8


    The amount of unused items in the database is actually impressive. As mentioned in the last Dev Log, I am working on cleaning up the base db upon which I assemble my own custom data. This base db was previously sweeped to only include items active in the NA client, and also to exclude all duplicate weapons/armor. It did not have any sweeps to remove junk items, NX items, or duplicate outfitters.

    The sweep I have been working on is the junk items sweep. Bit by bit, I have been chipping away at this, but it is the most monotonous work I've done in a while. The general rule I am following for what items I am "keeping" is that the item must either be a consumable that could still be used nowadays, it must be a unique piece of equipment, or it must be a material that can be used to craft something.

    This means older event boxes, random boxes, and even current gachapon boxes are being axed. Once the base Archives module goes live on the Armory, I will almost certainly add these back one at a time, as I gather enough info to fully reconstruct the event (the contents of each chest, the origin of the event items, the period it was active during). Without these data points, the presence of these items would only create confusion I feel.

    My current pass is specifically on items that go in the normal chests, not story items or NX items. Keeping that in mind, and that items were previously removed, I reached the end of the Season 1 items yesterday. At the time, I calculated out the ratio of how many items got purged as compared to how many got kept, as a curiosity. 45.4% of the Season 1 items were junk, and have been cut. I am still processing through Season 2, which is where this Dev Log leaves off for the next.

    I will end this by expressing my continued confusion at the fact that items which are clearly labelled for China, Taiwan, or Japan, are not locked to those regions. This means our client loads those items even though they were never intended for this region. These items represent the majority of those that are being cut.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

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

    February 2019 Empty Re: February 2019

    Post by Shippuu on Fri Feb 15, 2019 5:54 pm

    February 15


    Well, there is far more junk in the data than I thought. As a bit of forward planning that might bite me in the ass later, I also decided to purge every box type item from the data. I want to declare those completely separately as boxes, to try to have a more coherent data structure. It will also allow me to add them back one by one as I can figure out all of the data that they need to be linked to (source obtained from, contents, any related events/sales, etc).

    With all of that said, I have finished purging half of the db. All normal chest items are resolved, with more than 10k records axed off this particular copy. This is a rate of about 75.1% of all records being clipped. The majority were KR/CN/TH/TW/JP items never intended to be active in our client. Before I do the NX chest items, I need a break of doing less painfully tedious things.

    My next task up will be to tidy up what currently works on the item properties menu, and then I will add functionality to color box settings, item fusions, bind states, etc. Item Fusion in particular should prove interesting; there are a lot of items to have to pick from, and a lot of ways to do it. Color boxes and fusion should both be fun to do, rather than troublesome like the data was.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

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

    February 2019 Empty Re: February 2019

    Post by Shippuu on Wed Feb 20, 2019 11:30 pm

    February 21


    I've been dragging my feet on doing anything this week, so most of this Dev Log is going to be more of planning notes. As of today, the params menu can now actually load the item's data, so that it can correctly show the current enhance level, enchants, and etc in the inputs. Additionally, I have made a change where if the material rolls are already set, it will open to the Stats tab for setting Enhance/Prefix/Suffix/Quality/Infusion. In testing, it turned out to be quite annoying to default to the Materials tab, which I was usually only using once per item.

    I've also noticed some other efficiency and clarity issues, that I need to resolve still. The action to open this menu for an item is to left click the slot. This is convenient, but this same action also reloads the item list, which has to generate potentially over a hundred items. Ouch. This doesn't even cause a performance blip for desktop users, but it would be an avoidable waste of battery and resources on mobile; so it is something I need to resolve, somehow.

    The second issue that came up is one that I discovered in Discord chat with guildmates. There was confusion between the Materials tab which sets the stats of materials, and the Stats tab which controls Enhancement/etc. This tells me that I need to rename the Stats tab, though I haven't decided to what yet.

    For item fusion, a minor challenge I've been thinking on for a few days now, I think I've come upon an ideal solution. I am going to create a search box with an auto-complete functionality, and put it right in line with the rest of the options on the menu, so that it doesn't break the visual flow at all. You can only fuse an item to another item of the same slot (and type, for weapons), and additionally your character must be able to wear both items. Conveniently, this means I can directly load the contents of the Item List to search through, and not have to spend any extra CPU resources or bandwidth to make it work.

    The only downside is that I don't actually have such a search box yet, which means I need to make it. It will be useful in other places later, such as for searching the Archives or Item Compare, so I am likely going to sink a decent bit of time into coding it well and giving it plenty of functionality. I am using my own custom elements for my inputs, for visual purposes, but hopefully I can get them up to having all of the same functionality as the Windows versions.
    Shippuu
    Shippuu
    Forum Coder
    Server :
    • NA East

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

    February 2019 Empty Re: February 2019

    Post by Shippuu on Thu Feb 28, 2019 9:47 am

    February 28


    Bad news time, but first the good news: Item recoloring is now functional, with a pic to show the UI/colors in action:

    February 2019 V69VrGx

    The color format shown will be the default, but there will be a Settings tab to adjust the default format to whatever you prefer, be it "red/green/blue", "red, green, blue", "#RRGGBB", or whichever. Functionally, the textbox can parse any color given in Hexadecimal, Decimal, or RGB format, so you will be able to use whatever format you are familiar with, unless it is HSL (maybe later support will be added for that?)

    While I did get that working, it certainly wasn't seven days worth of progress, either. I've run into a showstopper of a problem for the v4 UI, and I need to resolve it before I can continue adding to the Armory. This ate up a lot of "planning time", and is why progress was small this week. I will try not to go too deep into tech-y details, while still attempting to thoroughly explain the issue I have found:

    Every object on the Armory has a defined width and height, to tell it how large it should be on the screen. Every font has a defined size for how big the text should be. Additionally, every object has what are effectively padding values defined, for how much empty space they should have both inside them and around them. On my Armory, even in v4, these are all defined in pixels, which is an absolute value. I chose pixels as my unit of choice because it gave me extremely precise control over the looks of the Armory, but it has a rather serious flaw as well.

    To use an example, let's say I am using a standard 1920x1080 monitor; if you didn't explicitly buy a higher quality monitor, this is likely what you are reading this on. The screen is 1920 pixels wide, and 1080 pixels tall. For the sake of an example, let's say a window on the Armory is 960 pixels wide, and 540 pixels tall. It would fill exactly a quarter of the screen, and has a lot of individual values, like a stats page.

    Now what if I viewed this on a 4k monitor? Its screen would be 3840 pixels wide, and 2160 pixels tall. But my window is defined in pixels! Instead of filling a quarter of the screen, it is now suddenly only an eighth... Everything in it would be too small to read or use. Effectively, it is not compatible with that monitor.

    This is the problem I need to resolve, and I am setting aside March to tackle this. I need to change every size value from pixels to a relative unit of measurement, that can scale upward as screen resolution increases, so that both 1440p and 4k monitors can use the Armory without a magnifying glass. In specific terms, I need to change from px units to em units.

    The em unit scales based on font size, which will naturally be larger on higher resolution displays. As font size goes up, my windows would then appropriately rescale themselves to the same relative size as the text. With this, that theoretical window would be a quarter of the screen on 1080p, 1440p, 4k, or any other resolution (as long as it is 16:9 anyway...).

    Ultrawide and Super ultrawide monitors complicate this a little, and maybe that will end up the subject of some interesting Dev Logs in March. Separately, I will be dramatically upgrading my video card tomorrow, so that is probably going to be an effective distraction for a while.
    Sponsored content

    February 2019 Empty Re: February 2019

    Post by Sponsored content


      Current date/time is Tue Jul 16, 2019 12:05 pm