Scripting issue(s)

[Draakthor]

I've been beating my head against the desk with this for hours now, and could use another set or two of eyes/brains.

I'm trying to add class detection to Dragowulf's SpellTimer Window. Basically, I'm setting it up for use by up to five different classes. I added a text object to hold the subclass name for comparison, and five hidden buttons with the scripts to copy data into the working set.

The gist of each button's script is (OnPress):

Parent.SpellTimerData.1.SpellName=Parent.ClassSpellData.A.1.SpellName
Parent.SpellTimerData.2.SpellName=Parent.ClassSpellData.A.2.SpellName
Parent.SpellTimerData.3.SpellName=Parent.ClassSpellData.A.3.SpellName

...repeated through 15. SpellTimerData is the 'working set' from Dragowulf's original code, which I haven't modified in any way (as far as I know); and ClassSpellData is the new set I added. There's one button per class, A through E, to reduce the workload.

I seem to have figured out the class detection part, but apparently the data getting put into the working set is "Parent.ClassSpellData.A.1.SpellName" and so forth, rather than the contents of that property.

A slightly less frustrating problem is getting the buttons to activate. OnPress should be triggered by Buttonname.Activated=true, correct?

If looking at the actual files would help more, links to both are below (the data is in a separate file for easy modification).
main xml
data xml

[Zonx]

Activate does not fire onPress.

Press is a Click event, meaning mouse down and up inside the Control. You can trigger it via script by setting Press = true (which fires the onPress event), but the "Press" property immediately resets itself back to False so that its ready for the next press.

De/Activate is similar to a check box's Un/Checked events. You can fire the OnActivate event by setting Activate = True, but unlike Press, the property retains the True value until you change it to False. When you do change it to False, the onDeactivate event fires. Note that for either of these events to be fired, a "Switch" must occur. For example, If the Activate is already True, attempting to set it to True again will not fire the associated event.

As for your data passing issue, getting the script passed rather than its value typically indicates one of two problems...

A) Your pathing is wrong, so the data you're trying to access isn't located where your path is pointing. Usually means you're missing a "Parent" tag. Remember that each level of object nesting in your xml introduces another level of "Parenting" if you're pathing through it.

B) You're attempting to assign the value of an expression without evaluating the expression. Typically solved by assigning the value of the expression to a variable, then assigning the variable to your original target. A good way to debug this sort of problem is to temporarily add a visible textbox to your target window at the same level as the control you're trying to target. Target the dummy text box and tweak code until you're sure the script is dumping out the expected result, then change the target to whatever control you really want it going to.

[Draakthor]

Thanks for the reply, I went back and fiddled some and somehow fixed the data passing issue (not sure what was wrong).

Having a slightly different issue now with the class detection. Here's the OnShow script for the main window page:

CLASS=Subclass.Text
ISCLASSA=(CLASS == ClassDataA.Class.ClassName)
ISCLASSB=(CLASS == ClassDataB.Class.ClassName)
ISCLASSC=(CLASS == ClassDataC.Class.ClassName)
ISCLASSD=(CLASS == ClassDataD.Class.ClassName)
ISCLASSE=(CLASS == ClassDataE.Class.ClassName)
ClassA.Press=ISCLASSA
ClassB.Press=ISCLASSB
ClassC.Press=ISCLASSC
ClassD.Press=ISCLASSD
ClassE.Press=ISCLASSE

"Subclass" is receiving the dynamicdata for Self.Subclass properly, yet all five ClassX buttons are getting pressed when the window shows. I was under the impression that (A == B) returns a boolean value, is this not the case or is there something else wrong here?

EDIT: I should add, the data for each Class.ClassName is different. A is "Paladin", B is "Monk", etc.

EDIT2: I'm just confused as heck now. Debugging textboxes show that, while logged in as a paladin, ISCLASSA = "true" and ISCLASSB = "false". So why is ClassB getting pressed...?

[Landiin]

If the object is not the parent of the objects you are trying to call the data from then you need to fix your paths. Also just an FYI; Button.Press=False will aslo simulate a button press. That has eat my lunch many times, then I remember Button.Press=<any thing> will simulate a button press.

[Draakthor]

Yup, that was the problem. Switched to using OnActivate since they only need to trigger once per login and it's working. Thanks a ton

[Zonx]

Strongly recommend you have your OnActivate scripts reset the button back to Activate = False at the end of the script. This way the script can be triggered again.

Zoning is known to sometimes reset scripted variables, so you should not count on your class detection only needing to be called once per session. If I'm not mistaken, this particular bug was the cause of several knock-off's of Fetish ClickAbilities sometimes failing and requiring a relog. Is one reason I tend to avoid automating class/level detection and instead give the user a mechanism for selecting what they want.

[Draakthor]

Good to know, thanks.

Hopefully it shouldn't be an issue with the way things are set up here, the only script variables are used during the class compares; once the OnActivate that needs to has been tripped, it copies the properties from the pages I added into the original ones used in Dragowulf's scripts (which at a glance seem to be way over my head). Probably an ugly solution, but it seems to work.

[soundchicken]

I'm glad that you are looking at this Draakthor.

I flip-flop a few "main" toons and love Dragowulf's SpellTimer Window mod.
My non-programming solution was to just add a few more of those windows to my UI, but I know that is only a cure up to a point before it will lag me.

[Zonx]

The way I handle this sort of thing is to provide a custom "Settings" window tied to the window you need variability in. The settings window has a series of "Preset" buttons you manually click to load up the settings for a particular class/scenario. These then pull the values from a file embedded as a separate include for easy editing out of game.

While this approach does require the user to select what they want, the nice thing is that they can have more than one setup for a given class, for example a "Raiding" set and a "Grouping" set.

Let me rephrase my earlier comment...

Zoning is known to sometimes re-initialize entire windows. This means any values set to said window that aren't fed directly by DynamicData, the client's hardcoded functions, or embedded in the XML files may be tossed.

Your class check should be setup to fire any time the dependent window is shown.


The technical reasons for anyone that cares...

Window XMLs are read by the client and used to instantiate objects in memory as needed. These object typically persist and are what receives any changes applied at runtime (changing text, variables assigned by script, etc).

Occasionally the client will try to do some memory management to free up system resources (most likely during zoning but could be any time). When this happens, it may decide to ditch a window object from memory and only reload it from the XML if needed. When a window in memory gets tossed, any settings made at runtime are lost. DynamicData and changes made by client functions are reapplied automatically, but script changes aren't unless they are somehow tied to the window's initialization.

From what I can tell, there is a prioritization to what windows get tossed from memory first. Custom windows are first to go, followed by anything not in MainHUD. Using the /hide_window xxx command also seams to immediately ditch the window.