Zugg Software :: View topic

Adept Joined: 18 Jun 2019 Posts: 279

I am a bit vague on this topic, so if anyone can clear things up a little...

Eg., The following checks the potion vars. I have some potion actions on buttons. I have noticed that sometimes when I click the button, the action is performed but the variable doesn't decrement. Thus, I made the following:

Posted: Wed Mar 16, 2022 5:50 pm

I believe you have to contain it all within {} if you want it to count as the named thread.
Supposedly just doing #WAIT 0 will shove the body of the setting in question into its own anonymous #THREAD.
I never got into all the capabilities of using #THREADs though, so you will have to experiment.

Posted: Thu Mar 17, 2022 4:29 am

Oh, I bet this is just the display bug of referencing a dbvar. The value will be accurate even if it still displays the old value.
For some reason variables used in the caption only update if they are stand-alone.
Disabling and enabling the button -should- update the display value, if that is indeed the issue.

Adept Joined: 18 Jun 2019 Posts: 279

I'll have to try the the thread thing again in {}. I did do this previously for a script but, whether it was the brackets or some other factor, the script didn't run at all.

For the most part (aside from the slight glitch) the variables do count down, especially out of combat as there is less spam from the mud.

The variables for these buttons are one-value vars: numHP, numMN, numMV. When I buy potions, a trigger script lifts any of the same potions out of a bag and, when they all go back in, the value is sent to num$pot ($pot=hp/mn/mv).

Currentpotions is populated when I shop for potions. Depending on char level, better potions are dropped into currentPotions: for hp, mn, mv, sanc, fly, etc. matched with a store to buy them in. Eg., for hit points: hp="level=60|keyword=duff|shop=23160".

Adept Joined: 18 Jun 2019 Posts: 279

Hmmm...I am not sure that THREAD{}does anything, or, if it does, there must be constraints which are undocumented. Thus, we have no real idea how to work these commands. It's a shame as I am sure it would increase the efficiency of the client/mud relationship.

Posted: Sat Mar 19, 2022 3:59 pm

Honestly, I'm not sure that there is anything complex enough to require threading on a daily basis.

It is mostly used to shunt code that would otherwise cause CMUD to freeze up as it processes, like a complex %mapquerry.
That way your other settings can still process incoming text from the server.

That was also one of the issues with #WAIT in zMUD, no other settings would process for the length of the wait, which I assume is why any use of the #WAIT command now pushes things into an anonymous thread.

CMUD has many ways to accomplish most tasks.
I am partial to using #EVENTs over #ALIASes anymore, if only because a disabled #EVENT won't send a nonsense command to the game in the aliasname.

Adept Joined: 18 Jun 2019 Posts: 279

How do you define your threads? I have been testing #TH and have found that, in many cases, the scripts do not execute, but some do. I have tried using the following variations:

If I have a trigger/alias:

Eg., #ALIAS fred {code}

I have used:

#ALIAS fred {#TH "thread" {code}}

#ALIAS fred {#TH thread {code}}

#ALIAS fred{#TH code}

Posted: Mon Apr 11, 2022 6:21 pm

The first example is the one cited in #HELP #THREAD.
Have you found a given script that reliably fails using that syntax?

Adept Joined: 18 Jun 2019 Posts: 279

Aye.

Posted: Wed Apr 13, 2022 2:39 pm

Does the failed script work outside of a thread?
I would imagine there is something getting misinterpreted with all those quote marks.