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 - melkor

Pages: [1] 2 3
General / Re: Popular Mud Clients?
« on: December 04, 2017, 10:16:21 am »

General / Re: is back!
« on: May 25, 2017, 09:46:15 am »
Great news! Good to see that the forum is back! 8)

General / Re: MUD documents and webpages
« on: May 25, 2017, 09:44:03 am »
I don't know if this counts but... - my small archive of old mudlibs and drivers.
I am still keeping it for educational purposes.

Drivers / Re: Fluffos 3.0-alpha-8.1 Releases
« on: July 05, 2015, 09:26:51 am »
Thanks @DarkWater it worked with ./build.FluffOS. Now i think i am an idiot. ;D

Drivers / Re: Fluffos 3.0-alpha-8.1 Releases
« on: July 01, 2015, 07:29:38 am »
Anyone else having issues compiling this on Debian Jessie?
It seems that i cannot pass the libevent check and it does not matter that libevent-dev package is installed...

Code: [Select]
checking for libevent >= 2.0... no
configure: error: Fail to find libevent (2.0+) header/library, install libevent-dev or change --with_libevent

Code: [Select]
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                  Version                         Architecture                    Description
ii  libevent-2.0-5:amd64                                  2.0.21-stable-2                 amd64                           Asynchronous event notification library
ii  libevent-core-2.0-5:amd64                             2.0.21-stable-2                 amd64                           Asynchronous event notification library (core)
ii  libevent-dev                                          2.0.21-stable-2                 amd64                           Asynchronous event notification library (development files)
ii  libevent-extra-2.0-5:amd64                            2.0.21-stable-2                 amd64                           Asynchronous event notification library (extra)
ii  libevent-openssl-2.0-5:amd64                          2.0.21-stable-2                 amd64                           Asynchronous event notification library (openssl)
ii  libevent-pthreads-2.0-5:amd64                         2.0.21-stable-2                 amd64                           Asynchronous event notification library (pthreads)

The result is the same on two different systems. One is running Debian Jessie, the other is Debian Sid.

General / PRIVS issues
« on: July 28, 2014, 03:21:50 am »
Hi guys!

I am having some issues with PRIVS in my project and i am currently out of ideas what it could be.
For some reason the files sefun.c and valid.c are not correctly reported by the PRIVS system and i cannot find why.
This is an example of the output during my tests:
Code: [Select]
> eval write(find_object("/adm/master/sefun.c"))
OBJ(/adm/master/sefun)Result = 0
> eval write(query_privs(find_object("/adm/master/sefun.c")))
0Result = 0
> eval write(query_privs(find_object("/adm/master/valid.c")))
0Result = 0
> eval write(query_privs(find_object("/adm/master/master.c")))
[master]Result = 0
> eval write(find_object("/adm/master/master.c"))
OBJ(/adm/master/master)Result = 0
> eval write(find_object("/adm/master/login.c"))
OBJ(/adm/master/login)Result = 0
> eval write(query_privs(find_object("/adm/master/login.c")))
[master]Result = 0
As you can see the master and the login objects are reported correctly, but the sefun.c and valid.c are not.
This is breaking the usefulness of the PRIVS system for me and i am really lost.
Why two of the objects are reported correctly and two of them are not?

I would really appreciate some help as i am currently at dead end.

Thank you!

P.S. - And a dump of all loaded objects during the test:
Code: [Select]
> eval write(dump_variable(objects()))
[0] == (/tmp/eval_file)
[1] == (/cmds/eval)
[2] == (/std/void)
[3] == (/std/user#2)
[4] == (/std/user)
[5] == (/std/user/save)
[6] == (/std/living)
[7] == (/std/living/hpsp)
[8] == (/std/living/stats)
[9] == (/std/living/env)
[10] == (/std/object/ob)
[11] == (/std/object/ob_logic)
[12] == (/adm/master/login#1)
[13] == (/adm/master/login)
[14] == (/adm/master/master)
[15] == (/adm/master/valid)
[16] == (/adm/master/sefun)Result = 0

@paven, check the above link. It should have it.
I just found that during the migration of my server the LPC archive was not moved properly and fixed it.

Drivers / Re: FluffOS 3.0-alpha7.4
« on: March 17, 2014, 02:07:16 am »
And another thing - is there a way to confirm that reclaim_objects() is run by the driver every five minutes or on whatever interval is set?
I remember one of your posts that reclaim_objects() now runs automatically and due to this did not bother to add the call_out which is calling it when i was writing master.c, but after this issue started appearing it was the only fix.

P.S. - I may need to say that i am writing my mudlib from scratch using TMI-2 and LPUni as a reference.

Drivers / Re: FluffOS 3.0-alpha7.4
« on: March 17, 2014, 01:30:14 am »
I am using FluffOS 3.0-alpha8, in fact i also found another issue there with the latest push - there is a missing "include "outbuf.h"" in which prevent the code compiling for me.

And actually i do not have a logon() function in master.c. It is in login.c and is called by function connect() which is in the master object.
Code: [Select]
staticf object connect() {
        object login_ob;
        mixed err;

#ifdef DEBUG
   debug("Master: connect() initiated.");

        err = catch(login_ob = new(LOGIN_OB));

        if (err) {
                write("It looks like someone is working on the player object.\n");

#ifdef DEBUG
    debug("Master: connect() failed to clone the login object!");


#ifdef DEBUG
   debug("Master: connect() finished.");
        return login_ob;

And here is the logon() from login.c:
Code: [Select]
void logon() {

#ifdef DEBUG
    debug("Login: logon() initiated.");

    if (clonep(this_object())) {
        call_out("autoDestruct", 60);

#ifdef DEBUG
    debug("Login: logon() checkpoint! Privs: "+query_privs(this_object())+", Name: "+this_object()->query("username")+".");

//    write("\n> ");
    termtype = "UNKNOWN";
    width = 24;
    height = 80;
    input_to("getName", 2);

#ifdef DEBUG
    debug("Login: logon() finished.");


TMI Tête - à - Tête / Re: read_file help
« on: March 14, 2014, 07:36:44 am »
It looks logical. However i can see that the return type of the function _touch() is string but you are returning an integer.
Try the following:
Code: [Select]
int _touch() {
    string sign_desc;
    sign_desc = read_file("/u/d/dorrin/obj/signpost_descs/workroom");
    if(sign_desc) {
        write("Signpost Desc: " + sign_desc + "\n");
        return 1;
    } else {
        write("There is an error! Tell a wiz!\n");
        return 0;

Here is the output of my little test as i do not have a working TMI-2 at the moment:
Code: [Select]
> eval string sign_desc; sign_desc  = read_file("/README"); if(sign_desc) { write("SP: "+sign_desc+"\n");  } else { write("Error!\n"); }
SP: --the contents of the /README file--

Result = 0
The above example works like a charm. But see what is happening when i try to read a file which is too large:
Code: [Select]
> eval string sign_desc; sign_desc  = read_file("/log/debug.log"); if(sign_desc) { write("SP: "+sign_desc+"\n");  } else { write("Error!\n"); }
Error: *Printable strings limited to length of 8192.

Current object: /tmp/eval_file ("/tmp/eval_file")
Current program: /tmp/eval_file.c
File: "/tmp/eval_file.c" Line: 1
"Line: 114  File: "/std/user.c" Object: /std/user#29 ("virosh") Program: "/std/user.c"
Line: 11  File: "/cmds/eval.c" Object: /cmds/eval ("/cmds/eval") Program: "/cmds/eval.c"
Line: 1  File: "/tmp/eval_file.c" Object: /tmp/eval_file ("/tmp/eval_file") Program: "/tmp/eval_file.c""

As you can see the error is thrown even at an earlier stage. You may also try to use catch() during the execution of read_file() or make some additional checks how large the file is before reading it.

When you write your code - always write checks even if you are currently checking something. :) It is a much better way of finding where your issue is.

TMI Tête - à - Tête / Re: read_file help
« on: March 14, 2014, 02:35:27 am »
The line "Result:0" is returned from the command "eval" which you are using to test the read_file() function.
Code: [Select]
> eval write(read_file("/README"))
--A buch of stuff from the README file---
Result = 0
> eval read_file("/README")
Result = 0
It is the standard behavior of "eval" in order for you to have the exit code of the tested command.

If you want to read the file and display it in some description - make sure that you are putting the file into a variable, parsing it if needed and then displaying the contents of the variable in your object description.

Drivers / Re: FluffOS 3.0-alpha7.4
« on: March 13, 2014, 04:42:25 am »
Does "reclaim_objects()" needs some special configuring in order to be run by the driver and on what interval is it running?
I was pondering why i am getting "Eval too long" errors in login object after 12-24 hours of idle and found out that i need to set a call out in master.c to call reclaim_objects() every two hours in order to get rid of this issue.

Drivers / Re: Fluffos 3.0 alpha7.3
« on: September 04, 2013, 06:26:38 am »
I agree with your opinion and i was leaved with the intention that this is the normal way how all this mudlib local_options ended in the driver in the first place.
It is just that the question popped up in my mind when i was reading the thread.

Drivers / Re: Fluffos 3.0 alpha7.3
« on: September 04, 2013, 05:39:20 am »
Actually, most people probably copy one of the mudlib-specific option files over as local_options, and then add in whatever's missing from options.h when it barfs on compilation. :)
And this brings the question - are these local_options files maintained and by whom?
I personally built a new file for the 3.0 version and after that i just check with the options.h if they are new things added after each new release.
Last time i was surprised by the RANDOM_RESETS feature. :D

@FallenTree, i can disagree with you on the topic of including "options.h". If i just created a new local_options and include the options.h in it without knowing that there is an enabled RANDOM_RESETS by default and this is not mentioned anywhere in the release... You can imagine the picture when the things start getting reset in a random way.

Actually, the earlier versions of Heaven 7 were interesting in that they ran on Amylaar, MudOS, and LDMUD.  The last version (alpha for 3.0?) dropped the legacy support to focus only on MudOS.

But if you find a version before the one called "avatar", it might be close to what you're looking for.

I may have one if it's not out there anymore.
You can find this version here -;)
I am still keeping this archive up and running. Probably will need to upload it also somewhere else just in case...

Pages: [1] 2 3