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] 2 3 ... 43
Skylib Stuff / Adding a channel to the MUD
« on: February 02, 2018, 09:43:40 PM »
So, for some reason EVERY mudlib out there seems to refuse to document this process, leaving it to us to figure it out every time we try a new one.  Skylib shares this philosophy, and so this is what I've figured out so far.

There are two distinct parts to adding an existing I3 channel to your shiny new MUD.  This is *NOT* the process of creating a new channel, this is adding one that already exists out on I3 to the MUD and to the players, so you can actually USE it.

Step one is to make the MUD aware that a channel exists.  AFAIK, there are not commands or objects to let you do this dynamically, so you have to go edit a couple files and run a line of code.

One such file is /secure/include/intermud.h.  In here, you will find the following:

Code: [Select]
  "imud_code", \
  "imud_gossip", \
  "nschat", \
  "nscre", \
  "skylib", \
  "url", \

You don't HAVE to change this, but this is the initial set of I3 channels the MUD will know about.

The next file you want to look at is /global/player/channels.c.  In here, you will find a function called register_channels().  For some reason, this doesn't let you add new channels, but simply sets the player's channel list to be a set of channels that's pre-defined, with some added or removed based on security settings and the channel existing on I3 or not.

Code: [Select]
private void register_channels() {
    string *orgs;

    channels = ({"chat", "singing", "newbie"});

    if( adminp(TO) )
        orgs = ORGS_H->query_orgs();
        orgs = ORGS_H->query_my_orgs( TO->query_name() );

    if( sizeof(orgs) )
        foreach( string org in orgs )
            channels += ({ ORGS_H->query_channel(org) });

    if( creatorp(TO) ) {
        string name;

        channels += ({"cre", "discworld-chat", "dchat", "free_speech", "intercre",
                     "intergossip", "nipples", "killers", "nscre", "nschat",
                     "skylib", "url", "wileymud" });

That line there, channels += ({ ... });  That's where you need to add your channels.  This is actually Step 2, we're doing, which I will explain in just a second.

I said there were two steps to this process.  The first step is making the I3 router send you channel messages for the channels you want to hear.  You can add your channels into that default list, and I *THINK* the I3 handler will listen to each one when I3 connects to the router.

If you don't want to add them there, or I'm wrong, you can manually force the issue by typing a command like this:

Code: [Select]
> exec return INTERMUD_H->listen_channel("dchat", 1);

In that case, you're sending a packet to the router to say "I want to get messages for the dchat channel".

That will allow the MUD itself to see the channel and interact with it.  For a player to do so, we need the SECOND part, which I described above.

The parser for the player object will look at what you've typed and do a little analysis on it to figure out what you should be doing.  Part of that process is taking the first word and seeing if it matches an entry in your player object's query_channels() result.  If it does, it calls a function in the intermud handler with whatever you typed.

So, even though the MUD knows about dchat, until you go edit the player object code, the parser doesn't know what "dchat" means.

Once both parts are done, the new channel should work... except it won't yet.  Of course, one would expect to have to do the following commands:

Code: [Select]
> dupdate /global/player.c
> dupdate /secure/handlers/intermud.c

But that's not enough.  There's apparently something else that needs to be done to get this to actually work.  I don't know what it would be, as I don't understand the full layout of the mudlib... and so for me, I have to reboot the mud.  When it comes back up, whatever else needed to be done got done, and the new channels work.

Skylib Stuff / I3 mudlist fix
« on: February 02, 2018, 09:18:34 PM »
So, following the same idea as we did for Discworld, ages ago, to fix the mudlist packets being broken into chunks issue... which will make you not always see ALL muds out there, fire up your favorite editor and point it at /secure/handlers/intermud.c

A little ways down, you'll find the function mudlist_reply().  This handles the mudlist reply packet that arrives during the startup procedure, and whenever the server decides it has changed and wants to send out an update.

Code: [Select]
private void mudlist_reply( mixed *packet ) {
    mapping mudlist;
    string *tmp;

    if( sizeof(packet) != ( S_P + SIZEOF_MUDLIST ) ) {

    // Due to a change in the way mudlist packets are broken up and sent
    // in chunks by the server, we can't skip id's that are the same
    // as the last one we saw anymore.
    // Change this to < instead of ==, so we still skip OLD packets,
    // if they somehow appear.
    if( packet[ S_P + MUDLIST_ID ] < config->mud_list->id )

You could also just comment out the line entirely.  The main thing is, if you ignore the 2nd and subsequent packets with the same ID, you may miss mudlist entries.

General / Re: I3 flakiness...
« on: January 22, 2018, 04:33:04 AM »
Oh, one other thing worth noting.... since I *CAN* connect to *dalet, but *i4 refuses to talk to me, it would seem the IRN connection is somehow broken.  I would guess that *i4 still remembers my MUD being back in Kalamazoo and refuses to accept the new IP address... *OR* perhaps when I get violently disconnected from *dalet, becaue it wasn't a clean disconnect, it never notifies *i4 of my being gone, so it thinks I'm still connected and won't accept a new connection attempt?

General / I3 flakiness...
« on: January 22, 2018, 04:26:11 AM »
I like a good pastry as much as anyone, but I think flaky layers should be kept to biscuits and turnovers, not the I3 servers. :)

Code: [Select]
<: 20180122.055016.260 - INFO - (i3.c;int I3_connection_open(ROUTER_DATA *),6250)
 : Attempting connect to on port 8080
<: 20180122.055016.260 - INFO - (i3.c;int I3_connection_open(ROUTER_DATA *),6294)
 : Connected to Intermud-3 router *i4
<: 20180122.055016.360 - INFO - (i3.c;void i3_loop(),7071)
 : Connection to Intermud-3 router *i4 established.
<: 20180122.055016.360 - INFO - (i3.c;void I3_startup_packet(),1714)
 : Sending startup_packet to *i4
<: 20180122.055106.260 - INFO - (i3.c;void i3_loop(),7015)
 : I3 Client timeout.
<: 20180122.055106.336 - INFO - (i3.c;void I3_connection_close(bool),6327)
 : Closing connection to Intermud-3 router *i4
<: 20180122.055106.336 - INFO - (i3.c;void I3_connection_close(bool),6335)
 : Will attempt to reconnect in approximately 15 seconds.

*dalet will eventually connect, but loses connection randomly without any warning.  Since my ssh connection to the SAME host the mud runs on does NOT lose connection, it's clearly the I3 server dropping things.

Sure would be nice if we had direct access to the server side debug logs, so we could figure out if it's an actual code issue... or a network issue... or what.

Drivers / Re: Sending large strings through socket efuns
« on: January 11, 2018, 09:02:03 AM »
The LPC way is not to just make things bigger, but break the problem up into small enough chunks to manage.

There'e no reason to keep the entire document web in a single JSON object.  Break it up by category, keyword, pathname, however you like.

I would probably just make the web service accept a pathname as an argument for the POST, and then the document object as a second argument.  That way the web server can place things into file paths, or store them in SQL, or whatever you want to do on that end.  Retrieval would simply be by the pathname.  The only extra legwork would be providing an index to map pathnames to all topics.

You can still load/save the whole document archive, but you just may need to do it in a loop, perhaps across eval ticks via call_out() if needed.

Drivers / Re: unable to compile with GDBM
« on: January 04, 2018, 02:26:54 AM »
It's a linker error, not a compiler error.

Unresolved symbol means the linker can't find the function referenced.  Check the contents of "system_libs" to see if gdbm is in there.  It's likely that the script which builds that system_libs is broken for all but the most common use cases.

Open Chat / Re: Merry Christmas and a happy New Year!
« on: December 30, 2017, 09:15:56 PM »
Merry Almost New Year!

Drivers / Re: new driver development.
« on: December 30, 2017, 09:12:00 PM »
In classic LPMUD there are two main issues with security.

The first is the ability to spoof privileges to give yourself "admin" access to the filesystem and corresponding game commands.  In a traditional MUD, developers used to be organized by "domain", so that they had the ability to write to their own directory and whatever subdirectories they were actively working on (assigned to).  Likewise, their objects would only function in their home room(s) and those areas.  Putting things, such as new weapons that players would carry through the game world, into the system areas required higher level access.

The second was the ability to spoof the driver to grant yourself arbitrary filesystem access outside the game.  Obviously that's worse, since you could write to anything the MUD account has privs to.

When most people talk about MUD security, they're usually talking about the former, since having a new wizard in training be able to wipe out the whole game is usually a bad thing. :)

Open Chat / Re: Quick and Easy MediaBox
« on: December 09, 2017, 11:42:47 AM »
Is there a popular digital tuner card that works well for such things these days?  I think I had a "happague" back in the days of analog TV, but these days you'd need a card with multiple digital tuners to be able to properly take the place of a tivo device.

Also needs to cost less than a tivo. :)

Code Vault / Re: New RealmsMUD core library
« on: December 08, 2017, 09:14:50 AM »
I just put all my stuff on github.  You can manage your local repository with whatever system you like and push a copy to github for "release" whenever you want.  No need to actually USE github for anything beyond a public repository host.

Open Chat / Re: Elder Scrolls Online
« on: October 07, 2017, 01:40:17 AM »
There are always dungeons that need doing.  I think I have a quest for the Undaunted guild that needs me to go into Spindleclutch, normally a 4 man dungeon.

Open Chat / Re: Elder Scrolls Online
« on: October 05, 2017, 11:19:43 PM »
The nice thing about TESO is that everything level scales, so you don't need to be any particular level range to play together.  I'm just working my way through the Glenumbria content, trying to remember to actually do some crafting research.  Not a big dungeon person though... not adverse to trying one, but the only game I ever did casual dungeons as a normal daily thing was World of Warcraft back in the Lich King expansion.

Drivers / Re: Link for repository of fluffos-2
« on: September 15, 2017, 11:16:52 PM »
I'm not sure how much more clearly I can possibly state this.

Code: [Select]
tar xvf dw_fluffos_v3.tar.bz2
cd dw_fluffos_v3
git clone fluffos_quix
git clone fluffos_carter
cd fluffos_quix/src
... adjust local_options to work for discworld ...
make install
cd ../../bin
... adjust dw.cfg ...
cp -p ../fluffos_quix/bin/driver .
cp -p ../fluffos_quix/bin/addr_server .
cp -p ../fluffos_quix/bin/portbind .
cd ../lib
... adjust a couple of well-known issues in the mudlib LPC files ...
cd ../bin
./addr_server 4999 &
./driver dw.cfg &
... telnet to game, verify that commands work and I3 connects, chat on I3, shutdown game ...
... kill addr_server process ...
cd ../fluffos_carter/src
cp -p ../../fluffos_quix/src/local_options .
make install
cd ../../bin
mv driver driver.quix
mv addr_server addr_server.quix
mv portbind portbind.quix
cp -p ../fluffos_carter/bin/driver .
cp -p ../fluffos_carter/bin/addr_server .
cp -p ../fluffos_carter/bin/portbind .
./addr_server 4999 &
./driver dw.cfg &
... telnet to game, notice that I3 connects, but all commands are queued ...
... kill driver and addr_server processes ...

You see what I'm getting at here?  ZERO CHANGES to the mudlib.  ZERO CHANGES to the local_options file.  CLEAN BUILDS of the C and C++ versions.  C version works, C++ one does not.

Now, if you want to leave fixing it as an exercise to the reader, that's perfectly fine.  I'm simply trying my best to report that this is a bug, a change in behavior, between the C version of the driver and the C++ one.  If this isn't clear enough to convince you that I'm not an idiot and did indeed plug the power cord into the wall, I don't know what else to do. :)

Drivers / Re: Link for repository of fluffos-2
« on: September 12, 2017, 04:41:46 PM »
The post I found said they fixed their problem but never elaborated on HOW they fixed it.

There may well be a workaround in the LPC code, but I assumed you were aiming for the driver to be a drop-in replacement for the older C version.

For my test case, I unpacked the discworld lib, compiled the driver from my own git repository (version 2.27.2), and verified that it worked, connected to I3, and I could walk around and do a few basic things.  Then I compiled the newer C++ version of the driver using the same local_options files and booted the same mudlib, in place, with that newer driver.  The result is that it boots, connects to I3, but logging in results in "Command Queued" no matter what you type.

Since the mudlib code has not changed, and the configuration has not changed, this must be a change in the driver's code, somewhere.  Since it has to do with delays, my initial guess is that it might be related to the posix timer stuff, but that's just a guess.

Drivers / Re: Link for repository of fluffos-2
« on: September 12, 2017, 05:26:57 AM »
It's a change in the driver behavior... for good or bad, I don't judge.  However, I'm using the exact same mudlib on your driver that I'm using on the old 2.27.2 driver.  What Discworld uses to do its "queued command" logic, I don't know... but whatever it is, the driver is acting differently.

Pages: [1] 2 3 ... 43