GU57 Interface Changes
 

I wanted to start a new thread for any UI authors that have questions about the changes made for GU57. Let's please keep this thread clean of speculation, suggestions, complaints etc. I'd really just like to hone in on questions from the modders and help them get things fixed in the remaining amounts of time before GU57 is released.

If someone asks a question and you know the answer, please feel free to chime in! I just want to make sure we have a dedicated spot for these questions.

I saw someone mentioned something about the new grab handle in the hotbars. Is this element required to exist in the hotbar xml?

I believe I read you're putting the clock back in (many have been asking about it)?

And if anyone can answer this one, what exactly is the Subtitle dynamicdata that went in? What's the difference from just the Name?

Thanks Rothgar.

The game crashes without the data for the handle if you try to show the spinner. But i made it 0,0 loc and size and it worked fine and does not affect appearance.

Subtitle appears to be target and timing data together from what i see.

Silat

Haven't had time to patch yet so I'll ask;

The new exp bar I gather will dock with the top and bottom of the screen so is it possible to make any page do that?

The grab handle shouldn't be required. The code should check for it and take it into consideration if its there. But if you leave it out everything should work. If you find this to not be the case, please let me know directly.

Yep, the clock is going back in.

By subtitle, I think you're talking about under the Maintained window, right? We currently had a value for amount remaining and time remaining. However, I didn't want a dedicated space in the UI for 3 lines of text. In most cases, a buff either has a duration or an amount remaining. In almost all cases, if something has an amount (poison, ward, etc) this value is more important than the duration. So the subtitle field shows the amount remaining if there is one, otherwise it shows the time remaining. This allowed me to condense the info down to a single text field.

Thanks, I'll look into that crash.

Only the XP bar will do that right now. I don't think we'd want every window to behave that way, so we'd need a set of options to control that behavior if we wanted this to be built into all windows.

dockhorizontal=true ,dockvertical=true ;)

Please,
Silat

Hehe, you did the easy part. Want to come write the code for it too? :)

Personally I'd like to be able to dock some windows. Eg., nail my chat window down to the lower-left corner, nail the beneficial and detrimental effects windows to the left side, pin the quest helper into the upper-right corner. I can position them so they're snugged up against the edges, but it'd be nice if they just snapped into place since I want them along the edges or in corners instead of floating free.

It'd also make changing screen sizes a bit easier. When windows and hotbars and the like are docked, the UI layout will adjust pretty decently to reasonable changes in screen size.

It kind of already does this. If you put your chat window in the lower left, it'll stay in the lower left when you resize the window. Move it to the lower right and it'll stay in the lower right.

I code enough to know what a mess eq2 has to be at this point between addons and staff changes. I would really like the snap-to functionality but from your response it sounds like it might be a major chore.

As for other things, why not use existing code from eq2interface for autoattack bar and have it off by default to reduce newbie clutter.

Click to cure is another feature that should be added to default why does there seem to be a lot of resistance to adding it to the ui? It would not add clutter or complications and there again you could lift the code wholesale from eq2interface.

Another feature I like is the reuse timer showing over the hotbar icons and I think that would be another newbie friendly thing to add to the default.

If you added those things to default then it would be used way more at least until you implemented LUA.

Thank you for adding the clock back I would have missed it :(.

Silat

Edit: Just saw your post on the soe forums and your statement that it was just resistance to adding for gu57.

We don't have any resistance to adding those things to the UI. Man, I think I've said that 8 times today on the official forums! I'm not quite sure how I can make it more apparent that we have no issues adding them. Its just a matter of time!

The AA bar would be pretty easy to add, but the click-to-cure I'd prefer to create an in-game command to do some of the work that the UI script is currently having to do.

The countdown timers over the hotbars is something I PLANNED on adding for GU57, I just haven't had time to get to it either.

Are we seeing a pattern here? Not enough time! :) I and many others on my team have been working 12+ hour days for the past few weeks to try to get everything in and its still not enough time to do all the things we want.

Sorry did not intend to make it sound like an attack.

Silat

Seriously... if you give me remote access to the existing classes for Macros, Hotbars, and Save settings, I will do my best to write the extensions needed to support ClickAbilities and ClickCures, then send you the revisions to vet and check-in to source control.

Not sure what language yall use, but with the requested classes in hand, I'd bet good money I could get 90% of it done with no hand holding. Possibly by Monday ;)

No worries, it wasn't taken that way! :)

This scares me! :)

RE the Map changes...

Seams to me that it should be possible to provide a template for the dynamic POI's with placeholders for whatever key is used to match the Journal reference, maybe a second key for the specific POI within that quest if POI IDs aren't unique across quests.

As long as the key(s) remains consistent from client to client, journal to journal, and the generated POI's inherit and fire scripts attached to the template, it should be possible to do a lot of script manipulation on the generated POIs.

The hard part then becomes discovering what the key values are if we don't have the dictionary on our end out-of-game. Not hard so much as a laborious process of using script to log the key values from a toon that has the active quest.

The new purple popup helpers seem to be un-movable even if you try to unlock them. This can be bad since other windows can get in the way. I made a new char with default settings/default UI and had a bunch of hotbars opened in their default location, and the helper popup was in a bad place there.

I'd recommend at least the middle of the screen or let it be movable.

sounds great man, and I believe you when you say none of this is as easy as we think. Just please, please save alittle time to look at PvP too ;)

Rothgar, First off thanks for the early heads up here to give us the time to get the mods in order before live that was very nice of you to take the time to do that.

second is my concerns with the default broker window and mouse cursers.

1.) Attached is my broker window that I use in game. I did not write the code save a few tweaks to my liking so please direct all credit to the origional creator. This is SO much easier to find stuff on the broker than the default ui I would really like to see the default ui have some version of this side by side window for buying & selling. maybe some simplified drop-downs such as these. I really feel that would benifit the noobs in helping them to search the broker for different items that are avail to them. My most often used part of this window is the button that automatically looks for specific tier (fabled, leg, MC, etc.) usuable for your class/tradeskill and within ten lvls. that is so handy :-)

2.) My guild leader is an older fellow with fading eyes and often "looses" his curser in the scenery and what not. is there any way that you could allow for some size, color, or both options for the curser please?
Nothing too extreme just a nice 10" curser that is florecent orange should do nicely ;-).

We've been discussing overhauling the broker window for a long time. I agree that the existing layout is pretty bad.

We've looked at modifying the cursor too, it'll just take some work to support both hardware and software-based cursors. Or perhaps this would only be customizable if you use the software-based cursor.

Regarding the Clock...

The way this window's visibility was handled in the past provided us with a mechanism for initializing custom windows and login scripts. I'm a little concerned the change to "hidden by default" will break this mechanism.

Would it be possible for you to include an "Initialization" window who's sole purpose is to fire "UIdidLoad" and "UIdidReload" events, guaranteed to fire after the rest of the UI finished rendering and was populated with data?

UIDidLoad would be a login only event.
UIdidReload would fire any other time the UI was reinitialized from XML.

This window would need to be scriptable but should have no rendered elements.

Edit: Optionally it could use existing event handlers if pushed off screen. Hidden to start, force a show after UI renders, then toggle Activate on/off for a reload.

Just so ya know Fetish, test server was updated again (yesterday?) and the standalone clock window now exists again.

Anyway, I support the hopes for some kind of initialization window, but I'm guessing this could all be done collectively with some kind of LUA implementation.

I'ed be happy with some DD that would send a pulse when Static Data was finished being pushed to the UI. I wouldn't need it to be an object, Just something I could toss in a DD of an object that would trigger a event to fire.

Rather than having empty windows that serve no purpose I'd rather add events that fire on widgets that want to listen for them, like your example of OnLoaded, etc. But I doubt I'd be able to do this by GU57.

By OnLoaded do you mean the widget would fire that event when it received the DD that was assigned to it? If so that would work just as good.

No, I meant it would fire when the UI was done loading. I assumed that's what you were talking about.

Dynamic data gets set at a bunch of different times. Sometimes the code initializes it to an empty string before the game server sets the value to something else. There's not a single process that sets all dynamic data.

Plus you can always use OnTextChanged to catch incoming changes of DynamicData, and you can always use a counter to check how many times it changes to prevent an infinite loop.

In that case wouldn't it be easer to just send that single to a gamedata variable and letting us read it with and object that can accepts a true and false states change? They way you said would work but just seems like it would be easer to change a variable then create code to make such an event. I guess if the UI widgets uses an inherent system it wouldn't be that bad to add it one of the base widget.

Any chance the default UI will include a auto attack bar? I would love to see that included if possible.

Not this GU, will likely be put in a later GU.

Is there a way to add it into default for the time without running a custom UI?

since there is no auto attack bar by default you will need to install a custom auto attack bar, sounds logical, no? :confused:

Hey Rothgar, this has bothered me for a while...

Is there any way to add commas to the Status Points prices in merchants?
It's really hard to make out the larger numbers, and we got commas in the personal status number.

Been asking about this over the years for a while, but it's definitely not bug ;)

183627SP hurts my eyes!
183,627SP lets me know it's not a million, and indeed just 100k

Explicit OnLoaded and OnReloaded events would be great.

A suitable alternative if its less work on your end would be DDs that set the following attributes when applied to a UI Object.

Text = Value
Press = Value
Activate = Value

For OnLoaded, Value is a BOOL initially set to "false" then changed to "true" when the UI has finished loading/rendering.

For OnReloaded, Value is a BOOL initially set to "false" then changed to "true" for 1 standard DD tick. After that tick, it flips back to "false" so its ready to signal another reload.

And of course when the DD values change, they should fire the corresponding event, onTextChanged, onPress, onActivate, onDeactivate.