What am I missing?
 

OK. I am trying to make a configurable texture in game.

When I paint this frame:
I get this image: CLICKY


Now, I set up the following lua functions to alter that texture via a slider, and (hopefully) save it across sessions (most of this is hacked up and taken from the SquidMod code):
The OnLoad and OnEvent functions are called elsewhere in my XML, the "Update" function iis called from the slider XML:


Now, here's where it gets odd. Here's another image: CLICKY (for reference)

The variable, DiivSkinSettings.hbar, is saved in my savedvariables, and it does save the textCoord's of whatever the slider was last on, but It only refreshes them after I open up that page of my configuration doohickey. Until that point, the full 12 slot bar is displayed. After the config page is opened and then closed, the correct "slot" confguration will persist.

The above code produces no errors, but has the mentioned issues. I tried just about everything I could think of to check for the value of the slider, but nothing worked. Almost every variant produced errors mostly pointing at the "DiivSkins_hbar1Update()" function. Either the reference in the slider XML was "referencing a nil value", or the lua broke alltogether, disabling all the other functions for buttons toggles and such that are present in the lua. This include trying to call the Update function from anywhere other than the <OnShow> in the slider XML. From there, its fine. Anywhere else, I get "an attempt to call a nil value" or it flat out tells me the function is broken.

I hope I explained that well enough. I'm sure I'm making some pretty elementary mistakes, but I feel like I'm getting close anyway.

Any help? :)

At a casual glance, a couple things throw up flags for me:

else if not (DiivSkinSettings) then
DiivSkinSettings.hbar1 = {}
end

If the above happens, then it will give an error. The above says if this table doesn't exist, then create a subtable under this non-existent table.

What you probably want is:

else if not (DiivSkinSettings) then
DiivSkinSettings = {}
DiivSkinSettings.hbar1 = (some default value)
end

On the value not chaning right away: A slider's OnValueChanged will get called BEFORE your variables are loaded. As part of a slider's initialization it will call OnValueChanged. This may be why its last state is not being saved initialially. I don't see a DiivSkins_hbar1Update() but I suspect it's assuming variables are loaded and they're not yet. (and in fact it'd be overwritten by this:GetValue())

How I handle sliders is this:
1. In the mod's initialization, after VARIABLES_LOADED, I slider:SetValue(last position)
2. In the slider's OnValueChanged() function, I check first if the mod is loaded, and if it is, then I assume the current position is valid and work with it from there.

When troubleshooting a sequence of events I'll often pepper my code with a lot of DEFAULT_CHAT_FRAME:AddMessage("In OnValueChange now") and stuff like the above will stand out right away.

Thank you much for the reply Gello, that was very helpful. I knew I had issues with my vairables, I just didn't know how or why. I was quite frankly astonished it worked as well as it did at first go.

I will have to try the chat frame mssg's. I thought maybe the "stock" XML frame was being rendered until the <OnShow> update worked its way into the mix, but I wasn't sure if it was that, or a variable value of 12 for some reason. That will be a good way to know for sure.


I was also worried about the way the update function read.

If yadayada then
elseif yadayada then
something yada

Seems logical that it should read more to the tune of

If yadayada then
something yada
elseif yadayada then
something yada

I thought for sure that was where "flags might have been thrown up," but I couldn't seem to get anything to work right there. Typically, my brain's idea of logic and lua's idea of logic seem to be at odds most of the time anyway. :p

Hehe i thought i was the only one to do that.

My chat box looks funny when im working on something new.

thingy: 1
thatstuff: 5
things: Hunter

[grumble]
While your post makes sense to me, I'm afraid I can't get the syntax correct. Heck, I can't even get the actual value to display in a CHAT_FRAME dump. I can display a message, but nothing productive. :p

What I think is happening is that my savedvariable texture reference, while being saved, is not being called until the slider is visible. I verified this by changing the root textCoord's of the original xml frame, as this frame is not hidden. (I just did something wacky to get a distorted image displayed).

On start up, I get the base (distorted) XML texture. Once I open the slider page, then the frame's SetTexture reference from the slider value is recognized and employed, and all is well. This will persist until reload/relog. Then we start over. The variable is saved, but not displayed, until I access the slider. I don't even need to adjust it, just make it visible on screen by opening its page in my config UI. The moment the slider is displayed on screen, the texture for the frame in question is displayed, correctly, from the saved variable as well.


Could you maybe point me at an AddOn that initializes referencing a Slider Value? I couldn't seem to find one, but maybe looking at how its done might help me. My brain tells me the slider value isn't the problem, but that I'm just not actively displaying the data contained in the SavedVariable on initialization.

I would think just running the update function would accomplish this, but I can't for the life of me get that DiivSkins_hbar1Update() function (posted earlier) to fire from anywhere other than the <OnValueChanged> call of the slider xml.

It always returns a ...attempt to call global ... (a nil value) pertaining to itself if I try to call it from an OnEvent or an OnLoad.
[/grumble]



Thanks in advance for any assistance anyone might be able to give, and for patronizing the unedumaceted. ;)

You need to do the following:

Setup your slider to change the savedVariable, and then call your textureUpdate function. You already have that so you are almost there...

Setup your textureUpdate function to check for the existence of the variable it needs. if the variable isn't there, then it needs to be created, which I assume you have elsewhere in your script, so we don't need to go over that. Once it has the varaible it needs, then change the texture. You have that, although the syntax is badly written, so you may want to fix that. I can assist if you need.

The final thing that needs to be done, which is your primary problem, is that you need to add a script section to your DiivSkins_Hbar1 frame. You see, the slider will NOT do anything until it gets shown. That means the config options have to be opened EVERY session in order for your texture to get updated. So you need to add the texture update to something that will be on screen every session. Since the frame mentioned above is the one with the texture you plan to change, it should have the update script in its OnEvent section. Do it like this:

<OnLoad>this:RegisterEvent("VARIABLES_LOADED");</OnLoad>
<OnEvent>if (event == "VARIABLES_LOADED") then TextureUpdateFunction(); end</OnEvent>

Basically that means that whenever someone loads the game, and after the varaibles get loaded, the texture update function will get run, which checks to see what they have set for that variable (if at all, else it creates a default value) and then udpates the texture accordingly.

Hopefully this gets you where you are trying to go. As always, let me know if you need any assistance. Especially with that texture Update function, as it looks like you didn't format the if, else, and elseif's correctly...

It's not the best mod for an example of sliders, but Recap here has several sliders in RecapOptions.lua and RecapOptions.xml.

In the xml, I define the min/max/default of the slider in the slider's tag.

<Slider name="RecapIdleFightSlider" orientation="HORIZONTAL" enableMouse="true" minValue="5" maxValue="60" defaultValue="10" valueStep="1">

The scripts section only has tooltip bits and OnValueChanged:

<Scripts>
<OnEnter>
Recap_OnTooltip("IdleFightSlider");
</OnEnter>
<OnLeave>
GameTooltip:Hide();
</OnLeave>
<OnValueChanged>
Recap_IdleFightSlider_OnValueChanged(arg1);
</OnValueChanged>
</Scripts>


In/after the VARIABLES_LOADED event, I make recap_temp.Loaded=true and call Recap_InitializeOptions():

function Recap_InitializeOptions()
local chatname,chatid,i;
RecapAutoFadeSlider:SetValue(recap.Opt.AutoFadeTimer.value);
RecapIdleFightSlider:SetValue(recap.Opt.IdleFightTimer.value);
RecapMaxRowsSlider:SetValue(recap.Opt.MaxRows.value);
RecapMaxRankSlider:SetValue(recap.Opt.MaxRank.value);
etc
end

To set all the values from the last session.

Then OnValueChanged is very simple:

function Recap_IdleFightSlider_OnValueChanged(arg1)
if recap_temp.Loaded and arg1 then
RecapIdleFightSlider_Text:SetText(arg1.." seconds");
recap.Opt.IdleFightTimer.value = arg1;
end
end

Try moving stuff out of the OnLoad/OnShow and into your VARIABLES_LOADED event. That way you're not dependent on when the UI gets around to loading up your UI during startup.

Don't try fitting everything into the xml. In many cases it's better to manipulate stuff in your OnEvent handlers than the control's own event handlers.

his problem isn't the slider. The slider is doing what it needs to do. His problem is that when he changes the slider, it changes the texture, as intended (or it should) but if you log out, and back in, the texture will be at the default until he opens and updates the slider.

He simply needs an onload in his initial frame to get the variable when the player logs in. The slider only needs to change it if they plan on changing it, not change it on game-load.

On a side note, I could easily fix your issues as posted and post the updated code, but I prefer not to. The only way for a person to learn (or at least the way I learn best) is by breaking it, and fixing it yourself. So I will kinda nudge you in the right direction, and help you when you need it, but anything more than that might hurt your own learning process ;)

Thank you for the replies. I know I'm clueless, but I sincerly appreciate your patience. I really am learning a lot. :)

Beladona,
I did as suggested... The update function now reads:
I then added the suggested <Scripts> to the original texture frame's xml. (better quote them too, just to be safe)

That, save the check in the Update function itself for the variable, is a variation of what I have been trying, although I was calling for the Update function from elsewhere, typically in my normal OnEvent function. The net result of your suggestion, assuming I executed it properly) produced the same nil error as before regarding the Update function itself. I get this error at startup or reload, or, I assume, when VARIABLES_LOADED fires.

you did say: I think(?) Gello set me straight there. I hope I did that correctly. For the record, I will ALWAYS welcome help in that arena, or any other for that matter, so don't be shy, and thank you. :)




Gello,

I will definitely take a look at Recap, and see if that doesn't shed any light for me, thank you. From a cursory examination of what you posted here, there does seem to be some pretty fundamental structural differences in the way you coded it all. (I don't understand the "arg" notion either, but admittedly I haven't attempted to dissect them yet.)
EDIT: Whoah, how have I missed this! (sorry, just got into game with recap, that looks to be a very slick little toy. :D )

RE:I probably poorly worded that. When I said fire, I meant I have the line: DiivSkins_hbar1Update(); in my <OnValueChanged>, and that seems to be the only place it doesn't return a nil error when called.

Something looked odd in the function I posted, so I tried this as well:
still produces a nil error.

edit: sorry, still produces a nil error when called after the VARIABLES_LOADED event fires. (rather than from the slider <OnValueChanged>, where it works)

The important bit, which should be stressed above all else, is that OnValueChanged will happen BEFORE variables are loaded. It's part of a slider's initialization when the game loads up.

Do you have DiivSkinSettings defined outside the functions above? Looking at it more closely I wonder that you don't get nil errors in the initial OnValueChanged.

If your mod looks like:is going to be a mess. Because DiivSkinSettings is not defined yet. (OnValueChanged will get called BEFORE variables are loaded)

You can do this:By moving DiivSkinSettings = {} outside the functions, when the xml is loaded and it hits the Script file="whatever.lua", it will run the lua file and make DiivSkinSettings = {} before anything happens in your xml.

Or you can doOther stuff I notice:

If DiivSkinSettings isn't defined yet (ie, if before VARIABLES_LOADED), then this will give an error. It's trying to see if a value beneath an undefined table exists.

When checking if something exists, if it's a table then the elements above it must exist or it will give an error. the above should read:If DiivSkinSettings doesn't exist it will fail right away. If it exists it will see if hbar1 beneath it exists.

But again, realize that OnValueChanged() gets called BEFORE VARIABLES_LOADED. You may think OnValueChanged() is the result of someone moving the slider but it can (and is) also the UI setting the default value.

As mentioned above, stuff happens before this function ever gets called. Notably OnValueChanged.

In OnValueChanged it's trying:

DiivSkinSettings.hbar1 = this:GetValue()

when DiivSkinSettings doesn't exist. This is one reason I avoid putting time-dependent stuff into the xml. You can write an entire mod in the xml portion but especially starting out it helps enormously to break things down into sequence.

Do this:

1. Move this to the top of your mod:

DiivSkinSettings = {}
DiivSkinSettings.hbar1 = 2; -- whatever you want for default
DiivSkinLoaded = false

for a lot of bars, you can do:

DiivSKinSettings = { hbar1=2, hbar2=2, hbar3=2, hbar4=2 }

and it's the equivalent of:

DiivSkinSettings = {}
DiivSKinSettings.hbar1 = 2
DiivSKinSettings.hbar2 = 2
DiivSKinSettings.hbar3 = 2
DiivSKinSettings.hbar4 = 2

2. In the VARIABLES_LOADED event

DiivSkinLoaded = true
DiivSkins_hbar1Slideretcforgotname:SetValue(DiivSkinSettings.hbar1)
DiivSkins_hbar1Update()

3. In the OnValueChanged:

<OnValueChanged>
if DiivSkinLoaded then
DiivSkinSettings.hbar1 = this:GetValue();
DiivSkins_hbar1Update();
end
</OnValueChanged>

In the update function, remove the if not DiivSkinSettings bit.

try the following code.

Your skinnable bar ----------
your slider ------------------------
and finally, the lua code ----------
As an aside, I assume you plan to create multiple bars, and therefore plan to make each one skinnable. Let me know if this is teh case, as I have simple code that can be plugged into the existing functions to make them work for ANY bar you want. Makes sense to use a single function for all your bars, and make that function work based on which bar is being passed to it. Smaller footprint = good :)

:eek:

Holy crap, I love you guys.

I have some real work to do now, but I will definitely be all over this later tonight.

Thanks so much for the help, both of you. Rest assured I'll report back when I have a chance to sit down with all this.



PS:
Yes, I will be adding multiple bars, as well as other elements. The end goal is to have configuration options for everything in my "kit" ( screenie ).

So, one of these widgets for each bar, horizontal and vertical, and probably a variation for the smaller elements, like a slider for each griffon that would toggle it between an assortment of images (lion, griffon, wyvern, right facing or left facing, etc.). At that point, it wouldn't be difficult (even for me) to break up the AddOn a bit into more of a "plugin" system, so users could only install the files that had the images they actually wanted to use if they wanted to keep it "lite". (We've already discussed that this won't have much of an impact on most systems, but "perception is reality." At the very least, this AddOn is pretty texture heavy, and busting it up into optional "expansions" would probably lighten the bandwidth load for Cairenn here).

I also want to ultimately include a "hide" checkbox, and a "lock" checkbox (to toggle moveability). I hadn't gotten far enough to sort how those variables would be saved yet either. I had thought originally the hide value at least could be a value outside the slider range, but now I'm not so sure. Regardless, the plan was to default all this crap to being checked "locked" and "hidden" so the user could selectively un-hide and manipulate elements as they set up their interface. Right now, they have that entire mess presented at first, and have to navigate within the restraints of a loooong MoveAnything scroll box to configure their set up. It's fairly unwieldy for even simply tweaking a layout in its presently released state. While I can't speak for all, I know I tend to "tweak" a lot.

The goal is to reduce MoveAnything! to an optional dependency, with a much shorter list for its MAPredefined frames file if the user opts to employ it. The purpose of this being mainly just so an individual could re-size an element if they desired. (I'm quite happy with MoveAnything's functionality for re-sizing, and don't see any reason to re-invent that particular wheel) All other functionality could be handled by DiivSkins. I think (with both your help) I'm getting much closer, and I can't thank you enough.

The possibilities start to get pretty broad, but its all the same basic principal. Ultimately, I'd like to think this could even "set a stage" for some actual artists to maybe have a go at doing some real tangible reskinning work on default elements, and still maintain configurability for the user. Now that would be exciting, much more so than my cut-and-paste hack job for a bunch of superfluous images on screen. ;)


I was just trying to get this first bit working correctly first, and hopefully learn enough along the way that I wouldn't need to keep badgering gracious souls such as yourselves. ;)
Much of what I detailed above I can now handle, but there's obviously a few "gaps" in my fledgling knowledge base just yet.

(I've already learned so much that I snikker at myself when I look at the currently released mod's code, and that's almost entirely just XML. Heck, I didn't even comment things very logically. :D)

OK, I think we're getting somewhere. I've gutted most of the original AddOn at this point. About the only thing left is the frames and functions we're discussing, and odds and ends relating to my funky options window.

Using the advice above, I'm mostly employing Beladona's code, with a few excepted suggestions by Gello, which did eliminate the odd error.

-- the bar ---- the slider ---- the lua --
Some of the variables stuff seems redundant to me, and I will re-read your posts tomorrow with a fresher brain Gello. That said, the changes (additions) I made did eliminate all errors except for this one:I get that whenever variables are loaded, or the slider is shown. Basically, the same "Update" function nil error as before.


The saved variable is saving correctly now and displaying the correct texture after VARIABLES_LOADED is triggered, and not displaying the original frame texture until an <OnShow> trigger as before.

Unfortunately, the slider is no longer working to dynamically update the texture in game. That is, it saves its variable, which is then displayed correctly the next time they are loaded, but nothing visually happens on screen when you adjust the slider. You need to reload to see the changes you have made. I can almost see where you are going with this however Beladona, so I'm more than willing to get it working if you are. :)

I'm getting tired, so I'll take a look at this again tomorrow with fresher eyes. I just wanted to give you both a status report.

I appreciate the help folks. :)

function name in LUA:
DS_TextureUpdate()


function name in XML:
DiivSkins_TextureUpdate();


result: DiivSkins_TextureUpdate a nil value

reason? doesnt exist.

;)


oh, and as to why it works in the first place and not when its changed? youre calling the correct function (DS_TextureUpdate()) from within DS_TextureOnEvent().

How many lua scripters does it take to turn on a light?

3 to try and figure out whats wrong with the bulb, and one to turn on the switch.

ROFL. In all fairness, I did say I was tired last night.

Works a treat now. thanks Greycap. :)

EDIT:
Still haven't had coffee yet, but I will look at the variables some more today. The appear to be working fine in game, but something looks fishy with what I added to Beladona's code. Didn't you set up a local for the DiivSkinSettings Beladona? And then I added them as globals for some sort of validity check?

Sorry, I've been staring at this for so many hours trying to sort it through, I think its time to step away for a day and let my brain clear out all the crap I tried, so I can go back to working with bonafide code again. LOL.

Beladona, if you want to withhold your "simple code that can be plugged into the existing functions to make them work for ANY bar you want" for the time being and let me try to figure it out for myself, I won't mind at all. I think once I stop staring at this with one hand on the save button and the other on the reloadUI button and actually just read the code, It will probably make a lot more sense.

Of course, If you want to continue to write this AddOn for me, <blush> I'm not proud. :p
Thanks for all your help. ;)

one problem. You changed your step to 1-12 instead of 2-12 like it was before. In the bottom configuration variables, you need to add:

DiivSkinTextures[1] = {a = 0.0, b = 1.0, c = 0.8984375, d = 0.9882812}; (or whatever the texture coordinates are for that texture)

Otherwise when they select 1 on the slider, it will return an error because there is no corresponding configured texture for the value of 1.

Also, you added variables to the very top of the lua script. If you define

DiivSkinSettings = {};
DiivSkinSettings.hbar1 = 1

it will reset the options they have configured every time they load. Leave it in the OnLoad statement as it will detect if the value is there, and if not it will add it.

just an example, as I dont know the real texture coordinates you are wanting to use...

-- the bar --
Fine as it is, no changes necessary

-- the slider --
* changed DiivSkins_TextureUpdate(); to DS_TextureUpdate();

Code:

---

<Slider name="DiivSkins_hbar1Slider" inherits="OptionsSliderTemplate" minValue="1" maxValue="12" defaultValue="2" valueStep="1">
        <Size><AbsDimension x="160" y="17"/></Size>
        <Anchors><Anchor point="CENTER"/></Anchors>
        <Scripts>
                <OnLoad>
                        getglobal(this:GetName().."Text"):SetText("Horizontal Bar 1");
                        getglobal(this:GetName().."High"):SetText("12 slots");
                        getglobal(this:GetName().."Low"):SetText("1 slot");
                </OnLoad>
                <OnShow>this:SetValue(DiivSkinSettings.hbar1);</OnShow>
                <OnValueChanged>
                        DiivSkinSettings.hbar1 = this:GetValue();
                        DS_TextureUpdate();
                </OnValueChanged>
                </Scripts>
        </Slider>

---

-- lua script --
* removed the first few lines as it will mess up your config settings
* changed the load detection a little pending inclusion of your other bars
* added DiivSkinTextures[1] since you now support settings 1 through 12 on the slider

Code:

---

-- Global Functions ---------------------------------------
function DS_FirstLoad()
        DS_ControlConsole:Show();
        DS_startup:Show();
        DiivSkinSettings.setup = true;
end
function DS_TextureOnEvent()
        if (event == "VARIABLES_LOADED") then
                if (not DiivSkinSettings) then DiivSkinSettings = {}; end
                if (not DiivSkinSettings.hbar1) then DiivSkinSettings.hbar1 = 1; end
                if (not DiivSkinSettings.setup) then DS_FirstLoad(); end
                DS_TextureUpdate();
        end
end
function DS_TextureUpdate()
        local key = DiivSkinSettings.hbar1;
        local var = DiivSkinTextures[key];
        DiivSkins_hbar1Texture:SetTexCoord(var.a, var.b, var.c, var.d);
end
-- Configuration Variables ---------------------------------
DiivSkinTextures = {};
DiivSkinTextures[1] = {a = 0.0019531, b = 1.0, c = 0.0, d = 0.0820312};
DiivSkinTextures[2] = {a = 0.0, b = 1.0, c = 0.8984375, d = 0.9882812};
DiivSkinTextures[3] = {a = 0.0, b = 1.0, c = 0.8085937, d = 0.8984375};
DiivSkinTextures[4] = {a = 0.0, b = 1.0, c = 0.71875, d = 0.8085937};
DiivSkinTextures[5] = {a = 0.0, b = 1.0, c = 0.6289062, d = 0.71875};
DiivSkinTextures[6] = {a = 0.0, b = 1.0, c = 0.5390625, d = 0.6289062};
DiivSkinTextures[7] = {a = 0.0, b = 1.0, c = 0.4492187, d = 0.5390625};
DiivSkinTextures[8] = {a = 0.0, b = 1.0, c = 0.359375, d = 0.4492187};
DiivSkinTextures[9] = {a = 0.0, b = 1.0, c = 0.2695312, d = 0.359375};
DiivSkinTextures[10] = {a = 0.0, b = 1.0, c = 0.1796875, d = 0.2695312};
DiivSkinTextures[11] = {a = .0, b = 1.0, c = 0.0898437, d = 0.1796875};
DiivSkinTextures[12] = {a = 0.0, b = 1.0, c = 0.0, d = 0.0820312};

---

On a side note, your slider shouldn't be doing anything with the hbar1 setting until you actually open the config and start changing values. Based on that, you dont need to check for the setting before changing it. Just change it as I have it above, because by the time you actually even see this slider, you will already have run your onLoad for your bar, which makes sure the setting is there. It will ALWAYS be there by the time the slider is shown.

I had that handled, thank you, and did add the extra config variable. That's all roses. I managed to squeeze an extra bar in the original texture, allowing me to use the full 1-12 range. The coords we're posting here are all jacked up actually, even my last set, I need to go back in and replot the new texture with the extra bar.

check. ;)

I'm at work now, but I will make the suggested changes when I get home. The crud I added was mid stream of my gutting out the original code as well as rebuilding that console and my "first use" stuff (I really need to focus). I probably put the additional lines in there to cover for something else that I hadn't pulled out yet (to correct existing errors that Gello had pointed out with the old code).

Sorry about that.

Thanks again for all your help Beladona. I'm quite certain I could not do this with out you.

no problem. just trying to balance "direction / help" with "do it this way".

Just know everything I tell you is the way I would do it, but doesn't mean it HAS to be done that way. In some case that may be true, due to the way lua wants it, but in many cases I show you the way I would do it if I was doing your mod.

On taht note however, I am not doing your mod, and don't really want to, or else it wouldn't be your mod :p - so I will stick to helping, giving input, and correcting, as long as you want it, and are willing to take the criticism. After all, criticism makes us better in the long run, and hopefully will make your addon one of the better, more well written ones out there! :D

I think it's confessional time. Last night, while dismantling what was left of the old AddOn, I noticed a slight oversight. I have the AddOn currently organized with seperate files for the basic frames displayed on screen, and the control elements. I had apparently forgotten to include<Script file="DiivSkinsControl.lua"/> in the DiivSkins.xml. So I believe any script calls to a function from the bar xml weren't being executed. BIG <blush> I would wager that previous suggestions would have likely had me up and running quite a while back in this thread.

So, thank you so much, particularly Gello, for the assistance thus far. I'm sorry it couldn't have been more productively applied. ;)

That little embarassing tidbit off my chest, I must say I am quite impressed with "your way" Beladona, and happily embrace it, and your guidance, as we move forward. :)

Now, next up would be "plugging in" additional elements to the existing code. So we're all on the same page, this is the lua as of current, including the replotted textures. (I snuck home for lunch).

Looking at that, logic tells me that I will need to add additional lines to the DS_TextureOnEvent function and the DS_TextureUpdate function to reflect a DiivSkinSettings.hbar2. Obviously, corresponding changes would then be made in the new slider frame as well, but a new bar frame would reference the universal Texture_Update. (?)

Where you really lost me, is where I would redirect attention to a new set of plots for the configuration variables once I move beyond horizontal bars and on to a new texture, say, for vertical bars.

I don't have time to fiddle with this in-game right now, but I'm guessing I will define a new set of Variables, a new [key], DiivSkinTextures_02 for example, for the new element. Or would I stay in DiivSkinTextures, and progress to something more to the tune of:
?

Am I close? :)

try this:

Only thing left to do after that is to give each of your bar frames an id. For instance:

getting your bars to use vertical or horizontal textures is a another function to deal with entirely. I would get multiple bars working with this before you start throwing in re-orientation. It can be done easily enough, but might take some time to understand. That and I am leaving work in 20 minutes so don't have time to type anything up about it :p

Hehe, no problem. I'm one of those lucky few that has times, like now, where I can pseudo dork with this stuff while I am at work. :D

Nice touch with the frame ID. Somehow I knew about them, but I didn't even think about that.

When you say, "re-orientation" you really pique my interest. I hadn't considered the possiblity of selecting whether a bar could be displayed horizontally or vertically, but the functionality is certainly intuitive, and would reduce the "meat" of the AddOn considerably. It also opens up worlds of possibilities on how to handle other textures, such as the end-caps. It also might shed some light for me on how I could incorporate "hide" and "lock" features. I'll stop speculating at this point, and also stop getting too spooled up with how I'm going to layout my options screen(s) just yet. ;)

I actually had another thought about the vertical bars. I'm not sure if it would work, but I think one could actually pull them off the same texture as the horizontal ones if the textcoords were re-directed to draw the image differently. I'll have to look at how textures are inverted again to be sure. If I'm tracking you, I don't think its really germane, but I'll try dorking around with it out of curiosity.




Another thing I want to try to do is incorporate bars that populate the opposite direction. This I don't think I can pull off with just textcoords, as a result of the "dead space" that is needed to keep the image from distorting as the bars get "shorter", so I think I would need to create a new texture for them. I guess I'm not really sure, but I'll play around with it when I'm horsing with replotting the bars for a vertical display.

Why does he want reverse populating bars?

Well, that actually brings up another question. With the current release of DiivSkins, I have been toying around with flexbar scripting and pseudo animation of textures. Think a pop-up flexbar menu, where you show/hide a button group on MouseEnter (or whatever Flexbar Event). Using simple /flexbar runscript :Show() and :Hide() commands I was able to mirror the action of my flexbutton pop-ups with their textural backgrounds. I was even able to selectively display two endcap images such that I had an expanding MainBar recreation that would dynamically update for me in-game. ( clicky for a visual )

Obviously, having a bar that populates right to left is handy when you are trying to create a flyout menu on the right side of the screen, and vice versa.

This isn't a sort of functionality I think is practical for direct integration into the DiivSkin mod per-se, but it does raise a question as to how I would execute this sort of behavior with this new system. I had originally thought I could call the variable data in a script to facilitate changes triggered by FlexEvents, but I don't know that this could be done with how the variables are now constructed?

In any event, it should still be feasible with conventional :SetTextCoord() type scripting, I was just looking for a slick way to keep it less verbose (oh the irony, I know ;) ), as textcoord strings can get pretty long for a single script line in the flexbar application. The saved variable state isn't actually important, in so much as the action it executes in game.

Regardless, the managability of external manipulation is last on the list of wants for what we're doing here. Just a passing thought, please don't let it occupy any of your time. I'm just thinking aloud.

Criminy, sorry for the essay, LOL. :p

okies. plugged the new code in.

on display of the slider, I initially got this:That prompted me to change the slider code to emulate what we had done in the lua, like so:aftermaking the slider change, and logging in and out, I then get this:at this point, I observed that the bar displayed on screen only has 11 slots, so I logged out again, and opened up the SavedVariables.lua, which still reflects:Curious, I then deleted this portion of the SavedVariables.lua, and logged back into game. Now, my bar had set itself to 1 slot, but I still got the same OnShow errror relating to the slider. I logged back out, and the SavedVariables had updated to my default:Just to be sure, I then reverted back to the older slider code and logged back in. this took me back to the concatenate error.

The saved variables tossed me for a loop at first, as once the barid is constructed, it appears the same as the last system. Now I see that It is at least recognizing and constructing a default value for us, but I have to assume the 11 slot bar was from a prior config, as the slider has not been functional with these most recent changes. (?)

I even looked up concatenate. :)But I'm afraid I'm still at a loss. :confused:

Any ideas?

Correction. The slider is adjusting vairables and saving them, but its no longer dynamically updating the texture in game. (this is with the original slder code)

edit: trying to plug in [barid] to the slider just breaks it all together.

the problem is that the slider doesn't know what to pass to the texture update, sorry I missed that part.. :p

try this:

You will have different sliders for each bar I assume, so for each slider you simply need to change the hbar1 to hbar2, hbar3, etc...

yeah the reorientation is kind of interesting. It would actually be easier for me to give you the source code to my upcoming mod. It takes the DEFAULT buttons and makes them draggable and allows you to re-orient them vertical, horizontal, or in different row configs similar to the way BiBmod did it.

The neat thing is, I did it all with the default buttons, including the main ActionButtons, so the default settings in the Interface Options still affect them, not to mention mods that add things like Cooldown numbers to your buttons, will affect them too, despite them being "modded". In other words, they are completely backwards compatible with other mods or changes that affect the default ActionButtons and MultiActionBars

*steps out of the shadows for a sec*
*points out that she's still reading avidly, even though she isn't posting and desperately hoping that things will calm down enough for her to try to work her way through all of this stuff as well*
*still really wants to understand all this stuff so she can get various graphical skins from EQ ported over*
*fades back into the shadows*

That did the trick on the slider. I tried to document my troubleshooting as I went along in the post above, looks like my first intuition was correct, I just (as usual) had the syntax all borked. :p

I assume now all I need to do to add more bars is duplicate the core texture frame and corresponding sliders, changing my "hbar1's" to "hbar2's" and so on. The lua functions they call will adjust accordingly? Very slick, and thank you very much!




What you are doing sounds really interesting. Utililizing the default action buttons is a nice feature. It should allow the user a nice variety of configuration options without actually reinventing the wheel, thus, avoiding all kinds of related problems. KISS principal at work.

In regards to re-orienting, I have played around with :SetPoint() to re-arrange the way elements are grouped. Somehow I don't think this is the method you employed. ;)

In any event, I don't think :SetPoint() would work effectively with DiivSkins, as its images are technically just one entity re-rendered to reflect several.(?) I could now reconstruct new functions for the TextureOnEvent and TextureUpdate to construct different elements, vertically oriented bars, or some of the other "bits", like endcaps. I think I could even constuct a toggle to flip between which elements are actually displayed and manipulated in the GUI, say, using a checkbox and a bunch of layered :Show() and :Hide() functions.

That said, I have a feeling you have a cooler way to do it. ;)

If you think it would be of any assistance to me, I would be very happy to peek at the code for your AddOn. Not sure if my addy is in my sight profile, but you can get me at: diiverr818 [at] yahoo [dot] com. If you're not "passing it out" just yet, I totally understand.

Thanks again. :)


EDIT:

Hiya Cairenn, I had a feeling you were lurking. <wink>

LOL. I stand corrected. I did that adding the following XML:
-- bar ------- slider -----This returns an error from this line of the lua:attempt to index local `texture' (a nil value)


So, true to topic.. I now go back to sorting out... "What am I missing" :D

edit:
Thinking out loud again... I am registering a variable, I now have [hbar2] in my DiivSkinSettings={}, but the update function is not performing its job, either dynamically with a slider change, or with the VARIABLES_LOADED event.

We should get into an instance messaging of some sort to work through this. I read through all your threads on the official blizz forums (yeah about time) and see the direction you are wanting to go with this.

You want to make your buttons and the like skinnable (maybe in the distant future, make everything skinnable, a full UI skin system)

You want to make it as easy as possible for newbie coders to make their own skin configurations and images.

You want to make it as plug and play as possible, so that people dont have to edit your existing UI to add mroe skins. THey can just add another addon (skin package) that adds onto yours with another skin choice.

I think I can help you with this. With some carefully crafted savedVariables, and option sets, you can reduce your rendered images to a single image (that gets repeated) and can be easily reoriented vertical, horizontal, 2x6, or whatever the heck you want. I have done it with my own button mod, minus the texture skinning, but it can easily be configured with the skinning system too...

the Texture in "hbar2" is named "DiivSkins_hbar1Texture". Change that to "DiivSkins_hbar2Texture" and the error should go away...

Bingo. Thanks. :o


reading your other post now.

By now, you probably know what you are getting into with my coding capabilities. You are a brave individual :p , sir (or madam).

The only instant messenger I have set up is yahoo, but I can install a different one if you're serious. Honestly, I don't mind hashing this out here, I'm in no spectacular hurry, and others might learn a trick or two (not just me ;) ) along the way.

PM me here if you like as well.

RE: the individual skinning of buttons, the current release of DiivSkins does something very similar. I understand where you are coming from. The reason I have been dodging it is the somewhat random way in which a texture will be rendered in a given layer or strata. You never seem to know which one is going to be on top of the next. I believe there are ways to combat this with code, but I could always work a little harder on the textures to where this wouldn't need to be accounted for. It should be feasible.

as long as your textures exist in a strata underneath any buttons that get placed on them, you should have no problem. Heck, you might even consider just adding this to the default blizzard bars, or using something similar to my code to tie the skinning and default blizzard buttons into a single standalone addon.

That way you have everything below, or above where it should be, and fully skinnable.

I know a lot of people prefer to use things like Flexbar and the like, but done the way I currently do it, they can use yours, or Flexbar, or both, and neither should interfere with the other...

I use MSN almost exclusively. I do have yahoo, aim, and other accounts, but would need to install them as well to be able to do this. For now though, I am about to log in and do some much needed player development (levelling) :D so I will shoot you a PM when I am on IM and ready to develop...

Almost done with an updated version of my Dreamweaver Highlighting plugin too, so that it will include Code Hints. Has been a pain in the butt getting working, and up to date, so will be good to have it done and released. After that I can get back to work on my original AddOn so that I can get it out and ready within the month...

DiivSkins skins them now with a pseudo static image. All I did was parent the frame that held the texture to blizzards frames, then viola. When you enable the bars, you have them skinned. You can disable or adjust the number of slots you display using the MoveAnything interface. Not Ideal, but it worked. Of course... It wouldn't work if you could re-arrange the way the bars were oriented... ;)

I've kinda tabled the bars for the moment, curious what you have in mind for the button by button rendering. I played around with it, but I always ended up making a baziliion frames in the XML again, something I was trying to avoid this time around.

I couldn't do nothing though, so I spent the afternoon playin with endcap images. ( clicky for a jpeg of the targa ) :)

Now, my first inkling is to replicate the coding for the bars to implement these. Basically, DS_CapTextureOnEvent, DS_CapTextureOnUpdate (capid), etc. I would think ultimately, I would have a whole new series up [cap1=x] type entries in my DiivSkinSettings variables.

Way I figure it, each endcap frame I put together could have up to 32 steps (16 128x128 textcoord references, plus a mirror of each) per slider if I finish off that targa. I thought that was pretty cool, I'm kinda excited to see them in game. :D

I'm pretty confident what I described above would work code wise, but I assume there's a better way? Can I still leech off the original functions some way with the totally new targa reference?

Also, another thing to consider here is how to work a simple SetTexture (rather than TexCoords) into the variables for the default endcaps, if they're visible. I'm guessing that would need a new function as well, and it might be able to be made more universal .. for getting names of other textures that we might want to reskin in the future... But I'm getting ahead of myself. Mostly I'm just curious the best route to work in these "auxiliary" endcaps.

Any advice before I stop copy-pasting pixels and start copy-pasting code?

Hmmmm, another thing to think about is to scrap the slider idea completely. If you do this based on skin packages (allowing anyone to make a set of skins in a single package) and then let them register the package with your mod, you could then have a dropdown that automatically lists all installed skin packages. They select it from a drop down, configure where and how they want their bars displayed, and the textures can configure to match. Shouldn't be difficult to turn it into a robust skinning engine that allows people the freedom to make a package to their own graphical tastes, and release it as an addon of an addon, so to speak...

Let me get some work done with my addons, and we can talk. I will give you the source to my own addon, and let you test it in-game before I release it widely as open beta. I use my mod already in-game every day, so I know it works well. Hopefully giving it to you will let you see how it is handled, and maybe start plugging in texture code to it, to see how you can modify what I did to work with your skin system. In the end I would like to see you make a skin system that bends to YOUR will, not the other way around ;)

That sounds like a plan. ;)

Thanks Beladona. :)