[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ Graphical mapper
Graphical mapper

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Axesider   (5 posts)  Bio
Date Mon 26 Jun 2006 08:17 PM (UTC)
Message
Hi

I'm working on a graphical mapper which is almost done. I'm currently looking for people who will do some testing.
So, download http://hero.mac.edu.pl/~axesider/m/mapik.exe
run
mapik.exe 2300 1
Connect from Mush to localhost:2300 and you should see set of commands. Now download http://hero.mac.edu.pl/~axesider/m/zmudexport.exe Enter Start->Settings->Control Panel->ODBC, click add, choose 'Microsoft Access Driver' and a proper zmud map. Source name as 'test'. Run zmudexport.exe, choose 'test' from combobox and 'Connect to'. Choose your zone and click 'Zapisz strefe'. Wait for minute and you will have a xml file. Copy this to directory where is mapik.exe
Type 'mapload yourzone.xml' in client and "goto location's short" this should put you in mapper.
Type 'go n' and you will go north on map.
If you are interested in help me with testing or writing a help, email me.

Axesider
Top
Posted by Ovvi   Poland  (13 posts)  Bio
Date Reply #1 on Tue 27 Jun 2006 10:33 AM (UTC)
Message
Hi,

I have got that mapper a few days earlier. I prepared plugin to connect between my 'master' World and tempolary World, which is directly connected to mapper. Mapper gives me two ways communication, when I use right clik on mouse on some point in map, I receive directions partition by ';'. On the other way my 'master' World use triggers to check where I am going and send directions to another World connected to mapper.
Please look at the example:
http://oceanic.wsisiz.edu.pl/~froniu/maper.jpg

Ovvi
Top
Posted by Indoum   Sweden  (17 posts)  Bio
Date Reply #2 on Tue 27 Jun 2006 04:45 PM (UTC)
Message
I'm impressed, this looks great! A graphical mapper would surely accelerate the number of users for MUSHclient, since that's one of the biggest complaints I hear from those testing it out.

Could you supply a map in XML for us without zMUD maps though?
Top
Posted by Axesider   (5 posts)  Bio
Date Reply #3 on Tue 27 Jun 2006 05:09 PM (UTC)
Message
Well,
<mapa>
<room id="1" short="Location short" x="10" y="10" k="#808080">
<exit nr="0" id="3" dir="sw"/><--first exit to location number 3-->
<exit nr="1" id="2" dir="ne"/><--second exit to location nr 2-->
</room>
<--next room-->
<room id="2" short="Room two" x="20" y="20" k="#808080">
<exit nr="0" id="1" dir="sw"/><--first exit back to location number 1-->
</room>
<-- and so on -->
</mapa>
Where is an editor http://hero.mac.edu.pl/~axesider/m/mapper.exe but I don't use it for a long time and I don't know if it works with current version of maper.

Top
Posted by Shadowfyr   USA  (1,787 posts)  Bio
Date Reply #4 on Tue 27 Jun 2006 06:28 PM (UTC)

Amended on Tue 27 Jun 2006 06:30 PM (UTC) by Shadowfyr

Message
Ok, I have a minor issue here.. It seems like the mapper just displays an "existing map", once in XML format? So, you have to map things in ZMud first? Begs the question of why not, if ZMud uses an ODBC file, just use the ODBC database itself, instead of converting, then you have the option to add in "real" mapping. XML is not a good format for data that needs to change at a regular rate, you have to export the entire file every time, not just update or add a single record for a new room.

The other thing to consider is your interface. You can do something like this in a plugin:


'In plugin.
dim mapper 'Mapper object must be global, so it persists.

sub OnPluginConnect
  mapper = createobject("mapik")
  mapper.SetWorldID(GetWorld)
  mapper.plugin = GetPluginID
end sub

sub Display_It (data)
  note "You can get there by going: " & dirs
end sub

----

'In your own program.
dim myworld as world '"world" is and object type created from the TLB file supplied with Mushclient.

sub SetWorldID (WorldID as string)
  set myworld = WorldID
end sub

sub onclick_map
  ... 'Get the info for the directions and put into "data".
  myworld.CallPlugin (me.plugin, "Display_It", data)
end sub


Note, this is VB code, so differs a bit for other languages. It also doesn't have any safety checks, like making sure a valid world is passed to it, etc. Here is a C++ example of the same thing:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3128

It is possible to use this indirect way to make it work, since you are the one writting the application. For stuff you have not not written yourself, this simply won't work, which is why I have been hunting for a more universal solution in OLE and COM.

Point is, there exists an already far better solution for this, that doesn't rely on a second world being created. And even if you don't get all this and are more comfortable with TCP/IP, then Nick added a way to tie into a program using UDP as well, which is not too different from TCP/IP. Its only main difference is that TCP/IP has some built in, and hidden from the developer, safe guards to make sure data gets where it is supposed to go.

Not trying to rag on you, but you have missed several better ways to connect the mapper to the client and I don't think XML is all that great of a solution for the data itself to be kept in. Still, you have gotten way farther than the rest of us malcontents that have been talking about making one. ;)lol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #5 on Tue 27 Jun 2006 06:34 PM (UTC)
Message
Quote:
XML is not a good format for data that needs to change at a regular rate, you have to export the entire file every time, not just update or add a single record for a new room.
That is a non-issue because it's a misrepresentation of how things work. Any file on Windows (and Unix for that matter) has to be re-written; you can't add a record without doing that. Database tables are also stored in files, so same problem.

So in this respect, XML is no worse than ODBC, except that ODBC is more likely to be optimized than home-grown XML handling routines. Still, we're not exactly talking about super-speed-critical routines here, so it doesn't matter. What matters is what's convenient, not what's super-speedy.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Axesider   (5 posts)  Bio
Date Reply #6 on Tue 27 Jun 2006 09:08 PM (UTC)
Message
Hi,
At the begining it uses UDP, but some of my friends which uses TF have problem with UDP, so I'v changed to TCP (this also simply solve feedback). Why not I'm reading directly from ODBC? Firstly I dont know how to handle ODBC under Kylix(and I dont want waste time for this), secondly some users dont have newest BDE.
You dont have to map things in Zmud, maybe some day somebody create map editor based on xml or exporter fro mother non-Zmud formats.
Besides this xml is about 20% of Zmud map weight and can be rar'ed with 16% ratio.
Top
Posted by Shadowfyr   USA  (1,787 posts)  Bio
Date Reply #7 on Wed 28 Jun 2006 06:09 PM (UTC)
Message
Quote:
Any file on Windows (and Unix for that matter) has to be re-written; you can't add a record without doing that. Database tables are also stored in files, so same problem.

So in this respect, XML is no worse than ODBC, except that ODBC is more likely to be optimized than home-grown XML handling routines.


Umm.. Wrong. ODBC doesn't load the entire thing into memory, then keep it there until you need to save it again (though it may cache large sections for quick access, while writing "new" data back to disk immediately). That is the problem with XML. Databases "do not" re-write the entire file. They write distinct chuncks of data to the file as needed and don't compress the file to a smaller size unless you run them through a cleanup tool to sort of defrag the empty spaces. This means if it deletes the 90th record in a 10,000 record file, then the next record gets inserted into the hole, but, if the insert is at position 54, *only* records 53, 55 and the hole are written to, for some types, others may have the drivers sort things out to maintain some consistent structure, in the background. Kind of depends on the type of system in use. In the case of a map, all records that are "known" to have back-links to the room need to be updated, along with the room. Usually that means only two records, since there is no why to be 100% sure that all exits have returns, just the one that you just came in from, and that isn't always certain (being the reason why making mappers is a pain in the ass). While some languages, like the old QuickBasic, allow you to write in binary mode and thus read/write data from specific points, just like with a database, most file types that are meant to function as documents, like XML, have no fixed block size, so there is no way to index specific points in the file. You are forced to load 100% of the file into memory, then write 100% of that file back out. Speed isn't the issue, because, unless you re-read the file every time to look for the data, the entire contents of the file is already in memory, in a form that can be searched far more quickly.***But*** it makes it more volitile, since any crash, power outage or other problem will trash all your new data. Not a problem here, but if this project where to be expanded to a mapper, instead of just a map displayer, it wouldn't be a good solution any more.

---

That said.. Never heard of Kylix.. However, its companion CD apparently comes with the ODBC system also found here:

http://open-dbexpress.sourceforge.net/

Well.. The proprietary version anyway.

Hmm. Seems you are using Linux here. Just realized what Kylix is. :p That complicates things by a huge margin. Its probably still possible, but the main problem won't be making it work on Windows, but connecting to the ODBC on Linux. I had kind of assumed that since you have an exporter application, you should be able to use it anyway. I mean, how are you reading the database in the exporter if not using the ODBC system? Unless that was written by someone else?

Oh, and your friends problem with UDP. Could it have been something in their firewall? UDP is unrealiable as is anyway. To use it effectively as anything but a general announcement system you kind of need to build a clone of TCP/IP over top of it. The underlying concept is the same in both, TCP/IP simply has checksums, response codes, the ability to repeat packets if one goes missing, etc. None of which UDP does on its own. As you found out, its not even capable of something as simple as, "I can't get there from here!" To do any of that the coder has to invent his own response codes, repeat codes and verification systems.

I can see, using Kylix, why there might be some issues with trying to support the COM interface instead, as well. Unless Borland is calling its Windows compiler Kylix as well now, you don't really have access to that. What we need eventually is something that runs in the same OS architecture as Mushclient, so they can talk to each other efficiently. UDP won't do it without heavy modification, TCP/IP is only workable if you don't mind cluttering up the client with extra windows. One extra is needed, at least, for each open world that uses the mapper, not the mention any other similar stuff people come up with later. That's not exactly efficient. ;) Maybe what we should try for is a more open project, something where those that know how to get the ODBC and COM connectivity to work can be helped by your expertise in managing to get a working graphical map.

Though, I don't know C++ well enough to write "Hello world!", so am probably not one who should be complaning much.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #8 on Wed 28 Jun 2006 06:51 PM (UTC)
Message
Quote:
Umm.. Wrong. ODBC doesn't load the entire thing into memory, then keep it there until you need to save it again (though it may cache large sections for quick access, while writing "new" data back to disk immediately).
I'm not sure what you're trying to say ODBC does that XML can't do. Why can't you do exactly this same thing with an XML system?
Quote:
That is the problem with XML. Databases "do not" re-write the entire file. They write distinct chuncks of data to the file as needed and don't compress the file to a smaller size unless you run them through a cleanup tool to sort of defrag the empty spaces.
You can do the same thing with XML, if you wanted to. Thunderbird does this with its plaintext mailbox files. What you call 'compress' is more accurately called 'compacting', because there isn't actually any compression going on in this part (although databases (and XML, of course) can store their data in compressed form).

If you had said that ODBC has the advantage that all this work is done for you, that would be a fine and perfectly accurate statement. But the statement you made blamed something on XML that has nothing to do with the XML specification and everything to do with how you actually use XML. ODBC is a system, not a format; XML is a format, not a system.

In fact, there are databases that use XML as their backing store, and are efficient etc. BerkeleyDBXML is an example. It uses XML as a backing store, which is in turn stored in a BerkeleyDB backing store. This program is a good example of the confusion you made, because what these people did is to build a system around the XML format, and it does everything you claim "XML" can't do but ODBC can.


By the way: you mix conventional asterisk emphasis and the unconventional quotation mark emphasis... do you mean different things with each? It's very confusing to me... :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #9 on Wed 28 Jun 2006 06:53 PM (UTC)
Message
And also:
Quote:
most file types that are meant to function as documents, like XML, have no fixed block size, so there is no way to index specific points in the file. You are forced to load 100% of the file into memory, then write 100% of that file back out.
This is also incorrect. Thunderbird is a good example where files are indexed despite being in plaintext. What prevents you from using whitespace in your documents and having a separate file indexing into the text document? The answer: nothing. Again, the issue is that you are treating a format as a system, instead of considering the system that you build around a format.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Axesider   (5 posts)  Bio
Date Reply #10 on Wed 28 Jun 2006 07:27 PM (UTC)
Message
Are you guys always talking too much and create problems?
Did you download mapik and try how it works?
I didnt write mapik just for mush client so it uses TCP (UDP is only one way protocol, so it is NOT suitable then i want have feedback).
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #11 on Wed 28 Jun 2006 07:55 PM (UTC)
Message
You could always use UDP both ways, but it is indeed less practical. UDP's unreliability isn't an issue at all on a local computer.

I haven't downloaded and tried the program, because I don't download and run .exes unless I either have complete trust in the source or have a strong need to run the risk. No offense, of course; I just am paranoid about running .exes from people I don't know.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #12 on Thu 29 Jun 2006 01:49 AM (UTC)
Message
Quote:

I don't download and run .exes unless I either have complete trust in the source or have a strong need to run the risk ...


I agree with Ksilyan here - running untrusted .exe (or .dll) files is a good way to get a trojan horse or virus.

Anyone who wants to run the program mentioned here (or any .exe or .dll for that matter) should take into account the risks that such a program may do more than is advertised.

I am not attacking the original poster here, I have no way of knowing whether, or not, his program is safe to run.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,787 posts)  Bio
Date Reply #13 on Thu 29 Jun 2006 06:13 PM (UTC)
Message
Quote:
And also:
Quote:
most file types that are meant to function as documents, like XML, have no fixed block size, so there is no way to index specific points in the file. You are forced to load 100% of the file into memory, then write 100% of that file back out.

This is also incorrect. Thunderbird is a good example where files are indexed despite being in plaintext. What prevents you from using whitespace in your documents and having a separate file indexing into the text document? The answer: nothing. Again, the issue is that you are treating a format as a system, instead of considering the system that you build around a format.


Interesting... Not sure how it manages it, unless it keeps an index in memory of the sizes of each "record" or some such. I suppose that is possible, though it would likely mean taking a big hit at startup, when initially building the index, especially with significantly large collections of stored email. Though, I suppose there are ways around that too, though I can't think of any that don't create a similar performance hit. And yeah, I meant compacting, but couldn't think of the right word.

----
Quote:
Are you guys always talking too much and create problems?
Did you download mapik and try how it works?
I didnt write mapik just for mush client so it uses TCP (UDP is only one way protocol, so it is NOT suitable then i want have feedback).


OK Axesider, I can see why you are looking for a different way of doing this, if you are looking at something that may work with other clients as well. Not sure you have considered the practical fact that probably 90% of the clients around couldn't use your mapper anyway. Not all of them let worlds talk between each other, not all of them allow multiple open worlds, etc. Or not in any useful combination anyway. Any client that can, probably has better alternatives for creating such a mapper.

Now, I am less paranoid than some of these other people, though I do make sure with stuff I am not sure of to scan it first, but my biggest factor was that, "from your description", it seemed that I would need a zMud map to start out with, and I won't touch that client long enough to turn on the mapper in it, never mind play for any length of time. lol I have been going entirely off of how you describe it working, which seemed a bit screwy for something intended to work with Muchclient only. I'm not sure its not a bit screwy for a significant number of other clients either, but I can't be sure of that, since I don't know their limitations quite as well as Mushclient's or just what clients you might be trying to shoe horn this thing into. ;)

In the long term, we are probably going to end up wanting a more Mushclient specific solution that takes full advantage of the client. In the short term... Based on what you have said about how it works, it seemed to be a step in the right direction, but not quite enough.

And no, we don't just talk to make problems. A lot of what makes Mushclient what it is today has been a result of exactly these sort of discussions about limitations we felt needed to be overcome. Sometimes that ends up with us arguing with each other. For example, I had no idea *anything* managed to use XML like a database. There are ways, but imho its "still" not intended to be used that way and you end up having to do all the dirty work, since the implimentation libraries for it are unlikely to support using it like a database, which does things "very" differently internally. In which case, I have to say, Thunderbird does? That's nice, but **how**? lol Its kind of an important question. ;) I can't think of any way that wouldn't be a total pain in the ass to impliment.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #14 on Thu 29 Jun 2006 06:57 PM (UTC)
Message
Quote:
Interesting... Not sure how it manages it, unless it keeps an index in memory of the sizes of each "record" or some such. I suppose that is possible, though it would likely mean taking a big hit at startup, when initially building the index, especially with significantly large collections of stored email.
Yeah, that's basically what happens; when you first access a mailbox (which is stored as a plaintext .mbox file), it builds a big summary file, which is a big index into the plaintext. It stores all kinds of stuff; most importantly, it stores the location of the various emails in the text index file. It's a big hit only the first time you access the mailbox; from then on it stores the summary file (.msf) on the disk. Even then, the hit isn't that big; for a few thousand email messages, it takes it about 10 seconds on my machine to build the summary file. When I get home, I'll post how big the summary file is compared to the .mbox file, to give an idea of the overhead.

Of course, this is not as fast as a completely binary storage format. I think Thunderbird chose to use plaintext .mbox files to maximize compatibility with Linux mailers, that all tend to store in the same .mbox file (or can easily export back and forth). And incidentally, the .mbox file is the same format as the mail spools on almost all servers, so it's a fairly universal format. What's also nice is that if the summary gets corrupted, you just delete it and regenerate it without losing any email. In Outlook, though, you can lose all your email if the storage file gets corrupted.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

67,695 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]