10 Sep, 2013, quixadhal wrote in the 161st comment:
Votes: 0
If you want to test full ANSI/curses support, telnet to nethack.alt.org and watch someone playing a game (or play one yourself).

If your MUD client supports that, it should handle almost everything. :)
10 Sep, 2013, plamzi wrote in the 162nd comment:
Votes: 0
quixadhal said:
If you want to test full ANSI/curses support, telnet to nethack.alt.org and watch someone playing a game (or play one yourself).

If your MUD client supports that, it should handle almost everything. :)


Hehe, it's refusing to talk to me after the initial set of negotiations.

I watched a game using putty. Seems like there's a lot going on with line redrawing and cursor positioning. Quite different from a MUD.

On an unrelated topic, does anyone know of a game that uses MXP custom windows and redirects output to them?
10 Sep, 2013, quixadhal wrote in the 163rd comment:
Votes: 0
Quite different from the normal MUD, yes. :)

As a roguelike, nethack uses the curses toolkit for full-screen manipultion using whatever the terminal claims it is capable of. Thus, if you're writing a MUD client which claims ANSI or VT100 emulation, it really should be able to handle what nethack throws at it.

I figured you'd want to use it both as a test suite, and as an idea for the future… since while I don't know of any MUD's which currently use curses, it seems like a direction some games might choose to go to offer better control over the user interface. Historically, the only issue that's kept this from happening has been the difficulty of using curses in a multi-threaded environment. (Original curses used a lot of global state info, there are now thread-safe versions).
10 Sep, 2013, plamzi wrote in the 164th comment:
Votes: 0
quixadhal said:
Quite different from the normal MUD, yes. :)

As a roguelike, nethack uses the curses toolkit for full-screen manipultion using whatever the terminal claims it is capable of. Thus, if you're writing a MUD client which claims ANSI or VT100 emulation, it really should be able to handle what nethack throws at it.

I figured you'd want to use it both as a test suite, and as an idea for the future… since while I don't know of any MUD's which currently use curses, it seems like a direction some games might choose to go to offer better control over the user interface. Historically, the only issue that's kept this from happening has been the difficulty of using curses in a multi-threaded environment. (Original curses used a lot of global state info, there are now thread-safe versions).


VT100 is not my goal, and I'm not going to claim full ANSI support, either.

My goal with the portal app is to actually get people to think "browser game" more than "a full-featured telnet terminal in your browser" :)

It seems to me that if someone wants to be able to draw and redraw on a 2D grid, there are now much easier, and may I add more beautiful, ways. Hence, my question about MXP custom windows. I imagine I can allow people to spawn their own automap, e. g., in a few hours of coding.

That said, the portal app would be pretty solid foundation if someone wanted to add ANSI cursor and VT100 support for their game. But it ain't gonna be me.
11 Sep, 2013, plamzi wrote in the 165th comment:
Votes: 0
And now for something very subtle but very important:

For authenticated users, the web app will remember window positions and dimensions. The layout is unique not only to a given server & port, but also to a given browser window size (so you can have a different layout on your laptop vs. your desktop).

This should be automagic. If it ain't, report it on the TMP support forum.
11 Sep, 2013, donky wrote in the 166th comment:
Votes: 0
quixadhal said:
I figured you'd want to use it both as a test suite, and as an idea for the future… since while I don't know of any MUD's which currently use curses, it seems like a direction some games might choose to go to offer better control over the user interface. Historically, the only issue that's kept this from happening has been the difficulty of using curses in a multi-threaded environment. (Original curses used a lot of global state info, there are now thread-safe versions).

There's also the issue that curses isn't really a valid solution on Windows last time I looked. I have a Windows-based "roguelike MUD" code base which I've posted about here in the past, and I gave up on it in the end due to the issues with client support. If it had been possible to use curses, I imagine that things might have been somewhat more productive.
11 Sep, 2013, Scandum wrote in the 167th comment:
Votes: 0
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.
12 Sep, 2013, plamzi wrote in the 168th comment:
Votes: 0
I'll take a look, thanks.
13 Sep, 2013, Zeno wrote in the 169th comment:
Votes: 0
I look forward to the future of the site, and I think I'm going to start pushing it on my players who don't know MUDs. Hopefully I'll get time to customize it with the plugins.

A bit of feedback: The site seems fairly slow on loading pages, etc. I doubt it's the server, it's probably Joomla-heavy. Have you tried turning on caching or considered something like CloudFlare? It looks like it takes 6 full seconds to load the home.... For example, MudBytes takes about 2sec to load.
13 Sep, 2013, plamzi wrote in the 170th comment:
Votes: 0
Zeno said:
I look forward to the future of the site, and I think I'm going to start pushing it on my players who don't know MUDs. Hopefully I'll get time to customize it with the plugins.

A bit of feedback: The site seems fairly slow on loading pages, etc. I doubt it's the server, it's probably Joomla-heavy. Have you tried turning on caching or considered something like CloudFlare? It looks like it takes 6 full seconds to load the home.... For example, MudBytes takes about 2sec to load.


It's hard to compete with the MudBytes front page when your background JPG alone is larger :) But I shaved off more than 2 seconds by removing the carousel rotating through all the game banners. I might bring it back in an abridged form because it was looking good.

Anyway, Joomla is not the issue, and server-side caching doesn't help when you have so many images. Joomla enabled me to put together a site in less than a week that would have taken maybe a year…
14 Sep, 2013, Zeno wrote in the 171st comment:
Votes: 0
Oh, I agree with using Joomla; I've worked with it for about 6 years. But it can end up bloated if not managed properly is just what I meant; sometimes I run into 3rd party addons that are horribly optimized and I don't notice it for a while.

Speed feels good now, thanks!
19 Sep, 2013, plamzi wrote in the 172nd comment:
Votes: 0
And now, for something completely different. A sneak preview of the new vector-based mapper:

19 Sep, 2013, Skol wrote in the 173rd comment:
Votes: 0
I now have vector-envy :p
19 Sep, 2013, arholly wrote in the 174th comment:
Votes: 0
neat
19 Sep, 2013, Rarva.Riendf wrote in the 175th comment:
Votes: 0
How does the mud send the map info ? msdp support ?
19 Sep, 2013, plamzi wrote in the 176th comment:
Votes: 0
Right now it's from an Aardwolf-spec'ed GMCP room.info data. But adjusting it to read from MSDP or MXP should be trivial.

The part that won't be trivial is coming up with something sufficiently flexible to map a game that doesn't send any location info other than what is player-visible…
20 Sep, 2013, Rarva.Riendf wrote in the 177th comment:
Votes: 0
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'.
20 Sep, 2013, Runter wrote in the 178th comment:
Votes: 0
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".
20 Sep, 2013, Ripley wrote in the 179th comment:
Votes: 0
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! :)

Please provide the msdp data structure so that I can add it to Luminari! The vector mapper looks REALLY good.
20 Sep, 2013, quixadhal wrote in the 180th comment:
Votes: 0
Of course, as I've said before, if you're going to go to the effort of cobbling custom tags into your code for a client, why not just do it the right way and send full data structures (JSON, XML, etc) that the client can just use rather than have to parse?

It's not hard to set up a second port and serve this kind of structured data on that port, while clinging to the pre-formatted ansi/mxp/telnet stuff on the "normal" port.
160.0/279