Zugg Software :: View topic

Posted: Sun Jan 13, 2008 3:32 am

Having a quick gander around the code, and really missing a diff - I assume you keep backups of each version, Viji - would you be able to provide us with a diff between the XML of the current version and the previous (or even the previous few)? It'd be mighty useful.

@QueryForStubExits(), line 45 - I believe you need to use <send '#signal StubDone'> and I'm not sure if #signal is callable from MXP- worth checking if you didn't already.

More constructive criticism is difficult when the code isn't commented - your regex at line 16 (and similar elsewhere) of @DetermineRequestKeywords() seems needlessly complex, but without knowing what you're intending to do with it later (your subsequent checks seem to mirror many elements), it's hard to suggest improvements. Not being the author, I don't have that unthinking knowledge of how the function's going to flow - I have to pick it up from the code, which gets harder the more complex the code is and this code is very complex indeed ;)

Incidentally, given the trouble you've had returning complex values, I'm really quite tempted to try Lua versions of a few of your functions ;) Perhaps I'll find some time one day...

Posted: Wed Jan 16, 2008 5:17 am

Question about @FindRoomFromNearby() - you mentioned in another thread that you'd use this function to find yourself if you were lost, but how? I get the impression (but it's another horrible data structure so I may have misinterpreted - I know you do the best you can, but bring on the nested hashes ;) that the second parameter is a list of rooms (with their names and exits) that are adjacent to the current room, with their direction from the current room. I understand that this is an awesome idea, because that way not only are you searching for a single room name and exit set, but name+exits pair with all the name+exit pairs surrounding it - very likely to return a unique match. But the first parameter is a list of rooms to search in - what does that mean? How would you use this function to find you if you're lost?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The assumption behind the function was that you captured some room data on your currently location and piped that into FindRoom. Even though you had a name, description, and set of exits FindRoom came back with a list of rooms that matched. The process of getting unlost is broken into 2 parts for the very likely reason that on a good mud 90% of rooms will be unique when all 3 of those things are checked. For that other 10% more information is needed, and that is the purpose of FindRoomFromNearby; to work on that information as fast or as slow as it can be provided. A user doesn't even have to supply exit information for the additional rooms, only 1 name and which direction it was found in is required to do something.

Now if you have the ability to look into surrounding rooms you can pump the list from FindRoom with whatever data you get as you look into other rooms into FindRoomFromNearby. FindRoomFromNearby allows you to either supply information about surrounding rooms all at once or 1 at a time. If you can't stand around looking into other rooms, just start walking. Supply each room as you step in there, then take the list returned by FindRoomFromNearby and use that as your source location next step. If you are in anything other then a maze area intentionally designed to be confusing you should get down to 1 room in the returned list in very short order.

It is possible that I made it so that the direction in which the name was found isn't even required. I can't actually recall right now. I think I did though just for those people that get moved in a random direction as a response to fleeing. In other words put your old room number in and the new room's name and it would come back with a list of which rooms you might have moved into. I am pretty sure I made it optional that way, because I have seen that random flee problem too often.

Posted: Wed Jan 16, 2008 6:43 am

I think I get the picture now, but I'm still unclear as to how FindRoomFromNearby will return fewer results if you "just start walking", as you put it. You have the FindRoom data for the first room, which returned multiple results, and the new room name (the one that you're now in). If you use @FindRoomFromNearby($OldRoomPossibilities,$NewRoomName) you get a smaller list for the old room, not the new one, and if you move again you're now two steps away from the original room, so how would you input the data for the first room? And then even if you manage to reduce the list to one room, it's a room that was a number of steps ago and not the room that you're currently in, so how will you determine the current room to #tele to? Would you have to save all the directions that you moved while you were lost so you can retrace your steps from the original room to the one you're in now?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Hrm, you are right. I will have to add something to that to make that 'just start walking' actually work instead of being something I just imagined doing. FindRoom was a section from my old mapping script that made logical sense to be pulled out and written as a reusable function. FindRoomFromNearby was a totally new extension to that aiming at doing what I described above. I haven't actually even gotten to writing most of the new usages planned for many of these functions in my personal scripts. I will add another piece or extend it just a little more so that walking concept is easily doable for users of the toolbox.

Having thought even more about it I also want to make sure it covers something like the various 'fear' spells I have run acrossed on some muds. I have seen a number of different ones that cause a character to wander around, often quite rapidly. I will make a solid goal of having all such problems handled. Maps are pretty much useless if you don't know where you are, this is definitely a high priority.

Posted: Wed Jan 16, 2008 9:35 am

I'm not sure how well you can implement this without sacrificing robustness (I can see it being rather complicated), but you're the king of ridiculous complexity, so I'll throw it out there. I also don't know how easily done this is with SQL - I don't know much of it at all. So much to learn, so little time.

Essentially what you're creating is another map, which will then be searched for as a subset of the master map. The more complex the sub-map you create, the fewer likely results you're going to get for the search. So basically, what you want is a general IsSubSet function, but one that compares a given set of map data against the master map rather than comparing two string lists or data record variables. Once you've found a single possibility for the subset, you can create a mapping of the rooms in your internal map with the vnums of the master map and, given that you know which room you're in on the small map, you can discover the vnum of the room you're standing in.

Then all you need to do is run around and use scan or whatever in every room so that the small map is as comprehensive as possible.

Again, I have no idea how feasible it is, but it seems like this is the inevitable destination of this problem.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

Just piling some ideas here with regards to Fang's idea above...
I assume you get an array of VNUMS back from the query you use to find yourself if you're lost.
Here is an incomplete supposition on how you might get found.

Posted: Wed Jan 16, 2008 2:03 pm

Using a map query would probably be faster than using %roomlink, but it's an excellent start. I would've used ipairs rather than pairs simply because table1 is an integer table, but it doesn't make a difference in this case.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

Yeah I figured you guys would take the ball and run with it.
It was like 8 am and I hadn't been to bed yet :p
You mentioned Sets and It got me thinking.
It was all I could do to get it out before I doubled back on the idea and surrounded myself in the confusion.
I'm just glad the idea at least has some merit.

Enchanter Joined: 05 Mar 2003 Posts: 593 Location: Canada

Hmm I'm not sure if mapquery will suffice, It only lets you specify the where clause and it appears to only be operating on the fields one sees when one does spreadsheet view in the map.
The %roomlink info I think is garnered from the ExitTbl table, one could do one's use a custom SELECT statement directly on the appropiate DB/Table but would All these extra steps be worth it.
Anyways maybe I'm off base, I dont know anything about mapping really.
Since I haven't really mudded for years I just DL'ed a Discworld map so I would have a decent sized map to mess with.

Second look shows mapquery works on all the fields of the ObjectTbl, but the info we need is still in the ExitTbl

Posted: Thu Jan 17, 2008 1:54 am

By mapquery I mean Vijilante's SpecialMapQuery function, which opens the map using the ADODB COM object and can search anything it likes.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Well I finally got a little programming time in today. I am pleased to say that I made very little progress on any front. I did however move some of the framework for all these things out of my head into the package. This is going to to end up creating another class in the toolbox for finding where you are.

As I worked through that framework I also realized that better handling of the SpecialMapQuery failure was required. This caused me to create a new function ValidateSpecialQuery. You can call this function after any call to SpecialMapQuery to find out whether the query was valid. This doesn't require any special sectioning because it is tied to the thread id's allowing you have as many queries as your system will allow threads. SpecialMapQuery still returns null when a query is invalid, but you now have a way of determining if that null is a valid result.

Now that I have a seperate test for these things I will likely go back through many other functions to see if I can make them faster with a conjoined query. For example this code at the command line

Posted: Mon Jan 21, 2008 7:12 am

Is there any documentation of the mapper's database format hanging around? I remember seeing something but can't remember where.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Finally a small update on this, I have been working with some really wacky SQL strings to get the whole exit data going the way I want. I think I finally got it. Along the way I ran into some issues with the SpecialMapQuery. Thanks to MrC, for pointing out the flaw with using RecordCount in there I was able to adjust that function to work better.

Sorry Fang, there really is no documentation on the map file format. Zugg wants everyone to use zMapper to access extended data, but there are many things that can't do. I would always suggest using zMapper's abilities when making changes to the map as the direct database manipulation will likely cause problems.

Now the fun part...the query I have been working with is for finding out where you got moved to. It basically builds a really big list of all possible rooms, and the movements involved to get there from a starting location. Well actually a list of starting locations. The query is built dynamically based on a range factor and a linear factor. The range controls how many steps away it should return and it makes a rather large attempt to eliminate duplicate values. The linear factor forces it to travel in a straight line like .5s or .5n instead of .nwnen which can make for a very fast query even at longer ranges.

I still have to add some more to this before it goes into its actual function and then I will have to spend quite a bit of time writing the needed parsing and requerying to properly handle the full range of options I want to cover. It will also take me a while to write the zScript side to do the same when the query errors out. Here is a preview of the query involved, and don't ask for support on it because this snippet is just some of my test code.

Adept Joined: 27 May 2008 Posts: 299

Viji - Is this planned to get any new updates?

Posted: Thu Jun 19, 2008 9:45 pm

Does it need any?

Adept Joined: 27 May 2008 Posts: 299

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Yes it is. I didn't realize just how long it had been. One of the major snags I ran into was %subregex couldn't do what I wanted it to do. That should be entirely fixed now, and then some. I should be getting back to this rather soon.

I should also be getting back into MUDding soon. I haven't actively played on my favorite MUD in even longer. Once I get the right vibe back you should be able to expect I will add a few more features I think might be useful.

Thanks for reminding me that I have been neglecting this.

Apprentice Joined: 08 Dec 2005 Posts: 108

Vijilante, I downloaded this and I can't seem to get things to work. What are the different commands available to me to walk to a different room?

Posted: Sun Dec 07, 2008 2:24 am

Are you using 3.01? The new mapper won't be compatible with this script.

Apprentice Joined: 08 Dec 2005 Posts: 108

I haven't moved over to 3.01 yet.

Apprentice Joined: 08 Dec 2005 Posts: 108

I think I figured out part of the problem, the script isn't getting the correct path to the map file. But it still would be nice to have some documentation on the available commands :)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

There is a bug with various COM usages in 2.37 that I found to be the root cause of the script failing. It uses COM calls to retrieve all of the direction settings and make queries on the map. Those calls not producing proper results in most script functions failing. A few of the functions do not depend on data retreieved by COM, but they don't accomplish much by themselves.

At this point my plans are to let this wait for a bit longer. Zugg has mentioned adding a function to zScript that allows querying the map with a full SQL statement; that likely won't be in for a few betas. I am currently working on putting together a few different libraries for usage with Lua, and then will be building a rather significant chunk of code with Lua. That group of code is the interface for an HTTP based mud. Once I have the interface built then I will want to do all sorts of scripting things for it, which will include using the mapper in some creative ways.

Doing that should put me in the right mode for building more of the scripts in my published package, as well as properly testing all things with the new mapper.