[locke]

NiMUD 5 has had record uptime since its last release.

The mud ran from Satuday, March 21 2009 at 17:19:51
until an unknown time after Thursday, April 30, 2009 at 00:29:33
when it reported: "Server now operational on port 5333."

This single run of the MUD included player logins and use, routine maintenance, automatic soft-booting, loading and reloading areas, and lasted over 39 days on a single hard boot.

It may have gone down due to the machine itself rebooting.

Get it now at NiM5 Documentation Index

[noodles]

Originally Posted by locke NiMUD 5 has had record uptime since its last release. The mud ran from Satuday, March 21 2009 at 17:19:51 until an unknown time after Thursday, April 30, 2009 at 00:29:33 when it reported: "Server now operational on port 5333." This single run of the MUD included player logins and use, routine maintenance, automatic soft-booting, loading and reloading areas, and lasted over 39 days on a single hard boot. It may have gone down due to the machine itself rebooting. Get it now at NiM5 Documentation Index

• You have no way of knowing why or when it went down.
• The last message you have sounds like it was from when it started up.
• It only stayed up a month and a bit.

Surely you should wait until your project is finished, stable and polished before posting advertisements that proclaim its stability, yet include details which don't necessarily show anything of the sort.

If this "amazing stability" is a feature which makes it stand out from the competitors, then I dread hearing about their even more unpolished, incomplete state.

If there is anyone who might be interested in your project, given its state, chances are they'll burn out on it and when you have it polished and complete, they'll have lost any potential interest in it.

Good luck!

[locke]

You're obviously living in a bubble, Noodles. "NiMUD 5" is the 12,773rd build of The Isles MUD, originally released in 1993. NiMUD 5 is "done" for all intents and purposes. While a few ancillary features may need attention, the MUD is mature and, as stated in my original post, stable with a 1.5MB logfile to prove it.

[Saffire]

It's been in development since 1993 and it's an amazing accomplishment for it to stay up for just over a month without having to reboot? That doesn't sound very promising to me.

[gth]

"You're obviously living in a bubble, Noodles"
That's rather condescending, isn't it? It might pay to check the company you're in before being so dismissive.

Perhaps you could politely ask what kind of uptimes other codebases have before proclaiming stats of yours are so good that they are the top of their category.

"automatic soft-booting"
Could I also (geniunely) ask you to explain what this feature involves and how many times it occurred during your record uptime period? Obviously you'd agree that having a server respond to PING is very different from being able to support a single, uninterrupted character login session playing throughout the entire uptime period.

[prof1515]

"automatic soft-booting" Could I also (geniunely) ask you to explain what this feature involves and how many times it occurred during your record uptime period?

Rebooting the game without disconnecting all of the players online. It's nothing new as other games have been doing it for some time and with greater success to say nothing of using far better codebases.

[locke]

NiMUD's OLC has appeared in thousands of active online games, and many of our features have been cannibalized over the years. I had recently received complements from our players who have actually taken the time to get to know the game. I doubt anyone who claims it hasn't been a success is being anything less than a troll.

39 consecutive days is a great example of a robust service and platform. My webserver is forced to reboot more often than the MUD server. Of course the MUD maintains connectivity through soft-boots. It also constantly updates thousands of concurrent script instances during its uptime. Some of the scripts involve many of the features used by players, and execute the same command functions that players do. Additionally, actors and objects with active scripts interact with each other, fight with each other, produce objects, and perform tasks that players do. I remained connected for three days during the aforementioned period, without issue.

[locke]

Originally Posted by gth "You're obviously living in a bubble, Noodles" That's rather condescending, isn't it? It might pay to check the company you're in before being so dismissive.

Public Profile: Noodles
Total Posts: 14 (0.01 posts per day)

[locke]

Originally Posted by prof1515 It's nothing new as other games have been doing it for some time and with greater success to say nothing of using far better codebases.

I don't know what "greater success" you are talking about, considering you have offered no evidence "professor" -- furthermore, since I doubt you know anything about NiMUD based on your commentary, you'd hardly be the judge of what is "better" ? Also, I don't think that sentence is semantically, nor grammatically, correct. It appears to be a complete sentence attached to a sentence fragment.

[locke]

Originally Posted by Saffire It's been in development since 1993 and it's an amazing accomplishment for it to stay up for just over a month without having to reboot? That doesn't sound very promising to me.

<G> maybe we could get someone else to do a comparison on how long various MUD servers stay up? I am guessing there are only a few that can beat NiMUD.

[gth]

I think I'll bow out of this discussion as you seem to prefer tearing into those who'd discuss what's a "good uptime" for a MUD. I was curious about the soft booting (handing over socket connections to another process, or however it works), but I'm sure I can find discussions of that elsewhere. Good luck with your codebase.

[locke]

Gth: You realize that it was Noodles who became condescending and I merely responded in kind. Your behavior is a bit irrational and hypocritical.

To further explain the process, descriptors (integers) paired with character names are stored in a file and then reloaded if the file exists during this process. This file is written whenever someone logs in or logs out. NiMUD attaches a handler which executes a shell, calling to the mud to restart on fatal errors (such as SIGSEGV). Other mud-state variables can be set in this file as well.

It is not a perfect system, however, because sometimes file handles (memory, etc) from prior (dead) executions can be left open, and accumulate, which causes an unrecoverable error at some point. The error manifests when a call is never made to restart the mud. However, detaching from the original process alleviates this problem perpetuating the service indefinitely unless there is collision with another process, a forced kill to the process, or the machine reboots or is shut down.

However, this is merely subscript to the overall announcement which was related specifically to NiMUD and its service offering. Many other things can go wrong which cause a MUD to die: such as infinite loops, file corruption, memory corruption, etc. Apparently, NiMUD functions so well that it is never at the whims of any of these reasons.

[prof1515]

Originally Posted by locke I don't know what "greater success" you are talking about, considering you have offered no evidence "professor" -- furthermore, since I doubt you know anything about NiMUD based on your commentary, you'd hardly be the judge of what is "better" ?

I know that I've tried your game several times amongst the other 950+ games I've looked at and found your code to be nothing I haven't seen done better. I also find it so amusing that your game's been down during two of the three most recent attempts in the last year that I've made to connect to your MUD. Although it could be an improbable coincidence, I doubt it and it's still a testament to the up-time of the code that a majority of my most recent experiences with your "stable" code showed instability.

Also, I don't think that sentence is semantically, nor grammatically, correct.

You should have ended your sentence after the word think and then you'd be correct (or are you commenting on your own butchering of the English language?). I'm not about to spend any more time pointing out your errors though. If indeed you have been working on the game since 1993 it would suggest you're old enough that your ignorance and unjustified arrogance are beyond the point of hope of correction.

Short summary for those interested: the code sucks.

[noodles]

Originally Posted by locke NiMUD's OLC has appeared in thousands of active online games, and many of our features have been cannibalized over the years. I had recently received complements from our players who have actually taken the time to get to know the game.

Can you list those games and perhaps quote some of those compliments? What's your peak player level during the uptime your game exhibits. This would be very helpful for those of us who are not familiar with your product, to lend some credence to your statements. Without this sort of supporting information, you could be anyone making grandious claims.

For instance, what say I claim that I am fifty-sixth in line for the throne of the British empire. Anyone who claims this is untrue is clearly nothing less than a troll.

Originally Posted by locke I doubt anyone who claims it hasn't been a success is being anything less than a troll.

I am not sure I understand. NiMUD isn't very well known, at least not to me. Yet, any queries for information which would help understand the statements you make about it is trolling?

Originally Posted by locke 39 consecutive days is a great example of a robust service and platform. My webserver is forced to reboot more often than the MUD server. Of course the MUD maintains connectivity through soft-boots. It also constantly updates thousands of concurrent script instances during its uptime. Some of the scripts involve many of the features used by players, and execute the same command functions that players do. Additionally, actors and objects with active scripts interact with each other, fight with each other, produce objects, and perform tasks that players do. I remained connected for three days during the aforementioned period, without issue.

I would agree that 39 days is a decent number of days to stay up. But what I was concerned about in my initial post, was that you didn't know why it went down and your logs only indicated information from when it went up. This is worrying.

But why is what you wrote above special? It sounds like a pretty standard list of features, albeit described in a vague way. I am not sure I understand why you think listing these makes NiMud anything other than par for the course?

[noodles]

Originally Posted by locke Gth: You realize that it was Noodles who became condescending and I merely responded in kind.

That was not my intention at all. I was just trying to voice concern and offer advice. You could take it as that, and reply clarifying my misunderstandings. I think you can understand why you might think my post was condescending if you admit your initial post lacked clarifying detail which would help me understand what was not described within it.

Originally Posted by locke Apparently, NiMUD functions so well that it is never at the whims of any of these reasons.

Again you indicate you're not entirely sure how NiMUD is functioning. I appreciate that you're not one of those people that posts vacuous statements that are not true - instead you just say how it is. It goes down for reasons you do not know, the logs are apparently incomplete and insufficient.. But these are the reasons I'd like to reiterate my concern. And to reoffer the advice, which I hope you take in the good natured way I offer it. That to offer a product that behaves in these unknown ways at this stage only serves to ward off those who might later adopt it when it is ready and behaves in known ways.

By your description and comments, it sounds incomplete and unpolished. This would be understandable, as it takes a lot of time and effort to get a code base up to a reasonable level of functionality and sometimes completing and polishing it just takes too much more that it never happens. Perhaps, if I am misunderstanding because of information you have not given, you might give it and then I could see what you do.

[noodles]

Originally Posted by locke Public Profile: Noodles Total Posts: 14 (0.01 posts per day)

No, no, he means you should accord me reverence and respect because I am fifty-sixth in line for the throne! On your knees boy! ;-)

But seriously, post count is a meaningless measure. Those with high post counts on forums, are so because they post any old thought that enters their head. Maybe they're lonely or something.

[Samson]

Originally Posted by locke Of course the MUD maintains connectivity through soft-boots.

It's called COPYOVER. The mechanics of this are identical to a "hard" reboot of the game with the only exception being that it does not disconnect the users. It is an illusionary system since performing one resets the game state unless one goes out of their way to add extra support to try and save more information than just player connections.

[Anasadi]

Your game seems to have a good deal of stability. Congratulations. I might suggest, however, you take care in the length of time between reboots. I am unsure why, but there are many players I've come across who are under the impression that reboots are required for new things. They get itchy around the second month or so without a reboot, and ravenous by the third and later months. It seems for some players a reboot shows the immortals care.

Anasadi

[Threshold]

Originally Posted by locke <G> maybe we could get someone else to do a comparison on how long various MUD servers stay up? I am guessing there are only a few that can beat NiMUD.

That would be interesting. I would really like to hear how long various mud servers are able to stay up between reboots.

I honestly do not know what the maximum uptime capacity is for Threshold. For various gameplay reasons (resetting certain conditions to "base" which is best done via a reboot), we generally reboot Threshold every 6-8 weeks. Our last uptime, however, was longer as we were in the process of setting up new hardware and wanted to move the game when the new hardware was ready. Our uptime then was almost 70 days.

We only hard reboot the machine one or two times per year.

[Delerak]

Originally Posted by noodles No, no, he means you should accord me reverence and respect because I am fifty-sixth in line for the throne! On your knees boy! ;-) But seriously, post count is a meaningless measure. Those with high post counts on forums, are so because they post any old thought that enters their head. Maybe they're lonely or something.

Plenty of people with a high post count don't just randomly post crap. I'm one of them. This thread randomly sucks though that's for sure.

[Anasadi]

Threshold wrote:

I would really like to hear how long various mud servers are able to stay up between reboots.

I am unsure. We often (too often, to players' lament) stay up 90+ days at a time. We reboot when we have something new to add on the Java side of the code. We've actually try to cut back on the amount of time between reboots to add small, new stuff and make the player base happy.

Anasadi

[locke]

Originally Posted by Anasadi Your game seems to have a good deal of stability. Congratulations. I might suggest, however, you take care in the length of time between reboots. I am unsure why, but there are many players I've come across who are under the impression that reboots are required for new things. They get itchy around the second month or so without a reboot, and ravenous by the third and later months. It seems for some players a reboot shows the immortals care. Anasadi

The MUD invisibly reboots once every 4 hours. Unlike other MUDs, it does not announce the fact that it is rebooting. Occaisionally, you notice the reboot, but it's usually mistaken for a refresh while playing. Many times you miss it entirely.

OT: Of note, my particular MUD is welcoming new builders. It helps to contact me via other methods, particularly email, when you want me to do something administrative like allocate new vnums for you. I tend to approve all applications which include at least a paragraph response during the login sequence, when new players are asked if they want to build or not.

[locke]

Originally Posted by Samson It's called COPYOVER. The mechanics of this are identical to a "hard" reboot of the game with the only exception being that it does not disconnect the users. It is an illusionary system since performing one resets the game state unless one goes out of their way to add extra support to try and save more information than just player connections.

I allocated no more time to the feature in light of other things on the to-do list. You could save the entire world state though, but the process might be slower when recovering.

[Samson]

Then your game reboots once every 4 hours and has a maximum uptime of 4 hours. Reporting it as 39 days is quite simply a lie. Only someone trying to make bogus claims about their stability would feel the need to deceptively call it a "soft reboot" or claim it was up for "39 days".

[Mabus]

Originally Posted by Threshold That would be interesting. I would really like to hear how long various mud servers are able to stay up between reboots.

I have went over 400 hours up with absolutely no errors or issues (I log extensively), but then I wanted to add new code that had been compiled and was waiting. I modify far to often to let it rest that long. I love new coded content far to much.

Barring a physical server outage, other processes on the same server eating to much memory, or a MYSQL failure I firmly believe my code could run forever, but then again it is Java (CoffeeMUD derived, extensive modifications). One of the beautiful things about System.gc().

I have seen a DBZ MUD on my old (shared) server up over 2,500 hours. No clue on their code base, but I was impressed when I saw it on "top".

[Anasadi]

I am adding a small side-comment. Mabus wrote:

Barring a physical server outage, other processes on the same server eating to much memory, or a MYSQL failure I firmly believe my code could run forever, but then again it is Java (CoffeeMUD derived, extensive modifications)...

*chuckle*

I've never worked with CoffeeMUD, so I cannot comment on it. Java, on the other hand, was the language on which our game was written, and we've not had many issues that would cause a crash. I've only known of two actual crashes (one was power supply failure, the other a strange bug between our code and the VM), plus a few times the main thread hung, but that's it. And we're talking since Java version 1.0 here. For all its perceived "slowness", Java has served us very well.

Anasadi

[locke]

Originally Posted by Samson Then your game reboots once every 4 hours and has a maximum uptime of 4 hours. Reporting it as 39 days is quite simply a lie. Only someone trying to make bogus claims about their stability would feel the need to deceptively call it a "soft reboot" or claim it was up for "39 days".

No, the MUD ran for 39 days. The "game" reboots, within the server. It does this to maintain a certain limit on uncontrolled growth. This number could be increased, and has in the past been as high as 1000 hours, or 30000 hours or whatever you would set that limit to. I like 4 hours because it keeps the MUD fresh and consistent.

[Samson]

Nope. The MUD ran for 4 hours. Then it was told to reboot. The fact that it kept the players' connections intact does not change the fact that your game did in fact perform a full reboot without their knowledge.

Of course, to be fair, if it happens to cater to "grinders" they may not even be aware it works that way. So to them, they see nothing more than a spot of short lag every 4 hours. But you are deceiving yourself and those of us who know how these things work by trying to claim you've had 39 days continuous uptime.

And yeah, other people have pointed out that this isn't a major feat. I had a customer who launched a Merc derivative and had players in and out of the place all the time and it ran for 120 days straight without ever rebooting OR performing a copyover. The only reason it got interrupted was because a kernel security update had been installed and needed a system reboot to bring it up.

[Zivilyn]

Originally Posted by locke NiMUD's OLC has appeared in thousands of active online games

Actually it's 'The Isles OLC' which was ported.
Saying it's NiMUD is like saying Merc is Diku isn't it?
I mean you did say that you completely rewrote the game between then didn't you?
It'd make NiMUD a Isles->Merc derivative, even if it's you doing it.
(or a completely new game if you started from scratch,
but I was under the impression you had said you'd re-written)

[locke]

Originally Posted by Zivilyn Actually it's 'The Isles OLC' which was ported. Saying it's NiMUD is like saying Merc is Diku isn't it? I mean you did say that you completely rewrote the game between then didn't you? It'd make NiMUD a Isles->Merc derivative, even if it's you doing it. (or a completely new game if you started from scratch, but I was under the impression you had said you'd re-written)

It's a Merc derivative, though the Merc part of it is rather small now, many years later. It's merely "The Isles" and the server "NiMUD" -- this has been the case since 1994, after "The Isles OLC" was released. I don't think it needs to move in the DMFT and if you wanted to trace lineage it's more or less something like:

Diku->Merc + LP + MUSH + Circle

It is largely rewritten. It is many times larger and more complex and possesses many underlying feature changes which set it apart from just being a Merc derivative. The game is, like M/D, loosely based on TSR products, with some Palladium Books ideas thrown in, an original world, totally original in-game statistics, and many features originally written by me but based on features from ZebestaMUD, DuneMUSH, LPmud, Merc, Diku, Circle and I bet some other variants. When I say "originally written by me" I mean that I wrote original source code that deployed functionality similar to those aforementioned software packages, some of which were never released publicly.