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.