Line capture

At least one other person has brought up this kind of situation and while using a trigger with just * in it works, there are potential problems with doing it that way. The biggest one being that a complicated enough script would, I assume, occationally miss lines and thus fail to do what it is supposed to. So here is an idea:

New commands>
world.capture (Num_Lines)
X = world.retrieve ()
I = world.eoc ()

The first command would not actually read lines, but simply save an array that keeps track of where the lines in the output buffer start that have been 'captured'. This solves both the problem of a script missing any lines and having to store them in another array.

The second command would pull the first line in the buffer that has been marked and decrement the number available, with all needed adjustments to pointers, etc.

The third is like an eof(), returning a 'true' value if all lines have been 'retrieved' and 'false' if some are still available. This would of course become 'true' if any lines in the captured set scroll off before read.

Doing it this way would allow a script to handle things, in most cases, without worrying about when the lines are coming in or other complications that could create problems, due to delays caused by the script itself. Hmm. It occures to me that some problems might be possible if you have two calls to capture following one another, but in most cases that shouldn't happen and it could simply be made so that the second one overrides the first. After all, you get the same potential problem if you had two triggers trying to use '*' at the same time anyway.

What brought this up? On the mud I play I have two seperate sets of eq, while I can put on most of it with aliases, store it the same way and even put it away at the end of the day, doing so requires changing 4 aliases every time I get some new piece of eq, this is made worse by the fact that of the 500+ items on the mud, only 20% (I am guessing) have been given unique ids that can be used in commands to tell them apart. While fixing the ids would be the best approach, bigger bugs are being dealt with and no time is available to fix this. Being able to simply drop a new piece of eq into a chest and the next day having my script 'see' what I picked up and from where, would be a lot easier. The trouble being that I fear any script complex enough to handle this and not misidentify items from channels, tells, sales, permanent inventory, etc., would also be prone to making similar errors due to not seeing every line.

I may be wrong about this though, since I am not real clear as to how the scripting works if a sub gets called while still doing something else. If it interrupts the previous call you would lose whatever it is doing. If it spawned a seperate process, then it would not update the global array, needed in my example, correctly and you would still lose something. Either way, this is not good.

I am not aware of any problems with scripts missing lines "because they are busy" or some such thing. MUSHclient processes each line the same, and calls all scripts. Theoretically at least, it should never miss any. More output arriving (within reason) would be queued and processed in turn. Possibly a highly complex script might take so long the queue is discarded, but I have not heard of that happening.

If you think it would be useful, I could add commands along the lines of what you describe to the next version, but try the script approach first. :)

I will definitely try it the other way, should I find myself dealing with eq that I can't handle otherwise. The only item I currently have that I would need it for is an old copy of an amulet that will likely be destroyed when the quest for it is officially introduced, and that wizard has already corrected the id issue for it. I am just looking at the situation for other people who may need something more complex and thus possibly causing them problems. Also, sometimes it may be useful to delay reading of the lines for some reason, as the current method of using a match on everything would require saving the whole mess into an array in order to process it later. Though that could possibly work better anyway.... Oh well, I suppose until someone manages to create a script that does have problems, such a feature is not exactly critical. ;) There are times that the client can and does miss lines though (as I describe below), but I am not sure why it happens, unless it is the insane number of color triggers I use. lol

However, about another item...

I did a search in your suggestion list for this, but didn't find anything specific to it or in help or other forums. I currently use a simple case statement to send commands to the mud, to travel to various areas, and the only ways of adding enough delay between commands is to either use a mess of aliases or to use something other than a simple case statement. The problem is that on some muds, either the client is not getting everything, or the mud is interrupting itself and trying to send the next room, before finishing the first. As a result it eats descriptions and the last several rooms in the sequence are often not displayed at all. (Thus making it hard to check if you got there ok). I attempted to use a look command to see if I did get there, but then that becomes the last group of lines recieved and it gets eaten, so I still don't know if i got there. :p

While I could read the commands by dissecting a string of them defined in the case statement, then sending each one with a loop in between for a delay, but that (I assume from another post) would prevent menu commands, etc. during the movement. This also would not create a consistant delay on different machines and could thus be too fast on some and not fast enough on others.

Some sort of 'world.walk' command that uses the speedwalk delay would be very helpful in this case. Especially since with the number of aliases I already have (76) it is 'real' fun trying to find the one I want to change and only two of those 76 are left over from when I did try aliases. I would need an extra 30 for those areas I have paths calculated for already, not including anything else I need to add, delete or change later. Being able to queue the commands from a script would be much easier for those who do use scripts as well as less messy than having 30 or more aliases to do the same thing. ;)

I can see now that you obviously play on Ages of Despair, which is also my stomping grounds.

Regarding the Equipment, here is the way I handle it:

I create a subroutine for each equipment location. I use a pile of aliases to set the item for each location. Here is the related script subroutines:

Sub Set_Item_LHand (thename, theoutput, thewildcards)
World.SetVariable "Item_LHand", CStr(thewildcards(1))
World.Note "L.Hand: " & World.GetVariable("Item_LHand")
End Sub

Sub Set_Item_RHand (thename, theoutput, thewildcards)
World.SetVariable "Item_RHand", CStr(thewildcards(1))
World.Note "R.Hand: " & World.GetVariable("Item_RHand")
End Sub

Sub Set_Item_Head (thename, theoutput, thewildcards)
World.SetVariable "Item_Head", CStr(thewildcards(1))
World.Note " Head: " & World.GetVariable("Item_Head")
End Sub

Sub Set_Item_Neck (thename, theoutput, thewildcards)
World.SetVariable "Item_Neck", CStr(thewildcards(1))
World.Note " Neck: " & World.GetVariable("Item_Neck")
End Sub

Sub Set_Item_Arms (thename, theoutput, thewildcards)
World.SetVariable "Item_Arms", CStr(thewildcards(1))
World.Note " Arms: " & World.GetVariable("Item_Arms")
End Sub

Sub Set_Item_Hands (thename, theoutput, thewildcards)
World.SetVariable "Item_Hands", CStr(thewildcards(1))
World.Note " Hands: " & World.GetVariable("Item_Hands")
End Sub

Sub Set_Item_Cloak (thename, theoutput, thewildcards)
World.SetVariable "Item_Cloak", CStr(thewildcards(1))
World.Note " Cloak: " & World.GetVariable("Item_Cloak")
End Sub

Sub Set_Item_Torso (thename, theoutput, thewildcards)
World.SetVariable "Item_Torso", CStr(thewildcards(1))
World.Note " Torso: " & World.GetVariable("Item_Torso")
End Sub

Sub Set_Item_Belt (thename, theoutput, thewildcards)
World.SetVariable "Item_Belt", CStr(thewildcards(1))
World.Note " Belt: " & World.GetVariable("Item_Belt")
End Sub

Sub Set_Item_Legs (thename, theoutput, thewildcards)
World.SetVariable "Item_Legs", CStr(thewildcards(1))
World.Note " Legs: " & World.GetVariable("Item_Legs")
End Sub

Sub Set_Item_Feet (thename, theoutput, thewildcards)
World.SetVariable "Item_Feet", CStr(thewildcards(1))
World.Note " Feet: " & World.GetVariable("Item_Feet")
End Sub

Sub Set_Item_LRing (thename, theoutput, thewildcards)
World.SetVariable "Item_LRing", CStr(thewildcards(1))
World.Note "L.Ring: " & World.GetVariable("Item_LRing")
End Sub

Sub Set_Item_RRing (thename, theoutput, thewildcards)
World.SetVariable "Item_RRing", CStr(thewildcards(1))
World.Note "R.Ring: " & World.GetVariable("Item_RRing")
End Sub

Sub Set_Item_Shield (thename, theoutput, thewildcards)
World.SetVariable "Item_Shield", CStr(thewildcards(1))
World.Note "Shield: " & World.GetVariable("Item_Shield")
End Sub

...A lot of repetitiveness, but it works. The aliases I created look like this:

Alias : Sethands *
Send : <nothing>
Label : Set_Hands
Script: Set_Item_Hands

I have one alias for each equipment slot. If I change an item of equipment, I use the related alias to set the variable for that item. I always try to use the most discriptive equipment name possible, but in some cases, the EQ can not be handled by it's full name. That is an issue for the MUD, there is nothing that can be done with the client to work around the problem.

Here are some additional aliases I use related to EQ:

Alias :won
Expand Variables: CHECKED
Send:
---
wield @Item_LHand in left hand
wield @Item_RHand
wear @Item_Head
wear @Item_Neck
wear @Item_Arms
wear @Item_Hands
wear @Item_Cloak
wear @Item_Torso
wear @Item_Belt
wear @Item_Legs
wear @Item_Feet
wear @Item_LRing
wear @Item_RRing
wear @Item_Shield
eq
---
Of course, don't include the "---" lines in the send section. This alias is particularly useful if you die (and get UNequiped). I also use it after my "gall" alias which gets all from my chests.

Another example:

Alias : parry
Expand Variables: CHECKED
Send:
---
unwield @Item_Lhand
parry on
wield @Item_Lhand in left hand
---

As you can see, once the EQ item has been established using the 'set' aliases, you don't need to go and modify your other aliases/triggers whenever you start wearing a new item. One last script and alias routine:

' ------------------------------------------------------------
' DISPLAY INVENTORY
' ------------------------------------------------------------
Sub Display_Inventory (thename, theoutput, thewildcards)
World.Note "L.Hand: " & World.GetVariable("Item_LHand")
World.Note "R.Hand: " & World.GetVariable("Item_RHand")
World.Note " Head: " & World.GetVariable("Item_Head")
World.Note " Neck: " & World.GetVariable("Item_Neck")
World.Note " Arms: " & World.GetVariable("Item_Arms")
World.Note " Hands: " & World.GetVariable("Item_Hands")
World.Note " Cloak: " & World.GetVariable("Item_Cloak")
World.Note " Torso: " & World.GetVariable("Item_Torso")
World.Note " Belt: " & World.GetVariable("Item_Belt")
World.Note " Legs: " & World.GetVariable("Item_Legs")
World.Note " Feet: " & World.GetVariable("Item_Feet")
World.Note "L.Ring: " & World.GetVariable("Item_LRing")
World.Note "R.Ring: " & World.GetVariable("Item_RRing")
World.Note "Shield: " & World.GetVariable("Item_Shield")
End Sub

Alias : dinv
Send : <nothing>
Label : Call_Display_Inventory
Script: Display_Inventory

I use that to confirm that my items are configured properly in my MUSHclient script.

Note: I don't check to see if an EQ location is marked as "None" or empty. The script works well enough for me as is... You can add to it to make it foolproof if you wish.

Note: If you have multiple EQ sets, you would probably have to create another whole set of script subroutines and aliase to handle secondary (and beyond) sets. I haven't had the need, or I surely would have done so myself. :)

I'm not saying this is the best way, but it's work I've already done, so feel free to borrow it.

Regarding autowalk aliases...

First, I should note that I have Ages of Despair configured to "bothdesc", and I have it set to verbose mode.

Here's my login-to-shop autowalk alias:

Alias : l2sh
Speed_walk: CHECKED
Send:
---
(brief/brief) n e 4n (brief/brief) n
---

I too, have experienced the problem you discussed, regarding output being cut off when you do an extended autowalk. The solution above resolves the problem, AND it's a hell of a lot faster anyway! :)

The key is the "(brief/brief) " entries. When executing your autowalk alias, the first "brief" command puts Ages of Despair into brief mode. You do the walk. The second "brief" command (always place second-to-last in the autowalk sequence) puts Ages of Despair back into verbose mode... and when you move in that final direction, it ALWAYS gets displayed properly, so you know where you are.

- I suspect that Ages of Despair is cutting off the output, not the client.

- If you are leading a party, and have a lot of followers, and you take an extended autowalk, Ages of Despair may issue an overflow/runtime error, and some of those following you will be dropped at that point, though YOU will still make it to your destination. That's an AOD issue again, not the client's fault (Well, actually, you could probably fix it by setting a longer auto-walk delay in the client). I just work around it by moving in steps. For example, login-to-eastgate, wait, east-gate-to-Avalon-Ferry, wait, Avalon-Ferry-to-Cearnafern(whatever)-Ferry, wait, ...etc.

...Hope all this helps!

I am surprised you need "Cstr" there - the wildcards should be strings anyway, you can probably omit it so it looks like this:


World.SetVariable "Item_LHand", thewildcards(1)


You can probably save a lot of scripting if you share the script routine between all the aliases, and then either use the alias label or the "output" of the alias to work out what to set.

For example:


Sub Set_Item (thename, theoutput, thewildcards)
World.SetVariable "Item_" & thename, thewildcards(1)World.Note thename & ": " & World.GetVariable("Item_" & thename)
End Sub


Then make the alias label the name of the item you want to set ...


Alias : Sethands *
Send : <nothing>
Label : Hands
Script: Set_Item


Then to be a bit fancier you could use a regular expression to save doing multiple aliases, something like this:


Alias: ^Set(hands|neck|arms|lhand|rhand) (.*)$
Regular expression: checked


You would have to change the script a a bit in this case. Wildcard 1 would be the thing that is to be set (hands, neck etc) and wildcard 2 would be what to set it to. This makes the whole thing a lot shorter. :)




There is such a command, it is world.queue. That queues up the command at the speedwalk delay.

To Magnum - Can I say "Ack!". The idea with equipment was to find an easy way to handle it, using one alias to get it, one to change to party eq, one to change to solo eq and one for puting it away. If I am getting a lot of lag close to reboot or it looks like the lag may be getting bad enough that a crash is immiment, I want the mud to receive all my eq commands, not one at a time as I type them. Your method definitely works, but it is imho a little too complicated and doesn't address these two problems. Also, the idea I suggested was intended as a more versitile tool, reasonably easy to use and capable of dealing with things not covered by my own particular problem. ;) P.S. I was already 99.9% sure you where on AoD, but since I use the Japanese version of my online name only on AoD so far, I am not surprised it took you a little longer. lol I'll give you a clue. Fire in Japanese can be one of several words, but the one I use is 'hi'. ;)

To Gammon - world.queue?? I did a search in the help file for that, but couldn't find a reference to queue in help, save as it related to aliases. The World.queue command just doesn't seem to be in the help file... :p I am using 3.16 now, since most added features/fixes in 3.17 are MXP related (and thus a non-issue for me), so it may be in the help for that version, just not this one. Thanks. ;)

Heh Heh...

I knew there was probably a more efficient way to handle EQ with scripting. :) Since EQ isn't all that exciting, I usually work on more interesting projects than improving my EQ script.

Anyway, I believe nick has provided some excellent suggestions that would greatly improve the script, cutting down on both code and the number of aliases!

This new alias/script is excellent for simplifying EQ handling... except it currently only handles ONE SET of EQ.

You seem to want some complex aliases and scripting to handle multiple equipment sets, but you haven't offered many insights into programming what you want. Are you requesting that I write the script FOR YOU? :) I believe it CAN be done.

I don't know ANY Japanese, do I still can't figure out your AoD handle. LOL.

Did the AutoWalk tip help?

The help file is sadly a little out of date. The most up-to-date list of inbuilt functions is online here, and is available at MUSHclient scripting functions

This is stored in a database, so you can search for keywords. Also there are extensive examples, in VBscript, Jscript, and Perlscript, for each script function.

Actually Magnum, I have done a lot of programming in various flavors of basic as far back as the days when Apple Basic was still used and a 256 color display on a PC was considered amazing, especially when you forced the graphics cards into aliased mode and got 'gasp' 1024x768. lol

If I need to I can code it myself. In fact I still have a mapping/data sorting program from playing the Trade Wars 2002 BBS game that is significantly more complex than anything this would require. Kind of wish I could find a place to download that game from, it was kind of fun. ;) I was purposely vaque because the intent was a feature that could be used for a wide number of purposes, not just eq. At the moment I don't even need it, but was mearly suggesting something that I thought could be useful at some point. However, I realize that for my purposes there may be a better, if more complicated way to do it.

I like the 'brief' trick, even with speed walk things in a long walk get swallowed. Being a healer I don't tend to have a bunch of people following along behind me, so also don't need to pause much. That by the way is your second clue to my identity. To remind you, the first one was the Japanese word for fire, 'Hi'. I doubt there are a lot of healers on that have that syllable in their name. ;)

To Gammon: Check the web site?? Who checks websites!? lol Will take a look in there, thanks again. ;)

Well, you are typing a message on one now. :)

I am moving towards documenting MUSHclient (and other programs) online, as it has a number of advantages ...

• Most people who play MUD games are on the web anyway
• Documentation can be updated (expanded, errors corrected) on-the-fly rather than having a static "help file" that might be wrong or incomplete
• People can see the power of the program before they necessarily download and install it
• You have an element of self-help amongst users (as on this page) where you can give tips to each other.

BTW - some of my earliest programming was on an Apple - I eventually got an Apple assember (Merlin was one of them) and coded a heap of stuff on that. Ah yes, those were the days when 48 Kb of RAM was a lot!

Regarding documention on the web, I agree that the relative ease with which it can be kept up-to-date is a useful feature.

However, providing the option of downloading a compilation of the documentation would be very useful as well for those of us who are on-line but only a limited amount of time as it simply costs too much with metered phone costs. I do almost all my docmentation reading and experimentation when off-line, so I can use my on-line time more effectively.

In that case I should probably write a quick utility that turns the database-based documentation (eg. the functions) into a text file (or web page perhaps) that you can download.

That file could be regenerated when necesssary.

That'd be a very good addition. :)

Merlin?? I had a copy of that for my Aple IIgs, only no hard drive, so I could never use the dang thing. Sigh.. Actually 48k was not a big deal, especially since you could actually hand code machine language on Apples without spending a century just figuring out what all the bloody opcodes where for. The 286 was bad, 386 worse, 486 even worse, I haven't even bothered looking with the new chips and the new 64 bit AMD will have opcodes so complicated I don't even want to think about it. ;) I miss being able to do quick and dirty stuff on my Apple, which included using assembly. Now unless you have an old copy of qbasic, you have to spend a week just looking up how to do the same thing you did a year before, even to program in Visual Basic. lol

btw Checked out the lark.crod.com mud... Why is it again that they have to make objects in a room bright blue and underlined, but can't use the mxp color to show the lilacs in one room as 'lilac'?? Not sure that site is a good example of 'using' mxp, unless I completely missed something I needed to turn on to make it work right. Not that I want to go back anyway, I also hate their mini map thing (makes me feel clostraphobic after the full outside maps on AoD) and I don't like the idea of 'you must do this this way to advance past level 25'. :p I would hate to see what people would do with an idea I had.

The idea being to create an addon that takes a text file containing scene code based on POVRay and actually raytrace a small 160x100 image of it. A lot more versitile that using graphics, since A) text is often smaller, especially compressed and B) you can set internal features of the script to adjust lighting, sky textures, sun/moon position, etc., all based on what is really happening on the mud. Not sure how to even begin developing it though, especially since it would detract from my mud play. lol

Figure it would have to be one of three things. A COM server object called from a script (bit of a problem doing it that way, since how do you make sure the data gets recieved correctly...). A proxy that sits between the client and windows (Not a clue how this would work). Or something built into a client (but in a seperate thread <is this even possible?>, since the render needs to take place even while the client does other stuff). Most scenes would take a few seconds even on a fast machine to produce, and may need to use several passes if I included support for true glass ior and reflections, which add a lot of calculation time. Not to mention fog or other stuff. Oh well, maybe I will get around to trying to do it eventually. ;)

You can turn the mini-map off. :)

Which then brings up the problem of having everything including exits in one color and crammed into a single status line. Lets just say that I was not won over and leave it at that. ;)

Bloodmoon at lark.crodo.com 1313 runs the Dawn of Time codebase. As the implementor of this codebase my comments might shed some light on things.

Regarding the colour of links, I expect you will find that you have 'Use custom link colour' turned on in
(Alt+Enter)Configuration->Appearance->MXP/Pueblo. The check box options that Dawn works best with are off,on,on, off,on,on, off (from top to bottom in the MXP/Pueblo config page)

Dawn uses ansi colour by default (even with MXP connections) unless you have HTML colour coding turned on (type 'col mode html' to change modes).

The automapper is different from most mappers I have seen, many of them generate the map once off and make it part of the room description. Dawn was originally written from a roleplaying perspective and therefore tried to give a real line of sight to players. Dawn's automap is generated dynamically and reflects doors closing etc, also supporting a map scale. Immortals have access to other versions of the map which can scan out a radius of up to 100 rooms away and have clickable room links with mxp options.

Then again you can't please everyone with something like mapping, I think everyone will generally like what they are used to.


I assume you are talking about letgaining?
The level of 25 is configurable and can be easily disabled. The letgaining system is used to give mud implementors the opportunity to maintain some form of quality control with players advancing to the higher levels. The code automatically letgains you if you request a letgain (using requestletgain) and an imm hasn't processed the request within a few days. While the system isn't liked by all it does help increase the quality of players on the mud.

Dawn is a very flexible mud server, pretty much everything you said you didn't like can be tweaked to your liking or disabled.

Regards,

- Kalahn
Implementor of the Dawn of Time Codebase
http://www.dawnoftime.org/

Hmm. Thanks for the comments. I had kind of wondered.

I still don't like the fact that exists are part of the status line (excpecially since some people like to turn those off). But the rest is helpful. I couldn't find a help file for MXP or anything else that I coudl think of (didn't think to consider html). :p Oh, well. I went there as a matter of curiousity. At the moment I am still playing Ages of Despair and am working on some ideas I may submit there for an area, so I really don't even have any time to play on another mud. But I do think MXP has potential, as long as some limits are placed on its use, but unfortunately that is a bit like trying to get the admin on the one I play at to admit that they messed up by not requiring unique item IDs. Real fun when you have 3 different amulets and the mud can't tell which one you are trying to use. :p

The ansi version at Bloodmoon though is more conducive to eye strain. I certainly hope that turning on the html type is a little better. ;)

As to the mapper... Yeah, that is pretty much the way AoD does it, but it also only uses the map outdoors. The problems I see with the one used on Bloodmoon is A) very limited 'field of veiw', even when you should be able to see farther and B) it intrudes in places like inside cities where you don't even need it. But that is mearly my opinion.

As to the letgain.... I guess my biggest problem is not this, but the 'requirement' of RP. On the mud I am currently one it is far more relaxed, so you can talk to people about non-game stuff as you play, but you can also act the part too. While there are no clans implimented in AoD, more than a few people have found themselves in serious trouble because they bragged about killing foxes on channels and someone who was friends with a healer name Fyxen told her about it. (She keeps a list. lol) Of course being Kitsune myself, I have passed the word along a few times as well... ;) imho Mudding is about fun, anything that restricts that by forcing RP or some other demanding requirement tends, at least for me, to make it a bit less fun.

Of course had I the time to play it for a while or any real interest in the rather limited number of races on Bloodmoon, I might not find it to be that big of a deal.

Earlier in this thread, EQ scripting was discussed. I am beginning work on this project, so I am posting to bring this thread to the top of the recent posts list.

I am attempting to design the EQ script as standalone, that can be "plugged-in" to any Ages Of Despair player's script using methods recommended elsewhere on these forums.

To save memory, I plan to store each Eq_Set to a file. The file would only be saved or loaded when the EQType was changed (or on world load).

I'll post more details as I move along on this project. File access in VBS is quite foreign to me, so I may ask for help. :)

Krenath has posted some examples of reading/writing to files from VB. Meanwhile, you might want to start a new thread if you go on with this one.