Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Since this seems to be the most popular script I ever published in the Finished scripts forum I decided I would work on redoing it for CMud first. I am completely rewriting the searching logic that it uses to determine where you want to go, and am still looking for ideas about what to do with the massive number of possible rooms when doing a room name match.

I guess some background is in order for those that never used the script. What it did was took a command line entry of "walk word1 word2 word3 etc" and then found an appropiate room and started you walking there. The words were checked against zone names and short IDs. If an ID match was found it would determine the closest room with that ID and send you there. If a zone was matched it would find the nearest edge of that zone and send you there. The room name handling was in a seperate alias because it was mostly worthless with the way it was.

My plans so far with the new searching is to let the user have better control. The new script will be able to make both a zone and ID match and interpret that as you want to go to the nearest room with that ID in that zone. This means the old script with an input of "walk comm asht" would find that 'comm' referred to a set of short IDs and then locate the closest and ignore the 'asht', the new script will find 'comm' is a short ID and that 'asht' likely refers to the zone named "Ashtan" and decide that it is a better match since it uses both words that were supplied.

That still leaves me with what to do with room names, I want to make them search up just as quickly, but anything other then some full parameter searches will likely take a very long time. Which was a major problem with the old script. Suggestions aren't just welcomed, I need them.

Also what else do people want to search on. Colors, room size, room type, room flags and room notes are all pretty easy. I don't think I can actually search on labels readily, but I can look into that. Of course the most horrible question of all...who wants me to put a hook in to do a search based on player location?

Then another question is what do people think about having the script take over the keypad macros for a short while if it needs the user to choose from a few different locations? Is there any interface that seems really good for this? I could do something like popping up a window with some results, and have the macros work there. I was thinking about completely taking over the keypad and doing some fancy stuff with #TELEPORT on the map, but that might cause problems for some people. I could always just display a bunch of results and then have a subseqent 'walk number' work as selection. Please let me know what you think.

Hopefully someone adds a few good ideas to the whole mix. I would like to actually have it put together into a solid package for the next public version.

Beginner Joined: 24 May 2004 Posts: 10

That would be a great script! One suggest for an additional feature would be to walk through all rooms matching the room name in one specficed zone.

Actually I have tried once to do a similar script. But whenever I called %mapfilter with a room name which was not mapped, the program would crash with an sql exception. I am therefore wondering what you have done to prevent this?

Posted: Thu Dec 06, 2007 8:34 pm

Mudbots mapper does this sort of thing. I'll post a bit of output from it, basically because its quite popular on the ?2? muds where it works, and people seem to find the interface easy enough to work.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

It is useful to see what someone else has done, although I am pretty sure they wrote mudbot after my original script was published. They definitely did some nifty things.

I will readjust some of the searches to be placed in my general toolbox, I was already putting a 'find what room I am standing in' function into it. It rather makes sense to put some of the other mapper searching functions there as well. That should cover mudbots 'room find' for everyone. I will add another function to do a multiple tight name search, which is similar to the 'who' list you showed. I am not going to add a who capture in the toolbox, it is too mud specific.

I will also add some other things, 'walk zone ????' does the searching for whatever then does the walk to the nearest border for that zone, 'walk near ????' does the searching for whatever then issues the walk to stop 1 room sooner. I will make those 2 combinable as well.

I guess this means about half of the functions to do this will be up in my toolbox package before too long. I will assemble the rest into another package. Both of those should be designed to be general enough to work with any mud and any map.

Which makes the third package I release will be the Achaea specific additions and overrides to the first 2 packages.

Apprentice Joined: 11 Sep 2005 Posts: 124

Awesome, I remember taking parts of your walk location system and doing some really cool things with it the last time, can't wait to see what you come up with!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I put the 0.18 version of my ToolBox up into the library (requires CMud2.17). It has most of the functions implemented in it in a totally general fashion. The function names are quite long by design because they really are meant to used in the command line and I want to help with uniqueness.

There are still a few things to put in the ToolBox before I will really start the earnest rewrite of the main walk alias from the old script, but not much. So take a look in my ToolBox and see what you can use.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I have been tweaking some more on this and will probably have a 0.19 version of the ToolBox up tonight. Here is what I did with the room name search.
#SHOW @SearchRoomNames("James of Central Market Tripoli Pizza") does the following set of searches, all are case insensitive.
James of Central Market Tripoli Pizza
%James of Central Market Tripoli Pizza%
Either of those 2 will end the search right there, mark the whole phrase used and return.
James
of
Central
Market
Tripoli
Pizza
Any match in this group will end the searching. All matches from this group are returned and the words are marked as used.
%James%
%of%
%of Central%
%of Central Market%
%of Central Market Tripoli%
%Tripoli%
%Pizza%
This is the progressive matching series. As you will see in the return below I have rooms that match "of Central Market", but I didn't have any that matched "of Central Market Tripoli" so it dumps the last word back and records the larger match it found. This portion doesn't mark words as used, because I consider it a best guess section.

James of Central Market Tripoli Pizza|of Central Market÷2-4÷M÷183-184-187-190-191-743-744
The return value is formatted as "original text less words marked as used|portion or word matched÷positions of words matched÷match style(L|M|R|E)÷list seperated by -|next match data entry". I pretty much set all the searching functions to return like that. I was planning on doing some higher logic in the next level and would mostly like to keep the return pattern cosistent.

Once again I am fishing for thoughts. That particular search took 766ms on my system with a map of 6200 rooms. To me that seems like an eternity. I will almost definitely add some optional flags to block some of the searches, but I wonder if anyone has any other needs with it? Does anyone want me to change the progressive matching so that it dumps the first word instead of dumping the whole phrase and trying the last word by itself?

Does anyone actually want me to do some general display functions like Caled quoted from mudbot?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I finally put the .19 version of my toolbox up.

It has that new room name searching I mentioned. Also I am pretty sure I have the tested the FindRoom and FindRoomFromNearby functions adequately. FindRoom locates a list of rooms based on name, description, and exits using an exact match method for the most part. FindRoomsFromNearby will take a list of rooms and a record of direction=name and exit information, then it will locate which room(s) in that list match. The zone borders caluculation is now fast, since it uses an SQL if it can. That whole SQL querying of the mapper is in there as well, and very easy to use. I may add documentation on all the fields and tables in the map, but that is a low priority.

I also put in the tabbing that I wrote for someone over in the zMud forums. I thought it was a useful addition.

Comments hold pretty much everything anyone needs to know to use all the functions in thier own triggers. I am still working away at the rewrite of the old walk script, it pretty much just needs the higher logic to guess what a user meant quickly and the find closest for a list of rooms. I guess I will be adding some display stuff for Caled, time for me to see how readily I can make a flyout window or something else useful.

Posted: Tue Dec 18, 2007 11:53 am

I'm going to download this now. I really hope you've commented the code well, because I can imagine it being pretty opaque to people who haven't been digging around in the guts of the mapper before ;)

Okay, downloaded it now and taking a look. The notes are nice, but specific code comments would be even nicer ;P Most of it's self-explanatory, but there are a few very arcane bits.

This should actually be really useful. There're aspects of its search-for-anything logic that can be applied to many things, which is great.

Found a typo on line 25 of @BuildZoneBorders(), a string isn't terminated.

I think that @FindRoomFromNearby()'s notes could be improved. I haven't read the code in detail yet, but as it stands I have no idea what the Nearby parameter's format is and what it's for.

@SearchRoomIDs(), @SearchRoomNames() and @SearchZoneNames() could do with some extended usage information as well. It'd be nice to have some working examples of data you would put in and data you could expect out.

And finally, a caution - your zMapDirType have a list of directions hard-coded, which isn't terribly useful for people on non-english MUDs. Perhaps a niche use and not worth the time to fix, but still an issue.

All in all, an excellent bit of kit.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I corrected the typo in BuildZoneBorders. I think there is another one in there somewhere still, but neither I nor the compiler can find it. The syntax colorer is spotting something though, see line 58. Thanks for finding that.

The zMapDirType functions are mostly legacy. I made them for my old SetOneWay alias, and the new AdjustOneWay function uses a named lookup instead of by number. Both functions use the DirectionSettings variable first, but the hard coded list has to be there. If you create a map with no #DIR settings, for example with zMapper, it populates the database's DirTbl with the default English directions. So I coordinated to that when the settings don't exist.

The notes for the searches were rather hastily written, I will expand on them. I suppose writing some code comments won't kill me since I actually do want other people to be able to understand what it is doing.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The .192 version is up. Still not quite to the main walk system, but I got a decent search display system in place. It is almost perfectly automated when using its own window which is in the package. The display system isn't really documented yet, but I did get better usages notes in for all the search functions. The button version of the display is off by default making the text version used, enabling the class will change that behavior. Sorry still haven't commented the code.

If you play with it and find bugs in my script PM me, if you find bugs in CMud...well that was what I was doing with it all day yesterday.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

No new version yet, I need some comments on things.

First is the rather hefty parsing of inputs for the top level user entered command. Some examples of what it will handle as paramters are:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I just might have gone insane with this, but a new version is up so anyone can see the progress and comment on it, now .198. I had to bump it a little extra for the new section handling I mentioned in another topic. Since I had a few instances in the new code I was writing where I wanted to grab the last x items from a list, I also added a function for that to the SetFunctions class. It works like %copy on steroids. Most of the recent changes and additions are pretty much untested.

The biggest change for it is in background handling and recording multiple searches. I currently have it set to 10 for the keyword parsing and 5 room search result lists. I am still considering putting some sort of delete search results in, which is the reason for the very wierd and complex indirection used with those. Is 5 enough stored searches?

If you look around in some of the new code you will see that I have failures outputting some rather detailed debugging messages. I plan on going back through most of the MappingWidgets and adding a debug parameter to them that will similarly give reports about thier progress. I think that may be sufficient code commenting, since I actually do hate useless comments.

Also since I am finally getting into the actual 'walk' alias I started to put some function hooks in for those of us that have our own speed walking scripts. I haven't decided if I will publish mine yet. The only requirements to making use of those hooks is to match the name and give a non-null, non-zero return value when you handle the call.

As always comments aren't just appreciated, they are really needed.

Posted: Sun Dec 23, 2007 12:56 pm

Posted: Wed Dec 26, 2007 12:23 pm

One thing I really wish CMUD had from looking at this is a diff-like version comparison tool. It's really annoying trying to sift out the (sometimes tiny) changes in your complex code. I guess you could keep the older version of the package around, export to XML and do it yourself that way, but the library isn't intended to let you keep old versions, so it's not an ideal solution.

Puzzling out all the changes between this version and the previous is too frustrating right now, so I'm off to eat my second Christmas dinner ^_^

Magician Joined: 23 Nov 2004 Posts: 364

After importing the package I'm getting a lot of errors, such as:

ERROR: Syntax error in Alias: walk : invalid local variable: Path
control+k gives this line:
#IF (%ends($Path,")")) {

Also getting unmatched braces in a lot of the functions.

Everything was brought right off the package library, just updated as well. Hoping its the script and not a bad install

Novice Joined: 02 Dec 2007 Posts: 42

Just a thought, but I've found that using the UserInt value of rooms is a handy way of 'forcing intelligence' into mapping scripts. For instance, UserInt =1 can mark the "entrance room" to a zone, UserInt = 2 can be set to mark a prison room, and if you're in a room with a locked door, setting the room w/ the key location to UserInt = %roomvnum(room with locked door) is a super easy (although botty) way of tracking down those pesky keys.

In the first example of setting the entrance to a zone, I realize you could keep track of the roonvnums and just #te num to put the map there, but there instances (such as non-map provided speedwalks or mud-side run commands that the mapper can't follow) where being able to query for room in zone w/ userint=1 is useful.

I should also point out that I haven't looked at your location system /plugins (just stumbled upon this thread), but thought that in your request for input/suggestions this may be useful.

-MrC

Posted: Tue Jan 08, 2008 6:56 pm

I'm not so sure about using the UserInt for entrance rooms, because some MUDs often have many entrances to zones. That can make adding those numbers quite time-consuming and the impetus should be on the script to do that rather than the user.

I suppose it could set the UserInt itself after running the current check-for-zone-borders code, but since you'd need to recheck very frequently (since the map is potentially very different every time the script is run) it wouldn't save much time.

Novice Joined: 02 Dec 2007 Posts: 42

I'm not familiar with the zone-borders code (again, I haven't yet used his script - this is more in response to request for ideas).

Re: UserInt = 1 to mark entrance to zone.. I can think of two instances where this is useful:

First, mud-side run commands (e.g. run 5s10eu3s). I know you can break that out into pieces the mapper could then follow to arrive at the destination (without actually #step'ing, since the run command will move you), but if you know where you'll end up, why not just tell the map that's where you'll end up? In other words, this is a akin to #TE room without actually knowing what the room # is. Agreed, for multiple entrances the decision about which is the actual entrance falls upon the user, but if you're starting from the same location (e.g. recall) this isn't really a problem - walks that will take you through other entrances or zone borders are most likely generated by the map's walk algorithm, which isn't what my suggestion was intended for.

Second, what if you don't know the name of the room you need to go to, just the zone? i.e. I have to get to a zone and find mob 'a guard' - I could have the mobs contained in room desc or notes and query them, but if not, I need to get to the zone (i.e. entrance room) and then use mud-side commands to find it. I don't trust that the first room returned by %mapquery/filter for a zone is the 'entrance room' so I'm not sure how else you'd get the map to know the correct spot you end up at. Yes, I'm ignoring #FIND and for good reason (not reliable / doesn't handle duplicate rooms well / depends too much on how room was created either via #TAG or mapconfig..).

Re: impetus on the user - I don't find it all that cumbersome. Right click on room, props, enter userint, change the color of the room to match (or run sep proc to do this), done. I map my own zones, and have used zones made by others. I happen to tag things one way, they another, and (unfortunately) you end up with inconsistencies (another reason I don't rely on #FIND). It happens, and I'd rather get on with life and play the mud with a subtle enhancement/work-around in place than trying to go through 20k+ rooms in the MDB and synchronize things.

Don't mean to hijack the thread, just merely pointing out that in addition to 'walk <room name>' it would be nice if you could 'walk <userint> [zone]', and I'm assuming that amongst the code for the WLS there are places where adding such a feature may work well. As an example of the other ideas I mentioned for userint, 'walk keyloc [room]' to get to key location for current/other room and 'walk noprison' to get to closest room you can recall/portal from are just two examples of things that can easily done using UserInt. Think of it in terms of something similar to 'do not enter' boolean on a room (which itself could be a userint value) but which is intended for adding intelligence to client-scripts and is not part of the shortest route algorithm.

As for implementation, it could be standardized with UserInt < 0 for specific user flags (-1 = entrance, -2 = prison, -3 = food/drink source, -4 = shop/store.. ) and UserInt > 0 for key locations to room numbers.. by the way, I know it's possible to modify the 'other command' for exit with locked door to backtrack to location as if you were typing it and get key, return, unlock etc., but in the spirit of thinking up potential uses for the walk command, I think it has at least some merit.

Carry on.

-MrC

Posted: Tue Jan 08, 2008 8:41 pm

You can actually walk just to a zone with this system. It detects whether a room is at the edge of a zone or not by comparing the zone numbers of the adjacent rooms to its own - if it's different, it's a border room. So if you try walking to a zone, the code will walk you to the nearest border room for that zone, which is essentially what you're asking for it to do there.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Sorry for the lengthy delay in updating on this. I still haven't posted a new version because I ran into a mental block with the second level of request parsing. Then life rather got in the way as well, so I really haven't been in much of a programming mood.

To answer MrC's thoughts...YES. The whole point of the script is to make it as simple as possible on the user, and the parsing code is extremely complex for just that reason. Searching on something like the USERINT field is already supported, but requires one to be a little verbose. Some things are just designed to be easier to search on because I feel they will be the more common searches. Just to give you an idea what the first stage of parsing does:
walk abc def field userint 7 zone ghi
Results in a searching set like this, from all the rooms in zone 'ghi' find those with a USERINT=7 and then figure out what the user meant for the 'abc def' within those results. This request would produce the same search "walk field userint 7 abc def zone ghi" because type checking is done for the extra fields. In fact it is likely this "walk field userint 7 abc def ghi" will produce the same results, because the parser tries to make some use of everything the user has supplied, and when 'abc def ghi' doesn't produce anything then it will searching with portions of it. Depending on what it finds it is possible that the same result set will occur. Doing that particular bit of crazyness is what mostly lead me to a mental block.

Fang is also correct just doing "walk ghi" will figure out that 'ghi' is a zone name and understand that you want to go there. My old script implemented further checking to determine if you are already there and I may still put that into the new one, but I am undecided.

In any case I should be back in programming form quite soon and will be looking to finish this particular project up.

Posted: Sat Jan 12, 2008 1:02 am

In association with this thread, SpecialMapQuery could do with some better docs. Some info on the RowSeperator and ColSeparator variables would be nice (and also on whether or not they're needed), and on the format of its return. Especially barmy in my eyes is line 14, mostly because I know nothing about the ADODB COM object you've opened.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I will see what I can do about documenting it better, and I will also put in a link to the 'wonderful' MSDN documentation on ADO. I was actually planning on not doing much documentation with it because of the expectation that when Zugg does the SQLite implementation of the mapper we might not need to play with the crappy ADO object anymore.

I originally spent the time researching and writing that function just to make the BuildZoneBorders faster. Since then I added the stub query which prompted some interesting changes in the display handling, and also noted that I could use a conjoined query like my original stub query to accelerate the display lookup. So the function is used quite a bit more within the rest of the script now; and definitely deserves more documentation.

The stub query got added as part of the MappingWidgets class, and after the display adjustments to handle it I decided to add 'stubs' and 'dist' as parsing keywords for the walk system. Dist will pretty much only be usable for the maps alias and makes it do a distance calculation for the display of your search. Stubs will be usable by both maps and walk, which means you could do 'walk stubs' and get to the nearest room that you need to map something on. This also required some changes in the higher level handling since the stubs query produces a record of RoomNumber=n-e-w-s-u-d|Room2=other command-nw|etc.; which is requiring me to rethink quite a bit of the existing search parse code that uses a straight list of room numbers.

Sorry still no update in the library, I haven't really gotten the more complex parsing issues figured out. I almost wish I was willing to give up on doing such a free form syntax, but I am not. Hopefully something will click in my head this weekend.

Novice Joined: 02 Dec 2007 Posts: 42

Re: documentation and pointing to MSDN (which agree is less than wonderful) - I've found http://www.w3schools.com/ado/ado_ref_connection.asp (and the rest of the content on there) to be quite helpful when working w/ ADO in ZMUD/CMUD.

On another note, you use the RecordCount property as one of the tests in your SpecialMapQuery routine IIRC. I'm wondering if this really works as you intended (believe the test is RecordCount = 0), as it will always return -1 when used with ADODB.Connection object since it has a forward only cursor. I don't have the package open now, but I tested between ADODB.Connection -> GetString and ADODB.Recordset (using .open(query,connstr,3,1 (RO) or 2 (RW)) -> GetString and found the RecordSet COM object to be faster by 5-10ms, despite claims in the documentation. And RecordCount works without a hitch, as long as the cursor is keyset/static/dynamic.

-MrC

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I put up a new version in the library. I still haven't actually finished the parsing code that is giving me a headache, but some of the parses are in and should be working. I also put in the maps alias that I mentioned before so people should be able to play with some of the parsing and searching finally. I didn't get to the comments and also just plopped in a screen dump of the variable when it hits the portion I still have to write in DoRequestedWalkAction. I did adjust line 14 of SpecialMapQuery so it makes a little more sense.

I also haven't heavily tested or debugged any of the recently added code. I tend to test lower level functions as I build them so the new stub query is right (well I never forced it to use the brute force method), but the integrations between higher level functions are not tested.

chris-74269, I never did find bunches of functions that had unmatched braces. Perhaps you could point them out to me if they are still there in this version.