20 Sep, 2011, Runter wrote in the 61st comment:
Votes: 0
Quote
It means the builders can come up with clever things and implement them without needing to rush to the admin/coder to hack it into the driver. It means the players actually see the game as something more than a meat grinder with fancy wallpaper. Back in the day, when MUD's had players, I remember many times a player had a good idea or request, and they would go unanswered or be told that the coder might be able to implement it eventually, because in a DikuMUD, it has to be done by someone with shell access.


This cuts both ways. I can see reason why I wouldn't want to give ordinary builders the power to change gameplay substantially. This is going to swing wildly from game to game, but I don't want my pastry chef designing the menu. I just need them to do the little flowers made out of sugar.
20 Sep, 2011, Cratylus wrote in the 62nd comment:
Votes: 0
plamzi said:
I did assume that quixadhal meant time between reboots when you're pushing changes. That's the only practical difference I can think of between a fully debugged Diku server and a fully debugged LPMud one.


Right, so this is the disconnect, then.

High uptime is not the point. High uptime is a shorthand way of illustrating the point, which has much less to
do with waving around a stability metric and much more to do with describing a different approach to adding
functionality.

What I was trying to say with the 55 weeks wasn't really the 55 weeks themselves. It was that on that
mud, anyone who logs in is automatically granted coder privileges. Not just player, not just builder, not
just imm, actual, no-foolin coder, able to write code that gets loaded into the game while the game is
running.

The implications here go well beyond uptime. This makes it so that you don't need to "hire" coders.
They can self select and self train. They can immediately feel rewards of creating not just pottery
and zombies but also sophisticated devices and even commands and complex systems, with less
of an admin bottleneck.

So, you see, it's not just "big deal, so they reboot less". It's a fundamentally different approach to
the relationship between code contributors and the mud.

Now, my dev mud is not the norm. Normal LP muds don't auto-wiz joe schmoe off the street, nor
do I advocate that they should. The 55 weeks uptime on an autowiz mud was meant to demonstrate
that when implemented well, a system that allows code mod at runtime doesn't have to live in
morbid fear of failure.

scandum said:
I've seen the standard LpMUD line editor and it made clear to me why LPMuds have done so poorly. One of the first changes I made to TinTin++ was adding support for indented multi-line scripts, because no matter how awesome a language is, if it's unreadable or inaccessible nothing decent will be created.


The "ed" line editor is pretty much the bane of modern LP coders, yes. Fortunately it is not the only option.
For building, you can do stuff like code a "Quick Creation System", for coding you can do stuff like
code a "Creator's Web Interface", or you can even implement a character mode editor so your coders can
use arrow keys and backspace and edit code in-mud without cryptic modes. In a pinch your creators could
also use your built-in ftp to upload code to their in-mud home directory, allowing them to use whatever
editor they like on their home PC. That's the neat thing about a mud with a built in dev environment. You
aren't stuck with the tools you start out with, and neither is your staff. This is an important
point for those of us with 80 hour work weeks…a system that lets your people help themselves is a gift.


return said:
This cuts both ways. I can see reason why I wouldn't want to give ordinary builders the power to change gameplay substantially. This is going to swing wildly from game to game, but I don't want my pastry chef designing the menu. I just need them to do the little flowers made out of sugar.


So far what I've described makes it sound like LP's are sheer anarchy. They are anarchy to the extent
you want them to be. Normal LP admins put in place tiers of responsibility and sandboxed roles that
keep a new hire from ruining the game. My 2 year old can hammer away at the Windows 7 account I created
for him…all he'll hurt is my keyboard and mouse.

-Crat
http://lpmuds.net
20 Sep, 2011, Runter wrote in the 63rd comment:
Votes: 0
Crat said:
The 55 weeks uptime on an autowiz mud was meant to demonstrate
that when implemented well, a system that allows code mod at runtime doesn't have to live in
morbid fear of failure.


Many diku games have code that can be safely modified at runtime. The scripting languages are generally crappy, but they're fairly standard in the diku world. DG scripts and mprogs come to mind. I'm pretty sure you can't modify LP muds driver at runtime. So I'm not sure there's a huge difference other than the breadth of what is exposed, and the quality of the overall system.

That being said, Diku overall is a steaming pile of unicorn chocolate without heaps of modification to make it more like an LP.
20 Sep, 2011, quixadhal wrote in the 64th comment:
Votes: 0
Runter said:
Many diku games have code that can be safely modified at runtime. The scripting languages are generally crappy, but they're fairly standard in the diku world. DG scripts and mprogs come to mind. I'm pretty sure you can't modify LP muds driver at runtime. So I'm not sure there's a huge difference other than the breadth of what is exposed, and the quality of the overall system.


The difference is, in a Diku context, those "scripts" are just tiny bits of code that can only launch from triggers that happen in the driver. The vast majority of the game is still hard-coded into the driver itself. If you discover a new event you want to let builders code for, hacking the driver is in your future.
20 Sep, 2011, Runter wrote in the 65th comment:
Votes: 0
quixadhal said:
Runter said:
Many diku games have code that can be safely modified at runtime. The scripting languages are generally crappy, but they're fairly standard in the diku world. DG scripts and mprogs come to mind. I'm pretty sure you can't modify LP muds driver at runtime. So I'm not sure there's a huge difference other than the breadth of what is exposed, and the quality of the overall system.


The difference is, in a Diku context, those "scripts" are just tiny bits of code that can only launch from triggers that happen in the driver. The vast majority of the game is still hard-coded into the driver itself. If you discover a new event you want to let builders code for, hacking the driver is in your future.


Well, as I said. It's a larger breadth and quality overall, but it's still the same concept. Would you feel better about conceding this if dgscripts were used for initializing npcs, assigning resets, and logic for things like quests? That's exactly what they're used for in a lot of diku based games.
20 Sep, 2011, Cratylus wrote in the 66th comment:
Votes: 0
Runter said:
Many diku games have code that can be safely modified at runtime.


That's fine. I get the feeling we're veering into rah-rah codebase jingoism and that wasn't my intent, though LP is obviously superior to scripts.

Runter said:
I'm pretty sure you can't modify LP muds driver at runtime. So I'm not sure there's a huge difference other than the breadth of what is exposed, and the quality of the overall system.


The breadth of what you can modify in an LP mud without touching the driver after initial config is pretty much 99.99% of use cases.
The only functionality-adds I ever needed to mess with the driver for was pretty low level stuff, like adding character mode and telopts.

If Dikus are there now too, great. Last I knew they weren't, but maybe that's something we can report to OP as progress.

I understand your point is "hey, with great effort you can sort of do some of the stuff yer talking about in Diku too!"
And you know, great. I would concede that yes, a skilled practitioner can shoehorn the emulation of some of LP's
delicious goodness into Diku, and LP is not the only one to boast of swell things. It's fair to say though, that there is a difference
between a codebase designed specifically for that flexibility, and a codebase which can be forced, given adequate violence,
to appear to have some of those features that being flexible would provide, were it actually flexible.

-Crat
http://lpmuds.net
20 Sep, 2011, Runter wrote in the 67th comment:
Votes: 0
I'm not a diku codebase advocate. Quite the opposite. I'm a fierce diku critic. I think LP is a much better choice. However, I am a facts advocate, and if my army ever finds itself between LP and Diku columns I'm going to order an attack in both directions. I think there's room for revolution across the board.

My only point was that LP isn't so far removed from a Diku that they're not comparable, or in a new technological sphere that's revolutionized the way we play or design text based games in 2011. And they do share similar flaws, and in fact, for many people LP is and always was the only mudding experience they know. In that regard, how has LP been revolutionized? A lot of the work you've done on Dead Souls as I understand it has been to incrementally improve the codebase while still following the ideals it was founded with. I think a tally figuring out where dikuish people are ahead and where LP people are ahead isn't useful, but I don't think all of the gold stars belong on the LP side of the tack board.

So revolutionary isn't a word I'd use. I don't mean to be pedantic, but my understanding of the word is that it means to effect revolution. Maybe LP's great message has been ignored for many years, but from what I see, there hasn't been any such great revolution at all. There's been small, incremental and usually overly careful steps towards what modern gamers have come to expect as minimal entry level features. LP people hold their favorite codebase up on a pedestal, other people hold their own up on their pedestal. I'm somewhat disappointed with the entire state of the mudding community at large. There seems to be little interest in progressing to the 1990's. Let alone, the new millennia.

LP's great power is that it's flexible in its design. I don't believe flexibility is a derivative of being related to LP. It's a derivative of a design principle. Reasonable people are going to disagree about the merit of a 'LP or bust' philosophy. I believe we can have flexibility in ways that are different from how LP muds do it. Because different games have different requirements, and a single codebase can't be everything for everyone. Embedding Lua, for example, as a scripting language allows for as much flexibility as is exposed. As much or as little. I consider the expressiveness and power of the language itself a factor in the flexibility.
20 Sep, 2011, Cratylus wrote in the 68th comment:
Votes: 0
Runter said:
So revolutionary isn't a word I'd use. I don't mean to be pedantic, but my understanding of the word is that it means to effect revolution.


Yeah a bit earlier I objected to the term myself. I think it makes more sense to respond to the OP's question
in terms of progress in interesting directions, else the thread is liable to devolve into partisan opinions of
what "revolutionary" means.

Note also I brought up MOO as an example of a flexible codebase. LP is definitely not the only one deserving of a pedestal, IMO.

I will chafe, tho, at ignorant sounding dismissals of LP as being basically good only for booting once a week rather than twice,
and implicit suggestions that diku scripts make up for differences in flexibility between LP and Diku.

-Crat
http://lpmuds.net
20 Sep, 2011, David Haley wrote in the 69th comment:
Votes: 0
Quote
and implicit suggestions that diku scripts make up for differences in flexibility between LP and Diku.

Well, if you think about it, a true embedding of scripting like Lua or Python into Diku is not that different from a driver running a scripting language.

Nobody's actually done this to the same extent, though, so there you have it.
20 Sep, 2011, Kjwah wrote in the 70th comment:
Votes: 0
David Haley said:
Nobody's actually done this to the same extent, though, so there you have it.


That you know about. :p
20 Sep, 2011, David Haley wrote in the 71st comment:
Votes: 0
Yes. It is true that I'm assuming that if somebody had actually integrated Lua (or other) scripting into Diku to the considerable extent that LPC is integrated into the LPMud driver, somebody would have mentioned it on the forums given that the topic attracts a fair bit of interest here. This seems like a pretty unnecessary assumption to state, but there you have it.

None of the scripting integration in Diku MUDs that has been discussed comes close to that level of integration.
21 Sep, 2011, Tyche wrote in the 72nd comment:
Votes: 0
Scandum said:
Tyche said:
I use type because I'm not converting strings of digits.

You're still converting an arrays of bytes.


Generally speaking this is not considered a conversion an array of bytes.

value = *(unsigned int *)buf;
buf = buf + (size_t)4;

or

mov( [ebx], eax );
mov( eax, value);
add( 4, ebx);

Rather than looping through a buffer of bytes, checking to see if each one is a valid digit, while looking for a delimiter, while copying them to another buffer, but not too many digits, and then passing that assembled buffer to something like atoi() or strtol(), and then storing the result in your variable. Or for even more work using some sort of regex().

That's the reason I use the data format I do. It's simple and efficient.
21 Sep, 2011, Splork wrote in the 73rd comment:
Votes: 0
Here is a link to our scripting language, it is not entirely up-to-date but I think you get the picture…
MUDL
Overview
functions

There is quite a bit missing but we add the majority of our new content through the use of this language…



Splork
21 Sep, 2011, Scandum wrote in the 74th comment:
Votes: 0
Cratylus said:
The "ed" line editor is pretty much the bane of modern LP coders, yes. Fortunately it is not the only option.
For building, you can do stuff like code a "Quick Creation System", for coding you can do stuff like
code a "Creator's Web Interface", or you can even implement a character mode editor so your coders can
use arrow keys and backspace and edit code in-mud without cryptic modes. In a pinch your creators could
also use your built-in ftp to upload code to their in-mud home directory, allowing them to use whatever
editor they like on their home PC. That's the neat thing about a mud with a built in dev environment. You
aren't stuck with the tools you start out with, and neither is your staff. This is an important
point for those of us with 80 hour work weeks…a system that lets your people help themselves is a gift.

ced looks like a step in the right direction as it offers integrated editing. Syntax highlighting is another important step to aid software development. I guess I should bring up MSDP as well as it provides an alternative to ftp to easily transfer data blocks (which can be compressed with MCCP) back and forth between the server and client. Large files might be problematic using traditional connection handling, which would be solved with Tyche's approach.


Tyche said:
Rather than looping through a buffer of bytes, checking to see if each one is a valid digit, while looking for a delimiter, while copying them to another buffer, but not too many digits, and then passing that assembled buffer to something like atoi() or strtol(), and then storing the result in your variable. Or for even more work using some sort of regex().

It's not all that cumbersome when using a central parser that generates events and ready to use data tables.

How to assemble something like the equivalent of MSDP's ROOM variable? I imagine it'd be rather verbose.
21 Sep, 2011, David Haley wrote in the 75th comment:
Votes: 0
Scandum, sometimes listening to you talk, I want to start talking about reverse polarity flux capacitors just to throw in some extra buzz words to cover the hash pointer lookup tables and centralized data table event-driven parsers.
21 Sep, 2011, Runter wrote in the 76th comment:
Votes: 0
21 Sep, 2011, Ssolvarain wrote in the 77th comment:
Votes: 0
David Haley said:
I want to start talking about reverse polarity flux capacitors


Those bathroom floors are slippery.
22 Sep, 2011, Tyche wrote in the 78th comment:
Votes: 0
Scandum said:
Tyche said:
Rather than looping through a buffer of bytes, checking to see if each one is a valid digit, while looking for a delimiter, while copying them to another buffer, but not too many digits, and then passing that assembled buffer to something like atoi() or strtol(), and then storing the result in your variable. Or for even more work using some sort of regex().

It's not all that cumbersome when using a central parser that generates events and ready to use data tables.

How to assemble something like the equivalent of MSDP's ROOM variable? I imagine it'd be rather verbose.


I'm not really known for being verbose. You might imagine that it's also very brief and fast.
26 Sep, 2011, Kjwah wrote in the 79th comment:
Votes: 0
David Haley said:
Yes. It is true that I'm assuming that if somebody had actually integrated Lua (or other) scripting into Diku to the considerable extent that LPC is integrated into the LPMud driver, somebody would have mentioned it on the forums given that the topic attracts a fair bit of interest here.


I've been working on something like this. It doesn't get mentioned because honestly, I can't be bothered. The MUD community sucks and I pretty much hate everyone that's vocal about anything so there you have it. :D
26 Sep, 2011, Cratylus wrote in the 80th comment:
Votes: 0
why you mad tho
60.0/128