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)