[Michiel]

The Grendel Project is an attempt at creating a solid, fast, and stable MUD codebase, that runs natively on Windows(preferred platform) and Linux. Operational features include ipv6 support, plugin architecture, enhanced scripting, copyover, and numerous other features.

To be able to compete with other MUD engines available today, Grendel needs some serious work. For this, we need help. Currently, we need some experienced Delphi developers, and a number of enthousiasts willing to work on the documentation.

If you are interested in joining the Grendel Project, please send a mail to michiel@grendelproject.nl.

Thank you for your time!

Regards,

Michiel Rook

[Michiel]

Nobody? Open issues are fixing a number of bugs to facilitate a maintenance release of the current version, and adding new features, XML integration, documentation, sample areas and content, and much more.

Delphi coders, builders, and other enthousiasts are very welcome and encouraged to contact me and join the development team.

Thanks.

[KaVir]

Just some brief comments:

1. Within your credits.txt file, you state "Parts based on Smaug, ( c ) Derek Snider and Emlen, ( c ) Owen Emlen".  If your mud contains parts of Smaug, then that makes it a Diku/Merc/Smaug derivative, bound by all appropriate licenses.  Indeed there are many obvious similarities with the Diku code, despite the language translation.

2. You repeatedly use "( c )" as a copyright notice.  However "( c )" is not legally recognised - you should use "Copyright", or ©.

3. Windows is generally a poor choice for running a mud.  Not only does it suffer from stability issues, but it also makes it much more difficult to find hosting.

[Stilton]

KaVir:

Originally Posted by 3. Windows is generally a poor choice for running a mud. Not only does it suffer from stability issues, but it also makes it much more difficult to find hosting.

Only if you need to do it commercially rather than run it on your own box. At the very low-cost level nix hosting is available much cheaper than nix (small account on a shared machine). Once you're on a dedicated machine, hosting costs aren't THAT bad for Windows. I'm not sure how much the platform stability argument counts for these days. How many active muds go for so long without code changes that the difference between uptime for Windows vs nix really matters? (remember that he's proposing a Smaug derivative, not a fully scripted MUSH with sockets hardcoded but not much else)

Windows does have the advantage of native async socket support without having to worry about threading issues (yes, various *nix's have their own flavors, but they seem to be in flux, while the Windows implementation has been usable and stable for what, 10 years now?). This could be a very big plus for a first-time developer.

The biggest problem I see is Delphi- it's just not that common, making recruitment harder.

Stilton

[KaVir]

Originally Posted by Only if you need to do it commercially rather than run it on your own box.

True, but that seems to be the route that most muds take - sharing with other muds on a unix-style platform. And remember, this is supposed to be a public codebase, aimed at a wide audience of potential mud owners.

Originally Posted by I'm not sure how much the platform stability argument counts for these days. How many active muds go for so long without code changes that the difference between uptime for Windows vs nix really matters?

The problem with a server crash is that you need someone there to reboot it. Now I can tell you that my windows machine crashes on a fairly frequent basis, while I used a linux box ran for years without a crash. Mud crashes are annoying enough as it is, but at least the mud usually comes back up within a few seconds - a system crash, which won't come back up until someone reminds the hosting owner to do a reboot, is going to be downright annoying.

Then there's the whole host of security-related issues...

Windows does have things going for it, and would be good for the client-side development, but IMO it makes a poor choice for the primary OS of a publically available codebase.

Originally Posted by The biggest problem I see is Delphi- it's just not that common, making recruitment harder.

Indeed, that's another major problem.

[Michiel]

Originally Posted by (KaVir @ Sep. 11 2003,10:17) Just some brief comments: 1. Within your credits.txt file, you state "Parts based on Smaug, ( c ) Derek Snider and Emlen, ( c ) Owen Emlen".  If your mud contains parts of Smaug, then that makes it a Diku/Merc/Smaug derivative, bound by all appropriate licenses.  Indeed there are many obvious similarities with the Diku code, despite the language translation. 2. You repeatedly use "( c )" as a copyright notice.  However "( c )" is not legally recognised - you should use "Copyright", or ©. 3. Windows is generally a poor choice for running a mud.  Not only does it suffer from stability issues, but it also makes it much more difficult to find hosting.

1. Part of the development is moving away from the Diku/Emlen-inspired code.

2. Legal issues or recognition are not my focus.

3. This statement might have been valid 2-3 yrs ago, but is
entirely obsolete with releases such as 2000 Pro/Server and XP. Hosting is becoming cheaper every day. Also, the Kylix port will be updated soon, enabling dedicated Linux users to run the codebase - binaries will be provided.

[Michiel]

Originally Posted by (Stilton @ Sep. 11 2003,13:25) KaVir: Only if you need to do it commercially rather than run it on your own box.  At the very low-cost level nix hosting is available much cheaper than nix (small account on a shared machine).  Once you're on a dedicated machine, hosting costs aren't THAT bad for Windows.  I'm not sure how much the platform stability argument counts for these days.  How many active muds go for so long without code changes that the difference between uptime for Windows vs nix really matters? (remember that he's proposing a Smaug derivative, not a fully scripted MUSH with sockets hardcoded but not much else) Windows does have the advantage of native  async socket support without having to worry about threading issues (yes, various *nix's have their own flavors, but they seem to be in flux, while the Windows implementation has been usable and stable for what, 10 years now?).  This could be a very big plus for a first-time developer. The biggest problem I see is Delphi- it's just not that common, making recruitment harder. Stilton

I'm not at all proposing a Smaug derivative. Grendel is not new (it has been in on-and-off dev. for the past 2-3 years). Grendel merely uses some of the internal structures of Smaug, I included them as a starting point. Future development will make sure all traces of Diku/Smaug/Emlen-inspired code are removed and replaced with contemporary technology.

Delphi has a large userbase outside of the MUD community, but you could be very right recruitment within that community could prove difficult. We'll just have to wait and see.

Thank you for your comments.

[Loriel]

Originally Posted by 1. Part of the development is moving away from the Diku/Emlen-inspired code. 2. Legal issues or recognition are not my focus.

I recommend you to pay much closer attention to them.

Starting with what appears to be a translation of SMAUG (or emlen) means you are probably a SMAUG (or emlen) derivative.

Believing you can just lose that derivative status by "moving away" is naive - get some proper advice on your current status, and how to "lose" the derivative status (which may require you to start again from scratch).

Originally Posted by 3. This statement might have been valid 2-3 yrs ago, but is entirely obsolete with releases such as 2000 Pro/Server and XP. Hosting is becoming cheaper every day. Also, the Kylix port will be updated soon, enabling dedicated Linux users to run the codebase - binaries will be provided.

"entirely obsolete" is rather an overstatement. The situation is much improved with XP, but stability and cost issues still leave *nix a considerable way ahead.

What the... I am confused.. why, why, WHY on earth would you choose Delphi as a mud programming language? It's primary use is for writing Windows programs with buttons and scroll bars etc. That is what differentiates it from alot of more "textish" languages. But with a mud, the actual .exe file has no need for these bells and whistles. Most (all?) mud .exe files don't even bother interacting with standard in, and only interact with standard out to print log messages and bug messages. Since the fancy bells and whistles of Delphi have no counterpart in the telnet protocol, it is utterly pointless unless you are trying to craft a MUD where the admin can control things directly through the main .exe... but since most MUDs are hosted at a commercial place rather than a box, this would be more of a security risk than any sort of benefit

[Michiel]

Originally Posted by I recommend you to pay much closer attention to them. Starting with what appears to be a translation of SMAUG (or emlen) means you are probably a SMAUG (or emlen) derivative. Believing you can just lose that derivative status by "moving away" is naive - get some proper advice on your current status, and how to "lose" the derivative status (which may require you to start again from scratch).

As I explained before, I'm not starting Grendel, I'm trying to find other developers to help me on the project.

Grendel is not at all a translation of SMAUG or Diku, it merely uses some of the internal concepts and flags. If this makes Grendel a SMAUG/Diku derivative, I will have to take a look at my own license (which is as flexible a license available). I do not agree that I should start from scratch to rid myself of any derivative "status".

I find it somewhat amazing that instead of helpful replies, or even "I hope you succeed, good luck", all I get is remarks on licensing issues and "why did you choose windows".

Originally Posted by What the... I am confused.. why, why, WHY on earth would you choose Delphi as a mud programming language?  It's primary use is for writing Windows programs with buttons and scroll bars etc.  That is what differentiates it from alot of more "textish" languages.  But with a mud, the actual .exe file has no need for these bells and whistles.  Most (all?) mud .exe files don't even bother interacting with standard in, and only interact with standard out to print log messages and bug messages.  Since the fancy bells and whistles of Delphi have no counterpart in the telnet protocol, it is utterly pointless unless you are trying to craft a MUD where the admin can control things directly through the main .exe...  but since most MUDs are hosted at a commercial place rather than a box, this would be more of a security risk than any sort of benefit

Why I chose Delphi? I grew up with Pascal, and since Delphi is essentially just (Object) Pascal, the choice was clear for me.
Also, I believe that a language does not dictate the nature of an application. You are correct in saying that Delphi has a strong IDE, a number of components that greatly ease the burden of Windows interface programming, etc. etc., but do not forget that all these bits and bobs are not part of the language.

Thank you all for your replies. I intend to make Grendel a better codebase, and these replies certainly do help, even if they're not what I had expected. Feel free to contact me personally on michiel@grendelproject.nl too.

Regards,

Michiel

[KaVir]

Originally Posted by Grendel is not at all a translation of SMAUG or Diku, it merely uses some of the internal concepts and flags. If this makes Grendel a SMAUG/Diku derivative, I will have to take a look at my own license (which is as flexible a license available). I do not agree that I should start from scratch to rid myself of any derivative "status".

Unfortunately it's not about whether you "agree" or "disagree". It's about copyright law. Your mud is clearly derived from Diku, and is therefore a Diku derivative. You cannot simply "remove and replace" the old code.

Originally Posted by I find it somewhat amazing that instead of helpful replies, or even "I hope you succeed, good luck", all I get is remarks on licensing issues and "why did you choose windows".

You seemed surprised that nobody had shown an interest. The reasons given are perfectly valid explanations for that lack of interest. I would never work for someone who ripped off other peoples work, because (aside from the moral issues) the chances are that they wouldn't think twice about doing the same to me. I would not develop a mud codebase in delphi (which I don't know anyway) or for a windows platform because it would only be likely to be used by a very small number of people (if any) - and IMO the purpose of creating a public codebase is that it is useful to the public.

[Michiel]

[quote= ]
Unfortunately it's not about whether you "agree" or "disagree". It's about copyright law. Your mud is clearly derived from Diku, and is therefore a Diku derivative. You cannot simply "remove and replace" the old code.[/qoute]

Ofcourse I can. During SMAUG development, a lot of old Diku code was removed/replaced as well, so I see no reason why I cannot alter code in my own project.

You seemed surprised that nobody had shown an interest. The reasons given are perfectly valid explanations for that lack of interest. I would never work for someone who ripped off other peoples work, because (aside from the moral issues) the chances are that they wouldn't think twice about doing the same to me. I would not develop a mud codebase in delphi (which I don't know anyway) or for a windows platform because it would only be likely to be used by a very small number of people (if any) - and IMO the purpose of creating a public codebase is that it is useful to the public.

No, the reasons _you gave_ are perfectly valid explanations for _your_ lack of interest. I have no idea how many people actively post here (other than you), but yes, it did strike me as odd that the only comments I got (on this forum) are of this nature.

I strongly state that I do not rip off code, and have no intention to do so. If I'm at fault by misplacing copyright statements of other codebases that you feel Grendel is a derivative of, then I am sure we can work this out.

Maybe it's better to continue this off-list.

Regards,

Michiel Rook

[KaVir]

Originally Posted by No, the reasons _you gave_ are perfectly valid explanations for _your_ lack of interest.

No, they apply to a lot of mud developers.

Originally Posted by I strongly state that I do not rip off code, and have no intention to do so. If I'm at fault by misplacing copyright statements of other codebases that you feel Grendel is a derivative of, then I am sure we can work this out.

If I feel that Grendel is a derivative? Perhaps I misinterpretted the following:

"Parts based on Smaug, ( c ) Derek Snider and Emlen, ( c ) Owen Emlen"

"Part of the development is moving away from the Diku/Emlen-inspired code."

"Grendel merely uses some of the internal structures of Smaug, I included them as a starting point. Future development will make sure all traces of Diku/Smaug/Emlen-inspired code are removed and replaced with contemporary technology."

"I do not agree that I should start from scratch to rid myself of any derivative "status"."

May I recommend you read this article, in particular:

VI.D.2. Piecewise Reimplementation

Many people have reimplemented computer programs by rewriting them to replace the source code with code of their own writing. There is no reason to believe that this would not be a copyright infringement, particularly if the reimplementer had access to the source code of the original program, even if none of the original source code remains.

When the first segment of code is rewritten, the new code will be an infringing work if it is substantially similar to the original code, or may be an infringing derivative work if it is a reimplementation in a different programming language. That reimplemented first segment is combined with the remaining parts of the original program to form an intermediate version. Subsequent modifications produce another work. So when you have completed the piecewise reimplementation, you have a set of works, each of whose creation infringes the exclusive rights of the owner of the copyright of the original program.

As an analogy, consider the translation of a novel to a different language, something that would clearly be a derivative work. It makes little difference that none of the original words remain, or that the translation was done a little at a time. The resulting translation is still an infringing derivative work.

Even if you completely replace the program with new code, nonliteral elements also protected by the original program’s copyright are likely to remain and infringe – elements like the overall program structure or architecture and data structures that are not dictated by external or efficiency considerations. Although there is no case law on this point, it would seem that the only way to break the chain of infringing works is by some extraordinary act, such as a clean room implementation.

[Michiel]

Originally Posted by (KaVir @ Sep. 14 2003,10:53) <snip>

Check your e-mail, you have convinced me I have some licensing issues to fix.

[Samson]

Well I for one wish you luck on the project. I know nothing of Delphi, and woudln't dream of running a mud in Windows, but that's your choice to make and I hope it works out in the end.

So good luck with it

[the_logos]

I deleted this since I realized what I was going to say was said in later posts.

If there is a lessons to be learned, then it's that any Diku derivative is bound to have licensing issues because several people with an ego larger then the African continent INSIST on having their names on the most rediculous places.

Besides, there has GOT to be a cleaner way to handle a MUD then the diku way... Welcome to the age of cheapo databases, XML, rsync and SSL.