Well the spell would have to be filtered out each time the text changes. So my question is how would I do this with the include? And the passing the number?

If I can do the same thing with a smaller file, then I'd like to go that route. But most of these things with includes I don't really understand. I still feel like a newbie with this stuff.

Well you know you can traverse the xml tree so put your

1a=
2b=
3c=

in the <include> at the root of the page, and then always reference this via Parent.Parent. ... - that way you only need to define it once, makes it easier to edit it.

And the other things is you could put the actual hiding code in a button at the root and have the individual pages call it in the same ways (Parent.Parent. ... .Press=true). You'd need to pass the reference of the page to the button as well, e.g. Parent.Parent. ... .CallingPage=Parent.Name and then show/hide that page.

PS: Looking at your actual code I still don't get why you have all that scripting in their configuring the dynamic data objects? Why is that needed, why not just show/hide the entire page?

Less dynamic data is actually loaded which is better on the system performance.

Personally as a Defiler and a Raider(the worst combo for spam buffs that you don't care about!) I cant exatcally think of a use for this, I guess you could use some of your code to modify it into my proposed maintained window. But at what cost to performance?

Link to proposed maintained window.

A timer for debuffs/buffs/heals to track when to reapply them. I'm not big on certain maintained until cancelled buffs and some others I could care less about. I like a visual progress bar representation that helps me figure out when a target is mezzed or mez breaks and how long, and when to reapply buffs/debuffs. I like to have a window on the side of the center of my screen to track these. It seems to all boil down to personal preference. Kind of like how you like to be really minimalistic.

As to gm9:
I can't figure out how to use includes and text files to make it easier. It seems like you would still need a hell of a lot more coding and it would be more taxing on system resources.

Wow, this would come in really handy!

Once you get it all figured out, I'd love for this to be released
(I'll even do some testing for you if you want)

I remember seeing a thread that a dev added or is allowing greater than and less than values now. Can someone link me the thread?

Oh and I would like to know how I could do something like "greater than 0 but less than 75"

^ should work

I see what gm9 is getting at about reducing the used code. I did a similar include/config file with my Statbar and used a Top-Level-of-tree-located button, which gets pressed instead of repeated the same long amount of code multiple times.


To pass on the number, you can simply make a custom value on the button itself called something like "iPassedNum" or something shorter...

First set that number.
Then press the button. Have the onPress code in the button be the code you already have used a bunch of times, using the number value in the string (use the concatenated stuff... ##)

You could get fancy with your config.
Maybe use a Data object:
The check in the button:
As you can see.. you could get fancy, making it much easier to modify for different classes, and save some coding in the end when the list of buffs you're check gets longer... Especially if you did something like loaded it by your subclass or something spiffy for big config files :)

Please excuse any coding type-o's/mistakes, lol

What does IValue represent? Or is that just the Value of the property you're trying to do this to?


The other stuff above I seem to understand much better now. I'll probably convert my next version for that.

iValue is just a random variable name he chose. Drum's code needs a slight modification though, you'd need to put it like this (as with the OR || code):

iValue=10
a=iValue > 0
b=iValue < 75
COND=a && b

(with a and b being other random variable names.)

Ok, that makes sense. Since they're 2 different statements, and you're checking if both are true. I forget to break the checks into separate checks sometimes. Some times just hard to do the K.eep I.t S.imple (S.tupid) method :o

I hear you, EQ2 coding is a bit particular. ;)

We could always modify the client to use Lua as its scripting language, but then you'd have to re-write every line of your UI code. :)

Actually...

We could do something like look for a string at the beginning of a script command like "<Lua>" and if it exists, parse the script with a lua interpreter, otherwise pass the script to the existing interpreter.

*wheels start churning*

lol Rothgar's got himself another project.

It's probably a bit late in the game for LUA, my first priority is still to finally get eq2's scripting engine fixed to handle Unicode character encoding. After all certain default UI features that are not hardcoded but use scripting are also broken on international servers because of this. There, I said it again. :p

I'm down for that! I'd resurrect eXtremeUI if you guys added a real scripting language.

Not saying you guys haven't done a super fantastic job making the UI even easier to mod. I just hate having to do 10 steps to get 1 thing done.

Come to think of it, you could do it in a way people wouldn't have to recode every line of their UI. Just add new evens LUAOnShow, LUAOnHide... etc..

Hush you, nothing is to late.. I vote make this your #1 Rothgar :)

Yeah, I considered that we could have separate functions for lua commands, and then I decided that it would be much easier to add a new property to UIWidget "UseLuaScript" and if that property is set to true then all functions would be processed using the lua interpreter.

I talked to a coworker who is a big lua fan and has been doing lots of server-side lua work and he was pretty excited about this idea too. He's the type of guy that likes working on little side-projects too, so I'm thinking maybe I'll keep pestering him to do it. :)

With a lua script engine we'd have true function calls and we could expose a whole lot more of our UI to scripting. It would be much easier to create functions for reading/writing your own data to the new xml file. You'd also get all the built-in functions for lua. It would be nice being able to create local variables that don't turn into widget properties. The lua environment would be implemented on a window basis, so while each event would have its own stack space, you could declare global variables on a window level and they'd persist between function calls. So you wouldnt have to store data in widgets.

Implementing the "UseLuaScript" property would let existing UI's continue using UIScript even down to a widget level.

Actually if you properly implement it LUA should be unicode or even binary compatible. Don't mess it up! :p :D

Haha.

INI's saved as editble XML...
A possible in-game replacement of EQ2.ini setting files...
New UI script functions and events...
Talk of LUA function scripting...

Holy cow, EQ2 UI is really coming together this year. Can I get a hoorah for 2009?

Hoorah. :)

Yea that's even a better idea.

I would think you would implement it at root level. While lua isn't a OO language out of the box there are packages out that adds OO to the lua language. Ether way I'm looking forwards to it.

You're right, it would be done this way. I was just trying to give an example of using data out of scope of the local event.

Darn it. I'm just getting the hang of EQ2's XML..does this mean that I'm going to need to learn LUA (which means more questions for me to ask, which is bad for you guys because you have to answer) to maintain awesome status?

I'm still down for it however or if you guys decide to do it.

Is LUA more hard than EQ2 XML?

Lol. I haven't scripted with it myself before, but I've looked it over.

It's a normal scripting language (not tags like XHML) allows functions/methods, classes, code comments, etc...

http://lua-users.org/wiki/ClassesAndMethodsExample

I think it's more unfortunate than "too late in the game" for lua to just be implemented now. As in, it would have been awesome to see this sooner. No complaints though. Looking forward to any more info on this going into development status.