Zugg Software :: View topic

Wanderer Joined: 06 Dec 2004 Posts: 59

I'm trying to make a capture window for my mud's exp messages.
What I want to do is have the raw number for each kill subtracted from a known variable, and update each time, and sit in a child window off near the right-hand side of the screen

Here's an example of the relevant MUD output:

That will cost 6,128,035,328 experience.

You receive 169306 experience points.

Again, what I'm looking for is a floating capture window that displays the first line, then every time the 2nd line is recieved, it subtracts that amount from the first line, and displays the updated total.

Thanx in advance for any help.

-Merc

Posted: Thu Dec 08, 2005 12:54 am

Have a look at #status and #math

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

See:
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=5498&highlight=double+byte
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=20307&highlight=%23script+number

Very large numbers:
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=7637&highlight=%23script+number
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=22440&highlight=%23mss+number

Wanderer Joined: 06 Dec 2004 Posts: 59

I'm not really concerned with the commas in the first number. I can get around that via the methods you guys listed. I'm really trying to figure out how to output these to a floating (ie., undocked) window.

Thx

Merc

Posted: Tue Dec 13, 2005 12:35 pm

I think I'd use the status window instead of a full blown mud window. Having captured your variables you just have to use #stw @variable. In fact since it looks like you don't have a great deal to display you could use the status line just above the command prompt, #st @variable, this automatically updates itself as the value of variables change.

Wanderer Joined: 06 Dec 2004 Posts: 59

Taz: That worked perfectly....thx!

Wanderer Joined: 06 Dec 2004 Posts: 59

Well, almost perfectly.....

I've got my mud prompt set up with the following information:

Current XP -number-

and a trigger like this:

#trigger {Current XP %1} {currentxp=%1}

This perfectly pulls my current xp and adds it to the variable @currentxp.

I then tried to make a second trigger like this:

#trigger {That will cost %1 experience.} {#math nexttrain (%1-@currentxp)}

This returns a value of zero regardless of the values of @currentxp and %1

I also tried:

#trigger {That will cost %1 experience.} {nexttrain=%eval %1-currentxp}

For example if %1 is 1000000000 and @currentxp is 200000000, I'm obviously expecting it to return 800000000.
It returns the string "1000000000-800000000" instead.

I'm sure this is just something incredibly simple that I'm missing.

Also, zMud seems not to be able to handle very large numbers...I followed the "very large numbers" links that TonDiening posted, but they don't help at all. Most of the numbers these expressions will be evaluateing will be in the hundreds of millions up to 10 billion or so.

thx
Merc

Wanderer Joined: 06 Dec 2004 Posts: 59

Okay, I fixed the large numbers problem by just making it a function. For some reason this works.

At least I think it does, it still won't actually evaluate the expression....it returns the string 10000000000-5500000000 instead of 4500000000.

#Trigger {That will cost %1 experience.} {#fu nexttrain {%eval %1-@currentxp}}

That function trigger works as far as capturing the very large numbers correclty, but doesn't actually perform the operation:
%1-@currentxp

Merc

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

#HELP pattern matching
#HELP %eval

#TRIGGER {That will cost (%n) experience.} {#VAR nexttrain {%eval(%1-@currentxp)}}

Wanderer Joined: 06 Dec 2004 Posts: 59

nexela, unfortunately (as shown in the above posts), I've tried that exact line or a functionally identical one already, to no avail.

The problem comes in zMud's inablity to handle numbers greater than 2147483647.

I thought I had overcome that, but it was a ruse. zMud was evaluting the numbers as if they were strings (which is why it was returning the string %1-@currentxp (with numbers plugged in, example: 1000000000-5000000000) instead of actually performing the calculation.

Any other ideas?

Merc

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Well your biggest problem happens to be the way your using functions and pattern matching, as for big numbers use VBscript

#TRIGGER {That will cost (%n) experience.} {#VAR nexttrain {%mss( {cDbl(%1)-cDbl(@currentxp)}, VBScript)}}

Edit: Changed cInt to cDbl
Edit: Added bottom half

This is why this line is wrong

Wanderer Joined: 06 Dec 2004 Posts: 59

Well thanx for the tip....still not working exactly right, but I think I can work out the bugs.

Just fyi thought:

1] %1 has been the default pattern matching variable for years and years....not just in zMud, but also TinTin, Perl, Python, etc...
2] #fu math (%eval 2-1) assigns the value 1 to the variable @math. As you pointed out, #fu isn't doing the eval....that might be the %eval command in that string.
3] I was using parentheses. Your copy of my code had {}.

Thanx again for your help.

Merc

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

1] Not in zmud %1 is unsupported it only works for compatibilty with tintin but because of its nature can lead to bad things happening.

2] You are changing things again #fu nexttrain {%eval %1-@currentxp} creates a variable with the value: %eval %1-@currentxp, #func doesnt expand #var does. It has nothing to do with the %eval in the string

3] No you were not and no it does not. %eval(%1-@currentxp) NOT %eval %1-@currentxp AND NOT (%eval %1-@currentxp)

And what is not working with the script? I tested it and it seems to be working.

Wanderer Joined: 06 Dec 2004 Posts: 59

1] I've never had any problem with %1, ever.
2] I didn't change anything, the #fu line that I posted did exactly what I said it did, and I've tested other #fu expressions that also contain %eval, and they return exactly the same result as #math or #eval.
3] I see. *I* was the one who copied it wrong. I *did* use parentheses in my original version of that function.

As far as the script, it's working fine now, I had to change the way it stored the variable. Nothing wrong with your line, just in the other lines I had that drew information from it.

Again, thx for your help.

Merc

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Wanderer Joined: 06 Dec 2004 Posts: 59

Given that information, I would say that %n is TheWrongWay, because it would fire on a line that did not contain numerical information (the "a really large amount" line), and therefore would return null values for any subsequent operations you wished to perform on the expected numerical value.

In your pattern matching tutorial, and in the zMud help files, there are plenty of ways to distinguish between numerical, text-strings, general "catch-all" patterns, and any number of other types of patterns.

But w/e, I'm definately not interested in what it turning into a "who's right, who's wrong" argument. Accept my thanx for helping with my problem, and move on. Okay?

Merc

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

How is %n wrong? It matches numbers, numbers with commas, numbers with a +sign and numbers with a - sign %n. Tt is the perfect choice for dealing with numbers with comma's

(%n) would never capture "a really large amount"

Wanderer Joined: 06 Dec 2004 Posts: 59

Posted: Tue Jan 17, 2006 11:54 am

*rofl*

What did you expect, telling a person with 1369 posts and an excellent knowledge of zMUD that they are wrong when they are clearly right and then telling them to move on and ignore your inanity?

Wanderer Joined: 25 Oct 2005 Posts: 99

Definitely definitely funny.
By stating something is the right or the wrong way, you've started the argument no matter how many times you claim you wouldnt want it to turn into an argument lol.
It kind of reminds me of the game 8 year olds play. Tag! You're It! Can't tag me back! Wink

I view forums as suggestions. Take the advice, ask for more, ask for a better explanation, etc. People are here to help and I respect the time and effort they put into the posts.
Also, by stating it is the wrong way, they may start looking for a bug in the programming logic when the logic is designed to do exactly that. This is probably the reason they will ask for more information, not because you told them to move on.

Apprentice Joined: 20 Sep 2005 Posts: 135