 |
| kjaerhus |
Posted: Sat Apr 19, 2008 2:07 pm
Simutronics support |
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
 Posted: Sat Apr 26, 2008 12:51 pm
|
| Fang Xianfu wrote: |
| zMUD had a script debugger, but it wasn't as awesome as the CMUD one is. And the CMUD one was only added quite recently. The changelog will know exactly when. |
It sure is a helpful feature which I am very happy to have now.
| Fang Xianfu wrote: |
| We get quite a lot of people saying that, though - "I never knew it was there!". I get the feeling there should be a gigantic button on the toolbar for it. |
I'll vote for that. I've already missed the library button though but at least the slightly more perceptive user will find it easier then...  |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Sat Apr 26, 2008 2:55 pm
|
| Quote: |
| All of this could be done in #WAITFOR if it was changed to support a full pattern syntax, including captures. The captured portions only need to be available to the true set of commands. Possibly the addition of a regex version would be helpful. |
I think it already does. If you use () in the pattern you can grab the subpattern using the %pat function I think. Also, you can always use the new %/regex/% syntax anywhere that a normal pattern is accepted to match a regular expression. Should work for #WAITFOR too.
Not actually sure how that helps with the problem, but maybe you have an idea you are working on. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sat Apr 26, 2008 3:46 pm
|
Alright I found a problem in my testing method, and am seeing that the full syntax is supported. Seperate bug report for %pat not working.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Sat Apr 26, 2008 6:08 pm
|
| Quote: |
For roundtimes of 4 and 8 seconds I got these GSL values respectively.
|
Keep in mind that sometimes the server tacks on an extra second to the RT, which is never reflected in the actual message you see onscreen. SEARCH is like this--the GSQ/q tag math says the RT is actually 16 seconds but you only ever get [Roundtime: 15 seconds], but it looks like APPRAISE is not.
To see a list of tags that Dragonrealms sends, open up the Simutronics Preferences and look around in the Values tab. There are only 1 or 2 more tags that DR uses that are specific to one of the GSL modes but which are not sent to all of them (the GSB tag--character name--and the GSw00008 tag--time and weather info). You can't actually trigger on the B tag itself as it seems to be coming in during the login process but you should be able to work with the XML that appears in the w00008 tag. |
|
_________________
EDIT: I didn't like my old signature |
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun Apr 27, 2008 1:28 am
|
| MattLofton wrote: |
| Keep in mind that sometimes the server tacks on an extra second to the RT, which is never reflected in the actual message you see onscreen. SEARCH is like this--the GSQ/q tag math says the RT is actually 16 seconds but you only ever get [Roundtime: 15 seconds], but it looks like APPRAISE is not. |
Can't say I ever experienced that problem but now that I know how to get the roundtime through GSL codes I probably won't have to parse the feedback for roundtimes anymore. There were some situations where the screen said roundtime but where you did not have to wait. I think perhaps in these situations it means that your opponent or whatever person you may be dealing with has a roundtime. Anyway, with GSL codes it seems to be bullet-proof. Until now I've had triggers to catch situations where I should ignore roundtimes.
| MattLofton wrote: |
| There are only 1 or 2 more tags that DR uses that are specific to one of the GSL modes but which are not sent to all of them (the GSB tag--character name--and the GSw00008 tag--time and weather info). |
Not sure I understand what you mean. Could you elaborate on that, please? |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Sun Apr 27, 2008 6:52 am
|
To put it more clearly:
1)the GSB tag (it'll have information like 0000000000Symphaena in it) is sent in the Wizard mode (ZMud/CMud in the list of modes is merely a clone of Wizard). If you've used Wizard before, you've seen this in the way it names your play window based on which character you logged in with. This command is not sent in the browser_fe mode.
2)the GSw tag has several uses. 00003/00004 is used when someone dies. 00008 is used to pass on weather and time information. If you've used eScape, you've seen this in its Time/Weather window. In Wizard mode, the command is set to Ignorethis, or at least that's what Zugg has decided to expose to us. |
|
_________________
EDIT: I didn't like my old signature |
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun Apr 27, 2008 10:11 pm
|
| MattLofton wrote: |
To put it more clearly:
1)the GSB tag (it'll have information like 0000000000Symphaena in it) is sent in the Wizard mode (ZMud/CMud in the list of modes is merely a clone of Wizard). If you've used Wizard before, you've seen this in the way it names your play window based on which character you logged in with. This command is not sent in the browser_fe mode.
2)the GSw tag has several uses. 00003/00004 is used when someone dies. 00008 is used to pass on weather and time information. If you've used eScape, you've seen this in its Time/Weather window. In Wizard mode, the command is set to Ignorethis, or at least that's what Zugg has decided to expose to us. |
I just tried changing client and mode to Stormfront to see what will happen. I have trouble matching gsl codes. Seems sometimes the GSQ is a little late and if you then catch the GSq and think there is no roundtime for the command your script will continue to quickly. Do you have an always working solution on how to be sure to match the right GSq and GSQ codes? I suppose it's possible as it's probably these Stormfront uses to makes its wait command...
EDIT: Apparently the value after GSq is the current time and the GSQ value will then be the time at which the roundtime is over. Problem is to match the two when another irrelevant GSq code comes in between. |
|
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun Apr 27, 2008 10:51 pm
|
I get the feeling that if I just delay matching a little I will be sure to see the GSQ if there is a roundtime. That would explain what I said before about that if you used wait in Stormfront for commands without a roundtime the script would run a little slower. This is probably because Stormfront is waiting a little to see if a GSQ code is coming.
How about you, Zugg and Vijilante? Have you found out anything? Is there hope for a simpler solution?  |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Mon Apr 28, 2008 2:02 am
|
| Quote: |
I just tried changing client and mode to Stormfront to see what will happen. I have trouble matching gsl codes. Seems sometimes the GSQ is a little late and if you then catch the GSq and think there is no roundtime for the command your script will continue to quickly.
|
1)Stormfront only uses GSL during the login process. Somewhere, the GSw tag gets sent in there and it has a bunch of numbers in there (no idea what that might be as I can't see it, though it looks like maybe it was the last time you logged in). For Roundtime, it's depending on the <prompt> tag, which uses a time parameter (same as GSq) and the inclusion of visible status text (similar to the GSP tag). R = roundtime, but it doesn't say how long it lasts AND the prompt is only sent with new game messaging or on the status/prompt pulse.
2)GSQ is ALWAYS sent at the beginning of a block of visible messaging text sent to the user. GSq is always sent at the end of such text, in similar fashion as how [roundtime: 8 seconds] is always shown last right before the prompt. If you are not using a two-state trigger matching first on GSQ and then on GSq, either you are doing it wrong or someone on DR staff messed up somewhere.
Get very specific if you have problems, because I am not and never have and there's several hundred situations that produce RT in this stinkin' game (and, no, I'm not going to memorize them). |
|
_________________
EDIT: I didn't like my old signature |
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Thu May 01, 2008 10:16 pm
|
| MattLofton wrote: |
| Get very specific if you have problems, because I am not and never have and there's several hundred situations that produce RT in this stinkin' game (and, no, I'm not going to memorize them). |
Well, one problem I have right now is to be sure that the GSL q trigger is fired because DR acknowledged my command. Often DR sends a GSP code which seems to trigger a GSq code too which makes me react too quickly. I can't just ignore the first GSq code after a GSP code though as there might be a GSP code in the feedback from DR. Very confusing - they are not making things easy.
Do you have a solution? |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Fri May 02, 2008 10:38 pm
|
| Quote: |
Well, one problem I have right now is to be sure that the GSL q trigger is fired because DR acknowledged my command.
|
Multi-state triggers. You do not sound like you are using them, instead using two single-state triggers (#TRIGGER Q... and #TRIGGER q... versus #TRIGGER Q... and #CONDITION q...). This will cause problems because #TRIGGER does not establish context for any other #TRIGGER. Ergo, you can never be sure one will fire before the other or even that one fires at all. Multi-state triggers solve this problem by forcing each state to match in a set sequence with zero variance.
If you are using them, put up a screenshot with the GSL emulation turned off demonstrating the problem you are describing. I specifically have never seen it happen in DR, and I've been messing with this for the last 5 years. You may also want to include a second screenshot of the same situation with GSL turned on, and your code relavent to that situation. |
|
_________________
EDIT: I didn't like my old signature |
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun May 04, 2008 12:59 am
|
| MattLofton wrote: |
| Multi-state triggers. You do not sound like you are using them, instead using two single-state triggers (#TRIGGER Q... and #TRIGGER q... versus #TRIGGER Q... and #CONDITION q...). This will cause problems because #TRIGGER does not establish context for any other #TRIGGER. Ergo, you can never be sure one will fire before the other or even that one fires at all. Multi-state triggers solve this problem by forcing each state to match in a set sequence with zero variance. |
After introducing a multistate trigger things seem to work reasonably well. I didn't make the Q-q one you suggested though as I am trying to make a command that handles all three types of commands: prompt, feedback and roundtime.
I do get some strange InvalidPointer exceptions once in a while though and I am not sure why I get these. As I am not deliberately using pointers I feel inclined to believe that there must be a bug of some kind. Unfortunately it's hard to figure out exactly why and when it happens and the report is not exactly easy to understand. I sense that they happen at certain situations though so I might be able to narrow the problem enough to be able to present the problem better. If anyone knows pitfalls that leads to this exception I'd be glad to hear.
You sound like you have a solution for the command I request yourself, Matt. Care to share? |
|
|
|
|
kjaerhus
Magician
Joined: 18 Dec 2006
Posts: 317
Location: Denmark
|
Posted: Sun May 11, 2008 12:21 pm
|
I'm still stuck. Any ideas out there?
|
|
|
|
|
orphean
Apprentice
Joined: 21 Oct 2008
Posts: 147
Location: Olympia, WA
|
Posted: Fri Nov 06, 2009 9:55 pm
|
Sorry for the 2+ year thread necro but I managed to get a mechanism that respects the round time working reliably in CMUD. It uses one additional thread which executes a loop that uses Zugg's idea earlier in the thread to #wait out the round time, and then using a string list as a command queue, pop off the next command and send it to the game. It triggers off of GSq for the prompt and the round time provided by the game to do some additional state tracking. While in a round time it will also display the tick timer so you can see how much longer the round has as well.
The entire interface to the system is a single alias: rt_execute. It takes a single parameter, a string list of commands to send to the game. Commands with a round time and commands without can be freely interspersed in this list. You can still send commands to the game while in the middle of queue execution (this necessitated the addition of a sentinel variable which makes me sad, but I figure it's worth it since then it doesn't break when the user sends something )
So here's an example session:
| Code: |
> rt_execute power|hunt|look|power
>power
Xibar is dominant, while Katamba and Yavash's influences are strong.
Psychic Projection and Moonlight Manipulation spells are favored.
Roundtime: 8 sec.
>look
[The Crossing, Gull's View Lane]
Small shops and a few sparsely-stocked pushcarts line this street. One elderly street vendor is selling small clay cups of steaming hot tea which he hawks with a hearty smile. The clapboard buildings are weathered but well maintained, giving a shabbily genteel impression. Shrill cries and the sound of rushing water drift up from the south, plaintive and forlorn, causing you to shake off a clammy chill. Civilization, and the town's center, beckon to the north. You also see a modest outdoor shrine and a street vendor's cart with a wooden plaque mounted on it.
Obvious paths: north, south.
hunt
You take note of all the tracks in the area, so that you can hunt anything nearby down.
To the north:
1) a shaggy mutt
To the south:
2) a town guard
To the south, east:
3) a town guard
Roundtime: 8 sec.
look
[The Crossing, Gull's View Lane]
Small shops and a few sparsely-stocked pushcarts line this street. One elderly street vendor is selling small clay cups of steaming hot tea which he hawks with a hearty smile. The clapboard buildings are weathered but well maintained, giving a shabbily genteel impression. Shrill cries and the sound of rushing water drift up from the south, plaintive and forlorn, causing you to shake off a clammy chill. Civilization, and the town's center, beckon to the north. You also see a modest outdoor shrine and a street vendor's cart with a wooden plaque mounted on it.
Obvious paths: north, south.
>power
Xibar is dominant, while Katamba and Yavash's influences are strong.
Psychic Projection and Moonlight Manipulation spells are favored.
Roundtime: 7 sec.
A town guard walks in, glancing about with a false look of boredom on her face.
> |
You can see after the initial command, I interrupt the sequence with a 'look' and it doesn't trip it up.
If rt_execute is called while in the middle of an execution sequence it just tacks on the new commands to the end of the current queue. This is arguably wrong for some use cases where the user wants the old sequence to be interrupted, but seemed to me to be the right choice for most of the time.
Anyway, I am very new to Simu muds (this is running on DragonRealms) so there might be some other cases I am not aware of where this fails. But, it seems to work well. It doesn't do much on it's own but could be used as a base for round-time aware scripts.
It's in the package library as RoundTimeSupport in the Dragonrealms area if anyone wanted to check it out. |
|
|
|
|
Belmyrddyn
Magician
Joined: 17 Oct 2001
Posts: 371
Location: USA
|
Posted: Sun Nov 08, 2009 1:30 am
|
I had built a "engine" system for zMUD quite a few years ago when I was more active. While the example below is simplistic, it used the following basic idea:
A trigger that executes every second. If there was a roundtime, it deducted 1 second from the roundtime. It then executed any command in the "command buffer" variable(s). You could have a simple buffer that contains a list of commands to be sent when the wait time was zero, or you could have two buffers - one for commands that will get tripped up by roundtime (such as a command that causes new roundtime) or a one for a command that wouldn't be bothered (exp, or some such) and will execute immediately where there is a round time or not.
It's not terribly complicated. You just use an alias to store commands. This works fine for automatic scripting. However, scripting in cMUD will ALWAYS be dramatically different (and VASTLY more powerful) than scripting in any other client around. |
|
_________________
Belmyrddyn |
|
|
|
Arde
Enchanter
Joined: 09 Sep 2007
Posts: 605
|
Posted: Mon Nov 09, 2009 6:05 pm
|
I did a similar script more than year ago with usage of separate thread.
Unfortunately, I've given up with that idea: my script was good for popping up CMUD\Windows bug and was not too stable:
http://forums.zuggsoft.com/forums/viewtopic.php?t=31749
I believe several additional threads that will check each others status (working\terminated) on each iteration could add some stability, but that's too complex from my pov. I'd better wait till bugfix. |
|
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads |
|
|
|
Belmyrddyn
Magician
Joined: 17 Oct 2001
Posts: 371
Location: USA
|
Posted: Mon Nov 09, 2009 7:57 pm
|
I don't really like to use threading. My system avoided it entirely.
|
|
_________________
Belmyrddyn |
|
|
|
orphean
Apprentice
Joined: 21 Oct 2008
Posts: 147
Location: Olympia, WA
|
Posted: Mon Nov 09, 2009 8:16 pm
|
I actually updated my system to use your system idea and dropped the thread entirely. It's absolutely rock solid and, as a bonus, simpler than dirt. That was a great idea, thanks for sharing it.
A bit of an aside, if you're willing to share your work, please keep us updated on your progress with Stormfront XML. I'm very interested to know how you're progressing! |
|
|
|
|
|
|
|
