Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page Previous  1, 2
Zugg Posted: Wed May 28, 2008 9:23 pm
Next CMUD version and mapper plans
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed Jun 18, 2008 5:45 pm   
 
I don't think you're going to get any dissension on the MXP-mapping thing, Rorso. As for where a discussion would take place, I'm sure that teddy bears will be involved. You'd better go incognito. Today's the day, after all.

(I don't know, the rhyme's stuck in my head for some reason. I had to let it out Sad )
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Wed Jun 18, 2008 11:50 pm   
 
Yeah, DirectDraw has pretty much been merged into Direct3D... it's not discontinued per se, you can still use the DirectX 7 interfaces to access it (even in DX9).

When I was playing around with rendering tiles a couple of years ago, I found it simpler to use Direct3D anyway - basically each "tile" is two triangles (4 vertexes) and you render them with no "Z" axis/rotation, so they appear as a 2D object directy in front of the camera. Not sure how that compares speedwise to using 2D drawing, but it allowed for nifty things like real-time lighting/alpha blending/etc.

I guess with the mapper you could in theory build them all as cubes and include the Z-offset, so you can see more than 1 level above/below your current position and be able to rotate the camera to more of an "isometric" view, but that's probably vast overkill ;)

Edit: I was bored... so put together a program to do a 3d view of my MUD's map from the CMUD MDB file Very Happy I didn't support diagonals (since I don't use 'em) or non-standard exits but yeah... kinda neat.

Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Fri Jun 20, 2008 4:59 am   
 
Zugg wrote:
This thead is starting to get waaaay off track, so beware. Since neither CMUD nor the mapper need real-time 3D graphics, I don't have any plans to use either OpenGL or Direct3D. When I talk about "DirectX" I am talking about a larger package that includes stuff like DirectSound, DirectShow, and DirectDraw. Since CMUD already uses DirectSound and DirectShow for it's sound/MSP support, it's more natural to use DirectDraw to speed up some of the 2D map drawing.

But please don't sidetrack this thread with a DirectX vs OpenGL discussion. Thanks.

Just a discussion about ways to draw stuff to a screen, no off track intended...side note, 3d modeling=workstation app not desktop app, but anyway I'll let it die there.

I'm just learning programming myself so I'm working with WPF for my video and audio needs. I like what I see.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Jun 20, 2008 4:48 pm   
 
I'm not planning on doing any 3D stuff like that, sorry. I'm much more interested in graphical tile-based mapping, and that fits better with what a lot of MUD servers are looking for too. I actually want to get away from the "boxes connected by lines" concept of the current mapper and get into something a bit more flexible.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Sun Jun 22, 2008 11:24 pm   
 
Yeah, I agree that tiles would suit a MUD a lot better, it was more of a "I'm bored, I wonder what it would look like". The above image isn't really practical, to see the rooms clearly in 3D you need a much bigger window than you would in 2D, which takes away real estate from the main MUD window. Incidentally, there are ways to map a 2D surface onto a 3D object (even if it is just a plane), so you could potentially rotate the tile playfield to have it on an angle - like one of those 3D chess boards.
Reply with quote
Standoff
Beginner


Joined: 24 Mar 2007
Posts: 15

PostPosted: Sun Jun 29, 2008 3:15 pm   
 
I used to use MUSHclient before CMUD and nothing except scripting ever changed in that app. I like my software to evolve. Once he effectively said 'screw you' to any Vista users I knew it was time to switch.

So despite some frustrating bits, thank you for making a worthwhile alternative. :)

Let us know what you decide to go with, when you're there. :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jul 07, 2008 8:49 pm   
 
Getting this thread back on track:

I am starting on the Phase 1 of the mapper conversion this week. I hope to have this first phase done by early August, but stay tuned to the Beta Forum for more details. It will also have some other various bug fixes, but the next version due in early August will definitely be a new BETA version because of all of the mapper changes.

This new beta version will be CMUD 3.0, but it won't require any new license key yet.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Fri Jul 18, 2008 2:06 am   
 
Standoff wrote:
I don't know if I've ever seen a desktop app that uses OGL, and since the display code for a desktop app usually has a rather limited featureset, it's unlikely to be terribly difficult to get going right.

Just briefly then, for interest's sake, this is a (cross-platform) desktop app that uses OpenGL - in fact, it's a mapper one of the players on my MUD (the one I frequent) made for this MUD (it only works for this MUD so I think I'm OK in linking to some screenshots! Cool ). You can click on the image to get a bigger view on it, or see more here.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Jul 18, 2008 2:26 am   
 
Hmm, interesting. I particularly like the comment on their page: "Z-Mud alike map". Heh. Anyway, I think it would personally drive me crazy, but it's kind of cool in a way too.
Using the flat square tiles instead of cubes helps a bit though. It's not as hard to figure out as the one Rainchild posted. But I'd have to play with it live to see how easy to use and responsive it was.
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Fri Jul 18, 2008 10:07 am   
 
Mapper is one of the main z\CMUD features, visual enhancements for it should have a great effect (i.e. they are user attractive). After all, not everybody dreams of stuff like a new API for cMapper. Wink
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Fri Jul 18, 2008 12:27 pm   
 
Zugg wrote:
Hmm, interesting. I particularly like the comment on their page: "Z-Mud alike map".

Actually the first link I posted is not technically 'their' page, it's a MUME wiki page, although, judging by the page history, that part (and indeed that whole page, as of right now) was written by the author of the mapper, so I guess it's almost the same. Wink (The author is a Linux user IIRC, so I don't know if he's actually used zMUD, or if he's just looked at zMUD mapper screenshots...)
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Mon Jul 21, 2008 2:42 pm   
 
Zugg wrote:
Phase 1 : Database
The first phase involves replacing the current Microsoft MDAC/ADO database with SQLite 3.

I just wanted to check that the plan for the mapper was still to convert to using SQL in a more general form as suggested by this, and the other mapper feature I've highlighted:
Zugg wrote:
Mapper module
A new version of the mapper is planned that will use SQL instead of ADO/MDAC databases.
...
the ability to track the locations of multiple characters on the same MUD

I see this feature working as a result of being able to have shared mapper databases, e.g. PlayerA has a SQL Server map database to which he grants just sufficient privileges to PlayerB such that PlayerB can use his map (but, optionally, not edit it), possibly only when PlayerB is playing with PlayerA, and certainly one should have control over which other players using your map can see which other players (though clearly character position information shouldn't be held in the database), since they may be on different sides, or not friends of each other. I hope the mapper database will be like plans for user databases:
Zugg wrote:
Database module
...
It will be based upon the database components used in zApp, which support ADO, MySQL, SQL Server, SQLite, Oracle, DB2, Sybase, Interbase/Firebird, and more. The database module in CMUD will probably use SQLite by default, but you will be able to use these other formats as needed.

And I think I read somewhere else earlier on that directly suggested being able to use any SQL database engine as the mapper backend database, but I'm not sure where you posted that. It would be useful to be able to allow people to use your map, but not give them a copy of it, since you may be playing with someone for a session, but not trust them completely, or you may not want to give them your map and then have them use it against you another time when they are playing on the other side, or something.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jul 21, 2008 5:08 pm   
 
The new mapper will use SQLite. The Database components that I will be using for this are called ZeosLib and it has drivers for many different databases. So in theory you'll be able to use other database engines. But what I found when doing the MDAC/ADO mapper in the past is that the mapper always needs optimization for speed that usually prevents *any* database from working with it. For example, the mapper depends upon the database being in memory for speed. This is true for "local" databases (like SQLite or even MDAC/ADO), but is not true for server-based databases. My guess is that a server-based map database would be so slow that it wouldn't actually be useable. So doing a shared map database requires a lot more than just using a server-based database engine, and that is currently beyond the scope of what I am doing.

There are lots of issues behind shared map databases. Not all of them are technical. There are ethical/legal issues involved in publishing a shared map of a particular MUD, unless the MUD itself wants to host it. The areas and zones of a MUD are owned by the MUD itself, or the builder of the area. Right now this data is just stored on your local hard disk, similar to just a "cache" of the MUD that you are playing. Making this database "shared" and available across the Internet is essentially publishing this data to everyone, and I can see many MUDs who would have a big problem with that.

I don't want to get into that in this thread, so if you want to talk more about issues involved with shared map databases, create a new topic for that. It's also something that has been talked about in the past for zMUD so you might be able to search and find some older threads that talk about it.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Mon Jul 21, 2008 11:44 pm   
 
The only other thread on this suject (from 2002) appears to be in the zMUD Beta Forum, to which I cannot access.

Zugg, or another forum moderator, can you move this post, and the previous two (perhaps editing out the last paragraph of Zugg's post), to another thread in this forum called "Shared Map Database" or whatever you feel it should be called?

Zugg wrote:
The new mapper will use SQLite. The Database components that I will be using for this are called ZeosLib and it has drivers for many different databases. So in theory you'll be able to use other database engines. But what I found when doing the MDAC/ADO mapper in the past is that the mapper always needs optimization for speed that usually prevents *any* database from working with it. For example, the mapper depends upon the database being in memory for speed. This is true for "local" databases (like SQLite or even MDAC/ADO), but is not true for server-based databases. My guess is that a server-based map database would be so slow that it wouldn't actually be useable. So doing a shared map database requires a lot more than just using a server-based database engine, and that is currently beyond the scope of what I am doing.

A server-based database engine can still be configured to hold the entire database in its memory. The database connection should be held open whether the database is local or remote, so that's not an issue either. You merely have the network lag to and from the database. Now, this may well make it unusable for many people, but if your database server is on your LAN, then the network lag shouldn't be a problem, and if the database server is very well connected on the internet (not on ADSL, but with a 10 Mb or more link to its Internet peers), and your users have a good route to this server, the ping times may well be below 30ms (as my office's web server is from me at home on my standard ADSL - actually can reach 20ms, which is 4ms more than the far end of my ADSL - actually I'm impressed!) Now, whether or not a network lag of 30ms or so makes the map unusable, I don't know, but I suspect it could be made usable if the mapper preloaded the details of each room that is next to the current room, then simply selects the correct room (according to the usual algorithms) when you move. With some relatively simple prefetching of data, and caching of some other data (room types, exit types, the costs associated with these, any graphics, zones names, perhaps even the entire current zone the player is in), I reckon it would work reasonably even if the map database server is more like 100ms away.

A few players on the MUD I frequent made a map server program called CheeseLab, where the map is stored on the server, and the intention was for it to create a 'virtual lab' - effectively reducing the advantages that players playing together in teams in a lab get over players playing together in geographically disparate areas. I haven't tried the program but I assume it worked OK over the Internet as clearly this was the aim and they reached version 3.0.0 before the project fell asleep. Unfortunately there is not much discussion or instructions on use on the program but it is open-source. Hmm, Zugg, you mentioned recently in another thread that z/CMUD led MUD client development (and I don't dispute that this was the case for many years), but in _some_ areas of mapping (graphics and the subject of this post), CMUD has fallen behind several of the mappers available for my MUD. I welcome the new focus on this area, as do many others I'm sure! Smile

Zugg wrote:
There are lots of issues behind shared map databases. Not all of them are technical. There are ethical/legal issues involved in publishing a shared map of a particular MUD, unless the MUD itself wants to host it. The areas and zones of a MUD are owned by the MUD itself, or the builder of the area. Right now this data is just stored on your local hard disk, similar to just a "cache" of the MUD that you are playing. Making this database "shared" and available across the Internet is essentially publishing this data to everyone, and I can see many MUDs who would have a big problem with that.

That is true: there may be ethical/legal issues for some MUDs, but (a) not all MUDs; (b) this could be reduced by disabling off-line mapping if you are not the 'owner' of the map database (meaning you, more or less, have to be in a room on the MUD to see all the data on a given room); and (c) most people aren't going to publish their shared map on the Internet. If _possible_ ethical/legal issues stopped all software development, there would be no P2P file sharing, much of which is completely ethical and legal, and some is even protected via DRM, e.g. the BBC iPlayer (which BTW appears to be rather nasty (read underhanded) from what I've read).
Reply with quote
tonygks
Newbie


Joined: 02 May 2009
Posts: 9

PostPosted: Sat May 02, 2009 7:14 pm   about mapper
 
in last beta u changed mapper interface a little. u dock "editmap toolbar" at left side in MapMode mapper and u cant replace it or remove. its disadvantage cause when u change FollowMode to MapMode(edit) this toolbar appers and map area redrawing so it becomes lesser a bit.
i ussualy use alias for change mapper mode. and have a lot of triggers which uses this macros (fe doorcreator script or recoloringrooms) and it change mapper mode 2 times in 0.1-0.2 seconds(cause impossible to edit rooms color, doors, links and other in followmode, so script enable mapmode , create door and enable followmode). if i editing zone with a lot of rooms(50+) then redrawing map take a little time and "shake" of cmud interface. so very uncomfortably to edit maps (.. (my map count about 30-40k rooms and i dont have doors in it ( so need to do great job)

ps i have good pc and itsnt a reason of this
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon May 04, 2009 6:53 pm   
 
You can rearrange the toolbars however you want. Just make sure you have the Lock Layout option turned off.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri May 22, 2009 9:20 pm   
 
Just to update this post. The v3.0x BETA versions contain the "Phase 1" of the new mapper described at the beginning of this thread. I plan to release a PUBLIC version of 3.x as soon as I feel it is stable enough and has enough bug fixes.

The Phase 2 and Phase 3 of the new mapper will come *AFTER* the first 3.x Public version in later beta rounds. But all of the mapper improvements will still be added as part of the 3.x major version series.
Reply with quote
deathkitty
Apprentice


Joined: 14 Apr 2008
Posts: 105

PostPosted: Thu May 06, 2010 1:54 pm   
 
On the subject of mapper ideas, it would be really cool if there was a way for triggers to add dots or icons to rooms dynamically, like if you get a message saying when you do a "scan" that there are enemies 2 rooms away south, 3 rooms away east etc that it could place a dot or icon in that many rooms in that direction for each -- let us use the map like a "radar" :) of course and a way to when we move out of the room to change icons created from being in that room to a different colour to indicate that they are the "last known position" rather than being up to date.. hell could even make it so additonal floating text could get added dynamically to rooms with the icons so you can hover over one if you want and see what it was you saw before was in that room :) I think the problem at the moment is you can only the entire room colour or icon for the whole room, not add "extras", and even with the room colour you have to specify the room exactly with a number rather than being able to say x in direction


edit: hmm this is interesting via google, http://mudstandards.org/forum/viewtopic.php?f=6&t=87&start=50

oh and that picture Rainchild posted above is wowawesome :) but needs to be edited to be a thumbnail to click for larger pic or changed to a link really, it's making the text on the thread hard to read it's messing up the scrolling horizontally so you have to scroll text doesn't fit to the page anymor
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu May 06, 2010 5:31 pm   
 
Removing this post from sticky status because the information is old.
Reply with quote
deathkitty
Apprentice


Joined: 14 Apr 2008
Posts: 105

PostPosted: Thu May 06, 2010 8:47 pm   
 
okies cool hope you look at that idea I posted though, I wanted something like that a while ago but it seemed just not possible to do cos of the limitations of how colours of rooms can be changed (only exactly rather than directional), tho of course the ideas about going further and better to let people show what's in different rooms would be even better :)
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri May 07, 2010 1:51 am   
 
Essentially, that can already be done, DK. It's just not simple and easy, might not even be reliable, and it definitely requires the use of ZMapper (or later Cmapper when that comes out).
_________________
EDIT: I didn't like my old signature
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net