![]() |
Raid window detriment icons
Based on user feedback I've added dynamic data and UI elements to the raid window for raid member detriments. However, I expect some people that are not interested in this data to not care for the extra width of the raid window. I've added the ability to toggle the detriment icons on and off, but I'm not sure what outcome this will have on modded raid windows. So I'm looking for a little feedback.
Here's a screenshot of the raid window with detriment icons showing. When a player toggles the icons off, I basically shrink the group windows by the width of the detriment page plus a little extra for the border. Do any of you see issues with your current raid window mods or have any other suggestions? ![]() |
I don't see any issues, Thanks for the DD. Now I gotta go mod a raid window :)
|
I'd handle this slightly differently with more of a Basic/Advance mode option which would allow for other stuff to go into the advanced mode...
Raid |_Volume | |_Group1 | | |_Member1 | | | |_AdvPage | | | | |_arcane | | | | |_elemental | | | | |_etc... | | | |_BasicPage | | | . |_Rest of the member stuff | | |_Rest of the member pages | |_Rest of the group pages |_Rest of the Window stuff When mode is set to Basic, all AdvPages are hidden and Volume.CellSize = BasicPage.Size. When set to Advanced, Volume.CellSize = AdvPage.Size. This approach should allow us to add whatever we want to the AvdPages, not just the effect icons. Player Targeting should be restricted to just the BasicPage area. The AvdPage and Member page should not trigger player targeting or absorb input. Even better would be if we could place any number of pages labeled "Hitbox" inside either/both Adv and basic pages to define the area(s) that trigger targeting. We must be able to trigger scripts on mode change, preferably by scripting the mode toggle directly or via an out of frame button set by the actual toggle Advanced.Enabled=true/false. Ideally we'd get a dedicated RaidSettings popup (we can script and extend as needed) that auto-loads into memory when the raid window is first opened and persists so we can access the settings via script in other windows. OT: psst... where's my ColorStyles? :P |
Quote:
But still I'd like to use your way of shrinking it. To make this a viable alternative for modders, could we get the hardcoding to adhere to some modifiiable XML tags? I'm thinking of tags like
Would be great, also for all other hardcoding done in the UI. |
I really like Zonx's idea for managing the two modes of display. This seems like a pretty good way to allow modders to arrange the controls in any way they want. I didn't even think about the targeting yet so I'm glad you brought it up. It certainly makes sense to limit the targetting to the basic page or even have a targetting page that sits on top of both of them. This would allow you to place it over any of the controls you want.
As far as setting the Volume.CellSize = to the basic or advanced pages. These pages would only be large enough for 1 group member unless we make them much bigger than they need to be, but that would look messy. One option would be to make sure the basic and advanced pages are exactly the size you want for 1 member so that CellSize would equal the width of the basic or advanced page and the height would be 6 * the basic or advanced page height. Let me know what you think. |
Didn't even see Zonx's post when I posted. :eek:
This is what I have in my UI: <Page Name="ToggleCureEffectsButtons" OnHide="Parent.Volume.CellSize=201,115" OnShow="Parent.Volume.CellSize=285,115"/>These values cannot be auto-calculated from other elements. I need the possibility to configure them (the amount by which you want to shrink would be enough though, see my post above). Alternatively if you go Zonx's way please give me a way to opt out of your hardcoding. I can't just rename all elements to get out of it because raid leaders need to be able to drag'n'drop raid members, and that functionality is hardcoded. Or at least give us the event upon mode change that Zonx asked for and allow me to undo your hardcoding via that... |
The targeting issue is easy enough to code around but yea if u can limit to only the basic page and not the member1 page would be nice.
Why not call the effect page Effects? /shrug As long as ever thing is kept within the members# page I don't see how the hard coding is going to effect drag and drop in your mod gm9. I also like all the properties Zonks and gm9 has suggested. But then you would have to write a new window class to account for the new properties, I guess you could add it to the base page class and everything else could just ignore them but the raid-window code. |
I'm not sure we're all on the same page or we each interpreted Zonx's idea in a different way.
gm9, why couldn't the cell size be based on the "basic" or "advanced" pages? It's not really calculating it from the element sizes. Lets say that the basic page contains name, archetype, health, power and speaking icon. The size of the basic page might be 200,20. The advanced page would only contain the effect icons (or whatever else you guys wanted to add) and the size would completely overlap the basic page plus whatever other space you needed. So in the default UI, the advanced page might be 320,20. So if a user puts the raid window in advanced mode, the cell size would be 320x120(20*6) but in basic mode it would be (200,120). These values would be defined in the UI files because they are taken straight from the sizes of the basic and advanced pages. If you wanted to design a vertical raid window with the icons underneath the name then the basic page would still be 200,20 and the advanced page would be 200,40. So when the user puts it in advanced mode, now the cell size becomes 200,240 (40*6). All that the 'hard-coding' would do is change the cell size based on the basic or advanced page size but allow us to toggle the mode with a right-click window or user command instead of having to do it with a UI element. |
The issue is just that my window does not use a 6*basic page layout. If the hardcoding is not applied upon login (or can be modified OnShow) then I'm ok though.
|
I guess I'd have to look to see how yours is configured. You have to at least be following some of the conventions in order for the drag/drop and target functionality to work. If you would only have to make small modifications to conform to the new layout it might be worth doing it.
Where did you place your button to toggle the click-to-cure icons on and off? |
1 Attachment(s)
Screenshot attached. Actually for your resizing you only need to set the width, I see no reason why you would need to bother with cell height. If you leave the height alone that should solve the issue. And yes, I can add a dummy Advanced Page to make it work, I'm just trying to retain some flexibility here. ;)
|
The reason for looking at the height is so modders would have the ability to change the height of the overall group box between basic and advanced modes.
Flexibility is good! :) |
Alright, that's true. Okay, you do whatever you do, I'll cope. ;)
|
I don't pretend to know what's best, I just wanted to be sure we were all on the same page so we can make the best possible decisions.
I could see where people might want a layout that's more friendly when displayed horizontally and that might include putting the effect icons underneath the name or health bar instead of next to it. I'd also be up for putting the toggle button somewhere in the window, but the Default UI doesn't have those separator bars that you have in ProfitUI so there isn't really a good place to put a toggle button. |
No right click is fine. The separator bars are only optional in my UI so when they are not shown it is currently not possible to toggle, so the right click option would make it better. :)
|
gm9's issue could be easily handled with padding or margin properties on the Volume.
PadCellHeight="20" adds 20 to the cell height calculation. PadCellWidth="40" adds 40 to the cell width. This would allow modders to add whatever group elements they want and adjust for the extra space used. Oh... I used the "Basic" and "Advanced" labels because I'm assuming modders will want to put other stuff into the "Advanced" page besides effects. For example RaidAbilities. I also would hate to see the right-click menu option say "Show/Hide Effects". Should be "Basic/Advanced Mode". I'd really like to see a dedicated "Options" window. My current raid window uses an options overlay to handle some custom settings I'd love to move to a popup. Alternative Method: You could use a template based approach with a BasicGroup and AdvGroup template. The only issue here is that you'd need to feed the generated group pages an index number we could access for scripting. The advantage to this approach is that we'd only need to deal with 1 set of templates rather than a set for each of the 6 group instances. This approach would also allow for radically different layouts for each mode. In either case, all member elements should be valid inside Member, Basic, or Advanced. You might be asking, why Member? Because I might want stuff to reposition and/or resize as the page size changes. Lets say BasicPage.width=100 and advPage.width=200. I might want player name to be centered and as wide as possible. |
I considered rebuilding the raid window to use templates because I can't stand the fact that it has 24 pages with the same controls copy/pasted. From a client memory standpoint, its going to be the same thing once the controls are generated, but the UI would be much easier to tweak with a template.
However, I think it was originally done because of the volume control and wanting to see how it would behave in UI builder. Not sure if I'll have time to re-work it before the next GU. |
I was able to get back to working on the raid window today so I wanted to give an update.
I've reorganized the Member page to include a Basic and Advanced page. The code now loads the individual controls by searching anywhere below the main Member page. So you aren't required to put the controls in basic or advanced. You can even put them in the root member page and it should work. Right-clicking the raid window a user will get the option "switch to basic/advanced made" depending on which mode they are currently in. When a user is in basic mode, the main member page and basic page will be visible. The advanced page will be hidden. When a user switches to advanced mode, all three pages will be visible. Targeting is now done through the basic page only, so clicking on controls in the advanced page will not cause the target to change. Dragging and dropping for raid leaders will work anywhere within the member page. I also found and fixed a bug that was causing players to not be able to drag members to an empty slot in certain circumstances. (This made me pull my hair out for a while thinking it was something wrong with my new code). I've also made a change to the UIVolumePage control so it will now use its Margin settings when packing the child controls. I did this because I wanted to adjust the size of the main window when a user switches from basic to advanced. I didn't want the advanced portion of the window to be cutoff and not visible. So switching to advanced mode will force the main page to the minimum size for 1 cell so the advanced controls will be immediately visible. By making the margin work within the volume, I could size the main window to the proper size without having to hard-code the margin between the window border and the volume control. Now the volume control is placed directly on top of the main window and the margin allows the child controls to not overlap the window border. Here's a sample of the new page in case you want to get started early re-designing your raid window. Code:
<VolumePage AbsorbsInput="false" BackgroundColor="#FF0000" CellCount="1,4" CellPadding="0,0" CellSelectable="false" CellSize="318,125" CellSizeAdvanced="318,125" CellSizeBasic="230,125" Margin="5,5,5,5" MinimumScrollExtent="328,510" Name="Volume" PackSize="absolute,absolute" ScrollExtent="328,510" Size="327,510"> |
Sounds really good actually, thanks. I assume the volume page margin will work in other windows as well now?
PS: Since the specifications for the window above sound final I copied and stickied them in the XML modding help subforum. Thanks for the detailed runthrough! |
*Cheers at Rothgar*
Great work =). And fixing that old drag-and-drop bug is icing on the cake :D |
This behaves like an open window and its preventing my escape button from bringing up the EQII button's menu. Not a big issue but I can't seem to close this window. ini edits, changing the hotkey to something else and trying. It seems to shut off for half a second and then its back up and stuck open.
|
Quote:
|
All times are GMT -5. The time now is 07:12 AM. |
vBulletin® - Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
© MMOUI