Vyzor, UI Manager for Mudlet
Re: Vyzor, UI Manager for Mudlet
I don't mind at all. Enjoy.
Re: Vyzor, UI Manager for Mudlet
So I tried using Both VyzorGaugeUpdate() and individual gauge updates (for health and mana gauges), through both regular gui timers and temporal timers (both mudlet base ones) but still couldn't manage to get anything to update :/ just constantly at full. I'm also getting the following error every time the timer timer ticks -
MainGauges is the frame that contains the gauges.
Can anyone give me a working vyzor code example perhaps? Or any other help would be nice as well :\
Code: Select all
[ERROR:] object:<MainGauges Update> function:<Timer5>
<...config/mudlet/profiles/Kash/vyzor\compound\gauge.lua:240: attempt to perform
arithmetic on upvalue 'current_stat' (a string value)>
Can anyone give me a working vyzor code example perhaps? Or any other help would be nice as well :\
Re: Vyzor, UI Manager for Mudlet
Make sure you are converting the captured data to a numeric.
Code: Select all
--example
current_stat=tonumber(matches[2])
Re: Vyzor, UI Manager for Mudlet
The variable current_stat holds the value of the address you passed in the Gauge constructor.
By reading the error message, we can clearly see that current_stat is not, in fact, a number. It's a string. Hence why the error message reads "attempt to perform arithmetic on upvalue 'current_stat' (a string value)".
What this means is that, whatever address you passed to the Gauge constructor is pointing at a string variable. Perhaps, when you get your current health or whatever, you're storing it as a string. For instance, all triggers pass matches as strings; this means you have to call tonumber() to actually get a number.
So, as Drevarr suggested, in order to store a number from a trigger, you need to do something like this:
The fact that this error pops up when you try to update your gauges is a pretty good indication that something is wrong. Use the error dialog. Read the error dialog. It's not there just to be copy/pasted into the forums for someone else to read. The best way to get better at programming of any kind is to embrace error reporting; as a programmer, I am confident saying that more of your time is spent testing for and deciphering errors than actually writing code.
By reading the error message, we can clearly see that current_stat is not, in fact, a number. It's a string. Hence why the error message reads "attempt to perform arithmetic on upvalue 'current_stat' (a string value)".
What this means is that, whatever address you passed to the Gauge constructor is pointing at a string variable. Perhaps, when you get your current health or whatever, you're storing it as a string. For instance, all triggers pass matches as strings; this means you have to call tonumber() to actually get a number.
So, as Drevarr suggested, in order to store a number from a trigger, you need to do something like this:
Then, when you pass "MySystem.currentHealth" to the Gauge constructor, it'll actually pull out a number instead of a string.
The fact that this error pops up when you try to update your gauges is a pretty good indication that something is wrong. Use the error dialog. Read the error dialog. It's not there just to be copy/pasted into the forums for someone else to read. The best way to get better at programming of any kind is to embrace error reporting; as a programmer, I am confident saying that more of your time is spent testing for and deciphering errors than actually writing code.
Re: Vyzor, UI Manager for Mudlet
As a side note, any string that can be directly converted to a number via tonumber() can have math performed on it. "10" + "5" works just fine. So there is something other than just numbers in the value it is referencing, and consequently, tonumber(value) is going to return nil, not a number that can be worked with.
Re: Vyzor, UI Manager for Mudlet
But how do you guys handle the delay for gmcp data from when a mudlet profile gets started up and connection is finished?
Judging by the error I'm receiving of Char of Vitals being nil both only being mentioned in things like ( I guess Jor'Mox's post above is talking about that, but I'm not sure I'm reading the last part right..)
Anyway I'm guessing that its related to the fact that the script is still not receiving values from mudlet. I tried using a temporal timer, a normal mudlet timer a trigger to delay it but those didn't help, and a loop set up to check if the values are loaded up before going on just freezes and then crashes mudlet.
And I am reading the error logs, just that they do not always help out that much. I have been working on even these probably 'simple' hp and mana gauges for over a week now :/ and that does make me feel a bit pathetic :'|
Judging by the error I'm receiving of Char of Vitals being nil both only being mentioned in things like
Code: Select all
NioSys.currentHP = tonumber(gmcp.Char.Vitals.hp)
Anyway I'm guessing that its related to the fact that the script is still not receiving values from mudlet. I tried using a temporal timer, a normal mudlet timer a trigger to delay it but those didn't help, and a loop set up to check if the values are loaded up before going on just freezes and then crashes mudlet.
And I am reading the error logs, just that they do not always help out that much. I have been working on even these probably 'simple' hp and mana gauges for over a week now :/ and that does make me feel a bit pathetic :'|
Re: Vyzor, UI Manager for Mudlet
I can't say I'm too clear on your problem. Are you never getting values from GMCP? May be a settings problem. Is it that 'delay' that's throwing you for a loop? It should be irrelevant, because your MUD will send those values again later.
And, as a safeguard, why not just do something like:
And, as a safeguard, why not just do something like:
I need more details on what, exactly, is going wrong in the data flow before I could give you a solution. It looks like, at some point in your flow, the data is either missing or the wrong format.
Re: Vyzor, UI Manager for Mudlet
Okay, I'm doing a full backtracking to my last "Working" code, when it at least displayed everything.
Just in case giving more info: GMCP Is activated in the client + I have both drawing the borders and frames in one function and on one script with the gauges, mapper and etc. Only separate script is the colors, but that should be fine. considering all of the colors are getting passed to the frames properly in this last working version.
I'm omitting frame and border construction.
Nothing draws at all, only borders and this pops up, and whichever method I use to update gauges, it just stumbles at the first variable using gmcp on line 82 { NioSys.currentHP = tonumber(gmcp.Char.Vitals.hp) } and says that its nil:
Just in case giving more info: GMCP Is activated in the client + I have both drawing the borders and frames in one function and on one script with the gauges, mapper and etc. Only separate script is the colors, but that should be fine. considering all of the colors are getting passed to the frames properly in this last working version.
I'm omitting frame and border construction.
This was the version pre my inclusion of the following just before the previous lines of code while still logged into the game
giving me essentially this:
All works perfectly at this stage, well aside from my xp bar which displays 83/1 instead of 83/100, and a weird error
but that is not the issue right now. Bad things start to happen as soon as save, close and restart the profile:
Nothing draws at all, only borders and this pops up, and whichever method I use to update gauges, it just stumbles at the first variable using gmcp on line 82 { NioSys.currentHP = tonumber(gmcp.Char.Vitals.hp) } and says that its nil:
Re: Vyzor, UI Manager for Mudlet
I see a couple of things that could cause problems. First, the GMCP thing. Your scripts fire when Mudlet loads the profile, not when you connect to the MUD. This means, of course, that you won't have any GMCP data to use at load time. The simplest solution for you in this case is to initially fill your variables with dummy values.
Like so:
Now, the next thing I see is the way you're passing your addresses to the Gauge constructor. Vyzor uses a function that iteratively tracks through the global variable table (in Lua, this is _G) using the string you passed in, period delimited.
When you pass in something like "totalHP", it's actually looking in _G["totalHP"] (_G.totalHP) and finding nothing. It finds nothing, of course, because you actually stored that value in the variable NioSys.totalHP. Therefore, you want to pass in the address "NioSys.totalHP". This translates to _G["NioSys"]["totalHP"] (_G.NioSys.totalHP).
And, finally, the reason that your XP gauge maximum is 1 is because you passed in "100". This means that Vyzor is looking for a value stored at _G["100"]. Obviously, it doesn't find it, and Vyzor defaults the value to 1. Looking at it now, it may be a nice feature to allow you to pass numbers directly. However, for the foreseeable future, you'll want to make a variable to store that 100 in; something like NioSys.totalXP, to follow your naming convention.
So, to recap, you want something that looks vaguely like...
Like so:
Basically, this says "If the gmcp variable is not nil, then use this value. Else, use 100." It's not strictly necessary here, since we know that the GMCP table doesn't exist yet. But it's a good practice to learn and use elsewhere.
Now, the next thing I see is the way you're passing your addresses to the Gauge constructor. Vyzor uses a function that iteratively tracks through the global variable table (in Lua, this is _G) using the string you passed in, period delimited.
When you pass in something like "totalHP", it's actually looking in _G["totalHP"] (_G.totalHP) and finding nothing. It finds nothing, of course, because you actually stored that value in the variable NioSys.totalHP. Therefore, you want to pass in the address "NioSys.totalHP". This translates to _G["NioSys"]["totalHP"] (_G.NioSys.totalHP).
And, finally, the reason that your XP gauge maximum is 1 is because you passed in "100". This means that Vyzor is looking for a value stored at _G["100"]. Obviously, it doesn't find it, and Vyzor defaults the value to 1. Looking at it now, it may be a nice feature to allow you to pass numbers directly. However, for the foreseeable future, you'll want to make a variable to store that 100 in; something like NioSys.totalXP, to follow your naming convention.
So, to recap, you want something that looks vaguely like...
Hell, just as a bonus, here's how you could turn the whole thing into one loop, since there's a lot of repetition (disclaimer: written in browser):
I'll leave the colours as an exercise for you, if you choose to go down this route. But it may involve tables or functions. As a general practice, it's always helpful to identify areas of repetition, as these areas are usually great candidates for loops; cutting down on the sheer number of lines in your code makes it easier to modify and maintain over time.
Re: Vyzor, UI Manager for Mudlet
Okay, managed to get it to work.
All that still didn't help, was just resetting it to the alternative value of '100'
and normally resetting the gauges didn't help. Solved it by using my Gauge reset script grab new values from gmcp every single time. Thanks a lot for you patience everybody.
As for the chat compound though, I guess there are no ways to make them flash like in YATCO implemented yet?
P.S. Did I misunderstand the init_back in the gauge component? I thought it was supposed to be the background of the gauge, but it isn't drawing. Not that much of a problem but it is slightly annoying.
All that still didn't help, was just resetting it to the alternative value of '100'
and normally resetting the gauges didn't help. Solved it by using my Gauge reset script grab new values from gmcp every single time. Thanks a lot for you patience everybody.
As for the chat compound though, I guess there are no ways to make them flash like in YATCO implemented yet?
P.S. Did I misunderstand the init_back in the gauge component? I thought it was supposed to be the background of the gauge, but it isn't drawing. Not that much of a problem but it is slightly annoying.