[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUDs
. -> [Folder]  General
. . -> [Subject]  Bringing MOO into the modern MUD world -- Help Wanted
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Bringing MOO into the modern MUD world -- Help Wanted
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1  2 

Posted by Sundsted   (1 post)  [Biography] bio
Date Thu 23 Feb 2012 11:54 AM (UTC)  [ quote  ]
Message
There was a discussion about integrating KaVir's code into LambdaMOO on the Moo Talk Google Group:

http://groups.google.com/group/MOO-talk/browse_thread/thread/619f8928a8699dc8/ab1bbaeaf0225b4d

It's out of band for what I can work into Stunt personally, but I'd be willing to help ensure that correct internal APIs were developed/used if possible, and that those APIs were maintained (or at least not gratuitously broken at some point in the future).

Todd


http://stunt.io/
[Go to top] top
Posted by Hawgpadre   (5 posts)  [Biography] bio
Date Wed 15 Feb 2012 08:17 PM (UTC)  [ quote  ]

Amended on Wed 15 Feb 2012 08:18 PM (UTC) by Hawgpadre

Message
Have you seen the LambdaMOO stunt patches? It's on github: https://github.com/toddsundsted/stunt

And has done a ton of modernizing. Would probably be a much better starting point than stock lambdamoo. It includes the primitive verb calls, maps, you mentioned.
[Go to top] top
Posted by Devmind   (2 posts)  [Biography] bio
Date Mon 09 Jan 2012 04:23 PM (UTC)  [ quote  ]
Message
PS: You can look at the code here: http://www.mudbytes.net/file-2811
[Go to top] top
Posted by Devmind   (2 posts)  [Biography] bio
Date Mon 09 Jan 2012 04:20 PM (UTC)  [ quote  ]
Message
Hello.

Are you guys still interested in modernizing LambdaMOO?

I suggest adding support for a handful of TelOpts and protocols becoming very popular in the MUDing community and being adopted by the developers of many text gaming clients. These additions would allow folks to script graphical interfaces using Lua and other languages within the frameworks of clients like Mudlet, MUSHClient, etc.

KaVir, a veteran coder and developer of GodWars, has put together a code snippet that handles all the telnet negotiation. It is a generic solution written in pure C, intended to be hooked into any telnet-based server. It includes TTYPE, NAWS, MSDP, ATCP, MSSP, MSP and MXP, as well as UTF-8 (using CHARSET) and XTerm 256 colors.

Is anyone interested in folding KaVir's code into the LambdaMOO server? I think it would open whole new directions to MOO developers and attract an audience of developers who wouldn't otherwise give MOO a look.

Thanks.

-DM
[Go to top] top
Posted by Sproingie   USA  (8 posts)  [Biography] bio
Date Fri 12 Mar 2010 11:59 PM (UTC)  [ quote  ]
Message
I tried kdevelop and committed the project files for it, but I haven't been particularly happy with it, so I'm just using emacs with flymake.

As for legitimacy, you make a good point, though I might just decide to name it something other than "MOO" if it gets that drastically incompatible. Anyway, it's hardly all that relevant to development -- I just happen to be making a MUD codebase that starts from MOO as a base.

And I certainly don't want to replace the prototype-based system with class/object, far from it. What I want to do is unify waifs into the prototype system and lose the distinction that is starting to emerge. I think a consequence of this is that objects would have to become reference counted, which would result in a performance hit. I don't think the performance hit would be that bad anyway: MOO already throws strings and lists all over the place and those are refcounted.

Now that I have more time to put a post together, here's some other wild ideas I've had, not all of which are necessarily *good* ideas I might add:


  • Use berkeley db for the database format. Flush "idle" objects to the db to compact the heap. From a performance POV, it's probably a wash; while MOO's memory use is unlikely to strain any modern machine, some MOO workloads do fragment the hell out of the heap, so being able to move objects around on the heap as would be needed for such a system would be a bonus.

  • Use something even more exotic for the db format, like Cassandra. I can't think of an immediate use for this, since MOO data tends to be much more intertangled and coupled than most MUDs with generic and limited area/mob formats.

  • Verb calls on non-objects, ala ruby and to some lesser degree python. Could get rid of most $list_utils/$string_utils stuff. However, I don't want them hardwired and becoming a junk-drawer of one-off functions, so it would still dispatch to softcode. The question is, what do I assign as the handler? A server option comes to mind. It also really cuts into type-safety if everything can have verbs.

  • Generators. Would probably not even be all that hard, since MOO already has coroutines. One problem though is that they would introduce implicit suspends, and most MOO code tends to rely on the need for explicit suspend to have proper concurrency behavior. I don't want to complicate the concurrency picture that much, but I am going to have to come up with something, like maybe critical sections where suspends are disallowed.

  • Some kind of list comprehension syntax. Python's syntax is appealing because it wouldn't introduce any new keywords. I'm also considering something more like LINQ, which would allow people to expand it in softcode (just implement the "SelectMany" equivalent)

  • A mapping type. This isn't even controversial, I want the damn things. If I can make objects lightweight enough, I could use them for mappings (given some kind of "expando" property allowing one to add properties on the fly). Main problem there is objects have pass-by-reference semantics, and I really prefer keeping the pass-by-value semantics of MOO's "primitive" types -- it's something that really sets it apart. Then again I could also consider copy-on-write objects!

  • First-class verbs as a type. "foo:bar" would create a verbref type, that you could pass around and call with function syntax. Not actually too hard, since internally they're pretty well encapsulated already. It makes security somewhat trickier to reason about though, since neither the receiver nor the verb name are obvious anymore when your code gets handed an arbitrary verbref. It's not inherently dangerous, but it does limit their generality a little bit.
[Go to top] top
Posted by Lockewarrior   USA  (9 posts)  [Biography] bio
Date Thu 11 Mar 2010 04:24 AM (UTC)  [ quote  ]
Message
You're using kdevelop?? :(

I'm checking it out. Wow, it has been AGES since I've worked with Lambda, heh.

To comment quickly on your points:

-Unicode: Good freakin' idea, heh.

-Performance/JIT: I'm inclined to go the JIT route, but I'm totally unfamiliar with what has already been implemented. Lisp provided a 'compile' function, enabling the user to specifically declare items to be compiled. I -really- like that. I also really need to examine this branch a bit before I have anything relevant to add.

Legitimacy: Who cares? People argue all day and night about what is a MUD/is a MOO/is a MUSH/waste of time. I don't think making it incompatible with an existing core disqualifies it as a MOO. It makes older MOO cores outdated, that's all. :)

You would PREFER a classic class/object approach over MOO's already 'elegant' prototypes?
[Go to top] top
Posted by Sproingie   USA  (8 posts)  [Biography] bio
Date Mon 08 Mar 2010 09:58 PM (UTC)  [ quote  ]

Amended on Mon 08 Mar 2010 10:06 PM (UTC) by Sproingie

Message
I've nothing live in the sense of a running server that corresponds to my project, no. Right now I'm merely doing a little "gardening" on the MOO codebase and have it up on github at http://github.com/sproingie/NuMOO

It's not really in any shape where I would want to claim credit, all I've done so far is take Codepoint (the most mature branch) and *remove* some features in order to make it easier to add new ones. I've held off on massive breaking changes until I get a coherent vision for what I want in a new server before I go breaking compatibility.

Some of the goals I want to address:

  • Unicode. Codepoint thankfully does support unicode already, but I'm unsure how mature the support really is. It certainly doesn't expose much functionality to the user. GammaMOO does have more user-accessable unicode functionality, but I know its unicode support is extremely brittle and immature. One related issue is that MOO may have to become case-sensitive by default, which would be an incredibly incompatible change, but I think it's naive to do what it does now and only case-fold within the ASCII range (not even iso-latin!)

  • Performance. MOO would benefit most from JIT, which unfortunately is an area I have absolutely no experience in. Barring that, more aggressive optimizations could be employed in the VM, which would involve storing a program that doesn't necessarily unparse back to the original source code. Making the stored program representation more flexible would of course make a later JIT much easier.

  • Legacy removal. The built-in parser is antiquated and inadequate and can be emulated with softcode anyway. These removals would simplify a lot of things, though it would also render it incompatible with any existing core. Is a MOO that could never run LambdaMOO or Waterpoint still legitimately a MOO server?

  • Language and builtin function changes. It's the lowest-hanging fruit, adding a ton of new builtins and cool language features. I prefer to take a conservative approach there, one that wouldn't alter MOO's fundamental character of pass-by-value/copy-on-write everywhere. Obviously some kind of mapping type is first on the agenda as language changes go. Getting more advanced, things like closures and first-class functions turn out to be really interesting problems in a multi-user environment (emphasis unfortunately on "problem", especially with respect to things like security)

  • Fundamental model changes. The Waterpoint folks already started down a path of turning MOO's elegant prototype-based object model into something more hybridized with classic class/object with the introduction of waifs. Now waifs are certainly handy for what they do, but I really don't want to continue the duality if I don't have to. I've been looking at one of MOO's "spiritual ancestors", namely the Self language for inspiration, but I think unless I'm as ingenious as they were when it comes to JIT (the Self JIT was basically the prototype for Java's HotSpot JIT) I haven't a prayer of porting most of its ideas.


[Go to top] top
Posted by Lockewarrior   USA  (9 posts)  [Biography] bio
Date Sun 07 Mar 2010 03:46 PM (UTC)  [ quote  ]
Message
Hey Sproingie,

When I first started playing, I spent a bunch of time on Lambda and really, really liked developing on MOOs. I don't remember everything I liked about them, but I do know that tinkering and playing with a MOO on my own local machine was the start of my interest in programming period.

There came a point where there was 'x' feature I wanted that just wasn't in MOO, and I knew I wasn't the one who was going to put it in. I needed to learn a lot more about coding and so I started playing with newer, more modern MUD codebases.

I would absolutely LOVE to see a project geared towards overhauling a MOO, bringing it up to performance standard, and taking feature development in new directions. I would also love to get involved in such a project.

Do you have anything live? I'm definitely interested in more information on this project.

I'll look for your posts, though my e-mail address is public and I use lockewarrior for AIM, and lockewarrior@gmail.com for MSN.

See yah' around.
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Sun 28 Feb 2010 07:15 PM (UTC)  [ quote  ]
Message
I don't think the keybindings work in notepad windows, so I think the answer is "no".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Sproingie   USA  (8 posts)  [Biography] bio
Date Sun 28 Feb 2010 06:21 PM (UTC)  [ quote  ]
Message
The specific problem I'm trying to solve is getting MOO to optionally speak to existing clients that use telnet options without necessarily requiring the major gyrations it takes to switch an existing client to and from binary mode. Tunnelling MCP through it would just be a bonus.

As for doing MCP in MUSHClient, I'll be doing that too. I did have one question: is it possible to define new keybindings for just notepad windows? I'm used to having F7 be the "submit" key for local editing forms in vmoo and tkmoo, but it's a bit more involved in MCP than just sending the text verbatim to the MOO.
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Sat 27 Feb 2010 05:24 AM (UTC)  [ quote  ]
Message
Sproingie said:

Actually, I'm not entirely clear as to whether this Lua protocol (what's it called anyway?), or others like it are intended to be bi-directional, or are they strictly server->client?


I don't think it has a name yet. Perhaps I should have a competition?

My current implementation is in both directions, however for simplicity the client to server direction is simpler.

As for MCP, from what I read so far it is normal text that you could write a few triggers for (and omit from output) if you wanted.

Sproingie said:

Are servers usually set up to understand telnet sequences coming from the client?


From what I saw in SmaugFUSS, no they are not. I spent a morning rewriting the low-level interface to handle that. However that is now on public record, so there is no reason others can't incorporate it.

As for the rest, before we get too bogged down in what the protocol is, I think you need to work out: what is the problem you are trying to solve? In my case I wanted to send down mapping information (eg. a list of exits), and receive (from the client) what room number we wanted information about. The requirements of the problem dictated the design of the solution, somewhat.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Sproingie   USA  (8 posts)  [Biography] bio
Date Sat 27 Feb 2010 05:08 AM (UTC)  [ quote  ]
Message
Sending to the client is pretty trivial -- I'm referring to what would get called when the client sends such a sequence to the server. Actually, I'm not entirely clear as to whether this Lua protocol (what's it called anyway?), or others like it are intended to be bi-directional, or are they strictly server->client?

Right now MOO's answer to side-channel chatter with the client is to use the "out of band" prefix it defines, and usually the MCP protocol on top of that. I noticed that every few years the question of MCP support in MUSHClient comes up, though it does look like if I want it, I'm going to have to write it myself. Now I think the power and flexibility of MCP is pretty much dandy, but I would like to make it more transport-independent. Using telnet subnegotiations to transport this side-channel might do the trick. Are servers usually set up to understand telnet sequences coming from the client?
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Sat 27 Feb 2010 02:14 AM (UTC)  [ quote  ]
Message
You mean server to client? You could do that, although in my implentation I just did sprintf's where I wanted and put the IAC SB 102 and IAC SE in the printf myself.

Note the requirement for strings, where you need to add a backslash before quotes etc.

In my implementation I did *not* add Lua processing to the server end (the SmaugFuss), instead keeping the client to server protocol very simple (however, still valid Lua).

In particular, in the client to server end the messages looked like this:


obj_info = "23432"


Then I just parsed that with a simple sscanf in C. That kept the server end simple.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Sproingie   USA  (8 posts)  [Biography] bio
Date Sat 27 Feb 2010 01:19 AM (UTC)  [ quote  ]
Message
I did read that thread and quite a few others, before registering and posting. I'm concerned about that protocol specifically, since it seems to require the ability to parse and execute arbitrary Lua code. I can take my concerns to that thread though.

Since this lua protocol, ZMP, and ATCP all seem to follow the same IAC SB protocol# arbitrary-data IAC SE pattern, maybe I should just route any data in such sequences to, say, #0:do_telnet_subnegotiation()?

[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Sat 27 Feb 2010 12:01 AM (UTC)  [ quote  ]
Message
Sounds interesting. It is vaguely related to a project of mine here:

Template:post=10043 Please see the forum thread: http://gammon.com.au/forum/?id=10043.


Related in the sense that modern servers (and modern clients) have a lot more power than when MUDs (and MOOs etc.) were first invented, so maybe we should put that power to use.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

5,629 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]