I think in most cases, people filter this stuff out of their combat tab so they only see the info they are interested in.

Container is fine, only I mentioned the other idea because your first proposal was to save (and thus parse) everything.

And regarding the non-custom values I was only talking about those which get saved anyway if the user manipulates the window with the mouse. To make this clearer: If I move a window with the mouse the position currently gets stored to the uisettings.ini file. If I move a window via script the changed position will not be stored, but it would be great if it could, along with all the other tags which already get stored (size, visible, etc.).

Of course we could store the values in your custom tree and apply them on first load via script but IMO that would unnecesarily duplicate the data in the settings file.

What I meant by storing everything, was only to store custom properties saved in the root UI window. This way I'd look at the root page and only save data from there. However, after mentioning it, I think this would look cluttered and I'd rather see the data confined to its own container.

I see what you mean by values like location not saving. I think they should save if something caused the window to trigger a save of its values since you really are updating the location. The problem is that the windows only save their values when something in code modifies them. I could probably expose something like a function that you could call to force a window to save its data. This would let you make changes to visibility, location, size, etc., and make sure the window persists those values.

That's one possibility, but since you'll need to parse the window properties anyway for the custom data (be it in the root page or a container) you could simply at the same time parse location, size, visible, etc. and store them as well, no?

I only planned on saving the custom data when the game shuts down and saves all data for the windows. And at that point we're already saving the standard window data. So that makes me wonder why your changes aren't being saved. Are we talking about custom windows here?

Any window. I just double checked on the persona window: Set it's size during runtime via script, camp (uisettings.ini get saved) and log back in, the window will be back at the original size. If you resize the window with the mouse however the new size is stored and reloaded when you log back in. That has always been like that. The command /save_uisettings ignores scripted changes also.

I'd have to do some digging on that issue.

A window only has one "size". When the uisettings file is saved, it grabs the actual values from the window. There's no hidden size field, so if the window size is modified I'm not sure what would cause it to not save. It shouldn't matter if it was modified in script or by a user. The only thing I can think of is that the window doesn't think any values have changed, so its not really being saved. Maybe try changing the size with script, then move the window with your mouse so the location changes. This will definitely trigger an update for that window. When you camp and come back I would expect the location is where you left it since you moved it with the mouse, but would the size revert back to the old size, or the new size that you set with script?

Yes that's it, sorry should have mentioned that.

Well if I made a button that OnPress the value was something like Parent.Size='1,1' it would change the size of the window, but it wouldn't save. It only saves if the size value is changed manually (ie resizing the window). Same thing with things within the UI window like location of other objects.

If I understand gm9 he wants to have it save the changes made by scripts and buttons and all that. I wouldn't mind it either.

Well that got resized a bit I can post a bigger version if needed!

Things to note!
Maintained window Don't show until canceled buffs please move those to somewhere else I don't care.

Raid window, please only show the three groups you AREN'T in then make it so you can drag and drop to the group window. This would free up a TON of space and still allow them to be moved separately.

Hotkeys recast show or at least the option for it in hotbar settings, make out of range and out of power more visible( being colorblind Its to opaque for me to make out :( ) Show timers for items & item macros.

Player/Group Why separate these? The red bar underneath is the pet health.

Target window show hp and power percents.

Compass ad a fancy orb or something where the arrow thing is and make that the start button.

When is the dynamic data hitting test??

when
 

so when are you guys going to start working on this beautiful idea? :D no offence but the standard UI in EQ2 aint even half good. we rly need a new or atleast an option that comes with the game itself.

Feedback thus far
 

This has been an interesting thread to see, I rarely come here anymore but wanted to see what was needed to make the new maps and saw this thread and got completely derailed.

Firstly - 1 chat window would be my recommendation. Reason: combat window is worthless, thats what ACT is for. If you need real time information concerning your combat log you arent going to get it from reading the scrolling text. I like the tabbed approach, its easy enough to click back and forth. Level 1-9 chat has become really the defacto chat channel on most servers it seems due to alt necessity. So many people I know anyway have one tab set up for combat, 1 for all chat channels, and the primary has group/guild/1-9/70-79/tells in it for the things you typically want to see anyway.

(2) Agree that the primary benefits to the new UI should be increased functionality, minimalized foot print and lanscape usage.

(3) With regards to advanced features such as click to cure. I think even though these are advanced features they are more helpful to newer and more casual players in understanding their class and getting some assistance in playing them. This is one of the most useful mods out there and personally I think it should be included.

I think you're being a little hard on the Default UI. Maybe I'm biased, but I don't think its that bad. Keep in mind its intended audience is new and casual players, not advanced players. This project also needs to focus on new and casual players as well.

I worked on some ideas this weekend but had the hardest time trying to make everything fit in a minimum spec of 1024x768. I really wish we could count on widescreen or at least 1280x1024 but statistics show that almost half of our users are still on 1024x768.

Because of this limitation, I really don't see a way to incorporate more than 1 chat window unless there is a separate layout for larger resolutions. As soon as I have my mockup done, I'll post it. Has anyone else had time to work on any ideas?

/speechless

That's really surprising. Judging from the downloads of the 1024x768 compatible version of ProfitUI (or rather it's bottom bar) less than 1% of its users use that resolution. That likely means that nearly all of the 1024x768 users are using the default UI (or other mods, but I'd assume the distribution is comparable for those). So it would appear rather important that you keep supporting them.

PS: Is that display size or client size? Because I can imagine people running 1024x768 in windowed mode on a 1280x1024+ screen.

The PvP server is big in population and I guarantee you that most PvPers use at least 2 chat windows. I do myself.

Well I'm sure Advanced Users would not use 1024x768. That might contribute to your own statistics because I'm sure most advanced users use ProfitUI.

Hit test this morning.

As far as the dynamic data goes few problems if you care!

It has the same flaw that my auto attack script did, Riposte triggers an auto attack swing even though that doesn't consume your auto attack. Making this 100% useless for tanks.

Also if you get hasted the progress bars rate changes, which shouldn't happen. Being hasted mid cool down doesn't effect your time till next auto attack. Because of this you give the appearance that you should be auto attacking but really cant.

They should also toggle visibility so you can update double bars, single bar, ranged or primary attack. Until all that gets fixed this dynamic data sadly might as well not have been put in.

Edit: I SHOULD ADD They should also toggle visibility so you can update double bars, single bar, ranged or primary attack. That is the most important fix if you change that it solves all previous errors. Just make it so when they aren't filling up or counting down that they are not visible. If you ranged auto attack only it would become visible etc...

Well I was working a bunch of layouts just for fun one night working with my own UI and releasing a full package.

Anywho... this is just a mock-up design done in photoshop. I just used my own pieces, as I'm not really good at gfx design or coming up with a style to fit everything. I'm a minimalist and don't like titlebars and extra spacing being taken up by frills.

-The height of the bottom hud is about 300px (299).
-It was created in a 1280x1024 resolution. (1 step above the statistic norm)
-I included 2 chat windows just because.... I don't use 2, but this leaves more space for those like me.
-6 hotbars shown. I use 5 plus smaller hotkeys for potions, etc.
-compass, EQII button, heroic oppertunity window shown (scaled) and casting bar....
-mini map scaled abit. not sure what it's minimum size is.

I just put things I thought were most used most often. Missing most importantly would be the Journal Helper window, the pet window, and effects window. Most have these pretty stretched out along the side of their screens however.

Anyhow... here it is.... I hope it helps as some kind of start or "idea" starter for layout. Sorry for lack of design/style.

All great feedback so, no problemo!

* New AutoAttack dynamic data will now be more accurate when switching weapons or being hasted
* Visible flag is toggled when no weapon is equipped
* Riposte will no longer cause it to reset to 0
* Visible flag is toggled when progress is 100% and autoattack is off

This should be on test next time it is hot fixed.

Basically if autoattack turns off I let the bar go to 100% (ready to swing) and then hide it. When autoattack is on everything works as normal. When no weapon is equipped the bar is hidden. Also autoattack is broken out into ranged autoattack and melee autoattack. I also added "cl_enable_autoattack_dyanmic_data" which you can set to false to make these not update at all.

Thanks! Some other things are if you take off or put on your weapon it starts the timers even though you don't swing. Didn't have a chance to test it but also intercedes worked the same as riposte and for my auto attack bar triggered it as well. Visibility toggles sound fine and making sure they continue even if you take off auto attack(at least till they hit 100%) is very important good catch. If it all works correctly the dynamic data should work fine.

Ill keep checking back on test to see when they get updated.

Intercede may indeed do that I will have to test it. As far as taking weapons on and off that should work correctly with the changes coming in the hotfix.

You can autoattack without a weapon equipped.

More technically it is toggled when delay is <= 0.0 so if you have a 1hs and nothing in secondary, or a shield it is toggled off for secondary but on for primary. If you have no weapons and are boxing both primary and secondary are toggled on.