12 Aug, 2015, Tyche wrote in the 21st comment:
Votes: 0
The memory allocation routines were first added in Merc 2.0.
They have made their way into other derivatives.

It's a one line change to add more string space.

I wrote a fixed memory allocator for LE, using the same notion of allocating a fixed pool for each type of object.
It tracks statistics and can be navigated.
It didn't include it in Murk++.

13 Aug, 2015, Rhien wrote in the 22nd comment:
Votes: 0
I apologize, this is rambly.

I think these old code bases like anything have pros and cons. By trade, I'm a .Net/SQL developer. I think in terms in objects and I can't tell you the last time I've had to seriously worry about memory or strings, I bulk loaded 10GB of data today from C# without so much as a blip (although my mind numbs when people abstract things to an unintelligible level which is why most modern muds don't keep my attention). I've picked up some object oriented muds and they never seem any easier to work than any Diku I've worked on (although with much easier debugging and much less error prone memory management). Although as I say this earlier today I was wishing C had some kind easy to use reflection to get function names from code without putting them in a table, anyway (I moved my skill table into OLC).

I've recently picked up my ROM 2.4 derivative I've worked on and off on since 1998, put it on GitHub and perhaps it's just nostalgia but it has a charm to it. I mostly code on my Linux box but I've also got it compiling in Visual Studio 2015 which makes coding way faster (intellisense and being able to real time debug where it stops on a line of code that crashes and circles my bone headed mistake without having to get into GDB).

I guess I like a lot of the setup the MERC/Smaug/ROM teams did. I like their game play and I don't find adding stuff is horrible. I like the communities (although they've shrunk over time). Most things I want to do on a MUD I can accomplish fairly easily even with C, I just do them differently than I would in C#. Although I like C# better (and I can do *way* more with it in a shorter period of time), I don't have the personal incentive to re-write the code base from the ground up. I don't know what I would gain in the games actual game play. I feel like Merc/Rom (and Smaug) hit something correct, the right ideas about game play at the right time (I say that because I've logged into the implementation of ROM 4.x and I wasn't in love, even had it been released I'd probably not have started from it).

As a side note, I'm glad to see people still here. Once the ROM mail list went dark (and I had kids) I fell out of the community for years. I like the insightful conversation here. :)
14 Aug, 2015, quixadhal wrote in the 23rd comment:
Votes: 0
Just as a thing to note… you don't HAVE to refactor to full on object oriented to start using a more modern language.

Davion started converting ROM to python a while back, and Syn and I both did some work on it last year. It's not perfect, nor likely fully debugged and working, but it's a good place to start if you wanted to see one way to get off the C/C++ treadmill and still keep the basic structure and more-or-less familiar coding style.


I'm sure he'd be thrilled if somebody else picked it up and started working on it again. It's a good starting point for anyone who likes the ROM codebase, but hates dealing with C's memory and string handling.
18 Aug, 2015, Rhien wrote in the 24th comment:
Votes: 0
Good point. Was just looking over that project, it looks pretty cool. I haven't had a reason to work on Python before (except for some simple scripts on my Raspberry Pi). When I get home tonight I may try to compile it.

As a side note which pertains to the original post about MAX_STRING. This is from the Merc 2.1 documentation circa 1993. :D

Merc Release 2.1
Sunday 01 August 1993

Furey mec@shell.portal.com
Hatchet hatchet@uclink.berkeley.edu
Kahn michael@uclink.berkeley.edu

=== Memory Usage

In order to simplify the code, the Merc server has a fixed maximum size on
strings in the area database. This size is defined at the beginning of 'db.c'
'db.c' with a '#define' statement. As distributed, this size is:

#define MAX_STRING 1048576

This size is 10% larger than needed for the areas we distribute. Thus, you
can add about 4 more areas without touching the server at all. The server
will tell you when the string table overflows, and you can simply increase the
maximum limit and recompile. The immortal 'memory' command will show you
memory usage from within the game.

There is no other limit on area sizes or memory usage.

We decided to use a fixed size because it simplifies our job. It also allows
significant performance improvements: compare our load time and memory usage
versus other Diku muds with the same quantity of areas.
21 Aug, 2015, Rhien wrote in the 25th comment:
Votes: 0
Pymeus said:
I know mkwSys included something like that, although it seems to have been largely scoured from the face of the web. The only copy of it I can find is here in the Internet Wayback Machine.

This code base claims to have Michael K. Weiss's memory code in it (e.g. mkwSys). It lists it as being in memory.c which isn't in the source so I suspect they've melded it into their source files, I haven't looked hard at it. Anyway, this place maybe a good place to snag it from (I was looking for it myself).