dworkin
commented
2 years ago Hello "rubyFeedback",
Do you have a name? You seem to know me, but I don't know you.
I believe that you are conflating two separate things. Armageddon, in LPMuds, is a non-persistent reboot, after which the MUD has to restart from the beginning. That is what the comment you quote refers to; some areas in the MUD cannot handle a long uptime.
Object swapin/swapout is something which DGD does automatically, and which causes no lag. However, Padermud, which used to be memory constrained, would sometimes do a forced swapout of all objects, which definitely could freeze a MUD for a few seconds.
DGD's ordinary object swapping is good enough that DGD MUDs could keep running for an indefinite time, whereas LPmuds would have to reboot when they ran out of memory. Padermud, which was converted from LPmud to DGD, ran into the problem that many of the areas had been designed with the assumption that there would be frequent reboots, which was no longer the case when using DGD.
andreasfaerber
Hey there Felix,
This is kind of more a question.
Some MUDs that use DGD/LPC have "armageddon" e. g. object swap outs.
Other MUDs seem to not have these as frequently anymore.
In the 1990s I remember on the old PaderMUD (later Xyllomer) object swap outs and even lag during that time.
So some folks discuss it or dispute it that a LPC/DGD MUD can not be completely free of object swap out. For instance, I quote a comment from a few years ago:
"There are still many rooms and areas which would need a regular Armageddon."
I am not sure this is necessary, though. (Or global armageddon, probably room/area specific ones may happen.)
I don't know how much the code base has changed, so this may be more a generic question:
Is it possible to have a LPC/DGD MUD that can avoid global armageddon but perhaps even local ones? I guess an issue is with object creation to the point where it may cause problems, but this could - or already may - be handled automatically. I have no idea. Things change a lot over the years.
Since I think this may be interesting for some other folks, it would be nice if this could be covered / mentioned in the FAQ briefly. Does not have to be a long page, a paragraph or two perhaps with a recommendation for people who may want to fix an old code base, where to look at, and what to modify to change things.