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 ... 42
1
*sounds of gunfire and explosions*

Hey... *cough*  to anyone reading this...

*BOOM!*

*cough*  It's almost too late for us.  Emperor Trumpu has declared martial law, because he thought it was marital law.  The Russians used our email servers against us, and the millions of Walmarts around the country turned out to be Chinese troop staging areas.

*whistling rocket sounds, then another big explosion*

We never stood a chance.  They offered us cheap NES classic emulators on Black Friday, and cut us down like grass beneath a lawn mower.

I'm sending this message back in time, from the future!  In 2019, it's too late to do anything... but there's still ONE chance for you to stop the apocalypse!  Release a new Discworld distribution lib before Christmas, 2017!

Save the mudlib, save the world!

Oh no... Education Secretary DeVoss, Crown Prince Pence, and Emperor Trump are starting to form Dumbtron!  It look like that's the...

*end of transmission*

2
Drivers / Re: FluffOS v2.27.2 (Unofficial)
« on: May 01, 2017, 12:57:55 PM »
Actually, you can see what changed via:  https://github.com/quixadhal/fluffos/commits/master

I generally force move the tag along as I commit things, so 2.27.2 should be the most recent commit, even though you'll have to check all 5 actual commits to see all the changes (including my typos, and whatnot). :)

3
General / Re: LPMuds.net is back!
« on: April 25, 2017, 04:03:18 PM »
Always nice to see a new evil dictator rise to power.  Welcome Adam!

4
General / Re: wanting to loose this_player()
« on: February 28, 2016, 08:32:28 PM »
Well, if you're not using the built-in map code, but some custom stuff, that's even easier.

You put a general function in the reset() routine for every room that updates the player's map data.  reset() is called when something causes the room to be loaded, and if this_player() isn't set, that bit of code doesn't need to do anything.

Use the pre-exit hooks for your various security checking things, which shouldn't need to load the room itself, unless your check involves the contents of the room.  In any case, you can always ensure that you're only updating map data for environment(this_player()), even if they do trigger something.

As for finding all those things... assuming you used some kind of semi-standard thing like SetExit() or SetExits(), grep should find occasions where there's happy code nearby.  I forget the flags, but I know GNU grep has flags to check context so it can find things within N lines of the actual thing you look for.

5
General / Re: wanting to loose this_player()
« on: February 27, 2016, 05:33:12 PM »
Well, the mapper is just an NPC that walks around the rooms to map them.  So, of course it won't have a valid this_player(), but it does have a valid this_object(), and can certainly use enviornment() to see things about where it is.  So, to me, it seems like the solution is to not make your various exit checking routines rely on using this_player(), and if you want them to treat players and npc's differently, put the PC only code behind a check to see if this_player() is valid.

And you shouldn't be making 10,000 copies of almost identical functions.

Put your exit check functions into a small handful of objects (likely one for each domain), and have them inherited by the rooms, so the code isn't duplicated.  I seriously doubt you have 10K room exit functions that ALL do different things, they likely just do the same thing with different rooms and exits in their checks.

6
General / Re: wanting to loose this_player()
« on: February 27, 2016, 08:19:28 AM »
Make some_function() not use this_player(), but instead use this_object()?

Don't subvert the functionality of something that's used throughout the entire mudlib with a known and expected result to work around a local issue.  If your issue is with the way your exit check functions are working, change your exit check functions to be more predictable for your use case... don't change this_player() so it now doesn't perform its intended function.

7
Drivers / Re: new year resolution
« on: January 13, 2016, 01:34:48 PM »
If you're horrible enough to want to code in javascript :(

8
Drivers / Re: new year resolution
« on: January 10, 2016, 02:53:50 PM »
OK, fine. :)

How about a package that integrates libpng (or similar) to allow for the easy retrieval of blocks of graphical data from files without needing to parse binary stuff in LPC?

IE: if you wanted to use a large high-resolution image for your world map, via virtual rooms, you might want to grab blocks of 3x3 or 5x5 pixels at given coordinates so you can generate dynamic descriptions of the room and its surroundings.  Asking libpng for that is easy.  Parsing a PNG file in LPC... not so much.

9
Intermud / Re: Intermud-3 router status
« on: December 27, 2015, 08:20:29 AM »
Merry Christmas!

2015.12.27 -- *dalet is dead, *i4 is up, but nobody using the stock code will know that, as the intermud code is hard-coded to use router[0][0] in lots of places, rather than walking down the list when one is down. :)

Might be a good time to fix that, or at least hire someone to go physically kick *dalet again.

10
Code Vault / urlbot extension to chat daemon.
« on: December 27, 2015, 06:28:46 AM »
Hey guys, with the help of Drakkos and Aidil, I finally got around to changing my MUD to use a built-in solution to populate my URL channel, instead of the tinyfugue triggers I'd been using.

This should serve as a handy example of how to use external programs with fluffos.  NOTE:  I don't redirect errors away to NULL or anything... you might want to or everyone will see error messages on your channel. :)

For those who don't know... a while back, I write a small perl script to go get information about URL's that get posted to various intermud channels.  Because I didn't have a way to do the kind of regexp matching on channel input I needed, I programmed some triggers in my client to handle it and splat the result out to a specific channel.

This worked pretty well, but required me to be logged in (not a problem), and would break on occasions when the mud output line wrapped or otherwise disrupted the pattern.  I was thinking of making an NPC to listen to and respond to the I3 traffic, but Dead Souls makes it obnoxiously hard to do this for "security" reasons.

So, the next best thing was to code it inside the chat daemon itself, where all messages have to go anyways.  Dead Souls ALSO tried to stop me here, but a one line fix removed that "security" feature. :)

So, here's the goodies.

Code: (mudos.cfg) [Select]
# The external programs we allow to be run.
external_cmd_1 : /home/bloodlines/bin/untiny.pl

Code: (/daemon/services/channel.c) [Select]
@@ -83,7 +83,7 @@ void eventReceiveChannelMessage(mixed array packet) {
     tn("eventReceiveChannelMessage: "+identify(packet),"green");

     if( file_name(previous_object()) != INTERMUD_D ) return;
-    if( packet[2] == mud_name() ) return;
+    if( packet[2] == mud_name() && packet[3] != "chat_d" ) return;
     if( !packet[2] || packet[2] == "" ) packet[2] = "BustedAssMUD";

     CHAT_D->eventSendChannel(packet[7] + "@" + packet[2], packet[6],

Code: (/secure/daemon/chat.c) [Select]
static private mapping url_callback_buffer = ([]);

void url_read_callback(int fd, mixed msg) {
    if(member_array(fd, keys(url_callback_buffer)) < 0) {
        url_callback_buffer[fd] = "";
    }
    url_callback_buffer[fd] += msg;
}

void url_write_callback(int fd) {
    // This should never happen.
}

void url_close_callback(int fd) {
    // Here, we should send off the result we got back.
    SERVICES_D->eventSendChannel("CHAT_D", "url", url_callback_buffer[fd], 0, "", "");
    map_delete(url_callback_buffer, fd);
}

int check_for_url(string channel, string msg) {
    mixed check_url;
    int fd;
    string check;
    string *patterns = ({
        "(https?://www.youtube.com/watch\?.*?v=[^&\?\.\ ]+)",
        "(https?://tinyurl.com/[^&\?\.\ ]+)",
        "(https?://bit.ly/[^&\?\.\ ]+)",
        "(https?://goo.gl/[^&\?\.\ ]+)",
        "(https?://mcaf.ee/[^&\?\.\ ]+)",
        "(https?://migre.me/[^&\?\.\ ]+)",
        "(https?://durl.me/[^&\?\.\ ]+)",
        "(https?://is.gd/[^&\?\.\ ]+)",
        "(https?://dailym.ai/[^&\?\.\ ]+)",
        "(https?://ebay.to/[^&\?\.\ ]+)",
        "(https?://youtu.be/[^&\?\.\ ]+)",
        "(https?://onforb.es/[^&\?\.\ ]+)",
        "(https?://imgur.com/[^&\>\.\ ]+)",
        "(https?://amzn.to/[^&\?\.\ ]+)",
    });

    if(!channel || channel == "" || channel == "url") {
        // tn("CHAT_D->check_for_url : channel " + channel, "red");
        return 0;
    }

    foreach( check in patterns ) {
        check_url = pcre_extract(msg, check);
        if(check_url && sizeof(check_url) > 0) {
            string command_string = check_url[0] + " " + channel;
            tn("CHAT_D->check_for_url : pattern " + check + " match " + command_string,"green");
            fd = external_start(1, command_string, "url_read_callback", "url_write_callback", "url_close_callback");
            return 1;
        }
    }
    return 0;
}

and your chat daemon likely differs from mine, but somewhere down there you'll see something like:

        eventChannelMsgToListeners(who, ch, msg, emote, target, targmsg);

after that, add:

        if (check_for_url(ch, msg)) {
            // debug stuff
        }

And last but not least, the perl script.

11
Design Lab / Re: Timed events for player characters
« on: December 22, 2015, 03:59:07 PM »
First, I would likely change your AddFaction() function a bit.  Setting both ltime and rtime to the same value seems silly.  I assume "ltime" is the time at which the player last modified the faction by some action on their part?

If so, rtime could just be 30 * DAY_LENGTH * HOUR_LENGTH.

To see how much time has elapsed since then, and how many faction points to deduct,

(SEASONS_D->GetTime() - Factions["poo"]["level_timer"]) % Factions["poo"]["reputation_timer"]

So, you could, on login, deduct that many points from their reputation value and reset ltime so the next calculation is correct.

There's utterly no reason to check every N minutes for something that only happens every 30 days.

However, if you WANTED to for some other purpose....

In heart_beat, you could add a check to ensure the callout you want is there, and if not, make it there.

if( find_call_out("silly_check_function") < 0) {
    call_out( "silly_check_function", 60 * 60 * 30 );
}

You can also use the "handle" that call_out returns, which is more useful if you use the same function for multiple things.

However, heart_beat() runs every 1 or 2 seconds, so it's really a waste to do this for something that doesn't do anything very often.  In the case of your 30 day thing, checking during login is MORE than sufficient.

12
Drivers / Re: WIP: Fluffos 3.0 Alpha 9.0
« on: November 14, 2015, 07:26:55 AM »
I'm not an expert on character set encodings, but my first instinctive thought was... are you using UTF-8 or a similar extended character set, and are there any valid byte sequences that use 255 in them?  TELNET was designed for ASCII transmission, and character 255 was denoted as the special IAC escape code to say "Hey, the next byte is either part of a command sequence, or another 255 escaped"

If libtelnet is scanning data at the byte level for IAC sequences, and one happens to be part of a multi-byte character set in whatever encoding you're using, it's very possible that libtelnet might try to analyze it.  If it happens to be a valid command (but with nonsense data), it might do something unexpected.

That's just a wild guess though.

13
Drivers / Re: WIP: Fluffos 3.0 Alpha 9.0
« on: November 11, 2015, 04:31:12 AM »
It's probably also helpful to compile with the debug flags on, and link against the debug versions of your system libraries.  ./build_FluffOS devel used to do this (or maybe debug).

If you know how to reproduce the crash, or you have beefy enough hardware to not mind the overhead, you can also run the driver in gdb, which would let you poke around in the case of a crash.  If you do that though, I'd recommend using screen, or doing it on a console.... a remote shell without screen may stop the driver if you get disconnected.

14
Drivers / Re: Different CUSTOM_CRYPT
« on: November 11, 2015, 04:27:55 AM »
If you can find an old copy of the "crack" utility, you could harvest the old crypt versions of your players passwords and construct a password file in the old unix style format, which would then let you run crack against it.

Players who have weak passwords would be revealed to you, and you could then generate new ones using the new encryption to put into their player files.

15
Drivers / Re: function pointers and anon funcs
« on: November 01, 2015, 07:12:46 PM »
Thanks Dworkin!

You are correct.  In fluffos, the "update" command just recompiles the new code which may call restore_object(), and if that works... destructs the old version.  Not actually upgrading the in-place object at all, but making a new one.

In that respect, the only place function points can be an issue would be if you tried to optimize lookups like CHAT_D->get_chat_color(), which is a synonym for "/secure/daemons/chat"->get_chat_color(), or call_other("/secure/daemons/chat", "get_chat_color");

If you were to cache those and not properly update the cache, you'd get either an error if the old copy were destructed, or unhappiness if you expected a daemon to be a singleton, but somehow ended up with multiple copies anyways.

Pages: [1] 2 3 ... 42