27 Nov, 2013, Odoth wrote in the 1st comment:
Votes: 0
I work on a ROM based MUD which has support for mudFTP (which nobody uses or has used as far as I know since the inception of the MUD).

So I went in search of a mudFTP client to give it a shot and see if it was worth trying to use. The concept of editing descriptions and other strings in a graphical editor then sending it back to the MUD is quite appealing. The first obstacle was not being able to find a working mudFTP client. Erwin's page is dead (http://www.andreasen.org/mudftp/) as well as (http://www.abandoned.org/drylock/mudftp/).

Finally I found this one: http://lost-realms.org/import/MUDFTP.EXE
It actually seemed to be working for the most part until the mud crashed unexpectedly (presumably from mudFTP since it is otherwise very stable).

I am curious, do people use mudFTP anymore? Why can't I find much documentation or any discussion on it? Is there a general opinion that it is good/bad/useless/pointless or anything else?
27 Nov, 2013, Scandum wrote in the 2nd comment:
Votes: 0
There is MSDP and GMCP for this purpose nowadays.
27 Nov, 2013, quixadhal wrote in the 3rd comment:
Votes: 0
Many LPMUD mudlibs have normal FTP servers in them (coded in LPC, implementing PASV mode). No need for bizzaro custom hacks that are only known to the MUD world.
27 Nov, 2013, Vigud wrote in the 4th comment:
Votes: 0
I think one of modern approaches to this aspect of MUD world creation would be something like the game server acting as an HTTPS server, letting only authorized people (perhaps as a part of wider RBAC-like scheme) edit game objects through an HTML5 world editor, storing all changes in a Mercurial repository.
28 Nov, 2013, Nathan wrote in the 5th comment:
Votes: 0
archive.org, dude!

https://web.archive.org/web/201210300715...

quixadhal said:
Many LPMUD mudlibs have normal FTP servers in them (coded in LPC, implementing PASV mode). No need for bizzaro custom hacks that are only known to the MUD world.


It sounds like he's looking for a way to edit strings, which if you don't have them all stored in one file would be a pain in FTP. Although if you run on a custom port and whatnot just for sending strings, you might as well just have a full build only version of the server or some kind of editing interface there.

Vigud said:
I think one of modern approaches to this aspect of MUD world creation would be something like the game server acting as an HTTPS server, letting only authorized people (perhaps as a part of wider RBAC-like scheme) edit game objects through an HTML5 world editor, storing all changes in a Mercurial repository.


With the right file permissions utilizing something like .htaccess would be easy for a small group of people. Don't see why you'd need HTML5 unless you just mean HTML in general/and or using the latest form.
28 Nov, 2013, quixadhal wrote in the 6th comment:
Votes: 0
Nathan said:
quixadhal said:
Many LPMUD mudlibs have normal FTP servers in them (coded in LPC, implementing PASV mode). No need for bizzaro custom hacks that are only known to the MUD world.


It sounds like he's looking for a way to edit strings, which if you don't have them all stored in one file would be a pain in FTP. Although if you run on a custom port and whatnot just for sending strings, you might as well just have a full build only version of the server or some kind of editing interface there.


It's easy enough to do in most LPC mudlibs. While most things in an LP are individual files (orc.c is how you make an orc), you can easily use the virtual file system to allow direct string editing. Basically, whenever an access request is made on a pathname, the virtual system has a chance to intercept it and return an object (or whatever) based on the pathname. If it doesn't match anything known, it hands it off to the real file access system.

So, if you wanted to edit a player's description, you could (in theory) define it so accessing "file" "player.quixadhal.long_description" would make a "file" in the FTP area containing that text, and when the file was "written" back, it would reverse the procedure. From the point of view of a normal FTP client, you'd just see a directory sturcture that'd look like "/virtual/player/quixadhal/long_description.txt".

Off topic: I think a LOT of mud people who are used to working with Dikurivatives just flat out fail to understand what an LPMUD really is, because it's such a different working environment. I've found it's pretty common for them to assume LPC is just a fancy kind of "mobprog", and dismiss it out of hand for that reason.
28 Nov, 2013, Vigud wrote in the 7th comment:
Votes: 0
Nathan said:
Vigud said:
I think one of modern approaches to this aspect of MUD world creation would be something like the game server acting as an HTTPS server, letting only authorized people (perhaps as a part of wider RBAC-like scheme) edit game objects through an HTML5 world editor, storing all changes in a Mercurial repository.


With the right file permissions utilizing something like .htaccess would be easy for a small group of people. Don't see why you'd need HTML5 unless you just mean HTML in general/and or using the latest form.
I failed to properly describe my idea. What I have in mind is a fully fledged area editor, with multiple modal and non-modal windows, fancy widgets and whatever you think an area editor needs. Similar to the native Windows 95/98 applications you have probably used, if you were creating Diku/Envy/Merc areas around that time (I'm not aware of any other software like that; it's just an example). The application I'm imagining would be served as HTML5 app over HTTPS by the same program that acts as the game server. So .htaccess files wouldn't be the right tool for access control, since you would need to make apache httpd utilize those.

I chose HTML5 because it's easy to simulate native applications with HTML5, and it would seem to be quite future-proof, which is rather crucial for any MUD.
28 Nov, 2013, quixadhal wrote in the 8th comment:
Votes: 0
My area editor was always a pad of graph paper and /usr/bin/vi. :)
29 Nov, 2013, Nathan wrote in the 9th comment:
Votes: 0
Vigud said:
Nathan said:
Vigud said:
I think one of modern approaches to this aspect of MUD world creation would be something like the game server acting as an HTTPS server, letting only authorized people (perhaps as a part of wider RBAC-like scheme) edit game objects through an HTML5 world editor, storing all changes in a Mercurial repository.


With the right file permissions utilizing something like .htaccess would be easy for a small group of people. Don't see why you'd need HTML5 unless you just mean HTML in general/and or using the latest form.
I failed to properly describe my idea. What I have in mind is a fully fledged area editor, with multiple modal and non-modal windows, fancy widgets and whatever you think an area editor needs. Similar to the native Windows 95/98 applications you have probably used, if you were creating Diku/Envy/Merc areas around that time (I'm not aware of any other software like that; it's just an example). The application I'm imagining would be served as HTML5 app over HTTPS by the same program that acts as the game server. So .htaccess files wouldn't be the right tool for access control, since you would need to make apache httpd utilize those.

I chose HTML5 because it's easy to simulate native applications with HTML5, and it would seem to be quite future-proof, which is rather crucial for any MUD.


I was just pointing out that a fairly simple web form could be used to accomplish similar results, not that it's the only or best way. If you did that way, then you could use simple web server based access permissions. If you're going to make a fully fledged area editor you might as well tie it in to either the actual area file or the game server itself (direct editing). Non-modal windows seems completely unnecessary, although some dialogs might be need for yes/no or ok/cancel situations to confirm decisions.
03 Dec, 2013, Nathan wrote in the 10th comment:
Votes: 0
Lampost mud – https://lampostmud.org/ngclient/lampost.... which is a demo of sorts for it's codebase (as far as I can tell) has a pretty snazzy online web-based building interface (see the creator demo where you can test that out – since there are two instances running). It's not super detailed, but it does the job for standard editing and is pretty easy to work with. Might be useful as a reference/example for/of what can be done.
0.0/10