Second player window woes.

[Solf]

Cross-posted from: http://eqiiforums.station.sony.com/e...ssage.id=13602
(because I have no idea where there are more people with in-depth understanding of EQ2 UI mechanics)

I also found this thread: http://www.eq2interface.com/forums/s...ead.php?t=6146
(this seems to confirm my worst fears)

Nevertheless perhaps some of you could suggest some tricks to resolve some of the issues I've been having...



So the other day I decided to create a second player window for myself (the one that shows my own hit points/power). Why you ask? Because I prefer to have one in the middle of the screen for soloing and another one near the group window for the cases when I heal in groups (so that I can see both my and groups' hit points in the same spot).

Looked simply enough -- I just copied original player frame (eq2ui_mainhud_player.xml) into another file and modified the name of the page so that they wouldn't clash. I also included this new file at the top of the eq2ui_mainhud.xml file.

Unfortunately it didn't work as well as I hoped it would. Here are the problems that I've encountered and if someone can help with them, it'd be greatly appreciated


Auto-showing custom windows on entering the game

The first problem I encountered is the inability to have my custom window (second player window) to automatically show whenever I enter the game.

I tried embedding "show_window" commands into OnShow handler of the default window (Compass) as suggested in several places, but it didn't seem to work.

The best I've managed so far is to execute show_window in Target's window OnShow handler -- meaning that as soon as I target something, my window shows up. This is "ok" from the gameplay point of view (for this type of window). Still, it would be best if the window was shown immediatelly upon entering the game. Any advice?


Tooltip and click-targetting

After sorting out issues with window showing I've found out that custom player window sort-of works (it displays player's health and mana, updates correctly, etc.). However tooltip, click-targetting, and right-click popup menu do not work (i.e. if I hover my mouse over second player window, tooltip with hit points and power values is not shown; similarly if I click this window, my character is not targetted [unlike what happens with standard player window]).

I though that actiontype="Player" in page declaration is responsible for tooltip and click-targetting behaviour but apparently it is not enough. Is tooltip and click-targetting hardcoded into EQ2 somewhere? Essentially meaning that you can't have fully functional player window except for the default one?

On the other hand "concentration bubbles" which make use of DynamicData declarations seem to work.


Debuff display

Similarly to the tooltip & click-targetting issue above debuff displaying (the four icons in player window for trauma/arcane/noxious/elemental) doesn't seem to work properly. It does show icons when appropriate, but it doesn't render proper image on those icons (i.e. doesn't show proper debuff icon with a count) but instead simply shows them as gray areas (the way those icons are setup in interface files).

I was able to somewhat work around this problem by replacing default "gray area" image for those icons with the images appropriate for each debuff type. But needless to say this doesn't solve debuff count issue.


Summary

Overall I'm trying to understand -- is A LOT of stuff brutally hardcoded into EQ2 implementation and you can't do much except for changing style somewhat by modifying default templates or am I missing something obvious here?

I don't think having two separate player windows can be considered an exploit or something


P.S. I also took a look at the raid window implementation... It doesn't contain a single DynamicData declaration! I guess my worst fears are true and one can't do much besides altering color scheme and layout of windows?

[Zonx]

Highly dependant on the window. As you've discovered with the player window, DynamicData is provided for many things but these don't always contain everything you'd expect, like tooltips that match the hardcoded version of the same element. They raid window has no corisponding DDs. The XP window can be entirely reproduced except for the right-click menu.

When you run into a roadblock like this, you might have better results with another aproach. Ask yourself what it is you really want to acomplish. Sounds to me what you really need is a simple button that toggles the Player window screen location. No need for 2 windows. Such a button script would look something like this...

OnPress="parent.normalloc=parent.location
parent.location='xxx,yyy'
OnPress=OnPress2"

OnPress1="parent.normalloc=parent.location
parent.location='xxx,yyy'
OnPress=OnPress2"

OnPress2="parent.location=parent.normalloc
OnPress=OnPress1"

This script will make a single button toggle its parent window between the normal location you place the window and a hardcoded location, just replace xxx,yyy with the screen location you want the window to move to.

[Solf]

Yeah, I've thought about simply repositioning window as well... But then again, I'd prefer to have two windows and I'd prefer near-group player window to look like group member windows (i.e. w/o concentration bubbles) Exact windows look makes it easier to "control" healthbars

But thanks for the advice.. "Alternative approach" is the name of the game at this point

[Landiin]

The reason why your OnShow event handle in the compass didn't work is because you have visible set to true, so the OnShow never fired. Set it to !visible in the xml file and when the game loads it it will change it to visible thus firing the OnShow event.

Also I wouldn't use show_window in the OnShow event, I would do Parent.<window name>.Visible=Ture. show_window works but it has to be scripted in twice taking up clock cycles plus having to run the command show_window when it could just set the property by direct paths without having to execute the show_window command.

[Solf]

Originally Posted by Landiin

The reason why your OnShow event handle in the compass didn't work is because you have visible set to true, so the OnShow never fired. Set it to !visible in the xml file and when the game loads it it will change it to visible thus firing the OnShow event.

Also I wouldn't use show_window in the OnShow event, I would do Parent.<window name>.Visible=Ture. show_window works but it has to be scripted in twice taking up clock cycles plus having to run the command show_window when it could just set the property by direct paths without having to execute the show_window command.

Oh, OnShow _is_ fired, I know for sure. In my code it does many things, not only windows showing. And everything else works.

Setting Visible=true on custom windows appears to do nothing. Or, more correctly, it doesn't show them UNLESS you've already activated them once with show_window command (which doesn't need to be issued twice, btw, if you issue it as you would from in-game prompt (OnActivate="show_window MainHUD.Compass.Solf.ShowWindows") and not using that fancy = syntax).

So, basically, my experience thus far is:
- If you want for window to be shown (_any_ non default hud window including such things as ZoneReuse window), you HAVE to issue show_window command. Setting Visible=True has no effect prior to show_window.
- After show_window has been successfully issued, you can manipulate window using Visible=true/false.
- show_window appears to do NOT work when issued from OnShow handler of the standard windows that are automatically-shown (i.e. it doesn't work for Compass window, but it does work for Target window that is not shown immediatelly).

I've ran quite a few tests of all this.. and I'm reasonably sure that it is how it works.. unfortunately.

Of course, it still doesn't preclude me being wrong If someone has a working code sample to share that would auto-show custom windows on startup -- I'd greatly appreciate that

[Landiin]

Originally Posted by Solf

Oh, OnShow _is_ fired, I know for sure. In my code it does many things, not only windows showing. And everything else works.

Setting Visible=true on custom windows appears to do nothing. Or, more correctly, it doesn't show them UNLESS you've already activated them once with show_window command (which doesn't need to be issued twice, btw, if you issue it as you would from in-game prompt (OnActivate="show_window MainHUD.Compass.Solf.ShowWindows") and not using that fancy = syntax).

So, basically, my experience thus far is:
- If you want for window to be shown (_any_ non default hud window including such things as ZoneReuse window), you HAVE to issue show_window command. Setting Visible=True has no effect prior to show_window.
- After show_window has been successfully issued, you can manipulate window using Visible=true/false.
- show_window appears to do NOT work when issued from OnShow handler of the standard windows that are automatically-shown (i.e. it doesn't work for Compass window, but it does work for Target window that is not shown immediatelly).

I've ran quite a few tests of all this.. and I'm reasonably sure that it is how it works.. unfortunately.

Of course, it still doesn't preclude me being wrong If someone has a working code sample to share that would auto-show custom windows on startup -- I'd greatly appreciate that

- If you want for window to be shown (_any_ non default hud window including such things as ZoneReuse window), you HAVE to issue show_window command. Setting Visible=True has no effect prior to show_window.

Not true, you have to back out far enuff to get a handle on the window you want to be visible by calling its parent node. Yes you can use show_winodw command like you do but you are causing the game to execute the show_window code where if you do Parent.blah.visible=True you bypass that step freeing up clock cycles. All the show_window command does is set visible to true, it works kind of like an API call.

- After show_window has been successfully issued, you can manipulate window using Visible=true/false.

show_window never has to be used to make a window visible

- show_window appears to do NOT work when issued from OnShow handler of the standard windows that are automatically-shown (i.e. it doesn't work for Compass window, but it does work for Target window that is not shown immediatelly).

Correct, and thats because when it first proccesses the file its visible property is already set to true. If you go into the file and add visible=False it will fire when its proccessed.

[Solf]

Originally Posted by Landiin

- If you want for window to be shown (_any_ non default hud window including such things as ZoneReuse window), you HAVE to issue show_window command. Setting Visible=True has no effect prior to show_window.

Not true, you have to back out far enuff to get a handle on the window you want to be visible by calling its parent node. Yes you can use show_winodw command like you do but you are causing the game to execute the show_window code where if you do Parent.blah.visible=True you bypass that step freeing up clock cycles. All the show_window command does is set visible to true, it works kind of like an API call.

- After show_window has been successfully issued, you can manipulate window using Visible=true/false.

show_window never has to be used to make a window visible

- show_window appears to do NOT work when issued from OnShow handler of the standard windows that are automatically-shown (i.e. it doesn't work for Compass window, but it does work for Target window that is not shown immediatelly).

Correct, and thats because when it first proccesses the file its visible property is already set to true. If you go into the file and add visible=False it will fire when its proccessed.

No disrespect intended, but I have trouble believing you. Like I said, I've been testing it for quite some time. And I could not get windows to show in any fashion. Including setting visible=false etc.

If you could point me to a piece of code that is known to work (i.e. auto-show any window that is not shown by standard UI), I'd greatly appreciate that. Otherwise we are stuck where you are telling me that something works while I believe that I've tested it -- and it doesn't. So it looks like one of us is wrong

[Landiin]

I stand corrected! *swallows pride*

I did some test and it does seem that you CAN NOT make any Parent node visible from an object that isn't a child node by the Visible property. On further testing I found that this only applies to first generation siblings nodes of the Section nodes(MainHud, Inventory ect). You can make one of its siblings visible by the visible property from any object no batter its parent and it can in turn set the Parent visible by the visible property. You just can not set Parent node visible of section nodes by the visible property by any object that isn't a sibling.
( a bug IMHO )

I'm going to do more testing and see if the include has any thing to do with it. I'm also going to bug report this next time I log on because this doesn't work correctly.

[Solf]

Originally Posted by Landiin

I stand corrected! *swallows pride*

I did some test and it does seem that you CAN NOT make any Parent node visible from an object that isn't a child node by the Visible property. On further testing I found that this only applies to first generation siblings nodes of the Section nodes(MainHud, Inventory ect). You can make one of its siblings visible by the visible property from any object no batter its parent and it can in turn set the Parent visible by the visible property. You just can not set Parent node visible of section nodes by the visible property by any object that isn't a sibling.
( a bug IMHO )

I'm going to do more testing and see if the include has any thing to do with it. I'm also going to bug report this next time I log on because this doesn't work correctly.

You might want to test what I did... show_window seems to actually show -any- window... and once you use show_window to show the window once, you can manipulate Visible property to full effect from anywhere.

All in all, my suspiction is that setting Visible=true is simply not enough to UI engine to acknowledge visible window existence. show_window does some behind the scenes initialization to make UI engine acknowledge window existence and after that Visible property works as expected.

Default game windows are pre-initialized somehow so Visible property works for them from the very beginning.

So, overall, I think it's not even a bug -- it's a feature

OTOH it's more questionable why show_windows doesn't work from OnShow handler of the standard windows being auto-shown. That might be "by design" as well, but then it seems impossible to auto-show any custom windows as well.

Like I said earlier, I worked around it by associating initialization code with Target window OnShow -- which works and typically happens "soon enough".

HTH.

[Zonx]

I believe this is a function of how EQ2 manages windows in the memory space. Only certain commonly accessed windows are instantiated in the working memory space automatically. Other windows don't actually exist in memory untill called by show_window. Once shown (loaded to memory) visability functions work as expected.

The idea here is to save memory by only loading what's needed, and if an object doesn't exist yet, you can't set its parameters.

[Solf]

Originally Posted by Zonx

I believe this is a function of how EQ2 manages windows in the memory space. Only certain commonly accessed windows are instantiated in the working memory space automatically. Other windows don't actually exist in memory untill called by show_window. Once shown (loaded to memory) visability functions work as expected.

The idea here is to save memory by only loading what's needed, and if an object doesn't exist yet, you can't set its parameters.

That makes sense.

Now we just need to figure out what's so special about OnShow handlers in standard windows As I said, show_window doesn't work in them.. OTOH this DOES work:
'/MainHUD.MainChat.chat_textbox.NormalTextStyle'='/MainHUD.Compass.Solf.Styles.TextStyles.Font_ChatInput18'

This above line won't work (in my experience) from other places (other than OnShow in standard windows) -- you need to use relative Parent.Parent stuff.

Looks like perhaps when OnShow is executed in standard windows "windows system" is initializing -- and certain things work differently from the "normal" usage.

[Laffs]

Maybe this will be of some use to you (maybe not lol)

This is what I used to get 2 custom window to show..

Name="Player" OnHide="Visible=true Visible=true
 show_window=(MainHUD.CastBreath) show_window=(MainHUD.CastBreath)
 show_window=(MainHUD.PerLoc) show_window=(MainHUD.PerLoc)"
 OnShow="Visible=false Visible=false OnShow=' ' OnShow=' '
 show_window=(MainHUD.CastBreath) show_window=(MainHUD.CastBreath)
 show_window=(MainHUD.PerLoc) show_window=(MainHUD.PerLoc)"

Somtimes when using that for the very 1st time in game you have to toggle the player window.... And then again somtimes you dont.

[Landiin]

OK that does make perfect sense that show_window initializes windows and allocates memory for that window. But then I think it's already in memory or at least the windows code is already in memory because I don't see any disk access. I'll point my file monitor to the UI directory and see what is being accessed and when.

So if what we think is true show_window allocates memory for said window then hide_window should deallocate that windows memory or does it just make it !visible. I'll have to test this and see if it does or not. I do know pressing the X (Close button) does not deallocate that windows memory. Now that I think about it I only tested the Close thing with my Notes window and it doesn't use eq2usescomwndcontrols="true" directive so windows that use it my deallocate memory.

[seyden]

basiaclly I have a UI that is no longer supported ( Hope everything is well with you Wulf) and I dont have on my persona window under details their is no button for the zonereuse xml
can someone please explain where do I put the code and exactly what do I need to insert to get this button to show and work. I love the ui I have by Wulf and really dont want to change and just now starting to learn how to read all this and what it does just so I can keep up with the ui changes.

Thanks in advance