Home Forum Downloads My Favorites Register FAQ Mark Forums Read

Go Back   EQInterface Forums > General Discussion > SOE Corner
User Name
Password

Reply
 
Thread Tools Display Modes
Old 10-11-2008, 01:29 PM   #16
Haliken
Quintessence of EQUI XML
 
Haliken's Avatar
 
Join Date: Sep 2002
Posts: 773
Interface Author - Click to view interfaces
Default

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

Quote:
Originally Posted by Drakah
Updated 10/06/08

Custom Gauges not functioning

Gauges that do NOT have an autostretch feature (false) are still being stretched if the gaugesize is wider/longer than the actual drawn graphic. The only time a gauge should stretch is if you are using autostretch=true, and using the window margins to place the gauge where it needs to be when resizing the window.

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.

Quote:
Custom Player names, using EQTpe Labels for names, show up always Green when you are a leader. There should be a way to distinguish between if it should change color or not. (ie:EQType Player Name Static Color, EQType Player Name Dynamic -- as well as those for the party members).

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

Quote:
Target Window

The buff icons show from the Upperleft of the screenitem, and are displayed left-to-right. However, the Petwindow, Buffwindow, SDwindow all display from the Upperright going right-to-left. It should stay consistant.
You need to have the ability to set the speicific locations of the buffs for customization, along with eqtypes for each buff to be displayed in other windows. I have tried adding in Location X/Y in the TargetBuffs and moving them out of its own screen item window as I did with the Petwindow, and no matter what I do, I cannot statically place the buff icons in a specific location to change the order or display where they need to be. It seems we are getting less and less customization for the UI community.


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).

Quote:
The EQTYPE: 120
(target of target percent)

It always shows a 0 for the target of target health when something isn't targeted in the target window, or any other window when placed.
Only when your target has something targeted will it show the actual health amount.
It should not display a 0 at all, ever, at any time – maybe unless it is a corpse. There is no such thing as 0%.
Easily reproduced when you are not grouped.

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.

Quote:
Player Window

This is the only window where you can use the "Roles" submenu by clicking on your name to get the menu. If you try to utilize roles in another window by customization using eqtypes, it will not work. (see gauges/labels not functioning section).

Feature request, not a bug.

Quote:
Desperate need of an EQType for the CombatStateAnim (Rest Icon) and the AttackIndicator pieces, so we do not have to rely on needing to utilize only the playerwindow for that. For those people who integrate windows together, and want to just utilize 1 window (ie: group window), you would loose those 2 things (as well as the Role options).

Feature request, not a bug.

Quote:
Other:
Using Pop-Up Tell windows
  1. Audio triggers are not fired when a pop-up tell window is used. If you have an audio trigger set to "tells you", it does not play unless you turn off the pop-up tell window option.

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

Last edited by Haliken : 10-11-2008 at 01:38 PM.
Haliken is offline   Reply With Quote
Old 10-13-2008, 05:41 PM   #17
SmileyFAAce_
Guest
 
Posts: n/a
Default :^)>

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

Hiyas Enok..

SmileyFAAce_
  Reply With Quote
Old 10-17-2008, 06:27 PM   #18
Drakah
Skinning Guru
 
Drakah's Avatar
 
Join Date: Jul 2002
Posts: 1,076
Interface Author - Click to view interfaces
Default

Quote:
Originally Posted by Haliken
Many things listed in the 10/06/08 list are opinion or feature requests and not bugs.


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


Quote:
Originally Posted by Haliken
(Gauges stretching...)

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.


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.


Quote:
Originally Posted by Haliken
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.


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.


Quote:
Originally Posted by Haliken
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).


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


Quote:
Originally Posted by Haliken
(The EQTYPE: 120...)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.


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.


Quote:
Originally Posted by Haliken
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



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.
__________________
Regards,

Drakah

shakahr.com
Remember...it is only a GAME
Drakah is offline   Reply With Quote
Old 10-20-2008, 01:31 PM   #19
taylor13
A Ghoul
 
Join Date: Oct 2006
Posts: 19
Interface Author - Click to view interfaces
Default

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? =/

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


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
taylor13 is offline   Reply With Quote
Old 10-20-2008, 02:07 PM   #20
Haliken
Quintessence of EQUI XML
 
Haliken's Avatar
 
Join Date: Sep 2002
Posts: 773
Interface Author - Click to view interfaces
Default

Quote:
Originally Posted by taylor13
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'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
Haliken is offline   Reply With Quote
Old 10-30-2008, 12:11 PM   #21
Sylphan
A Predatory Creeper
 
Join Date: Aug 2002
Posts: 254
Interface Author - Click to view interfaces
Default Timer bugs

Currently, label item eqtype mercenary/TimeLeftText does not work... but maybe it's not supposed to.

The label item mercenary/ManageWnd/TimeLeftText does show but has some odd behavior. If you put it in another window (I used the potion window), it counts down twice as fast as normal. The version if it in the mercenary ManageWnd also counts down twice as fast. So it gets down to 0m 0s in only 7 and a half minutes. Then it continues to show 0m 0s for the next 7 and a half minutes until you are actually charged upkeep, at which point it is reset to 15m and starts counting down at double-speed again.
Sylphan is offline   Reply With Quote
Old 10-30-2008, 12:27 PM   #22
Halelen
Lord Doljonijiarnimorinar
 
Join Date: Jan 2003
Server: Povar
Posts: 1,047
Interface Author - Click to view interfaces
Default

Actually I have the hott info displayed in the target window and have no hott window at all. I have no modified hott window and no issues.


Hal
Halelen is offline   Reply With Quote
Old 03-13-2009, 04:55 AM   #23
Dimencia
Premium Member
 
Dimencia's Avatar
 
Join Date: Oct 2004
Posts: 204
Interface Author - Click to view interfaces
Default <EQType>CloseNotClicked 3-12-09

<eqtype>closednotclicked</eqtype>

ceased working after the 3-12-09 patch
__________________
Dimencia Everhate
Dimencia is offline   Reply With Quote
Reply



Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -5. The time now is 11:11 AM.


vBulletin Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
© MMOUI