2023 Armory Progress

July 15

Given my consistency, or lack thereof, it might look better and be easier to just have one thread per year and let it reach a few pages if that ends up happening. Among other major changes to these posts, I need to find an image host other than imgur nowadays, never know when they will decide to fully transition to social media instead of image hosting...

A lot of things contributed to this delay, only some of them being actually good excuses. The end result of what happened is that I got thrown out of funk and also simultaneously hit a creative block on fixing some tedious issues with the Settings window.

Today, I am posting that I have resolved around half of that tedious work. The root of the problem was the Color Themes tab in the Settings window. Its layout was completely antithetical to the design of everything else in the Settings window. It was horizontally laid out, while every other tab is vertical for ease of reading/use. Changing the design over to being vertical instead of horizontal seems like it would be an easy thing to do, and it really should have been, but this is where creative block started kicking in. Questions like which settings were more important and therefore got to be at the top of the page, what should a horizontal button row even look like since the Armory has never had one before this point, etc.

As part of cleaning up the Color Themes tab, I actually ended up reformatting the HTML of the entire Settings window. Instead of clicking a named tab on the left to open that page of settings, they are now all one unified scroll-able page. Clicking the left-side tabs will now jump to the start of that page's options. Incidentally, this caused me to discover a design flaw of my custom tables/panels that had never appeared before this point. The Color Themes table was inside of the scroll-able panel for Settings, and they do not support being nested. They would target the first scrollbar they saw, even if it was not their own. Oops. To fix this, the class that makes tables and panels work now looks for the scrollbar that identifies itself as belonging to that table/panel, via an extra attribute in the HTML. Simple and effective, always the way to go.

On the positive side of changing everything to one unified page, this allows for a cool feature idea I got from Old School RuneScape, where I can go back later on and add a search bar to the top of the Settings window itself, and allow users to text search to find the setting they are looking for, even if they don't know what tab it is categorized under. I can operate this via CSS filters just like the Item List's text search, so it will filter in real-time and be super fast too.

It turns out that the auto-settings for equipping items in the Gear tab require even more width than the Color Themes tab did, so the entire Settings window has been widened a bit to accommodate this. Taking advantage of this since I had to do it anyway, I widened the Color Themes table to show four themes per row, and the sub-tabs for editing the active color theme now show three color values per row. To keep the text information regarding each option in Settings easier to read, I capped their width a bit less than the full Settings window so that it would not require as much left to right eye motion.

The look of the Settings window at this point of the reformat is not even at what I would consider a beta state, so no images today. Auto-settings for the Gear tab are fully functional, as they were in January, but while the options for it exist in the Settings window, they still only exist as dummies. They are present and look right, but don't do anything yet.

Once I finalize the look and layout of the Settings window, I will need to go back and code in the auto-settings options to actually work. That will be a huge amount of tedious work, so hopefully I won't burn out again before it is done. This Settings window stuff is the last of the really tedious work on the entire Armory project, I believe.

August 3

The distraction of this cycle was the suspense over my new GPU arriving in shipping or not (BestBuy's provided info is TERRIBLE), but it finally arrived and playing around with it derailed me for a few days.

I've made good progress getting myself back into things on coding for the Armory over the last month now, generally trying to get myself to do at least a small bit of work each day. As of now, the Settings window is in a pretty good state, but not what I would call 100% on base functionality. I still want to add that search feature.

I am trying out this forum's default image hosting today, so let's see what happens long-term. Sorry in advance for poor cropping, this is significantly harder on Windows 11 since the background is so damn bright.



Aside from a bit of polish to the look of the Settings window, the main differences you can see are two details:
1: The left-side tabs no longer light up, as (currently) it is no longer possible to tell which pages are in view and which are not. I might figure out how to do this at a later date.
2: Each section of settings, which was formerly its own independent page, now has a header title to indicate transitions between groups of settings.

The settings visible in this image are those for the Gear tab and for Auto-Parameters, which has been the main source of complexity for the entire Settings window's implementation. The main settings are still dummied out and not functional, but I have included them to show what they will look like in use. The default values for these options will be exactly as shown here.

As for the more detailed Auto-Parameter settings per each slot, these are now fully dynamically loading. The design of these settings is also finalized. All that is left is to add in the last bit of code, for actually saving the values you set here. Here is a second image of Auto-Parameters, this time with a slot fully loaded in:



The default visible group is Weapons/Armor, which is self-explanatory. Accessories 1 includes the set of four enhanceable accessories (Earrings, Belt, both Rings), and Accessories 2 contains the other five accessories. Parameters that are not applicable to the item, such as Power Infusion on Artifacts, will not be present on that slot's options.

Auto-Parameters is nearing finalization, but it is not the only thing I am working on currently. I have also been renovating the code itself a bit, so that it is easier to read directly. This is taking some extra time, but should pay off in the long run. The next post will be when Auto-Parameters is fully completed, including the currently dummied out options for composite items/bracelets.

September 19

Auto-parameters are fully complete and fully functional. Not only that, but every setting for the Gear module is now completely functional and can be set in Settings. In the process of this, I decided upon a small change in how the auto-parameter settings work.

Previously, you could enable inheriting the parameters of the item previously equipped in the slot. So for example, if you equipped an Orna Helm over a +15 Cool Advance Ardri Helm, you would now have a +15 Cool Advance Orna Helm in the slot. You could also enable auto-parameter, which would set the items you equip to whatever you define in Settings, with fallbacks automatically handled for things like enchants that have restrictions.

These two were mutually exclusive, so you could not have both. They can now both be used together, if both are enabled. If both are enabled, inheritance will take priority whenever it is possible. So auto-parameters will be used if the slot is empty, and parameters will be inherited from the previous item if something was equipped.

I have also added explanatory hover tooltips to the default roll options for composite items and bracelets. They detail what rolls you can expect from each setting.

Finally, after that anchor of a job, I can now start on forward progress on the Armory again. New functionality! I am now in the drafting phase for the Buffs module, which will handle enabling/disabling any relevant status effects. This is the semi-final module for the Armory, with the last one being a Share module for sharing and loading Profile/Loadout pairs that are set to be public. I also fully intend it to be possible to share impromptu links like the old Armory could, but storing data in the address to the page is no longer feasible. I will need to look into something like temporary public links for that, but I absolutely will find some solution to allow the capability.

October 3

The Buffs module is fully implemented and fully functional! This one went so smoothly because it was truthfully a pretty isolated bit of data, and the rest of the Armory is well prepared to have additional data thrown at it. I have a function that can take an array of objects full of stat data, and it just sums them all up. Simple and effective, both for totaling up buff stats and for tacking buff stat data onto full stats.

A little bit of design iteration happened on this one, as I had a headache I wanted to fix from back in the days of v2. I had it in my mind the whole time designing it that I didn't want the list of buffs to be overwhelmingly long, and I didn't want to have to deal with toggling off other buffs when you have other incompatible buffs on. For example, if you have the buff for Transformation Stage 1 on, the Armory had to detect this and turn it off when you clicked the buff for Transformation Stage 2. This kind of thing happened with several groups of buffs, and it was annoying.

With v4, buffs are no longer independent entities. Instead, there are "buff groups" such as Transformation, which can have an arbitrary amount of options within them. In the case of Transformation, Stage 1 and Stage 2 are its options, and they are mutually exclusive. You can visibly tell from the UI that you are picking only one of the options, and setting that value overwrites the other buff cleanly, so no complicated checks are necessary. This has a side benefit of making the UI a bit tidier and easier to understand, which was another flaw of the old v2 layout. Stackable buffs like Acceleration had a number beside them, and you had to just already know you could click that tiny number to change it to a different number. It was not ideal.

With that in mind, I originally started drafting the Buffs module to look more like the Titles module's data, not that it survived for very long. I originally went this route because Armory buttons were pretty large, and I wanted space to accommodate them in each buff group. Here are the two early drafts of the Buffs module, just to show part of the development process.

Iteration 1:


Iteration 2:


The first iteration was scrapped for being too "loud" on highlight colors. The second iteration was when I decided this was taking up far too much space, and went back to the drawing board entirely. I have ended up with a design very similar to the original v2 layout, but with a small twist due to the buff groups setup.

The current (and final) design:


For buffs that have more than one option, activating it will expand out a section below that buff for you to choose which option of the buff you want. By default, it will choose the last option in the set (the highest stat option in almost all cases). If you don't want the last option, you can of course just click one of the other options to select it instead. When hovering on a buff listing or option, you will see the stats it would apply. For an unselected buff with multiple options, hovering on it will show you the stats of the default option.

You can only get a hint of it from the images, but a large number of outdated items/effects have been removed. The rule for what buffs are relevant enough to add to the Armory is this: If it can currently be obtained, it is in the data. Anything discontinued like the Succubus Chocolate is not present as the amount of people who have that item still would be very minuscule.

Buffs are saved and loaded as part of Character Profiles, whereas Loadouts will continue to exclusively be for equipment. Saving/Loading buffs is already fully functional, as part of making the Buffs module work.

Next up to do is the final Armory module, the Share module. This one governs sharing your saved Profiles/Loadouts with others, and importing theirs. I have had many different thoughts over time for how to handle this, so even I don't know what form these features will take in the end. The next Dev Log will be when I have decided on a route for this, as well as the reasons why I chose that way over some other method.

October 6

I have come to a decision. It deviates quite a bit from the original vision I had for how sharing links would work on v4, but it is significantly better and simpler.

First, a bit of history. Previously on the v2 Armory, whenever you made any kind of change to your gear or stats or etc, it updated a link in real time that you could copy and share to others by pasting that link. It was convenient and immediate, but the consequence was that these links were far over 1000 characters long, usually averaging ~1400 characters, and anything that tried to process them into a clickable link would usually get very confused by the characters used in them to separate parts of the data.

This is where the Share module will come in. While it would still be possible to generate those links in real time as it was on v2, those links were hideous. The Share module will allow you to create and save links much like you would save a Profile or Loadout. The difference is that these new links leverage the server-sided capabilities of the v4 build to minify them. Instead of leviathan sized links, the new share links will be 7 characters long. These 7 characters will all be normal characters, so there will be no strangeness when linking it in places like Discord. The subset of characters it can use is also trimmed down to be easy to read, so you won't see combinations like 1I, VVW, or 5S, those characters are not used. There is no need to worry though, this still leaves over 17 billion possible combinations.

My original very early concepting of this functionality was much more constrained and possibly more confusing. The idea was that a share link would be created by selecting one of your saved Profiles and one of your saved Loadouts, and it would associate these together into a 7 character link ID. The benefit to this was that it would update in real time to match any changes the creator made to the Profile or Loadout, but this may not necessarily be desirable. Additionally, despite that being my early plan solely due to the likely simplicity of it via sidestepping a bunch of data storage since it was already there, it would likely have turned out to be quite annoying to implement. So, we have the old system with a small modern twist to it. A running theme of late...

I am still musing over the idea of allowing Profiles and Loadouts to be shared separately if set to be Public like Color Themes can be, but they do not have this capability coded in already, and I am having difficulty coming up with any niche role these could fulfill if I did take the time to give them this capability. It probably won't happen unless someone points out to me a neat use for this.

I have already started work on the coding part of the Share module, and I can happily say that I have already loaded a saved Share link from the server onto the Armory successfully. I cannot create that saved Share link yet, but that is the tedious part. The fun part in making it actually work is already done.

Drafting a design for the Share module, and in turn making it work, will probably not take long. My next post will be reporting on the completion of the Share module along with images of what it looks like.

I do have to end this post with a bit of cold water though, this is not the finish line for the Armory. While the Share module is the last module that will be part of the release build of the Armory, I still have quite a bit of code cleanup, bug fixing, and holes to fill in before it is moved online into a 'private beta' of sorts. This final cleanup will take a significant amount of time likely. There will be multiple Dev Log posts as I progress through it.

For just a few examples of what remains after the Share module is done:

• The Armory does not support abilities on composite gear, at all, anywhere. I strongly want to do this unless it makes the Gear Params Prompt excessively messy.
  
• The Armory has no concept of the existence of Charon and Achel, of Level 115 battles, or of many of the recent outfits. Its data is quite behind.
  
• The code handles storing/modifying Profile data in a very messy way, and needs to be centralized/cleaned up.
  
• When moving an Armory window around, it is given an elevated z-index so that it is on top of other Armory windows, so that you can see exactly where you are moving it. When you click another Armory window, it loses this elevated z-index and goes back to its default based on its DOM order. I have no remote idea how I want to do this yet, but I want the user to have control over the z-index priority of all of their open windows.
  

October 12

As promised, this post is coming after the completion of the Share module. I actually expected to be done before now, but I had to remake an entire chunk of server-side code regarding validating item data, so that was a needed detour for share links to be workable.

A core fact I knew I would not compromise on with this functionality was that users would not be able to just feed it whatever data and have it save it, that is a recipe for chaos. The Armory loads the data the Share Link feeds it, so I am taking serious precautions on what the server will trust and save from what the user sends.

Functionally, nothing you send to the server is actually what is saved. The server takes the input, runs it through rounds of validation, and during this process constructs a "validated" copy of the data. This validated copy is what is saved server-side, and the data sent from the user is discarded. This means the only data that can be saved is exactly what the Armory expects to see. As a side bonus, this also disallows saving impossible gear configurations. If the gear can't go in that slot, if the enchant isn't compatible with that item, etc, it will discard the invalid data as it sees it.

Notably, this led me to slightly reduce the scope of what Share Links will store, at least for now. Currently, they store a name, a description, an expiration date, and everything about your stats/buffs/gear as of the moment you created the share link. The original plan was also for it to calculate the total stats of the setup server-side and store that for Discord preview embeds when linked, but I am putting stats on hold due to complexity issues. So embeds will only show the name and description on release, unless I can fix this during the final polish/cleanup round I am now in.

Here is the Share tab, as it looks once you have a few Share links created:

(...Don't mind the overlapping text, the actual width of this tab isn't going to be decided until I know the actual address to the site.)

As you can see, it is streamlined significantly from what the Profiles and Loadouts modules look like, per the Dev Log posts from when I was making those. Share Links are read-only once created, and cannot be modified in any way, hence no Save or Edit buttons. Being read-only is an intentional design choice. Links people share for guides or etc changing retroactively can be confusing, and this is needless when it is trivial to just produce a new link. I would also be concerned of the abuse potential of changing the contents of these links after the fact.

The main part of the tab, dominating nearly the entire thing, is the table of Share Links. By default these are sorted by alphabetical name order. At the top left of each share link entry, you have the name of course. To the right of it you have the expiration of each link, I will get to that in a moment. Below those you have the literal link to that share link. The buttons on the right side are to delete the share link, and to copy the link to your clipboard in one click, a convenience option.

Above the table, you have a text search that works exactly like the one the Item List has. As you type in it, the table of share links will be filtered to show only links with names containing the phrase you type in the search box. For example here if I typed 'Test', I would only see the listings for Save Test 2 and Save Test 4. Below the table you see a single button, "Create New Link". Its purpose is self-explanatory. When clicked, you get this prompt:


An evolution from the design used for the Color Themes, Profiles, and Loadouts prompts, this design better provides info on the max length of your inputs, and how much remaining length you have. The length limits for these are non-standard compared to the others, though. The name length limit is increased to 24 to be able to fit a bit more information, since the role of Share Links is rather larger than any of the others. The description length limit has been reduced to 150 due to possible issues with meta tag descriptions for embeds. Experimentation once this goes to beta testing may allow me to increase it back to 300, however.

The last input you have for creation is Lifespan, one unique to share links. It is unlikely that you want to keep every share link that you ever make forever, and remembering to go back and delete them after they have been used can be tedious, so you can set a lifespan on them and they will automatically delete once their lifespan is expired. For temporary lifespans, you can provide any integer amount of days from 1 to 30. Of course, if you want the link to last forever, you can tell it 0 and it will never expire.

The completion of the Share module marks the completion of all Armory modules that will exist on release. All that is left now is final polish and final cleanup. In this regard, I have a list of issues to address that I have been collecting as I used the Armory over this year. Some of these are quick to fix, some are work intensive, and some of these feel like nightmares right now. Transition to an online beta will not be soon, but I will be continuing to post here with updates on my progress and what I have been doing as I inch along toward release.

October 17

Current status:
14/21 checklist items completed
17 to go

It is exactly like the old programming meme. As I go through the checklist and complete things, I am discovering other things that need to be done. However, as you can see from the amount of items I have completed, I have been making better progress than I expected. In chronological order, here are the things I have done so far:

• Added a second sort to Rhod Compass, which previously only sorted by Rarity since they were all the same level. This now properly lists higher level rhods first, but still sub-sorted by rarity so that the better Rhod Compass are higher in the list than the lower ones, even if they are alphabetically later.
  
• Removed the Properties tab from the Gear Params Prompt; there is currently no need/use for any of those settings, so showing it is unnecessary. The code is not gone, so it can be re-enabled if needed one day.
  
• Fixed trade properties on weapons/accessories erroneously marked as binding on trade when they were not; I had copied the flags from Lv.80 accessories which do bind, but the higher level accessories do not because they cant be dismantled.
  
• Added support for composite abilities on items. This includes support for the relevant ability buffs that grant stats, such as Graceful Weapon. The ability buffs will only appear as options if you have their respective ability set on your weapon.
  
• Actually coded in the event to change tabs on the Auto-Parameter Settings for the two Accessory sets, whoops.
  
• Added effect text to Artifacts.
  
• Refactored how partial stats from enhancement failures are handled. This eliminated the need for an entire table from my database, and also saved me having to manually enter the data for Orna gear.
  
• Finished the tooltip code to show partial stats from enhancement failures. Rather than just showing that the item gained some percent of stats, it shows the exact stats gained.
  
• When changing the set character, if a slot is selected on the Gear tab, the Item List will now reload to show gear the newly selected character can use. Implemented for feature parity to the v2 Armory.
  
• The Item List Table now properly remembers closed item branches when loading slot contents.
  
• Fixed the spacing/scrolling on the Share Links table to be even and consistent.
  
• Rebuilt the entirety of the server-side code that handles saving user settings and window layouts. These are now split into two separate save processes, with rigorous validation for each.
  
• Added an option in the UI Manager section of Settings to change the stack priority of windows (which window appears ontop of the other when overlapping). As an intuitive design, you just drag the window's label up or down a list of your open windows.
  
• Added a bit of code to clear the set battle when changing to the lists of battles in the Battles tab. This allows it to default to showing the list instead of always defaulting to a battle.
  

Most of these are straightforward, but there is a bit of a story to one of them. Yesterday, I decided I would tackle one of the easier items on my checklist. The fact that the stack priority on windows was rather arbitrary, and depended entirely on their creation order. I was going to add a single integer value to the data of each window to save their z-index, which the user would set using a jQuery UI sortable list. This should have taken 30 minutes tops. As you can see by that listing above it where I rebuilt the save processes, things happened.

Truthfully, I didn't have to do any of that rebuilding. I could have slammed it in as it was and it would have indeed been a quick job. However, when looking at the server-side that handles saving, I was reminded of how flawed and honestly somewhat dangerous it was.

All user settings and window layout data was saved as a single block of JSON, with no validation. Window layout data used to be handled separately, but ended up bundled together for reasons I don't remember. This was always one of those big problems I knew about early on, but believed I would be able to solve it later in development. This was true, but I forgot about it until I started looking at the UI code again.

Fortunately, the Share module's save process was almost exactly like what the user settings and window layout data need, as far as validation goes. I was already experienced in this kind of thing, and it was fresh in my mind, so I just ripped out literally all of the old code and started over. Instead of taking it and storing it blindly, it now rebuilds the data from scratch, property by property. Aside from the safety benefits of this for the server, this also benefits the user. It was always a possibility in my mind that if somehow a value got corrupted (set to the wrong value) or an important setting's data was lost, the Armory would instantly error on load and become inoperable. Now, bad data is thrown out and replaced with defaults, and missing data is filled in with defaults. No more risk of breaking.

I still need to go back and do this same validation for Color Themes, Profiles, and Loadouts, but two of those can literally just call the functions used by the Share module. Only Color Themes will need actual work.

The remaining list of things to do stands at 17 items, 3 of which are some variation of "update old data/add missing data". I think only 4 of the remaining checklist items are complex or long, so I will hope progress continues at this pace. The next update will be another batch of small fixes like this.

October 20

I am vastly exceeding my estimated pace. The checklist is complete in its entirety now. I even did a couple of small extra QoL things while I was at it. Here is the last burst of fixes from the checklist:

• Fixed an issue with scrollbars sometimes not appearing on battle lists on the Battles tab.
  
• Added a setting for the Gear Params Prompt to either align itself to the item based on your tooltip settings, or to always open the same location. The default is still to align itself.
  
• When the options in a select list clip below the bottom of the visible page, they will now flip and appear ontop of the select element in a reversed order.
  
• Added a missing validation check for abilities, which caused them to be unable to be saved.
  
• Loadouts no longer require a weapon to be equipped to be saved/created. (Loadouts now tolerate a blank icon for weapon type)
  
• Windows are now limited to 4 tabs, to ensure that the names fit inside the actual tabs on the bar. Trying to drop a fifth tab will result in it being refused, and an error tooltip explaining why.
  
• Entering an invalid title for a window will now show an error tooltip explaining why it was not saved.
  
• Fixed significant issues with the code for saving changes to Loadouts; everything was flagged as different even if it was not, which was wasteful on resources.
  
• Improved validation of Profiles and Loadouts, reusing the rigorous validation code from Share Links.
  
• The Power tab will now remember whether it is set to Standard or Multi-view mode.
  
• Fixed an error where Settings tried to load when not logged in. To limit complexity, Settings will only be available when logged in on v4.0.0 of the Armory. This will be improved later.
  
• Removed an entire class from existence and merged its roles/methods into the Profile module.
  
• Added support for Achel to the client and server. Charon was apparently already defined/prepared for, just not implemented.
  
• Added the missing battle data to the Armory, and updated the text for how many clears you need for each achievement landmark in Brigid and Laura's raids.
  
• Reduced the height of the panel in the Battles tab to a height of two rows instead of three, to better match its height when showing boss stats.
  
• Redeemers and Space Time Distortion raids will now properly block stat bonuses from ineligible buffs when they are the set battle in the Power tab, in either Standard view or Multi-view mode.
  
• The Armory will now save which character you selected in the Overview tab, and default to it on your next visit.
  

Version checking was on my checklist, but led to me discovering that I already implemented it well over a year ago, and it was fully functional. A nice surprise from my past self. I also debated on the idea of writing a scripted tutorial to walk users through the Armory features, but it has been shelved. The amount of work it would require would not match the payoff.

All that is left to do now is add the missing items, those that built up over the last 14 months since the previous database update. By my counting, there are 305 outfit pieces missing right now, as well as one belt, 10 armor pieces for Achel, 34 hasta, and 32 grand targe. I finished fully implementing Charon's items (including icons) just a few minutes ago, and I am hoping to have Achel fully done by the end of today.

Unfortunately, this kind of data entry is what I am absolutely horrible at dealing with nowadays, so this will not progress at anywhere near the pace I was moving at before. I should be done within the next 7 days, barring a good event starting on the 24th, though. I am still confident to give an ETA of early November for the Armory going online. That may not be the date it is made available to all if problems are discovered during private testing on the online site, but the day is drawing near.

November 1

The news is mixed. The Armory hit a checkpoint on October 22nd where efforts began to try to get it online. I am not qualified to setup a server with an account system and hosting something like the Armory though, so I am working with another player to get the Armory online on their own site. In a curious twist, this is exactly how the first web version of the Armory went online too, back when the West server guild Ambition hosted it.

That player seems to be quite busy irl though, so progress is not as fast as I could have hoped for in an optimal set of circumstances. Our progress when we can work on it is good, though. A few bugs on the Armory have been found and fixed in this process, but it is mostly in the state it was on the 22nd.

I was originally planning to use this as downtime to take a break after getting an initial build of v4 done. I have not been able to just set aside the project though, so I have been working on other things over this last week. Incidentally, a keen eye may have noticed this thread is now titled "2023 Armory Progress" instead of just "2023 Progress". In a short bit, another thread will be going up, "2023 Archives Progress", where I have some news to share regarding my other project of long interest, the one that was not realistically feasible with the structure of the v2 Armory.