Drakah

This thread is for the Blue/Gold Default UI (new) concerning bug issues that you would like to announce. Whether it is misaligned graphics, wrong XML code, etc.

Hopefully the staff from SOE can periodically check this area and issue a fix.

Please only post Bug issues.
There is another thread specifically for "wishes" found HERE.

__________________
Regards,

Drakah
shakahr.com
Remember...it is only a GAME

Drakah

Updated 10/17/08


UI BUGS:
Custom Gauges not functioning as the should

All gauges are stretching when sizing the gauge.
- if autostretch is true, then the gauges should stretch.
- if autostretch is false, then the gauges would not stretch.

Custom gauges and custom labels are not clickable.
- you currently can use Gauge0 as the screenID type for a player gauge to be in the group window, and would become clickable. If you add another gauge, using the same EQType in the same window, the additional ones are not clickable.

** Tested 3 ways on 10/17/08 **

Using Group Window placing custom Player information:

1) Using only one custom player gauge name, eqtype 1, with screenID "Gauge0", you CAN click yourself.

2) Using 2 custom gauges, both eqtype 1. One with screenID "Gauge0", the other without a screenID. Only the Gauge0 is clickable, the other is not.

3) Using 2 custom gauges, both eqtype 1. Both using screenID "Gauge0". Only the last Gauge in the (Pieces) list is activated as Gauge0 and is clickable, the previous one is not. Still looks like you can only have 1 EQType gauge function to be clickable.


LinesFillTint tags:
- defaulting to Black no matter what the color is set to. (ex: inventory window: set to 240/240/240 and shows up as black)


Typo:
EQUI_PlayerWindow.xml
- Line 452 should say "ManaPercLabel", not "ManPercLabel"
- Tags for GroupRoleAssist, GroupRoleTank, GroupPuller are named with GW_ instead of PW_


Non-UI Related

EQUI_PetInfoWindow.xml
- Window stays open after death regardless if you have checked the option to have it pop-up and close when you have/dont have a pet. Happens occasionally, but frequently when you die and get a rez.

Invis or Not Invis?
(fixed?)
- Characters are shown as if they were invisible with the parentheses, when they are not invisible. If you click off the invis spell, the bug does not happen. If you cast while being invis, and the invis drops, the parentheses are still on your name. Only others can see this.

Bembaru

Hi all!

These errors came to my attention recently, so I fixed (most of) them.

The following xml files are headed to QA this afternoon:

• EQUI_Inventory.xml
• EQUI_GuildManagementWnd.xml
• EQUI_LootWnd.xml
• EQUI_Animations.xml

Once QA signs off on them, the files will be pushed to the live patchers. I'm guessing tomorrow afternoon, maybe Monday you should see them come down.

Wasn't aware of the the Target of Target percentage issue until now. I'll peek at that early next week. Since it is in code instead of an external text file, it will require an executable patch. Not sure when we're going to do that.


-Bembaru
EQ Programmer

Bembaru

These will be a few more days. Sorry for the delay.

-Bembaru
EQ Programmer[

Drakah

Thanks Bembaru, I have updated the 1st post to be consistant with the changes and will update them as they become legitamate. I am glad to see the feedback from the developers so we can correct the errors before they become more of an issue.

Drakah

I updated the list to reflect the bug about the invisable brackets over the players name, even though it isn't UI related, maybe you can pass it on to be fixed.

Bembaru

This issue is a known bug, and currently assigned to Prathun.

__________________
-Bembaru
EverQuest Programmer

Drakah

Updated list 5/30/08

Drakah

Updated 10/11/08

Turlo

LinesFillTint appears to be defaulting to Black no matter what the color is set to. This is apparent in the Inventory window (set to 240/240/240 and shows up as black).

__________________

Haliken

Many things listed in the 10/06/08 list are opinion or feature requests and not bugs.


Gauges stretching from their X/Y offset to the bottom right corner of the gauge object is simply standard functionality now. <AutoStretch> determines if the constraints of the object will size with its parent container and has no bearing if the contents of the object will stretch to fit or not; until now, all graphical objects stretched to fit their size, except gauges. Now gauges obey the same rules

Yes this change broke many UI designs (mine personally relied on TONS of gauges and assumed they wouldn't be stretched), but accounting for the change isn't particularly difficult.


This isn't a bug. You're just making a request.



While yes, the target buffs should auto-sort right to left like the other buff lists, you CAN manually place buff icons by setting their <AutoStretch> property to true and giving them the <Anchor*> values needed to place them where you want.

Your last sentence there runs directly contrary to the introduction of the new TopLevelWindow system which lets us add our own custom windows, ability to add buttons that open these new custom windows, and many new objects being put on a new EQType system so they can be moved around (mainly voice chat related).


This is standard functionality and not a bug. No custom labels for a gauge percent disappear when zero. Only labels with a specific <ScreenID> in their standard parent window will disappear when their value reaches zero. You're asking for one label EQType to behave differently than the others.

Asking for all labels to disappear when zero would take away customization, as currently we can pick whether they disappear at zero or not by giving them the correct <ScreenID>. In addition, these specific <ScreenID> can make objects other than labels disappear when the value is zero.


Feature request, not a bug.


Feature request, not a bug.


Not exactly a bug, but a poor design decision. When using tell windows, ''tells you'' simply doesn't occur in the text. Instead it's ''Name -> name.'' You may be able to audio trigger ''-> Yourname'' to trigger a sound. If ''->'' can't be made an audio trigger, then it would count as a bug (in the audio trigger system, not the tell window system).

---

I know it's harsh criticism of the list, but I believe a bug report should be a report of bugs, not a feature wish-list.

Enok

SmileyFAAce_

I wish to have the make"Popcorn Button "fixed in the PlayerWindow please...

Hiyas Enok..

SmileyFAAce_

Drakah

They are when they do not conform to the normality of the way the interfaces behave whether in-game usage or code base.




Again, if it was to be stretched, it would be autostretch=true. Gauges coded to be false, should stay false. It is not a request, its a fact.




The pet window is the same structure as the target window in relation to buff icons. You are able to copy the Pieces of the Pet window buff icon tags to the screenitem and giving them a static location to place the buffs where you want. However, the targetwindow for some reason ignores the placement regardless. The conformity is not identical.




I have not fully examined the functionality of that file since it only states it affects the attributes listed to the window when activated.




EQType 120 is a Percent, not a name, or a item in your bag.
When you target someone, and the targetoftarget is active, and they do not have anyone targeted, the EQType 120 shows as 0% all the time until they target something. If you look at the leadership window targetoftarget, it does not do that. It should act the same way and does not.





Well you certainly were able to raise my blood-pressure on your wording of your responses, but thank you none-the-less. I will re-arrange my wording from bugs to requests and hope that suits you more.

taylor13

This isn't a default UI error, but a general UI error.

Label EQType 135, target of target name, doesn't display a name if the target's target is a corpse. The text of the gauge does display the corpse name correctly however.


Also, has anyone ever tried putting the HoTT window INSIDE the target window (or any other window for that matter)? Wouldn't that allow usage of the specific screenid which would cause the % labels to disappear? The only detail would be, what would happen if someone tried to open the window normally? =/



I have to agree with Enok. Unfortunately, Sony controls the SUITE standard. Changes to that standard may create bugs for backwards compatibility, but the changes themselves are not bugs, unless the default UI didn't comply to the new standard. DirectX would be a great example of that =/

--Lashden

Haliken

I've tried all sorts of ways to ''hijack'' ScreenID's to use them in another window, but have never gotten anything to work. EQ only makes use of a ScreenID once, so if it's in two places (even twice within its ''home'' window) only one instance will get the benefits of the ScreenID. In addition, when the HoTT window (as an example) is made a child of the Target window, its contents become children of the Target window as well, so HoTT-specific ScreenIDs stop functioning.

The only success I've had is where existence of one object can be toggled, so two objects with the same ScreenID can coexist, though only one is functional at a time. If memory serves, you can create a child Screen object with a close button, put a ScreenID'd object inside and one outside of it, and ordered so the one inside the Screen object is functioning. When the Screen object is ''closed'' the ScreenID'd object outside of the now-closed Screen object starts functioning.

Embedding the HoTT window in the Target window is also a pain due to the ordering of the two windows' XML files within EQUI.xml. You either need to edit EQUI.xml to change the order, or gut the Target window XML and put its contents in the HoTT window's XML file.

Basically, one solution would be for SOE to add ScreenIDs to the target window specifically for HoTT-related objects for UI modders to make use of. They've actually done this for the group window to add support for putting player information (mainly Role-related) by enabling ScreenIDs for group member ''0'' (zero).

Enok