Pluginator Updates (and requests)
Re: Pluginator Updates (and requests)
First, thank you so much for the advanced warning. This would break a lot in Artus's pack so this gives me a chance to figure out how to prevent that.
One question. When you have a wound, and it heals up completely, will there be an update to show this? I know the game sends a message but I mean from the pluginator itself?
Really wish I had time/energy to get better with Lua. There's so much potential with this thing.
Oh, one other question. You said that the full string will be sent once upon login. But currently, the pluginator must be specifically enabled each time you log in a character. So does this mean that will no longer happen? Or, are you saying that the full string will be sent once after turning the pluginator on?
One question. When you have a wound, and it heals up completely, will there be an update to show this? I know the game sends a message but I mean from the pluginator itself?
Really wish I had time/energy to get better with Lua. There's so much potential with this thing.
Oh, one other question. You said that the full string will be sent once upon login. But currently, the pluginator must be specifically enabled each time you log in a character. So does this mean that will no longer happen? Or, are you saying that the full string will be sent once after turning the pluginator on?
Re: Pluginator Updates (and requests)
Yes, when a wound goes to 0 it will show it once as 0. Example: <<<PLUGINATOR!>>>{'wound_left_leg': 0}<<</PLUGINATOR!>>>
And yeah, I meant when the pluginator is initially enabled, it'll show all plugin data. I figure that'll be necessary to initialize client-side stuff.
And yeah, I meant when the pluginator is initially enabled, it'll show all plugin data. I figure that'll be necessary to initialize client-side stuff.
<Rias> PUT ON PANTS
<Fellborn> NO
<Fellborn> NO
Re: Pluginator Updates (and requests)
Definitely good to have the full string at least once. Okay, I will give this some thought and try to have at least a testable version by the time you push the changes. Thanks!
- OldNoctere
- Posts: 8
- Joined: Mon Oct 30, 2023 7:15 pm
Re: Pluginator Updates (and requests)
For any interested here is some code to work with the new pluginator. It can also be used to get started making your own.
Here is an example output from the pluginator:
As you can see the information is given in what is essentially key value pairs. For example you know that your current roundtime is "0" because of the line 'roundtime': 0
A good regex trigger to parse the info could be: (start your information grabbing trigger with this)
From there you need to look through whatever information is caught between the (.*) To do that there are several ways depending on the client you use and what code you are using. In Mudlet this is one way you can do it in LUA:
Feel free to pick any variable name or method you like but the above way will load all the information in variables such as coggroundtime will tell you what your roundtime is as a string "0" and coggroundtimenum will tell you what it is as a pure number 0 (different data types)
(BE SURE TO ZERO OUT EVERY VARIABLE WITH THE NEW CHANGES) You might be able to get away without doing it if the client sends you the full chunk of data when you login as previously posts mentioned. But for existing plugins or as a precaution you might need to take every variable and zero it out manually in the code. For example:
I hope this helps! As always, I plan to make my own plugins and release them to you kind folks but it never hurts to have a little more info.
Here is an example output from the pluginator:
Code: Select all
<<<PLUGINATOR!>>>{'roundtime': 0, 'traveltime': 0, 'exp_bucket': 112, 'morale': 1.91, 'nutrition': 87, 'balance': 0, 'energy_current': 500, 'energy_max': 500, 'sanity': 100, 'encumbrance': 3, 'risk': 0, 'armor_level': 3, 'disguised': 1, 'exp_total': 536308, 'next_level_at': 551250, 'next_level_until': 14941}<<</PLUGINATOR!>>>
A good regex trigger to parse the info could be: (start your information grabbing trigger with this)
Code: Select all
^<<<PLUGINATOR!>>>{(.*)}<<<\/PLUGINATOR!>>>$
Code: Select all
deleteLine()
dicty = matches[2] --this was the (.*) in the regex trigger from earlier
encur = string.match(dicty, "'energy_current': (%d+)")
enmax = string.match(dicty, "'energy_max': (%d+)")
foodmatch = string.match(dicty, "'nutrition': (%d+)")
exp_total = tonumber(string.match(dicty, "'exp_total': (%d+)"))
next_level_at = tonumber(string.match(dicty, "'next_level_at': (%d+)"))
exp_bucket = string.match(dicty, "'exp_bucket': (%d+)")
coggroundtime = string.match(dicty, "'roundtime': (%d+)")
coggroundtimenum = tonumber(coggroundtime)
cgbalance = string.match(dicty, "'balance': (%-?%d+)")
cgrisk = string.match(dicty, "'risk': (%d+)")
heado = string.match(dicty, "'wound_head': (%d+)")
necko = string.match(dicty, "'wound_neck': (%d+)")
chesto = string.match(dicty, "'wound_chest': (%d+)")
backo = string.match(dicty, "'wound_back': (%d+)")
abdomeno = string.match(dicty, "'wound_abdomen': (%d+)")
rightarmo = string.match(dicty, "'wound_right_arm': (%d+)")
leftarmo = string.match(dicty, "'wound_left_arm': (%d+)")
righthando = string.match(dicty, "'wound_right_hand': (%d+)")
lefthando = string.match(dicty, "'wound_left_hand': (%d+)")
rightlego = string.match(dicty, "'wound_right_leg': (%d+)")
rightfooto = string.match(dicty, "'wound_right_foot': (%d+)")
leftlego = string.match(dicty, "'wound_left_leg': (%d+)")
leftfooto = string.match(dicty, "'wound_left_foot': (%d+)")
(BE SURE TO ZERO OUT EVERY VARIABLE WITH THE NEW CHANGES) You might be able to get away without doing it if the client sends you the full chunk of data when you login as previously posts mentioned. But for existing plugins or as a precaution you might need to take every variable and zero it out manually in the code. For example:
Code: Select all
if coggroundtime == nil then
coggroundtime = "0"
end
Re: Pluginator Updates (and requests)
This doesn't sound right, based on what Rias wrote. If your roundtime is 10, 9, 8, and pluginator sends you things like wounds while you get hit, but your roundtime has not ticked in that exact instance as well, your roundtime would constantly get zeroed in between roundtime updates, for every other update that pluginator sends. Constantly zeroing it just because it's not included sounds like a bad time.Code: Select all
if coggroundtime == nil then coggroundtime = "0" end
<<<PLUGINATOR!>>>{'roundtime': 10}<<</PLUGINATOR!>>> = roundtime 10
<<<PLUGINATOR!>>>{'energy': 450}<<</PLUGINATOR!>>> = roundtime 0, energy 450
<<<PLUGINATOR!>>>{'roundtime': 9}<<</PLUGINATOR!>>> = roundtime 9
Re: Pluginator Updates (and requests)
Oo, this brings up another question. I think I know the answer but if Rias could confirm that would be great.
Will each change be separate then? Or if more than one thing changes in a tick, or whatever increment you're using, would the line still potentially include more than one item? For example, you get hit by something which both lowers your energy and adds or increases a wound. I assume both would get sent in the same line then?
Will each change be separate then? Or if more than one thing changes in a tick, or whatever increment you're using, would the line still potentially include more than one item? For example, you get hit by something which both lowers your energy and adds or increases a wound. I assume both would get sent in the same line then?
- OldNoctere
- Posts: 8
- Joined: Mon Oct 30, 2023 7:15 pm
Re: Pluginator Updates (and requests)
A good thought Serity. You do want to be careful not to zero out the information every time it triggers. That is why I recommend checking to see if the information is "nil" before doing so.
So if your roundtime is 11 then you can check with the code:
If the information is anything other than nil then it will go ahead and update the info.
for example:
This will not be zero'd out if you check if it was nil beforehand.
So if your roundtime is 11 then you can check with the code:
Code: Select all
if coggroundtime == nil then
for example:
Code: Select all
<<<PLUGINATOR!>>>{'roundtime': 11}<<</PLUGINATOR!>>>
- OldNoctere
- Posts: 8
- Joined: Mon Oct 30, 2023 7:15 pm
Re: Pluginator Updates (and requests)
I am fairly certain Rias will pair updates together if they happen in the same second. For example:Will each change be separate then? Or if more than one thing changes in a tick, or whatever increment you're using, would the line still potentially include more than one item? For example, you get hit by something which both lowers your energy and adds or increases a wound. I assume both would get sent in the same line then?
Code: Select all
<<<PLUGINATOR!>>>{'roundtime': 11, 'energy_current': 400}<<</PLUGINATOR!>>>
Re: Pluginator Updates (and requests)
Right, but then you get some other update, such as "{'energy': 450}", and your script parses...OldNoctere wrote: ↑Tue Nov 28, 2023 4:10 pm A good thought Serity. You do want to be careful not to zero out the information every time it triggers. That is why I recommend checking to see if the information is "nil" before doing so.
So if your roundtime is 11 then you can check with the code:...Code: Select all
if coggroundtime == nil then
This will not be zero'd out if you check if it was nil beforehand.
Code: Select all
dicty = matches[2] --this was the (.*) in the regex trigger from earlier
coggroundtime = string.match(dicty, "'roundtime': (%d+)")
You likely want the line to look something more like:
Code: Select all
coggroundtime = string.match(dicty, "'roundtime': (%d+)") or coggroundtime
- OldNoctere
- Posts: 8
- Joined: Mon Oct 30, 2023 7:15 pm
Re: Pluginator Updates (and requests)
Serity, it sounds like some order of operations are getting a little 'confuzled' between us. But it sounds like you have a grasp of what is going on. Keep in mind I am using the method I mentioned above successfully in my current plugins.
However your idea of checking if the value is true upon its original parse is a good one. But things get a little strange when comparing true, false, nil, 0, "" and other things in LUA and mudlet. (It is VERY possible I am wrong) I recall trying to check NIL as a false value before and having some weird behavior coming from it. So, I tend to avoid it.
More testing is required, but that may just do the trick!
However your idea of checking if the value is true upon its original parse is a good one. But things get a little strange when comparing true, false, nil, 0, "" and other things in LUA and mudlet. (It is VERY possible I am wrong) I recall trying to check NIL as a false value before and having some weird behavior coming from it. So, I tend to avoid it.
Code: Select all
coggroundtime = string.match(dicty, "'roundtime': (%d+)") or coggroundtime