28 Jan, 2012, Igabod wrote in the 1st comment:
Votes: 0
Hades_Kane said:
I enjoy building online because of the social interaction and everything else that is present while building. I couldn't do a builder port, an offline building tool, etc. because the social aspect of MUDing is very important to me. Sure, I could have the MUD up while also building on another port or in another window, but honestly, I'd much rather do it all in the same window. When I'm coding, I'm rarely social on the game because most of my time is in another window, and it breaks my concentration to constantly be switching back to the MUD window to see what the latest chat is. So usually, when there are a lot of people on and a lot of socializing going on, I'm normally not coding. That's when I'll do some of my most productive building, however.

But anyhoo, that's my 2 cents. I think it's great when someone is putting effort toward thinking outside of the box and doing something that might help promote any aspect of MUDing, making building more accessible, easier, or quicker… so good job! But I thought I might throw in my perspective, and I suspect the perspective of others who might not find an offline or browser based building tool something they would be likely to use.

It might be something for MUDs to consider offering as an option for their builders, though, because what fits for one doesn't always fit for others.


This is exactly why I have always had an interest in the various attempts people have made at adding the ability to modify the source code from within the game itself without needing to open putty or whatever. Unfortunately, all of the examples I have seen of this are either VERY limited or incomplete or just plain inoperable. I'm still waiting for that feature to make its way into common usage.
28 Jan, 2012, Cratylus wrote in the 2nd comment:
Votes: 0
Igabod said:
This is exactly why I have always had an interest in the various attempts people have made at adding the ability to modify the source code from within the game itself without needing to open putty or whatever. Unfortunately, all of the examples I have seen of this are either VERY limited or incomplete or just plain inoperable. I'm still waiting for that feature to make its way into common usage.


It's in common usage in most every LPmud.

-Crat
http://lpmuds.net
28 Jan, 2012, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
What is the problem by opening another window, as it will be the exact same result ? Just use the tiling option of your window manager. Editing code comfortably needs a real editor. Building is very different, especially online as your character can immediately test how it looks / react etc.
29 Jan, 2012, Tyche wrote in the 4th comment:
Votes: 0
If 468 out of the 1081 muds currently running support complete in-game programming, would that be common usage?

For example on a ColdX server:
> @list $weapons.damaged
@program $weapons.damage() +access=pub
arg @args;

if (!damage)
damage = [1, 4];
if (args)
damage = args[1];
if (.special())
damage = [.special(), .special()];
catch any {
if ("sharpened" in (.enhancements()))
return [(damage[1]) + 2, (damage[2]) + 2];
}
return damage;
.


You can cut and paste that command and method code to and from an external editor, a mud client editor, or use the in-game editor.
That's at least three different ways to work depending on your preferences.
Several servers support full screen editors as well as line mode editors.
Some have escapes in the modal editors to send commands to the game while you are editing.

What's really missing from what you've looked at?
29 Jan, 2012, quixadhal wrote in the 5th comment:
Votes: 0
I think what he meant to say was, in the Diku-centric universe many mudders live in, he wishes there were some way to edit code online without having to use a shell account to edit, and then having to recompile and reboot the game.

LpMUD's have had online (if somewhat crusty) editing via "ed" since 1990. Not too long after that, they implemented ftp daemons in LPC that allowed wizards to download, edit and re-upload files pretty simply… client triggers and macros can make that almost seamless. As Tyche pointed out, some also now have full-screen editors, and other kinds of MUD's also allow similar functionality. So far, only the DikuMUD branch seems to be left out in the cold because they have only a limited scripting support that still relies on most of the game mechanics being hard-coded – and thus not easily changable from within.
29 Jan, 2012, Rarva.Riendf wrote in the 6th comment:
Votes: 0
'Problem' of dikus is the only 'seamless' way to do so is copyover. And even then, as there is no built in 'plugin' system no way of isolating code. Way too easy to crash a program in C.
And everything a little complex need to be hard coded anyway.

You won't come up with anything that dispatch damage on your charmies if there is no hardcoded functionalities that does it. Or something that redirect attacks to your opponent. Because you cannot just plug it in just one place.
29 Jan, 2012, KaVir wrote in the 7th comment:
Votes: 0
quixadhal said:
So far, only the DikuMUD branch seems to be left out in the cold because they have only a limited scripting support that still relies on most of the game mechanics being hard-coded – and thus not easily changable from within.

The branch seems to have happened earlier than that.

AberMUD and Monster were (as far as I can tell) both clunky hardcoded muds. But Monster had some sort of OLC, which allowed you to create your own objects.

TinyMUD was designed to be a stripped down version of Monster which had the creation tools without "all the hairy stuff".

DikuMUD was designed to be a streamlined AberMUD that could be quickly and easily run "out of the box".

LPMud was designed to combine the gameplay of AberMUD with the flexibility of TinyMUD, making it a sort of hybrid of the two approaches.

Since then we've seen TinyMUD derivatives adding more gameplay features, and we've seen DikuMUDs adding more creation tools. LPMud already had both, so it sits happily in the middle while the other two gradually converge.
30 Jan, 2012, Tyche wrote in the 8th comment:
Votes: 0
quixadhal said:
I think what he meant to say was, in the Diku-centric universe many mudders live in, he wishes there were some way to edit code online without having to use a shell account to edit, and then having to recompile and reboot the game.


I had thought he was writing a new mud server.

KaVir said:
AberMUD and Monster were (as far as I can tell) both clunky hardcoded muds. But Monster had some sort of OLC, which allowed you to create your own objects.

TinyMUD was designed to be a stripped down version of Monster which had the creation tools without "all the hairy stuff".


I don't what that means. Both the original Aber and Monster were clientless, implemented as shell commands. Communication between users was implemented via shared files and locks. They weren't servers in the sense that later AberMud, DikuMud and TinyMud were. I can't really find any features of Monster that TinyMUD didn't have.

KaVir said:
Since then we've seen TinyMUD derivatives adding more gameplay features, and we've seen DikuMUDs adding more creation tools. LPMud already had both, so it sits happily in the middle while the other two gradually converge.


That's a very old and optimistic view. DikuMud hasn't even come close to converging. The real problem with DikuMuds lay in its static structural view of objects. You can embed the latest and greatest scripting languages and you still won't get the online game redefining capabilities of MOO, LP or MUX. The hardcoded game elements have probably crippled Diku, since you can only find a handful of different game systems in Dikus, yet more than a dozen different game systems implemented in MUX. PvE just seems to be a lot less popular in Mushes than Dikus.

Rarva.Riendf said:
And everything a little complex need to be hard coded anyway.


That's not true at all.
30 Jan, 2012, Rarva.Riendf wrote in the 9th comment:
Votes: 0
Quote
That's not true at all.

Yeah well you can make you whole code totally dynamic sure…
But you will have to have a way to update multiple files at once as well, and simultanesoulsy.
Of course it is possible, everything is….
30 Jan, 2012, plamzi wrote in the 10th comment:
Votes: 0
Rarva.Riendf said:
Quote
Tyche said:
Rarva.Riendf said:
And everything a little complex need to be hard coded anyway.


That's not true at all.

Yeah well you can make you whole code totally dynamic sure…
But you will have to have a way to update multiple files at once as well, and simultanesoulsy.
Of course it is possible, everything is….


Actually, you can't make everything dynamic. Some code has to be static and contain the logic for how to load/call the dynamic stuff.


I agree with Tyche that you can add fairly complex code dynamically. But one must always remember that the ability to add stuff w/o rebooting the game server has not made any game great, or even good, or even remotely playable. It is not even a tool that makes things easier–it's just something "nifty".

Maybe in the days when MUD servers had very low RAM quota and hundreds of players, dynamic libraries (e. g. mud drivers) would have meant less frequent interruptions to the gameplay and fewer annoyances to players. Nowadays, it just doesn't matter. Anyone can run a separate instance for development, and most any MUD can find a time when their active player count is very low so they can release changes. Releasing in batches is standard industry practice, and you should probably follow it even if you do have the ability to update near-everything at runtime.

That said, in a recent post I shared that any CircleMUD (fairly early DIKU derivative) is about 10 lines away from having the ability to dynamically override any user input command. It's about 20 lines away from intercepting all special procedures and scripts (these all have very few entry points). So if you care about that sort of thing, and it's lacking on your server, do a bit of homework and add it. Honestly, I cared about something completely different (being able to map functions by name) and got this as a peripheral benefit.
30 Jan, 2012, Rarva.Riendf wrote in the 11th comment:
Votes: 0
I call something complex a functionality that needs to be plugged in many functions at once to actually work.
When you need to replace code in every object manipulation method, in update, in the saving character method, in some spells that affect objects etc…
Updating code dynamically to do all that in the right order without breaking anything in the process is a recipe for disaster. There is just no point.
give me an example of anything 'complex' that you can add dynamically. Everything that can be plugged in a single place is not something complex at all…
30 Jan, 2012, quixadhal wrote in the 12th comment:
Votes: 0
LpMUD's have done exactly what you describe since 1990. Some even have persistence, meaning objects are updated via new code on-the-fly, retaining their local values in the process and existing (via statedumps) forever.

Consider a typical use case. You are fixing a bug in an inheritable, such as /lib/std/room.c. This code is inherited by every specific room in the game, as well as a handful of room-like things. When done with your changes, you run "update -r room.c" and voila, every single thing in the game which (directly or indirectly) inherits /lib/std/room.c is recompiled and updated. If you made an error, the process halts before any existing room objects are affected, meaning you can go fix it and your players will never know. When it does work, the updates happen and in a non-persistent game, the players might notice the room they're in reset… in a persistent one, not even that.

Seriously, you guys act as if this stuff is some magic fantasy from the future. It's been here, it works, it's worked for 20 years. Pick your head up out of the DikuSand and look around. :)
30 Jan, 2012, plamzi wrote in the 13th comment:
Votes: 0
quixadhal said:
LpMUD's have done exactly what you describe since 1990.

Seriously, you guys act as if this stuff is some magic fantasy from the future. It's been here, it works, it's worked for 20 years. Pick your head up out of the DikuSand and look around. :)


Regrettably, this post is a perfect encapsulation of a general attitude. Is there nothing else you can feel superior about? Do you think any player in history has ever played a game because sometimes a bug can get fixed (or replaced by a worse bug) at runtime?
30 Jan, 2012, Rarva.Riendf wrote in the 14th comment:
Votes: 0
Quote
Consider a typical use case. You are fixing a bug in an inheritable, such as /lib/std/room.c. This code is inherited by every specific room in the game, as well as a handful of room-like things.

Most of my coding is not fixing bugs…it is adding actual functionalities that is most likely scattered in multiple classes. Creating new properties (meaning all the thing needed to display/edit/save) them. Not something as simple as updating a single class. And I like the 'wen there is an error it halts'..why did it not halt the last time since there was a bug….chuckle…
And all that risk of corrupting your database with wrong values to save what… 5 seconds of downtime ?
30 Jan, 2012, Cratylus wrote in the 15th comment:
Votes: 0
plamzi said:
quixadhal said:
LpMUD's have done exactly what you describe since 1990.

Seriously, you guys act as if this stuff is some magic fantasy from the future. It's been here, it works, it's worked for 20 years. Pick your head up out of the DikuSand and look around. :)


Regrettably, this post is a perfect encapsulation of a general attitude. Is there nothing else you can feel superior about? Do you think any player in history has ever played a game because sometimes a bug can get fixed (or replaced by a worse bug) at runtime?


I think the idea was that folks in this thread are asking for stuff that's already available in established, nay ancient form, as if it were some novel thing.

I get that you don't care for uptime e-peen contests. Fine.

I will say I personally find it very convenient to be able to fix stuff and add functionality without reboots. I also like the half dozen people idling serenely (on average) on my mud, returning perhaps after a few hours or a few days to check out what chats they missed and who's online, etc.

It's not revolutionary, it's not essential to anything. It's, in your own terms, nifty. It's worth touting, and not worth getting snippy about.

-Crat
http://lpmuds.net
30 Jan, 2012, Cratylus wrote in the 16th comment:
Votes: 0
Rarva.Riendf said:
And I like the 'wen there is an error it halts'..why did it not halt the last time since there was a bug….chuckle…
And all that risk of corrupting your database with wrong values to save what… 5 seconds of downtime ?


I'm not sure you really understand how LP does its thing. You seem to be describing a failure condition to which LP's aren't normally subject.

And yes, adding major functionality is one of the things you can do on the fly. I used to do major upgrades on a mud with over a year uptime.

Let me reiterate, though: is it necessary? No, of course not.

Is it nice and is it convenient, well, I think so.

-Crat
http://lpmuds.net
30 Jan, 2012, plamzi wrote in the 17th comment:
Votes: 0
Cratylus said:
I also like the half dozen people idling serenely (on average) on my mud, returning perhaps after a few hours or a few days to check out what chats they missed and who's online, etc.


Hmm, it so happens that my game saves the history of several channels in persistent storage. So my users can serenely catch up at any time without having to scroll back.


Cratylus said:
It's not revolutionary, it's not essential to anything. It's, in your own terms, nifty. It's worth touting, and not worth getting snippy about.


Ah well, since you feel it's "worth touting", I can say that it took me about 30 min. to add this functionality. It's trivial. I find it amusing that the people who tout it the most seem to have gotten it "for free" with their first LPMud. Maybe if they actually coded it at least once, they would know it's not worth more than a mention.
30 Jan, 2012, Cratylus wrote in the 18th comment:
Votes: 0
you win. it sux.
30 Jan, 2012, plamzi wrote in the 19th comment:
Votes: 0
Cratylus said:
you win. it sux.


In your passive-snippiness mode, I'm afraid you're missing the point. The point was to throw some cold water on the LPMud folks who show up predictably to every thread of this sort, eager to snub their nose at their inferior Diku brethren. Silly stuff.
30 Jan, 2012, Cratylus wrote in the 20th comment:
Votes: 0
plamzi said:
Cratylus said:
you win. it sux.


In your passive-snippiness mode, I'm afraid you're missing the point. The point was to throw some cold water on the LPMud folks who show up predictably to every thread of this sort, eager to snub their nose at their inferior Diku brethren. Silly stuff.


I guess the joke's on me for responding to arguments on their merits.

Do carry on with whatever other thing you were doing.

-Crat
http://lpmuds.net
0.0/111