(No Title)
Sigma MUD Server Documentation
Check it out. That’s the current, documented program. Cool, huh?
Sigma MUD Server Documentation
Check it out. That’s the current, documented program. Cool, huh?
Neil Cavuto:
So the United Nations is all hot and bothered over leaflets. That’s right — leaflets. Not the insurgents’ leaflets — the ones that talk of murdering anyone who dare goes out and votes. Not a word about them.
No, they are upset at “our” leaflets. The ones that simply remind Iraqis they have the chance to vote. They’ve plenty of words about them. The U.N. claims that we’re taking sides.
So, let me get this straight: Celebrating democracy is bad. Promising to butcher those who practice it is good?
Only a body of soulless bodies like the U.N. could ignore the sacrifices for freedom and all but endorse those doing everything in their power to squash freedom.
Why doesn’t the United Nations just put out a sign that says, “You go, butchers!” At least that’d be more honest than the sneaky, sniveling, backstabbing way these disingenuous bastards are acting now.
Never mind the fact that the U.N. stood by when another Iraqi butcher had his way with his people. They’re just as happy to do the same as new butchers try to have their way with the same people.
All I ask of the U.N. is to show your true colors. Admit it’s not the Iraqi people you care for at all. It’s not their home you want to protect. It’s your own sorry asses on the thoroughly wasted piece of Manhattan real estate that you call yours.
I know your greatest hurdle is securing dinner reservations at Lutece — figures, French.
Just understand that the people whose fates you blithely ignore, want to secure something a tad more meaningful.
So look in the mirror. Then get out of “their” face.
Another proof of concept:
Python doesn’t like pointers too much, so how do you identify a Player, Room, Item, or whatever within Python and make the C++ API able to modify the correct object? Well, here’s an idea that seems to work:
Memory addresses (void*, castable to any class or data type pointer) are of type long int. Since we’re not in quantum here, only one object can occupy a certain memory address. So, cast all pointers to classes as long integers and send them via the Python API to the script. The API functions will accept long’s (not like Python checks types anyway) as arguments to in-script manipulation functions like GiveItem() or something. When the C++ API receives these longs as arguments, it casts them back to class pointers and dereferences them.
This seems to work. I like that it seems to work.
Food for thought…
MUD Update (What Else, Lately?):
- The “go” command (as well as appropriate symcommands “west”, “east”, “north”, “south”, “up”, “down”) work on what we might call a pseudorandom basis, meaning that go doesn’t listen to the arguments passed to it (like “west”), it just picks an available exit and goes there. I’m just too lazy and preoccupied with other things to write a token parser right now.
- We are (AFAIK) segfault-free. Nice to fix the problem by upgrading a shared library (written by someone else). Affirming to know it was their problem, in a weird sort of way.
- Multi-area, multi-file XML importing and parsing is fully enabled for room data. It’s wonderful to use open standards for such a normally-closed file format.
- The Python embedding/extending concept was proved this morning. No real work, but I’ve pulled in the header files and am linking against libpython2.3.so right now, so that looks great. I ran some null code through it hard-coded and it didn’t take a dump on me (I’m just realizing the pun potential with “core dump.” Goodness gratious.) For the skeptical out there, I also ran some “bad” (erroneous) null code and it DID take a dump. Gracefully.
- Looking into a concept called “functors” (classes that encapsulate functions using an overloaded parenthesis operator). Mucho weirdo, but I’m currently fighting to get class member functions (i.e., accessors and modifiers [gosh I hate those terms]) that will provide a Python interface for the master players list, etc. The Python interpreter will only hold pointers to C-style static functions as opposed to class functions (which actually are called with a hidden Class this pointer). The idiot solution I came up with in bed this morning:<br />Server</strong> ServerObject(Server* server = NULL)<br />{<br /> static Server* the_server;<br /> if (server)<br /> the_server = server;<br /> return the_server;<br />}<br />
I could “register” my server class in the static variable with this function at the beginning of API registration and then call it to retrieve the pointer from API functions. Functors might smooth this out, but I have a lot of reading to do (since today is the first time I’ve been exposed to them, thanks Google).
Anyway, off to shower.
<br />void<br />Player::SendWrap(const char* message, int indent)<br />{<br />int base = 0, offset = (WRAP_LINE_WIDTH - 2), end_pos = (strlen(message) - 1);<br />char line[WRAP_LINE_WIDTH];<br /><br />while ( (base + offset) < end_pos ) {<br />while ( ((message + base + offset) != ‘ ‘) && (offset > 0) )<br />offset–;<br />if (offset <= 0)<br />offset = (WRAP_LINE_WIDTH - 2);<br />strncpy(line, (message + base), offset);<br />(line + offset) = ‘
Memory holes are patched. A few basic commands and I’ll need to write a Circle->XML world file converter script and start making a game!
When Insomnia Strikes
A little update rundown for your enjoyment:
Well, d20 is turning out to be a disappointment. As I’m now preparing to start the command interpreter, I’m trying to make sure I’m okay on how to implement combat, skills, and other things like that. It looks like d20 is primarily written for tabletop/pencil-paper game settings, so I think implementing the rules verbatim would be impractical. However, the combat system (basically a la NWN) is great, as are the stats, saving throws, etc.
I don’t really feel like remaking NWN by implementing all their stupid skills, so I think I’ll borrow their math and stats and implement everything else on my own. d20 doesn’t even specify how characters are created or how experience is earned.
This should end up being a good thing. I think it will allow flexibility and standardization at the same time.
The MUD master command queue is now functional!!!
Let’s party!
Oh, wait. It’s 2:00 AM. Let’s sleep.
Alright, so the MUD project had some success tonight. Allow me to elaborate architecturally:
In anticipation of Python, Coming Soon™, I envision a method in which commands may be inserted into the normal command search list at arbitrary positions based upon some XML-based, Coming Soon™, command map. Let’s take a look at an example of what I see for the future before I go into tonight’s progress:
C++ (Built-In) Command Map for G
go
giggle
gasp
In the fashion of Circle, the command parser would traverse this list (assuming the command started with “G”), matching the typed command to the first appropriate function call (“g”=”go”, “gi”=”giggle”, etc.).
Now, imagine an XML tag for an inserted Python function:
“name” defines the official name of the function, “src” tells the server where to grab the Python code, and “priority” tells the server where to insert the function. The task of “priority” is accomplished by the server acting as though a user typed the “priority” string. The appropriate handler mapping (in this case: “ga”=”gasp”) is performed. At this point, the new Python command is inserted BEFORE the mapped command, in essence giving the inserted command priority over the shortened string “ga”. Of course, a bottom priority for the command could be specified by giving “h” as the priority value.
Now, on to today’s work:
The big question is, how do we make Python and C++ coexist? The answer lies in function pointers. Both the C++ calls and the Python embedded function lookups return pointers to functions (albeit of far different structures). So, I created a class Command, which is an abstract class. The class is made to be abstract by including the pure virtual function CallFunction(). Currently, there is a CxxHandler class that inherits Command and provides an implementation of CallFunction(). This CallFunction() interacts with a function pointer (to a C++ function) that points to a C++ function defined by macro as a friend of the Server class. The anticipated PyHandler class will fill a similar role, but it will include a private function pointer to the Python interpreter’s location of the Python function. CallFunction() will resolve the syntactic details of the different function calls.
This way, a normal linked list that holds Command objects can be used without exceptions based upon the implementing language. Function calls are wrapped on a per-instance basis by CallFunction().
This architecture was proven tonight, as a handler called “fallback” was defined to print “Huh?” when an unknown command is typed. This is currently the default and only command available to the growing interpreter.
Yay!