Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - quixadhal

Pages: 1 ... 41 42 [43]
631
Dead Souls Support / Re: Controlling hunger and thirst
« on: September 19, 2007, 04:56:46 PM »
One general idea to toss out here.

In Dikuland, we often did things based on a tick counter, and that tick counter was simply an ever-increasing integer which was incremented in every driver loop.  So, if the driver loop happened every half-second, and you wanted something to happen every 4 seconds, you'd run it when tick%8 == 0.

If the driver itself doesn't keep track of heart-beats, perhaps the mudlib could keep a global read-only variable which gets incremented every heart-beat.  The resolution would only be every 2 seconds (by default), but it would give you a clock to work from.

I suppose there might also be an efun to get the current system time, and you could use that (number of seconds) for the same purpose. :)

632
Design Lab / Re: multi-threaded versus single threaded mud servers
« on: September 19, 2007, 04:15:22 PM »
For me, the question boils down to benefit vs. cost.  There are benefits from having multi-threaded lpc execution, but those benefits don't really show through to the end user unless you design a really different kind of real-time game.  Something like the hand-to-hand combat in Gladiator Pits comes to mind.  The driver itself can already be multi-threaded to handle things like blocking I/O, DNS lookups, etc.

The costs though, are quite a bit more immediate.  As others have said, you have to sprinkle mutex code all throughout every aspect of your game.  Consider a simple fight where a mob hits you and you cast a spell of reflect damage.  In a single threaded driver, this is easy.  If you go first, the attack bounces and damages the mob.  If they go first, you take the damage and either flub the spell, or it goes up late and the next attack hits it.

In a multi-threaded interpreter, if you don't mutex lock the combat events, one thread may start doing the attack, get to the part where it gives you damage... then the spell thread goes through... then perhaps the attack thread picks up and sees there's a spell effect, and does the damage to the mob as well.

Not a great example, but somewhere, mutex's have to be put into play to avoid partial effects that aren't intended.

The real cost though, is in debugging.

Have you ever debugged a multi-threaded application?  It's not pretty, and even when you lock things down in gdb, it's still a pain to have to flip back and forth between threads to look at the states of everything and figure out which part is firing out of sequence.  Without a real debugger that can step through LPC code in multiple threads (and how would you do THAT in a live mud?), it would be down to debugging statements and timestamps.

So, the question is.... is there ANYTHING you've ever tried to do in a mud which has ever come even close to hitting the CPU limit of a reasonable machine these days?  If the answer is no, don't even worry about multi-threading at that level.

If you just want to do some multi-threaded programming... how about a database script which handles transactions between lpc threads as an external proxy?  The discworld folks are using sockets to do their database activity through a python script instead of trying to get the MudOS driver to do it... a multi-threaded version of that might be pretty cool.

633
Design Lab / Re: new server design- call for features
« on: September 18, 2007, 02:56:27 PM »
I am currently looking into what sort of issues would arise if the system ends up being multithreaded.

You might want to wander over to the DGD camp and ask Dworkin a few questions about DGD/MP.  He's been working on a multi-threaded version of DGD for some time, and can probably give you a long list of things to stumble over and hit your head on. :)

634
Dead Souls Support / A couple of polish things.
« on: September 16, 2007, 10:02:02 PM »
So, I got ds2.5a12 up and running under fluffos 2.7.  Hooray!  It looks nice and simple so far, I'll hopefully have more time to dig into it this week.  Anyways, I just have a couple of little "polish" suggestions, which aren't critical in any way.

All the files which handle logging in, both the initial install one, and the final one, have extra newlines which place the prompt on the left edge of the screen, below the place it logically should be.  Not a big deal, but an easy fix whenever that file gets visited for something else.

The initial login process (for me, at my terminal size of 34 rows) stops at the "sourcing boards" command.  That is to say, it appears to be frozen.  I let it sit for a few minutes assuming it was loading and indexing something.  When I hit return, it immediately continued on, making me go "D'oh!".  If that's the place it pauses for everyone, a "hit return" prompt would be nice.  If I just got lucky, no biggie.

When doing a short directory listing (ls), I notice some files show up zero padded, others not.  Is there any reason for this, and if so what does it indicate?
Code: [Select]
004 biography.c     1   language.c      002 skills.c
 1   brief.c         001 lines.c         1   speakcolor.c

Finally, just a comment about I3:  I've always liked it and actually added support for it to a couple of old Diku's and a barebones mud.  However, my server was only up for 15 minutes before I got spam from "RSS_Bot@Rock the Halo" on the inews channel.  What do you guys do to smack those people? :)

Thanks!

635
Drivers / Re: FluffOS-2.7
« on: September 16, 2007, 05:52:38 PM »
I have a small patch for FluffOS 2.7 which I needed to compile under Debian/Etch linux.  I ran ./build.MudOS developer and used local_options.ds.

Code: [Select]
diff -uraP fluffos-2.7/add_action.c fluffos-2.7.new/add_action.c
--- fluffos-2.7/add_action.c    2007-08-03 17:25:07.000000000 -0400
+++ fluffos-2.7.new/add_action.c        2007-09-16 17:57:30.000000000 -0400
@@ -1,6 +1,8 @@
 #include "std.h"
 #include "comm.h"
 #include "backend.h"
+#include "eval.h"
+#include "efun_protos.h"
 #include "add_action.h"
 
 #ifndef NO_ADD_ACTION
@@ -227,7 +229,7 @@
        return;
 
     debug(d_flag, ("Enable commands /%s (ref %d)",
-                  current_object->name, current_object->ref));
+                  current_object->obname, current_object->ref));
 
     if (num) {
        current_object->flags |= O_ENABLE_COMMANDS;
@@ -266,7 +268,7 @@
     int where;
     int save_illegal_sentence_action;
     
-    debug(d_flag, ("cmd [/%s]: %s\n", command_giver->name, buff));
+    debug(d_flag, ("cmd [/%s]: %s\n", command_giver->obname, buff));
 
     /* strip trailing spaces. */
     for (p = buff + strlen(buff) - 1; p >= buff; p--) {

Hope that's helpful.  There's probably a better choice of include files to get those function prototypes, but I'm a n00b again, so I'll let someone more qualified fix it the right way. :)

636
General / Logout AI
« on: September 16, 2007, 04:15:38 PM »
Not sure if this is really a driver question, a design question, or a specific mudlib question.  ???

In any case, I was reading the code for object persistance and it occured to me to ask if it's possible, in MudOS and perhaps under DS, to rehook a player object so that it becomes an NPC when the player logs out, and (if still loaded) again rehook the connection object to it when they log back in?

One of the things I always felt important to a really persistant world, was the idea that all players would be in it.  Just as mobs wander about doing whatever they were coded to do, likewise, players could be sleeping in an inn, or their own castle -- or perhaps they would choose to let the AI roam them about to try and gain minimal treasure.  That would allow really unique objects to exist, and if a player didn't purchase enough traps/guards/other safeguards to protect themselves, they could be stolen.

Not everyone's cup of tea, I'm sure.  But it was a thought, and I figured I'd ask folks who've done low level mudlib coding before I hurt myself too much. :)

637
Design Lab / Perlin Noise and The World(TM)
« on: September 16, 2007, 02:56:51 PM »
Hey all,

I'm just starting to get back into fiddling with muds, so this is mostly just a feeler to see how much anyone else has done with, or is interested in, procedural world generation.

The goal is to have a fairly realistic feeling world, where players really can get lost in thousands of rooms of forest, and be able to have both random encounters and carefully crafted places.  I'd like to spent more of my time working on the carefully crafted places, but not give up that large world feeling.  The old Diku I worked on had several large grassland, jungle, and wooded areas... most of which involved a great deal of cutting and pasting with minor variations.  Yuk. :)

The concept is to use something like Perlin noise (http://en.wikipedia.org/wiki/Perlin_noise) to have a giant semi-realistic world map which can be evaluated in small chunks as players wander into the area.  As a builder wanders around (or looks at an overhead rendering by an external application) and finds a nice looking area, they can edit rooms which then become real rooms.

I know people have done similar things with the old virtual grid system and large ASCII files for the map, but I'd rather avoid the fixed-size file and use a procedure.

The bits involved seem to be:

(1)  A virtual description system that is good enough to let the players "see" what is up ahead, but not sound totally cut-and-pasted or totally random.  Much of that would come down to the number of phrases for each terrain type, and how well they meshed.

(2) A virtual "grid" which is smart enough to load real rooms if they're present or call the procedural generator if not.  Ideally, it would load a block of rooms around the player, and allow them to be unloaded if they were left empty and idle for long enough.  The old nightmare/TMI versions were pretty close to this, as I recall.

(3) The actual terrain generator, which should evaluate all the properties of a given point so a room can be generated to fit.  Assuming the fractal or noise system is tweaked properly, adjacent rooms should be similar to each other more often than not.

Comments?  Suggestions?  Yawn, been done before?

638
Drivers / Re: FluffOS-2.7
« on: September 16, 2007, 02:18:29 PM »
changes in Fluffos 2.7:
...
read_file() can now read compressed files.
write_file() now has an extra flag (2) that can be ORed with the existing one
             to write/append compressed files

Just a quick question, what kind of compression is used?  bzip2, gzip, or something else?  I suppose I could fire it up and see.

add_ref() destruct objects with high ref counts (they're usually on the way to
          wrap around to 0, which is where you crash).

Wouldn't it be safer to have a check in the part of the driver which actually does add to the reference count so if (ob->ref_count >= MAX_REF - amount_to_add) boom()?  I mean, assuming the ref counters are at least 32 bit, you shouldn't ever get up there unless your code is broken in some way, but who knows -- maybe someone really has enough RAM to make a 64K x 64K grid of rooms. :)

Thanks for the continued work Wodan.  It's pretty cool to revisit the mud community ten years later and see it still alive and kicking.

639
Design Lab / Re: Pathfinding
« on: September 15, 2007, 10:24:27 AM »
Just as a quick note, you will probably want to add in an option to control the weight of closed doors and locked doors (for which you don't have the key).  The shortest path is only the shortest path if you can actually travel it. :)

(NB: I haven't actually looked at the code yet, so if it's in there, you can tell me to go back to the corner)

640
Design Lab / Re: new server design- call for features
« on: September 15, 2007, 10:19:11 AM »
The ability to use an SQL database, both for storage and for logging (statistics). :)

Pages: 1 ... 41 42 [43]