Recent Posts

Pages: [1] 2 3 ... 10
1
Drivers / Re: new driver development.
« Last post by silenus on April 12, 2018, 10:44:58 AM »
I have been doing some other things for a little while but I would like to get back to learning some programming. Is anyone here familiar with Rust? My understanding is that it's a systems programming language like C/C++ but perhaps a bit easier to learn and with a cleaner syntax. I am wondering how much work it would be to write a parser in it for a version of lpc by essentially translating some of the fluffos code in the compiler in vm into it.
2
Intermud / Re: New I3 Routers - Now Online
« Last post by Adam on February 19, 2018, 09:31:02 AM »
Currently, their is a sync issue between the routers in relation to channels, we are aware of this and working to resolve this as soon as possible within the next  2 - 12 hours

Thank you for your patience.


All Routers are now in sync, the collective mind has been restored, resistance is futile... [20/02/2018 7.00am AET]
3
Intermud / New I3 Routers - Now Online
« Last post by Adam on February 18, 2018, 12:00:39 PM »
Two new i3 routers are online and part of the LPMuds.net IRN network:

*wpr   
IP: 195.242.99.94
Port: 8080
Location: Netherlands, Europe
Maintainer: Aidil@Way of the Force

*Kelly
IP: 150.101.219.57
Ports: 8080, 8787
Location: Victoria, Australia
Maintainer Adam@Dead Souls Dev

Full router list: https://www.themud.org/imc2i3-routers.php
4
Skylib Stuff / Adding a channel to the MUD
« Last post by quixadhal 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]
#define DEFAULT_CHANNELS ({ \
  "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();
    else
        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.
5
Skylib Stuff / I3 mudlist fix
« Last post by quixadhal 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 ) ) {
        packet_invalid(packet);
        return;
    }

    // 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 )
        return;

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.
6
Drivers / Re: new driver development.
« Last post by silenus on January 30, 2018, 09:34:20 PM »
I think obviously you have function call checking already probably not too hard to add that if you want. I am currently working on hacking garbage collection (something that js has built in) into fluffos. Quite a bit of spadework involved. Mostly involving tracking down where candidates for the root set are. I am almost done though. I will see if I can get the whole thing finished by the end of the week. After that I will probably try to assess how much work it is to use LLVM as a JIT for fluffos. Probably try to just do some sort of call threading for now and make it very minimal.
7
Drivers / Re: new driver development.
« Last post by kriton on January 29, 2018, 07:15:14 PM »
Well I am not saying that a noninstrumentation approach does not work but I think instrumentation is quite general and can cope with a multitude of problems if used correctly. The perhaps canonical method for doing this is to find all loop backedges and do some sort of check on each one (perhaps have a counter) and do the same for every function entry. What is __bfc() and __efc()?

__bfc/__efc (begin/end function call).  I am asserting alarm time and maintaining an object stack (for this_object / previous_object functionality and for valid_* applies).  The loop assertion does have a counter so it's not doing a full assertion on every pass through the block.

I ended up passing a handle through the block with another user-restricted identifier (__ctx) :P

I am also thinking about adding protected/private modifiers for properties and methods to be more like other languages.

Code: [Select]
    setRouterList(data) {
        let __ctx = __bfc(this, 'setRouterList'); try { var routers = { length: 0 };
        Object.keys(data).forEach(function (id) {
            let __ctx = __bfc(this, 'undefined'); try { if (id.startsWith('*')) {
                routers[id] = new I3Router(data[id]);
                routers.length++;
            } } finally { __efc(__ctx); }
        });
        this.setProtected('routerList', routers); } finally { __efc(__ctx); }
    }
8
Drivers / Re: new driver development.
« Last post by silenus on January 28, 2018, 06:07:27 PM »
Well I am not saying that a noninstrumentation approach does not work but I think instrumentation is quite general and can cope with a multitude of problems if used correctly. The perhaps canonical method for doing this is to find all loop backedges and do some sort of check on each one (perhaps have a counter) and do the same for every function entry. What is __bfc() and __efc()?
9
Drivers / Re: new driver development.
« Last post by kriton on January 27, 2018, 10:24:36 PM »
I am relying more and more on instrumentation.  I am now trying to use it to maintain the object stack but allowing async code makes things so messy.  I really don't want to insert an actual context reference in user code but... I need to go buy a whiteboard I think.  A method is called, the current object/method are put on a stack but if there is a context while executing that method things get messy fast.

Code: [Select]
    cmd(args, cmdline) {
        __bfc(this, 'cmd'); try { let player = thisPlayer,
            dirList = [],
            options = 0,
            flags = 0;

        for (let i = 0; i < args.length; i++) {
            __ala(); let opt = args[i];
            ...
        }
        ...
        this.removeDirectories(dirList, flags, options, cmdline); <-- bunch of async stuff
        return cmdline.complete; } finally { __efc(this, 'cmd'); } <-- __efc / getContext() may or may not get right value.

Such a headache!
10
General / Re: I3 flakiness...
« Last post by Adam on January 22, 2018, 09:31:34 AM »
Well, we did test ur connection on my test router and everything works flawlessly, even reconnects. So quix is right there is a definite issue with both current IRN routers.

Hopefully, with the introduction of *wpr and my router to IRN we can get to the bottom of this, I know I'll be making the debug logs public
Pages: [1] 2 3 ... 10