shillingworth

Have a bit of a list of updates to do to this, some I have planned out while others I'm still feeling out as I play using the UI. Easy enough to pick up the code changes, behavior of all the newer stuff and what each element affects takes a bit to observe.

Just learned in Linux you can actually use 'tail' with the UI log. So 'tail -f UIErrors.txt' dumps all new lines to terminal. No idea why I thought this wouldn't work before, maybe because EQ is so finicky to get working perfectly in Linux (mouse is particularly tricky).

shillingworth

Uploaded a preview of what some of the changes in place look like. Note that a lot of the gauges are broken right now because I'm in the process of changing how all of that is rendered to utilize layout boxes for a consistent look. I am also separating my UI pieces into individual files grouped into folders. The EQUI files will mostly be scene graphs when I'm done with the actual elements loaded in their respective files.

An example of this is the player HP gauge is in it's own xml file. This file contains the player's HP value, percentage, shadow outline on the percentage, gauge, and regen amount. The MP and EN gauges are then just copy, paste, regex to replace the appropriate EQTypes, names, and remove any not needed parts like how XP gauges don't need regen or actual value text.

Will be doing the same with the stat displays and maybe move the text onto an overlay layer for ease of adjusting. Still attempting to set up a recreation of the effects to produce that style of text. Originally the text was pixel art then 3 or 4 layer effects stacked up. Currently having to produce it with sampling similar pieces and plopping down pixel art. Way out of practice having focused on CAD so much the last few years.

Also unlike the old gauges, these are all resize-able to some extent.

Update:

Had to remove the outline effect from names since the player name and merc names can be automatically tinted, the shadow effect only works if I can control the tint. Managed to finish the group window gauges and names. Next I'll get the new gauges into the Target / HoTT window and start work on new buttons for group roles. Maybe at that point it will play well enough to upload.

shillingworth

Preview version will be merged in for the next update along with minor fixes. A couple gauges were 1 pixel off alignment. Testing a chopped down version of that status window as an alternate form. I don't like having all stats displayed on my shaman or bard but my paladin is way too technical for a simple display to work out. Also did some tweaking to chat windows to crunch down the page tabs and squish borders tighter, really not liking this tabbing schema they used, seems to want to be huge for no actual benefit.

shillingworth

Getting this ready for the next update turned into writing a small program to handle layout for all the stuff in the extended target window, then repurposed it to rework the group window. Currently it's just generating all the group members from a copy of the first member's xml and string replacement. Same with target window. Still need to add group role indicators to the group window but ext target is being wonky so trying to figure that one out. Sometimes I can use the context menu, sometime's I can't. Something is overlapping wrongly I suspect.

Edit:

Found the clickability problems on the player window, group window, and my new extended target window. It's the percent labels. I created boxes for those that were same size as the gauge but shifted upward then right aligned the text for reflow to drop it into the correct place. Turns out the empty space of a label element is actually clickable space and opaque, so it can occlude other clickable elements. The actual role settings are on the HP gauges like I initially thought.

Solution is to adjust all of the labels, easy for group, and extended target. For player window going to write the layout function like I did with those. In the updates will be a folder called "generator" that contains the source for the generator project, details will be provided for running it in case need be by other users but it's dirt simple C# string manipulation.

shillingworth

Forgot to mention in the update. If you would like to make any changes to the XML, I highly suggest you install or open VSCode, and load the workspace file. It will load up the UI and the default UI in a workspace, assuming the folder is in EQ's uifiles folder. It might even ask if you would like to install the C# extensions, not sure how large the download is but goes fast on my machine, and is used for the generator.

NOTE 7-7-2022 Version: I didn't realize I changed the chat window to have a blank draw template during testing. This means for the couple of places in the game where you get a popup chat box that doesn't go into a tab page, there is no titlebar or border to easily close it or resize it.

Proper fix for the chat spacing I was solving by doing that is to change the following two lines in EQUI_ChatWnd.xml:
* Line 35, change WDT_Blank to WDT_Inner
* Line 39, make sure it says 'false' for Style_Border.

This was intended to remove borders so that text fits tightly in the chat window instead of stacking templates. The original chat window is just a child-window for one of two variations to use, so makes no sense having border when the containers for it already do.

shillingworth

BUG: found a bug that I didn't notice during testing. I use the open-source variant of Adobe's Source Code Pro font set, which is a matching set of San, Serif, Monospace, and variations of each to provide a cohesive set for coders and engineers. They tighten up the spacing of characters both in alignment and glyphs, so the characters tend to be narrower, especially numbers. So using one of the MSFonts that are made to a more medium glyph size and spacing causes numbers to clip and wrap. Fix is in the next version in the form of more space to accommodate larger fonts and disabling word-wrap in single-line labels.

At some point I'm going to add some xml parsing to the generator to go through all labels and give them compatible parameters as well as gauges to sort out different behaviors. This is one of those things I had fixed in other windows but forgot for some.

shillingworth

Developed a technique to tile border edges semi-dynamically. Have been trying to figure this out in order to make all windows a bit easier to modify and a bit more dynamic. I would like to get it to the point where I can just drop desired elements into a vertical layout box and let it flow the elements according to what elements are used.

If you look at the left edge of the player window, group window, casting window, and stat window it's all the same edge. What I created was dicing up the spell window into "items" being each spell or gauge that could have been there.

LayoutBox -> LayoutBox -> VerticalLayoutBox -> LayoutBox -> StaticAnim

That's the order of elements to produce that edge dynamically. It's kind of hard to explain but makes sense when you see it. Will be in the next update for spell window and maybe more depending on how well it works to achieve a dynamic border edge for the fancier windows.

Liking this technique so not sure just what all I'll do with it before the next update. It's really removed one of the more painful steps to adding and removing window elements.

Valisbourne

I really like what I see in this UI set (first time I've come across it). This one feels almost custom built for what I actually WANT in a UI.

Is there any way I can resize the bags? They are tiny and (/sigh, getting old I guess) hard to see for me. With the current setup where you can't just drop in other UI pieces for it, it's the one thing that might make me use a different UI.

shillingworth

You can replace the container xml with one from another. Ones from other UIs might have references to stuff in those UIs but any that use the default stuff should work fine. I overrode a lot of the default stuff so it should pick up at least the borders.

shillingworth

Going wild with the text stacking to create outlines and glows, I replaced the AYAUI group role indicators and experimented with a group window using the dynamic borders I developed for the spell window. This just might be the way forward for most of the windows. Certain windows like the player window and target window will only kind-of benefit from the approach. Going to be wiping out the pixel art text in favor of rendered labels that look very similar but using whatever font is loaded. Was testing with Arial and Source Hans Sans, so I know it looks acceptably good with Arial though spacing is perfect on Source Hans Sans.

I'm surprised how well the game handles the text stacking, usually that's disastrous for sprite font systems but EQ handles it like a champ.

Not sure how much I'll use the dynamic borders I set up for the spell window. Attempted to use them to replace group window and not sure. Need to set a lone serif bar set up to plop in things like the lower corner of the group window to see if that make that difference. It makes layout way easier but seems lacking without the full serif dressing on the border.

EDIT: Abandoning the idea of the dynamic borders. The problem is since none of the elements involved have a fixed sized except for static animations that are layers under layers deep, there's no selectable area to move the window. Even abusing frames within frames to maybe keep the border edge selectable just doesn't cut it. I really dislike how the rules for what constitutes clickable zones and what doesn't varies so wildly from one element type to another.

shillingworth

Have everything ready for the update except for one problem. Somewhere in the large amount of changes I made, the spell window become unmovable. Can't click anywhere to get a drag handle and I have absolutely no idea why after fiddling with it for awhile. The group window did the same thing but after reverting changes to how it's background is drawn back to a static animation it got the top-left drag handle back. Same thing did nothing for the spell window. This clickable area for various features is infuriating without a real freaking manual to look at to see what exactly is the actual behavior of the UI system. Ugh, I'll just debug it with a 3rd party program later, I already know which one can spy the entire UI structure in memory.

EDIT: If anyone was curious what the problem was. VerticalLayoutBoxes just don't behave how you would think they do. They work differently with coordinates, anchors, and all the parameters we have to control placement. As I learned they will seek out the nearest (in hierarchy) Screen element and anchor on that instead of whatever element contains it. They also ignore the anchor offsets but there seems to be some rules to that as some ignored certain anchors (usually bottom-right) while others just autostretch to fill available space regardless of what settings you use. After changing those all to TileLayoutBoxes with HorizontalFirst set to false, it all cleared up and clickable areas for drag handles were restored.

shillingworth

Have a few minor things banked up for an update so far but nothing near enough to justify uploading yet. Been focusing a little on learning to multi-box, leveling, doing some achievements to unlock a couple things I'm missing, and leveling. Really picked up boxing well once I figured out a software stack to reasonably manage multiple sessions. Wild hotkey idea for melee boxes. Auto-follow will bring them to a tank, range attack will snap them to face the mob, attack can be turned on from a command, throw that all in a hotkey. It's so silly but satisfyingly effective.

Anyone else find themselves using commands like /emote to soak up cycles for /assist and /tar to settle? I don't remember those having so much delay to settle in the target for successive commands in the past.

shillingworth

Updates may not come for awhile, dunno for sure though. I am in the process of quitting smoking after having smoked for 20 years. Both tobacco and mj. Got off to a really rough start, almost wound up in the hospital because I couldn't eat anything. So quitting one then quitting the other. I know mj helps some quit but for me it made things much worse.

shillingworth

Next update will contains some significant changes to how the UI is loaded. With these changes things will become a bit more modular. This is both to make it a bit easier for me to manage with the complexity growing rapidly and to make it easier for others to maybe copy out pieces they like into other UIs.