 |
mercatroid
Wanderer
Joined: 06 Dec 2004
Posts: 59
|
 Posted: Fri Feb 09, 2007 3:09 am
Variable Expansion
|
zMud 7.21, WindowsXP
I'm an admin on my mud and I'm trying to create a zMud database with some basic information on everyone who logs in. I have a trigger which captures their Name and IP from the Wiz channel (only Imms can see this channel). I then compare their name to a stringlist to see if they are one of the immortals. If not, I then check the playerdb to see if they are already there, if not, I add them. Here's the full trigger:
| Code: |
#TRIGGER {^~[Wiznet~: (%w)@(*) has connected. ~]} {
#VAR LastPlayer %proper( %1)
#VAR IP %2
#DBLOAD player
#IF (%ismember( @LastPlayer, @Immortals)) {immtalk Hi @LastPlayer} {
#ADD onlinecount 1
#IF (%numitems( %query( ((&Name = @LastPlayer)), All)) = 0) {#NEW All Name=@LastPlayer|IP=@IP}
#DBSAVE
}
} |
Now this works beautifully. No complaints.
However, I want to add a little more data to each player. There's an Imm command on the mud called "query" which does nothing but return the name, class, and clan of the player. For example:
| Quote: |
(query mercatroid)
Name Mercatroid
Class Mage
Clan Forsaken |
To include this, I made two triggers:
| Code: |
#TRIGGER {^Clan(%s)(%w)$} {#VAR LastPlayerClan %proper( %2)}
#TRIGGER {^Class(%s)(%w)$} {#VAR LastPlayerClass %proper( %2)} |
...then I added two fields to my database (for class and clan), and modified by original trigger like so:
| Code: |
#TRIGGER {^~[Wiznet~: (%w)@(*) has connected. ~]} {
#VAR LastPlayer %proper( %1)
#VAR IP %2
query @LastPlayer
#DBLOAD player
#IF (%ismember( @LastPlayer, @Immortals)) {immtalk Hi @LastPlayer} {
#ADD onlinecount 1
#IF (%numitems( %query( ((&Name = @LastPlayer)), All)) = 0) {#NEW All Name=@LastPlayer|Class=@LastPlayerClass|Clan=@LastPlayerClan|IP=@IP}
#DBSAVE
}
|
The triggers for query work perfectly, but here's the snag: when someone logs in, it gathers their info into the LastPlayerClass and LastPlayerClan variables, but doesn't pass it on to the database. Then when a second person logs in, it passes the information for the 1st player on! What's happening, of course, is that it's not waiting until the variable is filled by the query trigger before sending it on to the database.
What would work perfectly, is if there was a function or something that was the equivalent of pressing the Refresh button in the Settings Editor. That way I could make sure it had the current value of the variable before it passed it on to the database.
Any ideas? |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Fri Feb 09, 2007 3:38 am
|
This is a perfect opportunity to use multistate triggers. How's this?
| Code: |
#TRIGGER "JoinTrig" {^~[Wiznet~: (%w)@(*) has connected. ~]} {
#VAR LastPlayer %proper( %1)
#VAR IP %2
#IF (%ismember( @LastPlayer, @Immortals)) {immtalk Hi @LastPlayer;#state JoinTrig 0} {
query @LastPlayer
#DBLOAD player
#add OnlineCount 1
}
}
#COND {^Class(%s)(%w)$} {#VAR LastPlayerClass %proper( %2)}
#COND {^Clan(%s)(%w)$} {
#VAR LastPlayerClan %proper( %2)
#IF (%numitems( %query( ((&Name = @LastPlayer)), All)) = 0) {#NEW All Name=@LastPlayer|Class=@LastPlayerClass|Clan=@LastPlayerClan|IP=@IP}
#DBSAVE
} |
|
|
Last edited by Fang Xianfu on Fri Feb 09, 2007 6:11 am; edited 2 times in total |
 |
|
|
mercatroid
Wanderer
Joined: 06 Dec 2004
Posts: 59
|
Posted: Fri Feb 09, 2007 5:43 am
|
Xianfu: Thanks for the quick response.
Unfortunately, that code doesn't work at all. It doesn't capture the Name or IP, much less the Clan and Class. I think there's a problem with the #state check, because after someone logs in, I check the settings editor and it's stuck on #state 2 (ie., it doesn't reset).
I did add a #state 0 to the end of the #state 2 command set, but it doesn't help.
Merc |
|
|
|
|
mercatroid
Wanderer
Joined: 06 Dec 2004
Posts: 59
|
Posted: Fri Feb 09, 2007 5:45 am
|
Oh wait
You have a typo in your 1st COND statement....triggers on ^Class(%s)(%w)$ to set the LastPlayerClan variable.
So there's *TWO* "^Class(%s)(%w)$ triggers competing...
Lemme fix it and get back to you. |
|
|
|
|
mercatroid
Wanderer
Joined: 06 Dec 2004
Posts: 59
|
Posted: Fri Feb 09, 2007 5:58 am
|
Yeah, fixing the typo didn't help.
It's just stuck turning on and off various states. It doesn't seem to know which state to be in at any given time, and is always stuck on the wrong state.
-sigh- |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Fri Feb 09, 2007 6:13 am
|
Yes, I naffed up my copy and paste good and proper. They were supposed to be in the order they were recieved - it's fixed above now.
And for some reason #state isn't working like the documentation says it should. If you give the trigger an ID (It's got one in the example above) and then add the ID to the #state command, it should start working.
I used some test input and commented out the DB parts of the script and it's capturing all the variables properly. |
|
|
|
|
mercatroid
Wanderer
Joined: 06 Dec 2004
Posts: 59
|
Posted: Fri Feb 09, 2007 6:24 am
|
Xianfu:
Yay that worked.
Okay, next question. I think I know the answer to this one.
If I wanted to be able to use the query command externally of this trigger, WITHOUT it firing the trigger, I could just make an alias that does
| Code: |
#T- -classname-
query -player-
#T+ -classname- |
...right? |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Fri Feb 09, 2007 6:31 am
|
That's the beauty of multistate triggers. State 1 will only fire after state 0, and state 2 will only fire after state 1. As long as you're not using query inbetween when the script recieves the "connected" line and sends its own query, and when the response arrives, the trigger won't do anything.
EDIT: If you were going to make an alias to turn off a trigger though, just for future reference, you'd use #t- as you described but you'd have to find a way of not turning the trigger back on with #t+ until after the response is recieved. The #alarm command will do it, or you can devise a #temp trigger to turn it back on. |
|
|
|
|
mercatroid
Wanderer
Joined: 06 Dec 2004
Posts: 59
|
Posted: Fri Feb 09, 2007 6:54 am
|
Neat...I've never really bothered with multistate triggers, because I can usually do what I want by setting up a #FU or just chaining together aliases (trigger calls alias which enables trigger2 which calls alias, etc...)
Basically I kludge a lot.
Thanx for your help! |
|
|
|
|
|
|
|
