SIDL changes with the 9-3-08 patch
LayoutVertical/LayoutHorizontal
TemplateContainer I'm not sure what this is for other than a container. In the default UI its used to nest layouts. Although its supposed to be a template, I haven't seen any pieces in the template container inherit and properties of the template you specify. TopLevelWndowList From the sound and look, it may have the potential to allow you to create new windows. I haven't been able to create any though. |
EDIT:
Sizable window inside of another window will never work. There is no place for EQ to save the size of the inside window. So the stuff below will only work until someone logs in again, but I'll leave the information here for informational purposes anyways. You might be able to get it to work if you make the top level item for the window a SC without borders where you want it to size and you make the child SC anchored so it can stretch and give it borders where the top level one doesn't. I found another neat trick with LayoutVertical/LayoutHorizontal that allows a the user to size a window only in the direction you want them to. Only vertical or horizontal sizing. All other borders can be used to move the window. Your main Screen (SC) element for your window must be changed to a TemplateContainer (TC). There is a bug with positioning when nesting TCs and SCs. TCs are subsets of SCs so they function almost identically. Then, you give your main TC either a vertical or horizontal layout property. You give it a border, and leave out the sides you want the user to be able to size. In your main TC you only have one piece which is a SC, because TCs cannot be sizable. You make this SC sizable and give it borders on the sides you want the user to be able to size it. With the location you can also tweak the relative positioning. Inside of the SC you can place your window elements, probably anchored so that they can size with the window. Make sure any sub elements are TCs not SCs or you will see the positioning bug. There was also another bug. When I tried to only allow the window to be sized from the bottom, after the first sizing I could not size it again. Only allowing the top to be sized works, but sizing is kind of buggy. When you first move your mouse to size it bigger, you cannot size it smaller and visa-versa. The further you size it the faster it increases with size. All this makes it take some work to size, so it should only probably be used on things that don't need to be sized often. Here is a little example with the buff window: Code:
|
The main issue I've been wrangling with is it adding width/height for things I don't want it to. There's an easy solution though: say it's adding 44 width to my window that I don't want, create a dummy button with -44 width. The negative value will be added to (and so end up subtracting from) the total calculated width.
If you use, for example, a horizontal layout, but have an object that autostretches to the width of the object that uses said layout, EQ will crash. I've often used buttons as my dummy objects but am not sure if another object type would have a smaller impact on performance. Enok |
I noticed that the pet winodw only resizes horizintally but I didn't see the layout command in there at all. Can you give an example of code?
|
Quote:
The pet window is hard coded to only size horizontally. You can emulate the same thing, except the borders that do not size cannot be used to move the window. So you would need a title bar to move it. If you do not want the top of the window to be sizable, you can replace the top border with a title bar that looks like a border. The basic idea is to create a sizable Screen with a draw template that has borders with zero width and height on the sides you do not want to user to be able to size. You then make a child Screen and anchor it so it fills the parent window. On the child Screen you give it borders on the sides the parent doesn't. Place all your window components inside the child window. In order to move the window the parent window will need a title bar. The title bar is placed underneath the top border. You can specify no top border and make your title bar look like a border, or you can take that into account when drawing your images. One thing you have to remember about sizing windows is that their size comes from the ini file not the size in the XML file. If someone loads your window and the unsizable dimension was different than what your window was made for, they either have to edit their ini file or uncheck "Keep Your Layout" when reloading the UI. You can find an example at http://www.eqinterface.com/download....php?s=&id=5665. It allows you to size horizontally and vertically, but if you only wanted it to size horizontally you would replace MUI2_WDT_NoTop with: Code:
|
OMG, Sizable buff windows...with buff labels.
You rule! One question: What would I need to do to flip the buff name to the other side? |
Quote:
Add <AlignRight>true</AlignRight> to every <Label item="BW_BuffXX">. |
I have been trying to find a way to click a button that makes a window bigger or smaller. I see a few ways it could possibly work.
You could give the window a layout so that it would size to the contents. Then you could place an object that exists only when you want the window larger on the far edge. The only things I can think of though that may or or may not exist are spell gems, container slots, and group members. There are more things that may not have a value, but the only things that do not have a size in a window with a layout is an object that truly does not exist. None of those objects work well for general use though. Togglable buttons like sit/stand, run/walk, and invite/follow work too. These would probably be more useful. The most useful would be LFG/LFP on/off since pressing them doesn't affect your character. Other players probably wouldn't like that much though. The speaker for voice chat should work too. The lag would suck when you turn it on and it would only work for people who don't care about the feature. I haven't tested it, but dynamic animations may work. You could put a child screen inside a screen with a layout. I tested giving the child window a minimize box, but it would not cause the parent window to size. Giving the child window a close box does work though. This method opens up a few interesting possibilities. The problem though is once you close the child window there is nothing you can press to open it again. The other problem is every time you load your character the child window will be open again, because EQ does not save its state. There are a few methods I tried that didn't work at all too.
Unfortunately all the solutions I came up with won't work for my particular problem. All the dynamic objects I can think of would have too large of an impact on game play to toggle extra UI information. Unless someone thinks of another way or thinks of a dynamic object that does no affect game play :). EDIT I came up with a dynamic element that might have some possibilities. The spellgem/button/inv slot on the hot button window. Its only a minor annoyance to have to place a certain type of item on a certain slot to pick different window layouts. |
I think my posts are deviating from the topic quite a bit. But I think its better than making 50 new threads for each topic. Hopefully someone will find this information useful or someone will find alternatives to my approaches. Todays project :), was to find the best way to override a hard coded animation.
You can alter the EQUI_Animations.xml file. But whenever that file is changed, your UI will break. You can alter the texture file from the default UI and change the piece to whatever you want. This actually isn't a bad method. The only downsides is if the image it came from is altered in the default UI, it may cause visual issues in game. The animation will also be stretched if you want a size different than the default. Its possible there may be a bug in EQ. When EQ searches for duplicate objects it may compare the strings in a different way than when it searches for the animation to display. I tried adding all kinds of things to the beginning and end of an item name including: slashes, null character, new line, carriage return, tab, space, and unicode. Some of them caused parsing errors. Some caused the second animation to be recognized as having a different item name. None of them worked. There is another possibility for the above type of method. EQ most likely uses a standard function to compare the strings. If this function is dynamically linked, you could replace the C runtime library dll in your EQ dir with a custom dll that replaces the string compare function. Replacing a file would cause problems with the patcher overwriting your dll. You could also hook the function at runtime so that you wouldn't have to worry about the patcher. If not written very carefully, it could have other side affects. It is also on the edge, if not over the edge of "hacking the game". There seems to be an undocumented attribute named scope, that can have the value internal or default. I placed this attribute everywhere I could think, but it didn't seem to have any affect. It may be undocumented because its not implemented :). |
Thanks for the info Stoplaughin. It did take me a while to figure out that the buttons were anchored to the right via the template. Once I flipped that everything else pretty much fell into place.
Thanks again |
Nice I really like this. Think I'm going to have to try it out myself tonight. Derred, is it possible for you to post the code for left side buffs or PM it to me please?
|
Quote:
I only changed the Buff Window. I did not change the Short Duration Buff Window as I use one without labels. In order to get this code to work you will also need the BW_Border500.dds file Stoplaughin included with his buff windows. You can find that here: http://www.eqinterface.com/download....php?s=&id=5665 I also made slight offset adjustments to Stoplaughin's window and increased the buff label font size from 1 to 2. Code:
|
Excellent, I managed to get them setup pretty well. I also set the text for the regular buff window to align right, alongside the buffs themselves. One of the questions I wanted to ask was how to add static animation backgrounds (buff slot holders) in a window which can be auto stretched. You see the holders I use in my sig.
|
Just wanted to say there's another way to make windows sizable in one direction only. You don't need to remove borders, just overlap them. I can't remember whether I needed an overlap of 1 or 2 in the end, but it definately worked, and it might give a better look to the piece.
Code:
|
The negative value will be added to (and so end up subtracting from) the total calculated width.There's an easy solution though: say it's adding 44 width to my window that I don't want, create a dummy button with -44 width.
|
All times are GMT -5. The time now is 04:31 PM. |
vBulletin Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.