|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4715 Location: Pensacola, FL, USA
|
Posted: Thu Feb 06, 2003 1:00 am
Command troubles with GS3 |
ok im trying to get a #func i haveto set variables for me, but the mud im using only allows a set number of queued commands, is there a way to differentiate between commands sent to zMUD and those sent to the game?
|
|
|
|
Emit Magician
Joined: 24 Feb 2001 Posts: 342 Location: USA
|
Posted: Thu Feb 06, 2003 2:06 am |
for you to differentiate? zmud commands all start with #. also, any alias name won't be sent, unless the alias sends. or do you want to know which commands send their arguments? like #SEND and #EXEC? and what does this have to do with #FUNCTION? --a little confused--
--------
moon.icebound.net:9000 |
|
|
|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4715 Location: Pensacola, FL, USA
|
Posted: Thu Feb 06, 2003 6:43 am |
Well the problem is that even using
#var x y
it hits the mud command buffer limit and doesnt get performed
Shalimar |
|
|
|
TonDiening GURU
Joined: 26 Jul 2001 Posts: 1958 Location: Canada
|
Posted: Thu Feb 06, 2003 7:05 am |
If I understand correctly,
#var x y
is being sent to the mud and not being processed by zMud. If this
is the case you have either parsing off (witnessed by a big red X
through the computer icon on the bottom right part of your zMud
window right of the command line).
Or you have change your special characters and disabled Command Char #
or changed the command char to something different.
Did I perceive your issue?
//
As for tracking what is sent to the mud you could probably use
#ONINPUT (^(*)$} {#VAR LastcommandSent "%1";#SHOW Last command @LastCommandSent}
You could make a history list of those commands or track them etc.
Ton Diening |
|
|
|
Anabasis Wanderer
Joined: 26 Jan 2001 Posts: 74
|
Posted: Thu Feb 06, 2003 4:08 pm |
Well I play DR not GS3, but they are both Simu products, and if it's the same there, there is a limit to the number of commands that you can send to the mud. This limits you from just sending a long string of commands, so one of the primary things needed in any script for DR anyway, is to slow it down a bit.
The actual issue with this isn't clear to me, but I think this may be what he is refering to.
Ana |
|
|
|
Guldar Beginner
Joined: 04 Feb 2003 Posts: 12
|
Posted: Thu Feb 06, 2003 11:53 pm |
Simu games dont allow you to type in more than one command between prompts. The prompt signals that you entered a command in and was recieved by Simu. If you type in anything after the initial command, before the next prompt, the imput gets dumped by simu. Basically, the script has to know that the > has been displayed signaling that the previous command was accepted before it executes the next and so on. I have been trying to figure it out in gemstone III scripts but have yet to find anything work yet.
|
|
|
|
TonDiening GURU
Joined: 26 Jul 2001 Posts: 1958 Location: Canada
|
Posted: Fri Feb 07, 2003 5:56 am |
Sounds like you are heading to command queueing. This kind
of script imho becomes very complex and very mud specific.
The basic idea:
Capture all the commands via:
#ONINPUT (^(*)$} { #VAR CommandList %additem("%1",@CommandList);#GAG}
Maintain a list of queued commands with some sort of priotity.
Then send a command when ready
#TRIGGER {SomethingHere?} {#SEND %item(@CommandList,1)}
Figure out when the command sent was executed and %pop it from the
front or %delitem it.
#TRIGGER {My prompt or message saying command complete} {#VAR CommandList %pop(CommandList)}
Ton Diening |
|
|
|
|
|