Mudlet - Forum

We used to have it back in the starting days, though. Mudlet actually used Webkit for display - so MUD output could be styled with CSS even.

It was terribly slow though; the wilderness map actually froze you for 1-2s. Then we used a standard text display widget, but it wasn't fast enough - so now heiko wrote a custom one, which beats most terminals even in display speed.

Yeah, I remember back in the day when Mudlet came out saying "You're going to be able to use stardard HTML and CSS to output to the screen!"

I always wondered about that...

Yeah... definitely was true at that point. Turned out to be horribly inefficient.

(the Flash MUD client strips all background colors from the wilderness as well. Although they just claim not to support them, imho if they did, since flash embeds webkit, they'd have the horrific performance as well. It's also why I'm not in the hype for html5 mud clients).

so tell me more about what you are proposing, then. Standardized XML tagging to be interpreted via pre-hypertext processor, and via lua scripting for uniform layout?

Are you still using WebKit for the output display??

IE: The output displays HTML colors, correct? How are those parsed?

If not, then writing a simple HTML engine with support for just the basic content management shouldn't be too difficult.

tsuujin wrote:so tell me more about what you are proposing, then. Standardized XML tagging to be interpreted via pre-hypertext processor, and via lua scripting for uniform layout?

Right.

For example, if I have this raw input data:
I'll get the HTML out of it: ... and the following Mudlet code for the display:
Or perhaps just this, because for links we'll need to use echoLink:

Playing around with it some, maybe just using labels will go. We do lose the clickable links though, but I'll see if there's anything that can be done around having them call lua code upon being clicked or somesuch.

This seems pretty simple, really. The problem I see comes in using a standardized layout that everyone agrees on. Because of the limitations of using text output on the Mudlet side, you're really going to be limited to linear menus. If you wanted images, you'd need to implement a caching system within Mudlet that would either pre-fetch (which I wouldn't be a fan of) or load and destroy on usage for memory concerns.

Outside of that, the tagging should be straight-forward. PHP could easily handle the preprocessing to turn that tagging into valid HTML.

I don't see any reason to use labels, frankly. Clickable links would make or break the usability of this system.

We can't use images inside the main display. At most, inside a label.

I wasn't thinking about images, didn't really need them in the documentation system I already have tbh.

Not sure about PHP because I'm not familiar with it - making this in Lua would make most sense. The content will be static once made.

Well, if the intention is to have this be loaded by Mudlet for display in the client, and use a website for display outside of the client, you're going to have to store the file externally and load it in (which is not a problem with Lua).

In order to get it to display as a webpage, you're going to need it to be interpreted. Lua can't be used for this, so you're going to want to use a prehypertext processor such as JSP, ASP, or PHP. PHP is both very simple to use and incredibly powerful, so that would be my suggestion. It'll do the exact same thing as the Lua conversion algorithm, breaking the file down into parts and converting it to usable HTML.

Unless you're thinking about editing the file, using an external program to generate alternate scripts, and loading those scripts manually into a web server or Mudlet. Which makes no sense to me. Should be on-the-fly.