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


    August 2019

    Shippuu
    Shippuu
    That Guy
    Server :
    • NA East

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

    August 2019 Empty August 2019

    Post by Shippuu Mon Aug 05, 2019 4:03 pm

    August 5


    My tentative planning for the Loadouts tab's design and functionality is mostly complete; the unexpected challenge aspect that has arisen has been the requirements to make it work cleanly. I think I've mostly wrapped my head around what I need to do now though, so I have a sequence of tasks to do.

    Before getting into the technical details on coding requirements, I will first cover what I've worked out so far for the user end of the module, the interface itself.

    The UI of the Loadouts tab will have a Grid view and List view, naming not yet final. In Grid view, you will see a grid of the weapon class options, represented by a colored weapon icon for each. Upon clicking one of these, you will see your list of saved Loadouts where the weapon is this weapon class. For example, clicking Twin Spears would show all saved Loadouts using Twin Spears. List view would show all of your Loadouts in a list, organized by Character or weapon class.

    (Your warning is here, partial ranting and technical details are below.)

    Once I got to the point of figuring out the design itself, I went to make the server-side table in the database to get the ball rolling, and realized my folly. The raw data the Armory uses for items is rather large, and it would be very unwieldy to save as is. So I would want to compress it down to only the essential information, like the game does. The server can generate these, but it is the client that needs to be creating them. You'd think it'd just be a case of porting the server-code to the client, but it's not so simple. The client doesn't always have the data needed to generate these.

    To generate an item data string, the client needs to have the min and max roll values for things like sockets and composite materials. So to accommodate this, I need to create a new server-side function to pre-generate a cache of sorts, so that whenever someone loads the Armory, it immediately requests these values, and stores it till they leave the site. This actually turns out to be a huge optimization overall, but it has yet still more issues.

    In the current implementation, the Armory can silently update since the item params data from the server is usually fresh, so if a new scroll or something is added, it will just pop up as the user is using the Armory. With a pre-cached object, this won't happen. So to make it work, I have to setup a class to manage the update version of various pieces of the Armory, and when the server says it has a newer copy, to reload it. To do *THAT*, I needed to work out a means to actually ping the server for changes without hammering it or the user.


    Finally, with help from people better at this stuff than me, I have a game plan:

    1: Create a client-side class to gather the build number of various parts of the site, and check the server for newer versions at a set interval of time. If there are changes, renew the data and send the user a notification that a patch or update has arrived and either applied itself, or needs a page refresh.

    2: Create a server-side function to build a ready to serve cache of all enhancement, enchantment, infusion, bracelet, and composite data. Store it in a text file, and ship it to every client that asks for it. Browser caching will lighten the load on this.

    3: Refactor the Gear Params Prompt to not ask for these properties anymore, since it will already have access to them. Additionally, refactor the Item List module to stop asking for composite material data, for the same reason.

    4: Port the item data string generator from the server to the client, and refactor it to not crash horribly whenever anything goes even slightly wrong.

    5: Create the serverside database to save Loadouts to, and create a few test entries.

    6: Create the Loadouts module, and finally do the fun stuff.


    Some time tonight, I will begin working on the first step, which should hopefully be finished tonight as well. I have already worked out which things need separate build numbers and what not. As for the rest, I don't dare give any ETA or expectations.


    Last edited by Shippuu on Wed Jun 01, 2022 2:14 am; edited 1 time in total (Reason for editing : Name consistency)
    Shippuu
    Shippuu
    That Guy
    Server :
    • NA East

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

    August 2019 Empty Re: August 2019

    Post by Shippuu Wed Aug 21, 2019 6:24 am

    August 21


    RuneScape caught me up in another event, letting me blitz my least favorite skill. That ate about ten days, and hopefully they won't run any more crazy events for a while. That is supposed to be Nexon's thing.

    Progress on the cache is moving nicely nonetheless. The client and server now have a version system to compare against, and they successfully employ it to avoid unknowingly using old files. The server now generates a cache of item prop data, which it sends to the client on request. This completes steps 1 and 2 on my previous to do list.

    The size of this cache is larger than I expected, weighing in at 194 KB. Additionally, for now, I've had to force it to ignore browser caching and always request a new copy. This is a downgrade in efficiency, but hopefully I can figure out the problem and fix it. If it isn't set to ignore the browser cache, it will always retrieve an old file, even if the server has a newer copy. It's rather silly.

    From here I need to recode existing client-side things like the Gear Params Prompt and the Item List, so that they will use this new cache instead of requesting new copies of the same data. This will allow me to slightly shrink the bandwidth used in these. More importantly, it will let me delete obsolete code, making those sections smaller and easier to manage, even if only by a little.
    Shippuu
    Shippuu
    That Guy
    Server :
    • NA East

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

    August 2019 Empty Re: August 2019

    Post by Shippuu Sun Aug 25, 2019 8:27 am

    August 25


    Step 3 is complete. The Item List and the Gear Params Prompt now refer to my property cache for data, which now also includes set info for convenience.

    The data the server sends for the Gear Params Prompt to work is now a whopping 93.7% smaller, but the data for the Item List only became 26.6% smaller. I have also been able to remove a rather silly dependency that item tooltips had, where set bonuses could only be displayed if the Gear tab was open. Overall, these are pretty good gains for doing something I was already forced to do for Loadouts.

    With this, all of my pre-requisites to save Loadouts are complete, except for one. I still need to build code to convert the longer Armory data into a more compact item data string. Both the server and the client actually already have obsolete code that was doing this. Hopefully some of that code is worth salvaging, and saves me a bit of time.


    Last edited by Shippuu on Wed Jun 01, 2022 2:15 am; edited 1 time in total (Reason for editing : Name consistency)
    Shippuu
    Shippuu
    That Guy
    Server :
    • NA East

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

    August 2019 Empty Re: August 2019

    Post by Shippuu Tue Aug 27, 2019 5:40 pm

    August 27


    Progress continues, despite some mental flailing with an oversight I realized yesterday. The client-side can now generate item data strings for items, but it cannot parse an iem data string back into a proper item yet.

    The problem I realized yesterday, as I started writing the generator, was that I can't reverse it back into an item without having a copy of the item in the first place. Since these will be used to load Loadouts and items in the Storage tab, there will definitely not be convenient copies of the items laying around to use. So, I need to implement a function for the Armory page to request a bunch of items all at once, and get them all in one response.

    The code to do this is trivial, but the challenge is in deciding how I want to do it. Two methods can both work but have vastly different methods and "consequences". This will need to load 26 items at once potentially, so it needs to be fast and efficient. I am probably going to spend more time thinking about how I want to do it, than actually doing it. Nonetheless, I hope to have it done tomorrow.

    I'm so close to actually getting to start on the Loadouts module, at this point.


    Last edited by Shippuu on Wed Jun 01, 2022 2:16 am; edited 1 time in total
    Shippuu
    Shippuu
    That Guy
    Server :
    • NA East

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

    August 2019 Empty Re: August 2019

    Post by Shippuu Wed Aug 28, 2019 9:23 am

    August 28


    Bulk requesting items now works, covering all pre-requisites for the Loadouts module. I have yet to write the code to unpack item data strings back into items, but I won't have a reliable way to test such a capability until the Loadouts module is functional anyway.

    Today, I can finally start on the design of the Loadouts tab, after so many detours. This Dev Log is earlier in my day than usual since I won't have anything to talk about or show on the Loadouts tab until I am happy with the design and feel of it. So I may as well report the progress now, and avoid possibly forgetting later.


    Last edited by Shippuu on Wed Jun 01, 2022 2:16 am; edited 1 time in total (Reason for editing : Name consistency)
    Shippuu
    Shippuu
    That Guy
    Server :
    • NA East

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

    August 2019 Empty Re: August 2019

    Post by Shippuu Thu Aug 29, 2019 7:52 pm

    August 29


    Today was a detour day, but a good one. [Removed text here] Additionally, I finally brought the Armory DB up to date, where it had fallen several months behind again.

    It's far from complete, but I've started the first steps to setting up a mechanism to add future items to the NA data that the Armory uses. It still needs a lot of manual work at this stage, but for now, I've successfully merged Bel's items into my NA August data. The availability marker now shows "Present" in Green if the item is available, and in Red when the item is not available. When not available, the text will instead show which update the item will be coming with.

    I will finish the code for future item merging at a much later date, likely. This diversion shouldn't drag on too long. The Loadouts module comes first.

    I have some rudimentary concepts of what I want the Loadouts UI to be like, but I haven't finalized anything yet. I *have* hit my first instance of a technical limitation though. Originally, I wanted to use at least one colored item icon per Loadout save for display purposes. As it turns out, this is too resource intensive to do for purely cosmetic purposes. This will likely force me to stick with text-based listings, but I will continue to look at my options.


    Last edited by Shippuu on Wed Jun 01, 2022 2:18 am; edited 1 time in total (Reason for editing : Removed the story about the detour work out of paranoia)
    Sponsored content

    August 2019 Empty Re: August 2019

    Post by Sponsored content


      Current date/time is Fri Mar 29, 2024 2:20 am