20 Sep, 2013, plamzi wrote in the 181st comment:
Votes: 0
Runter said:
Rarva.Riendf said:
Hmm just a thought, could it be possible (I mean without giving you a lot of work) that the mud send the whole map data and how it wants it to be shown once and for all (link lenght, room position etc) and then only send the info of wich room the player can actually see as the room he visited only and not the whole map ? (would be send at char logging, then each time a new room is 'lit'.


…the best way I've found to deal with this is always considering the client and the player to be the same thing..

It's actually worse to make it so that only the technically minded people can get access to these unfair advantages.


I'm with Runter here. That the client is the same as the user is especially true for JavaScript running in your browser. If you don't want the user to have access to certain location info, just don't send it.

As for favoring tech-minded people, this client in the cloud will be able to combat this fact better than others before it. If someone techy maps their favorite game, others will gain access to that world file automatically. I picture a simple wiki model for collaborating on the map (with revisions kept automatically) as well as giving people the ability to overlay their own custom notes, or clone off the world file completely.

Rarva, I think I know what you're getting at and the solution I believe is for the game to send info on what exactly it wants the map view to render at any given location for any given player. This is what I do currently for the old web app and the iOS app, except the renderer is not nearly as powerful or sleek. The big advantage to this approach is that you can render subjective views, not just fog-of-war, but really, anything you may want to vary based on a character's current state. Since the server is in full control, it is easier to push overlay data like players or mobs passing nearby. And since you're sending only display info, you're not divulging anything you don't want players to know. I am pretty sure this mode will be supported by code I write (as opposed to people having to add code later). One, it's pretty straightforward to make the renderer "dumb". Two, there are quite a few games with server-side automappers that can be leveraged fairly easily to drive this mode. Three, I may use it myself for the mobile app.

There will also be an option to upload a world file in JSON format that the mapper will interpret. I want to do a little better than Mudlet in this respect by not requiring this file to contain any room coordinate data, something that most MUDs would have great difficulty providing.

Ripley said:
Hey Plamzi - If you put in some hooks for triggers and whatnot that allows the player to define 'this is a room name', 'This is an exit string', 'This is how the exit string is parsed', etc., perhaps even using some custom-set colors, that would place some of the onus on the player for muds that don't want you really mapping, while also allowing those mud admins who wish it to provide data in a specified format via msdp, mxp or atcp, whatever.

At least, that is how I handle mapping text data coming from the mud in my client, for muds that don't want to expose the sacred vnum! :)


I've also heard that Mudlet's new automapper can scan room descriptions and contents to automatically check for room uniqueness. All that's doable, just tricky. At some point, there's gotta be some kind of freeform edit mode where players can just move rooms around to get the best result.

My sense is that I'll focus first on getting this out to games that do want their players to get around more easily, then worry about empowering geeky players on games that put up a fight.

Ripley said:
Please provide the msdp data structure so that I can add it to Luminari! The vector mapper looks REALLY good.


Does your game already send location data via msdp in a fairly standard format? If so, maybe I should use it as a model. I'm almost ready to start alpha testing with different games.
20 Sep, 2013, KaVir wrote in the 182nd comment:
Votes: 0
plamzi said:
Rarva, I think I know what you're getting at and the solution I believe is for the game to send info on what exactly it wants the map view to render at any given location for any given player. This is what I do currently for the old web app and the iOS app, except the renderer is not nearly as powerful or sleek. The big advantage to this approach is that you can render subjective views, not just fog-of-war, but really, anything you may want to vary based on a character's current state.

That's the approach I use as well. As GW2 doesn't have rooms, regular automappers wouldn't be much use.

plamzi said:
I've also heard that Mudlet's new automapper can scan room descriptions and contents to automatically check for room uniqueness.

I've seen other automappers use the same approach, but it's not foolproof. I wouldn't personally consider it a priority if I were in your shoes - better to focus on features for those who want to make MudPortal look good for their games than workarounds for those who don't.
20 Sep, 2013, Kaz wrote in the 183rd comment:
Votes: 0
Scandum said:
plamzi said:
VT100 is not my goal, and I'm not going to claim full ANSI support, either.

I defined a reasonable subset a while ago:

http://www.mudpedia.org/mediawiki/index....

http://www.mudpedia.org/mediawiki/index....

This list omits codes that are known not to be universally supported.


I know you're only listing the "most frequently supported" ones, but I'd just like to say that XTerm mouse tracking is of great utility on top of these.
20 Sep, 2013, Rarva.Riendf wrote in the 184th comment:
Votes: 0
Runter said:
Rarva.Riendf said:
Hmm just a thought, could it be possible (I mean without giving you a lot of work) that the mud send the whole map data and how it wants it to be shown once and for all (link lenght, room position etc) and then only send the info of wich room the player can actually see as the room he visited only and not the whole map ? (would be send at char logging, then each time a new room is 'lit'.


This would be a security risk if you actually care about players not being able to build their own client (or minimal plugin) that always shows all of the data.

Having dealt with these concerns almost every day for the last few years in my professional life, the best way I've found to deal with this is always considering the client and the player to be the same thing. If the client can see/access/change, using any logic or permutation of the API calls, then so can the end user.

It's actually worse to make it so that only the technically minded people can get access to these unfair advantages. Not hard for them to release a plugin or "hack" to "reveal map".


I perfectly agree, never trust the client is a basic security measure. I think I just supposed for some reason that the final map would never be sent to the client, but would stay on Plamzi server and all calculation done on it before being sent to the plugin.
On second thought, I do not understand why I supposed it was done this way per default.

Still have question for the plugin though, can you specify the size of link ? Or is it purely automatic ?

I could send the msdp info in the they way you like it best pretty quick. Just create a basic 'format'
lsomething like this
room name
room vnum
room desc
exit up
link lenght up
exit down
link length down
exit north
…etc

I think I already provide some info about room but not link length as I had no use for it.

Indeed I do

if (pRoom && pRoom->vnum != (unsigned int)d->pProtocol->pVariables[eMSDP_ROOM_VNUM]->ValueInt) {
unsigned char door; /* Loop counter */

strcpy(buf, "\003"); /* MSDP_TABLE_OPEN */

for (door = DIR_NORTH;door < MAX_DIR; ++door) {
if (pRoom->exit[door] != NULL) {
const char MsdpVar[] = {(char)MSDP_VAR, '\0'};
const char MsdpVal[] = {(char)MSDP_VAL, '\0'};

strcat(buf, MsdpVar);
strcat(buf, dir_name[door]);
strcat(buf, MsdpVal);

if (IS_SET(pRoom->exit[door]->exit_info, EX_CLOSED))
strcat(buf, "C");
else /* The exit is open */
strcat(buf, "O");}
}

if (pRoom->area != NULL)
MSDPSetString(d, eMSDP_AREA_NAME, pRoom->area->name);

MSDPSetString(d, eMSDP_ROOM_NAME, pRoom->name);
MSDPSetString(d, eMSDP_ROOM_EXITS, buf);
MSDPSetNumber(d, eMSDP_ROOM_VNUM, pRoom->vnum);
}


I have a problem with sending all the map the player can view at all time though, it can be pretty big.
I support a 'minimap' that I think is what you mean (player can see up to 3 room around him (provided he visited them)

but if he types map, he can see all the map he knows that is on the same level.
I can send it once, and only update it if a new room is visited though, but that means the plugin have a way to store that?
20 Sep, 2013, plamzi wrote in the 185th comment:
Votes: 0
Rarva.Riendf said:
Still have question for the plugin though, can you specify the size of link ? Or is it purely automatic ?

I could send the msdp info in the they way you like it best pretty quick. Just create a basic 'format'
lsomething like this
room name
room vnum
room desc
exit up
link lenght up


This may be part of a larger conversation about resolving the many kinds of non-Euclidean conflicts. The short answer is that I can definitely let the server specify link lengths, but that I'd rather not have this as the only way to generate the map, since I suspect that for many devs link lengths would be as difficult to provide as it would be to ask for x, y, z coordinates. Maybe I'm misunderstanding this but are you saying that your game already has "link length" ready to send out?

Right now, the mapper is trying to resolve some simple overlaps automatically. After that, it lets the server supply some form of "inside vs. outside" flag or meta data field. It uses the "inside" flag to increase density and it will, at some point soon, also use it to decide smartly when not to draw certain parts of the map.

I experimented with auto-extending link lengths to avoid overlaps but the results can be very poor when applied automatically to huge maps, and I'd rather not make users think about those things. I think the "inside vs. outside" approach is very simple for server devs (I suspect many world already have sector types and indoor flags, etc.) and can ultimately produce better results. For example, if you have a city and many houses inside that city, the city street rooms may be enclosing a number of rooms inside a house. Now, even if said house is not a different area, it can be flagged as "inside". If it's only a few rooms, they will fit nicely between the "outside" links framing them. If it's huge, the mapper will detect overlaps and suspend drawing the house until a player actually enters (or maybe when they get near, mimicking a "line of sight" experience).

At least, that's the idea. From what I've tried so far, things look nice, without information overload. And the map remains dense so people can still see (and soon click) pretty far.

Rarva.Riendf said:
I have a problem with sending all the map the player can view at all time though, it can be pretty big.
I support a 'minimap' that I think is what you mean (player can see up to 3 room around him (provided he visited them)

but if he types map, he can see all the map he knows that is on the same level.
I can send it once, and only update it if a new room is visited though, but that means the plugin have a way to store that?


Not the whole world every time, of course. If you're serving display info, like e. g. those old-school real-time ascii maps, you'll be sending the immediate surroundings when/if they change. The mapper is not going to need to store anything that lies outside the visible range because when the player changes locations, the server will send the new view.

In this mode, the awesome power that is d3 can really help optimize things. For a new frame, you can choose to send only the data points that have changed. For instance, if a player or mob is passing by, you know not to re-send terrain info. But even if you do send all the display info every time you want to change the view, d3 will automatically skip over data points that haven't changed since the previous frame and achieve the best possible rendering speed on the client side.
20 Sep, 2013, donky wrote in the 186th comment:
Votes: 0
Kaz said:
I know you're only listing the "most frequently supported" ones, but I'd just like to say that XTerm mouse tracking is of great utility on top of these.
Why?
20 Sep, 2013, Rarva.Riendf wrote in the 187th comment:
Votes: 0
Quote
Maybe I'm misunderstanding this but are you saying that your game already has "link length" ready to send out?


Nope, those has to be manually entered. But could it not be an option that if present have the rendererer use it instead of trying to calculate it? (or use a forced 1 length per default if the map send: do not auto calculate link length ?)

Quote
but that I'd rather not have this as the only way to generate the map


It was definitely looking for something optional. My minimap (ascii) is dynamically created, but I have mapped the whole mud in zmud, and I know some minimaps definitely look awful because of numerous magical mazes or stretched secret passages, non logical exit etx, though I have made those maps look quite fine when manually reordered (like how the builder created them to begin with)

If my memory is right zmud use a very simple database to store the info, so I could extract the info quite fast as well.

Quote
or maybe when they get near, mimicking a "line of sight" experience


How I see map in my game has nothing to do with line of sight. (that I can deal with my dynamically generated minimap that I could very quickly add in whatever format you would decide on) It is basically like a magical parchment that draws a map of every room you visited. So once you have been somewhere, you can just click on it and walk to it, wherever you are in the world. You can also share your map with friends so you get instant knowledge from someone else. It is a road map. Wont help you at all to how to avoid mobs or find keys to reach some places. Exactly like what someone would have done with a client automapper as a matter of fact.

That gives me an idea though: with two map plugins: one that is as updated eveytime the player moves, showing its 'line of sight', automatically calculated, and one that is updated only when a new room is visited. (with a still optionnal forced display format)
20 Sep, 2013, plamzi wrote in the 188th comment:
Votes: 0
Rarva.Riendf said:
That gives me an idea though: with two map plugins: one that is as updated eveytime the player moves, showing its 'line of sight', automatically calculated, and one that is updated only when a new room is visited. (with a still optionnal forced display format)


Well, the plugin will probably support both, but my guess is if you offer both to your players, few, if anyone, will choose the more limited option. Having both on at the same time seems redundant.
21 Sep, 2013, Runter wrote in the 189th comment:
Votes: 0
The mapper looks pretty good. I'm curious about what makes it vector based?
21 Sep, 2013, Rarva.Riendf wrote in the 190th comment:
Votes: 0
plamzi said:
Rarva.Riendf said:
That gives me an idea though: with two map plugins: one that is as updated eveytime the player moves, showing its 'line of sight', automatically calculated, and one that is updated only when a new room is visited. (with a still optionnal forced display format)


Well, the plugin will probably support both, but my guess is if you offer both to your players, few, if anyone, will choose the more limited option. Having both on at the same time seems redundant.


One would follow your position, one would stay static so you have a better view of an area (and can navigate in it independently of your position). Not the same goal. Difference is also in limiting the info you send.
You can send the full explored map only once at boot, and only update it if a new room is explored, and the minimap is send everytime the player moves.

But maybe you can combine the two thing with the plugin, I would need to know exactly what it can do to know if what I say makes sense :)
21 Sep, 2013, plamzi wrote in the 191st comment:
Votes: 0
Runter said:
The mapper looks pretty good. I'm curious about what makes it vector based?


The SVG. Powered by d3.

Rarva.Riendf said:
One would follow your position, one would stay static so you have a better view of an area (and can navigate in it independently of your position). Not the same goal.


The big map can move with your position as well as let you navigate it independently. It can be limited to render a smaller window, which effectively makes it a minimap. I'll let people preview how it works soon.

Rarva.Riendf said:
Difference is also in limiting the info you send. You can send the full explored map only once at boot, and only update it if a new room is explored, and the minimap is send everytime the player moves.


There's no need to send the fully explored map on every boot. You can upload an initial file, then send info on current player location only. If the room layout changes, you can send the new info when players re-enter those rooms–it will be merged into the client's flat-file world data.

If you don't upload an initial file, you can send current room + exits info as players move around. The mapper builds the world data file incrementally.
21 Sep, 2013, Rarva.Riendf wrote in the 192nd comment:
Votes: 0
Ok, guess I will get a better understanding on how it works once you put it live. It looks very nice as is, I am just wondering how I can use it to the best for my liking.
21 Sep, 2013, plamzi wrote in the 193rd comment:
Votes: 0
Latest screenshot, showing zoom and a larger area with some non-Euclidean room links.

21 Sep, 2013, Ripley wrote in the 194th comment:
Votes: 0
That looks really nice. Looking forward to getting going with that!
22 Sep, 2013, Runter wrote in the 195th comment:
Votes: 0
I think this is pretty impressive. Good work with that.
27 Sep, 2013, plamzi wrote in the 196th comment:
Votes: 0
Thanks for the encouragement, all. It helps a lot, especially when this much math is involved :)

I'm still dealing with some performance optimizations and working on big features I want this plugin to have from the get-go. But it's now good enough for people to see it in action and play with it:

http://www.mudportal.com/play?host=mud.p...

The "dev" parameter loads the mapper. The "debug" parameter enables more logging to the console. You will be able to see a lot of what's going on under the hood.

Charting new rooms and editing existing ones is enabled via a button on the toolbar. In edit mode, you can select rooms and move them. Ctrl+click selects a whole area.

Outside of edit mode, clicking on nearby rooms will move you there. Clicking on more remote rooms may fail silently (for now).

I'm disabling the save option for now until I get a basic system up for map data locking / sharing / cloning.

This is still alpha, so if your browser hangs, it's probably me. Open your Task Manager beforehand so you can kill me more easily. :)
02 Oct, 2013, plamzi wrote in the 197th comment:
Votes: 0
Now (at last) in Open Beta!

How to get started:
http://www.mudportal.com/forum/site-app-...

Preview of the edit / data upload menu:

09 Oct, 2013, Zeno wrote in the 198th comment:
Votes: 0
Do you have any RSS feeds I could use (like for new MUDs listed)?

I'd like to add the feed to https://twitter.com/MUD_news
10 Oct, 2013, plamzi wrote in the 199th comment:
Votes: 0
There's a pretty lean feed for new forum topics:

http://www.mudportal.com/forum/topics/mo...

Thanks for the add!
10 Oct, 2013, quixadhal wrote in the 200th comment:
Votes: 0
If your MUD is on the I3 network, Tricky has a few bots that post mud/sports/news/etc news to a particular channel, which you could easily use as well.

My log page *could* provide this, but it would be more efficient to do it from the channel logs directly, and also more reliable since mine is just on my home network (very little upstream bandwidth).
180.0/279