Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dworkin

Pages: 1 [2] 3
My planned Technology Stack (likely DGD based):
  • OS - Host Server(s) (ie Linux, Windows Server, etc ...)
  • Driver (VM Sandbox, Compiler, Security, Services, ...)
  • Driver Extension(s) (3rd Party MudLIB Optimizations)
  • MudLIB(s) (Game Methods, Mechanics, & Models)
  • Story OBJs (Actors, Settings, Events, & Context)
  • Interface (Client Tools such as Telnet, TinTin++, Adaptive Tech)
  • Player (Total Wetware Interactive eXperience -Silly rabbit, TWIX is for Kids!)

I am of course flattered that you would consider using DGD for your project. I have one suggestion:

Put the interface at level 3, not level 6, and take the technological developments of the last 20 years into account.  Nobody wants to use telnet anymore; not even when it runs as an app on a web page.

Promotions / Re: New LPC driver at
« on: August 18, 2011, 06:48:42 pm »
When do you expect the feature set to be stable enough to release the source code?  I guess you would have said if you knew, but I had to ask :)

Are you aiming for backward compatibility with a particular existing LPC dialect?

Drivers / Re: FluffOS feature requests for 2.23+
« on: June 16, 2011, 01:31:02 pm »
Y'know, I had this guy who used to code for me hack some version or another of MudOS so that classes actually were functional lightweight objects, doing so Perl-style -- designating an object where the methods for the class lived.  He said it was pretty easy.  I could've sworn he said he submitted patches for it, too.  You guys might want to look into that.

I know this guy who rewrote some version or another of LPmud, and implemented actual light-weight objects.  But his server is quite obscure, and few people would consider using it.

Copy-on-write for arrays and mappings doesn't suit LPC, especially considering that classes in FluffOS and light-weight objects in DGD are implemented on top of arrays, too.  The drawback is that with reference-counting garbage collection, self-referential structures need special treatment to be freed from memory.

For DGD, there is a twist: all data is local to objects, and if some array or mapping or light-weight object is shared between objects at the end of a task, each object will get its own unique copy.  The structure of the data will be preserved in each copy, including self-references.

Who knows exactly which LP drivers use copy-on-write or some other mechanism to break pointer behavior with respect to mappings and/or arrays?

No offense, but if your muddled posting offers the best rationale for whatever it is you are arguing for, it would lead me to consider copy-on-write as a fix right now ;)

The answer to what I believe to be your question is: none.

Drivers / Re: Hydra 1.2
« on: March 20, 2011, 06:03:36 am »
Thanks, I took a quick glance at that link.  You can see the classic lp resemblance. Is the difference between hydra and DGD is that hydra is more scalable and can use multiple machines (distributive) at the same time to power library up?

Hydra is more scalable because it will use multiple CPUs, but it is not distributed and it is not designed to be.  Of course, one could still use it in a distributed setup, but in that case it would be distributed at the LPC level, not below.

Drivers / Re: Hydra 1.2
« on: March 18, 2011, 05:42:54 am »
Would be nice to hire some coder of Elance to port Lima to Hydra.

You might want to take a look at A git version of the repository can be found here:

General / Re: Pike: what's the deal?
« on: October 05, 2010, 05:05:39 am »
I would love to know the status of any such Pike or related framework projects anyone might know of or be working on. We are looking to collaborate, learn, or just discuss. Many thanks!

You might also want to take a look at DGD, which was released under an open source license earlier this year.

Drivers / Re: Hydra 1.2
« on: September 14, 2010, 07:47:31 am »
Sounds like a great achievement.  Do you have any interested parties lined up to license it?  I would have assumed that Skotos, and licensing of MUD-related engines in general, was no longer a viable area.

Nobody yet.  :)

Would you consider World of Warcraft "MUD-related"?  That's the sort of game that Hydra is aimed at. And of course, LPC is just a programming language, and not especially tied to MUDs, or even games.

Drivers / Hydra 1.2
« on: September 13, 2010, 06:14:48 pm »
I have just released Hydra 1.2, the culmination of about 10 years of work.

Hydra is compatible with DGD, but uses all available processor cores to speed up operation, while simulating DGD's single-threaded behaviour. Hydra is intended for very large online games.  It runs on Linux/i386, Linux/powerpc, Linux/s390, Solaris/i386, Mac OS X and Windows.

While DGD is open source, Hydra is distributed in executable form only. It can be downloaded from

General / Re: heart_beat v. call_out
« on: April 22, 2010, 09:06:57 pm »
One thing I've found is that call_out as a mechanism is really very poorly suited to cyclic, rather than one-time, usage, and because of the way it's structured, the more heavily you use it for cyclic calls, the more inefficient it gets.

That is however an implementation matter. There is nothing inherently costly about callouts as such. In DGD, there are no heartbeats, and all the operations needed to simulate them are O(1).

Dead Souls Support / Haiti Mud
« on: February 27, 2010, 05:29:12 am »
You'd be setting up an economy where the natural outcome is complete devastation. Players would compete for plants because they represent wealth. A few of them would corner the market; the more plant species they wiped out, the richer they'd be. Griefers would simply destroy without bothering to profit. Your mud would be dirt-poor (mud-poor?) and, after a few seasons, potionless.

Drivers / Re: DGD 1.4 Open Source Release
« on: February 04, 2010, 11:51:35 am »
A DGD function pointer is a two-element array with an object in the first element and a method name in the second. :)

Better yet, a light-weight object holding those.

Drivers / Re: DGD 1.4 Open Source Release
« on: February 04, 2010, 08:18:56 am »
If someone has FluffOS compatibility code for DGD, I have a fairly large mud I'd like to try on it :)

In the past, most attempts to write a compatibility layer have floundered because they were written in LPC.  Closures and function pointers are not so easy to emulate.  But here is one such layer:

Drivers / Re: DGD 1.4 Open Source Release
« on: February 03, 2010, 02:11:49 pm »
Correction: it appears that Google doesn't like the AGPL.  Weird.

Site changed to:

Pages: 1 [2] 3