Zugg Software :: View topic

Beginner Joined: 24 Jan 2012 Posts: 16

Prompt in my Mud looks something like this:

100H 100M 100S 20X 1190334x [tankName:tankStatus][targetName:targetStatus]hours:minutes[NS]>

I was able to load the first few numbers into variables, but I would like to load the strings (tankName, tankStatus, targetName, targetStatus) and numbers at the end (hours, minutes)into variables as well. So far I haven't had any luck with Triggers... need someone with experience

Beginner Joined: 24 Jan 2012 Posts: 16

Forgot to mention that I tried to use #setprompt but it required me to put symbols right at the beginning of my prompt and would only gather numbers, not strings. Whatever triggers #setprompt created are not visible in the settings so I don't know if they will get in the way of anything.

Posted: Sun Oct 28, 2018 12:03 pm

Something like this:

#TR {(%d)H (%d)M (%d)S (%d)X (%d)x ~[(%w):(%w)~]~[(%w):(%w)~](%d:%d)~[NS~]} {
hp=%1
mp=%2
sp=%3
level=%4
xpNeeded=%5
tankName=%6
tankStatus=%7
targetName=%8
targetStatus=%9
time=%10
}

Oh, dont forget to change it from firing on newline to firing on prompt, those are checkbox options you can toggle in the GUI

Beginner Joined: 24 Jan 2012 Posts: 16

Beginner Joined: 24 Jan 2012 Posts: 16

I'm not sure if I need to escape the > symbol at the end of my prompt because the pattern matching help page has a dead link for special characters.

Further I noticed that zmud user manual pages redirect to cmud user manual pages, and I'm not sure if there are differences in syntax between them. #HELP command in zmud doesn't work.

edit: OK the problem is that statuses can have a space in them or be empty ... now I will go try to fix this
edit: new pattern is this:

(%d)H (%d)M (%d)X ~[(*):(*)~]~[(*):(*)~](*):(*)~[(*)~]~>

It is workingvery well except that the exits variable is storing a right bracket, eg exits=ws] when i'm expecting exits=ws

Posted: Mon Oct 29, 2018 1:15 am

There is no reason for that to happen unless you occasionally get one with a double square bracket closer: ]]
Unless you have another trigger also defining your exits variable

Beginner Joined: 24 Jan 2012 Posts: 16

OK thank you for the help. It isn't actually storing the right bracket in the variable. I thought it was because the script appears in brackets when show triggers is enabled. Silly me....

Now I would like an opinion if you have time. If I want to use triggers to keep track of when a debuff will fall off a mob, what would be the best way to do that?

I am thinking to create a trigger on, for example: {(*) goes blind!}

let's say that blind lasts for MUD hours equal to level of the caster (are MUD hours the same as ticks? one MUD hour is equal to one real world minute)

So I will make the trigger store the expiration time of the debuff in one variable, and i will have another variable which is time remaining (expiration time - current time gathered from prompt). I think I can use an IF statement calculate accurate times in case the debuff rolls over into the next day.

I will do this for all debuffs and finally make an alias along the lines of:

{<calculate current time remaining on debuffs>;
#show blind: @blindRemaining;
#show cripple: @ crippleRemaining;
...}

One problem however is that different characters will see different debuffs applied. And yet another character may want to use the alias to view debuff information. Can an alias on one character be used to get information about variables stored on other characters? Or is there a simpler way to do what I want that you know of?

Posted: Mon Oct 29, 2018 4:47 am

You can set the #TICK interval as the end user.
It essentially works as an #ALARM, which I would suggest you learn instead.

#ALARM blind%1 +@level:00 {#SAY %1 regains sight}

Variables cannot be shared in zMUD, however, you could always a #TRIGGER off a given question and just flat out tell the person on the other end the current value of your variables.

#TR {(%w) asks, "How long will I be blind?"} {tell %1 roughly %int(%eval(%alarm(blind%1)/1000)) more hours}

Beginner Joined: 24 Jan 2012 Posts: 16

Shalimar,

The characters may be unable to communicate via the MUD, however. So does it make more sense (for multiplaying) to just have multiple instances of one character, and turn folders on/off in each window based on what character is logged in within each window? The only problem I would have is that I've been using one window as the 'master' to send commands to the other characters ie. using charname:command , and I don't know how to target other windows if they have the same charname.

From poking around, it sounds like it's possible to view the current state of variables in another window. Some people have even made graphical hp bars. I don't need anything graphical, but I can't see how to accomplish this...

Posted: Sun Nov 04, 2018 12:54 am

It is much easier to do in CMUD.
You could also make use of named variables.
@bobHp
@billHp
etc

Beginner Joined: 24 Jan 2012 Posts: 16

You mean handling settings for multiplaying is easier in CMUD, or the part about showing the variables in an external window? I am willing to learn if it saves $30, but not if it's impossible. Are there some relevant commands/functions in particular that I should study up on?

Posted: Sun Nov 04, 2018 2:25 am

if you mean a child window within zMUD, it is easy to just print in another window with the #WINDOW command.
#WINDOW ScoreCard {Bill: HP:@billHp/@billHpMax}

You might also want to take a look a the #STATUSWINDOW object in the GUI (looks like a speedometer), it appears in the status window (open it from the window menu) and is essentially like a whole bunch of such #window statuments that try to stay updated automatically.

In CMUD it is possible to use the COM interface to access other programs, though I haven't played with that much to be able to explain it.
As well as execute code in other languages such as Lua, JScript, VBScript, and most anything you have installed locally.

It really depends on what exactly you are trying to do, or have familiarity with.

Beginner Joined: 24 Jan 2012 Posts: 16

That #WINDOW command is exactly what I was after. Thank you! Now if I can figure out how to make it update... Would it be too heavy to send updates every single prompt.

I do not understand what you mean about #STATUSWINDOW, however. It is not in the command reference, and the only speedometer icon anywhere in my GUI is "define status bar" in the actions dropdown (it's for making #STATUS definitions)

Posted: Sun Nov 04, 2018 3:20 am

Yes, it's the same item, there should be a checkbox to toggle it between status line (between the main window and the command line) or the status window I previously mentioned.

Beginner Joined: 24 Jan 2012 Posts: 16

OK. There is a window field for making status variables output to a window, and it works, but although the status bars above the prompts update automatically, the status window "ScoreCard" does not

Posted: Sun Nov 04, 2018 10:49 am

Correct, that is expected, you can ditch the Scorecard window if the #STATUS object is working for you.

Beginner Joined: 24 Jan 2012 Posts: 16

My question is, is it possible to have the scorecard window update automatically, because it would be good to have the the information from 3 windows all visible in one place, instead of over 3 separate command bars.

Posted: Sun Nov 04, 2018 10:05 pm

Unfortunately not.
But if you are abble to give each person separate variables, you can make guages with them out of #BUTTONs.
#buttons all but have to be made via the settings editor.
Set the type to guage, the just insert the appropriate variables on the guage tab.