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

Pages: [1]
1
Heaven 7 Symposium / Compiling on modern Linux
« on: March 23, 2020, 02:49:36 am »
Hey everyone,

I was actually looking to get both Heaven 7 (v4 and Avatar) compiled recently; to get them working with anything past 3.3 will take a massive amount of work I think but I can't seem to get them working on any version of 3.3 - It appears like it might be related to the XERQ/ERQ utils. I've tried on AWS Linux (Redhat/Centos essentially), Ubuntu 18, and OSX - every time I get similar outcomes:

* When logging in as soon as the selection is made to login the driver segfaults but untraceably (unknown ??)
* Sometimes on v4 (depending on driver build) it crashes on the lsword.c heartbeat, but commenting that out goes back to the above.

Has anyone managed to get this running recently? I'd like to take a stab at cleaning it up but hoping I can shortcut past the segfault bit ;-)

Kaylus

2
General / Re: Starting a mud: worthwhile or not?
« on: September 27, 2011, 10:11:22 am »
Quote
If you were to allow people to hook text feeds from twitter/facebook/etc into in-game channels, and give them a way to post back to these things, it might both give them a reason/excuse to sit around in your MUD and socialize... AND it would perhaps get their friends to wonder what "FooMUD" is.

The main issue with this is attribution; if I post to a comment to the game, the following messages on the channel going into a reply to that comment might not be related, so you'd have to have directed message to the character, and this doesn't happen alot on channels. "[chat] Kaylus replies to Jezebel: Hahaha, that's the funniest thing I've heard!!!!"

Of course, it's feasible if you do make such a system, I'd be interested in looking at it. Another idea would be linking a channel into a direct twitter feed of it's own (MojoMud_Chat twitter account, or facebook "interest page" account). With the twitter account you'd have to worry about text limits, and with the facebook account it would be really great to be able to thread/take advantage of comments but you run into the same issue as above.

Quote
People love collections and achievements too.  If you make systems where you can collect bits of things and turn them in for credit and/or earn achievements for doing certain things, AND have that auto-post to their twitter/facebook/etc, it also counts as a plus for most people.

That's an excellent idea, since it's the basis of sites like PSN, XboxLive, and even Facebook and G+ gaming systems. At least that mine garner interest for the game and allow an outside competition/some kind of link to the facebook world.

3
General / Re: Pike: what's the deal?
« on: August 18, 2011, 08:48:51 pm »
Actually I found a previous message by myself on these boards: http://lpmuds.net/smf/index.php?topic=736.msg3732#msg3732

Concerning this. :)

4
General / Re: Pike: what's the deal?
« on: August 18, 2011, 08:45:22 pm »
Again, this will have to go to searching my archives but I wrote an entire Pike based mud that, in its brief life of a few months, reached 25+ players online. The unfortunate thing was that I ran out of motivation and then lost most of the code due to not paying my hosting account. (No I didn't backup)

I still believe I have a base system with a "generic lib" (more like Lil') in my archives. I basically wrote it in a manner that mimicked LPC type engines. The code was segregated and the Mudlib code was passed through it's own limited (sandbox) compiler since Pike allows you to do that. The biggest issue I had was that somewhere they deprecated the whole "this_player()/this_object()" concept and I had to mimic that via the backtrace.

Even at the height of things the backtrace method was a pain and required working with it, not letting it work for you. I eventually rewrote it to a point that I could work with, but I'm not sure if that code is in my archived version. I'll look around and see if I can't find it, I hope it's not on one of the CD's I tossed over the years.

5
General / Re: Old mudlibs and drivers
« on: August 18, 2011, 08:38:41 pm »
I suddenly got flashbacks from browsing ftp.aragorn.uio.no while trying to learn how to code for some early LPmuds... NM4Dos... Although I also remember having an LPC4 mudlib written that was a pretty good mud that never became popular and the owner finally closed down and sent me the code. I wish I remember what I did with that. :-/

6
Dead Souls Support / Re: Error with 357 revolver
« on: August 05, 2008, 03:01:29 pm »
Hunter,

Gotcha, because that is what you are telling it to do. I'm taking it "Caliber" is the name of the float variable within the weapon and all of the code is within the same file. If that is the case then your logic problem is right there:

Code: [Select]
266        if(Caliber){
267            if(to_float(Caliber) < 1.00) Caliber = to_float(Caliber) * 100.00;
268            if(Caliber > 99) Caliber = to_float(Caliber) * 0.10;
269            dam = (to_int(Caliber) / 6);
270        }

You are changing Caliber to Caliber * .10 -- when what you need to do is either evaluate it within the expression or just create a new variable.

Code: [Select]
If(Caliber) {
  if(to_float(Caliber) < 1.00) dam = (to_int(to_float(Caliber) * 100.00) / 6);
  if(Caliber > 99) dam = (to_int(to_float(Caliber) * 0.10) / 6);
  else dam = (to_int(Caliber) / 6);
}

Or something similar, that should fix you up -- note, that I don't have the lib you are using and haven't tested this code -- it was just written in a post at the spur of a moment, so anything like a missed parentheses or colon is not my responsibility.. :D

Kevin

7
Dead Souls Support / Re: Error with 357 revolver
« on: August 03, 2008, 07:25:45 pm »
266: Caliber is equal to 357, which is true.
267: Caliber, even as float, is > 1, still 357.  Next.
268: Caliber is greater than 99, but is made a float and multiplied by 0.10!  which sets Caliber to 35.700001!  Which returns the 35.7 as the caliber. 

I haven't been able to study down into the mechanics as to what this is calculating, but I wanted to see if I'm the only one experiencing this.

Hunter,

The section in eventfire is calculating the damage done to an individual. A lower caliber weapon is going to be causing less damage. Basically it's purposefully creating a lower number so that you don't end up having massive amounts of damage, but then again that code is totally wasted if you don't use a standard.

I would recommend setting the caliber to '.357', that way the code doesn't accidently allow a 357 to best a 50-cal weapon. That's the proper way to calculate them anyways, for example.

One weapon with caliber 50.
One weapon with caliber 357.

The 50 cal will be set to 5
The 357 will be set to 35.7

Now if you use .50 and .357 they come out to

50 and 35.7

Which is more appropriate given the context. That code though isn't really ideal for what you are working on, need to hook that puppy in with the limbs system and link it to a weapons skill if it isn't already! Heh.

In summary: It does that on purpose to generate the damage passed on to another function, but it uses floats so you can specify the caliber how it's supposed to be. (.357 and .55and .22)

8
Drivers / Re: driver rewrite
« on: July 29, 2008, 03:05:21 pm »
Quote
The "mudlib" code was sandboxed in a 100% secure restricted mode where all access to resources (disk, network, etc) can be abstracted away? Python doesn't have such a mode.  Ruby doesn't have such a mode.  I'd be surprised if Pike had one which cuts the mustard.

I was talking with regard to a replacement driver for MudOS.  I see the DikuMUD argument as a straw man, that it relates to the scenario where the scripting language "driver" is in the same language as the "mudlib" and there is no sandboxing.  More of a library or framework to build upon, where bleed-over is generally inevitable.

Proper experience of a language allows one to see the ways in which it can perform certain tasks. I will not comment overly for Python or Ruby as they are outside the scope of my original comments (although sandboxing in ruby is quite possible). Theatrics of promised surprise aside, I will answer:

Yes, the mudlib code was able to be sandboxed in a (as a computer security professional, I hate saying 100)% secure restricted mode where all access to resources (disk, network, etc) can be abstracted away. Pike allows you to call the internal compiler to compile pike code through the application, when doing so you can specify a custom-built compile handler, I used this compile handler to lock-down and over-ride internal functions to pike by restricting access to any function but those I explicity specified in any code compiled by the 'driver'.

As a basic example I've just chopped up bits of code from mine and the following (incomplete) example would create a compiler handler that only allowed the following: array_sscanf, backtrace, crypt (over-ride mapped to the custom_crypt function in the driver), write (over-ride mapped to send_message function in driver), and the usage of the == and != operations.

Quote
mapping comp_map = ([ "`==":`==,"`!=":`!=, "array_sscanf":array_sscanf,"backtrace":backtrace, "crypt":custom_crypt, "write":send_message ]);

private object compile_handler = class {
    mapping(string:mixed) get_default_module() {
      return comp_map;
    }

    mixed resolv(string id, void|string fn, void|string ch) {
        throw( ({ "Error in program : "+id+"\n", ({ }) }) ); /* Throw it off, it's already in backtrace */
        error( sprintf("%O %s", id, "Problem with compilation.\n"), id );
    }
  }();

object compile_object(string file, void|int user) {
   <...
    verify file, create object reference number, load_file, etc
    ...>

    newLoad = compile_string(newCode, file, compile_handler);
    newOb = newLoad();

    <....>
     return add_global_object(newName, newOb, obj_cnt, creator, time());
}

Given this, i'm fairly certain that pike has the capability to sandbox effectively in a .. mustard cutting... way. I'm not quite sure where you gathered your information for reliability, but that argument isn't even worth going into here. It is similar to me insisting my grandfather use the internet for e-mail, he assures me that the internet is unreliable and the postal service is the way to go.

Your comment about ease-of-use doesn't make much sense to me. In the current state of LP there is not any more opacity than there would be in a scripting language. The driver needs to be compiled, this includes (in a few cases) modification of files in the source directory, and sometimes Makefiles, to make sure that your MUD works properly.

The same applies to a scripted driver, it resides in a separate directory from the lib and the user doesn't generally mess with it. Their interaction with the driver only has to be "pike ./driver/main.pike" or "./startdriver". I would argue that for a user that isn't loaded down with compilation tools, the scripted driver would be less complicated:

1. Install Pike
2. Unzip Mud
3. cd ~/mud
4. ./startmud

Perhaps you are assuming that much of the game-logic would have to be incorporated into the game driver? That's simply not the case, just because the game is written in the same language doesn't mean the logic can't be abstracted from the driver. Especially with the sand-boxing technique demonstrated.

Kaylus

p.s. Grammatical mistakes likely, this post has been something I've been typing in the background while actually working ;-)

9
Drivers / Re: driver rewrite
« on: July 25, 2008, 03:23:09 pm »
This project would best be done in a low level language, like C or C++.  Doing it purely in Python, Ruby or another slow scripting language would be a bad choice.  PyPy is an exception however, as it can compile down to C - note that writing something in PyPy is not the same as writing it in Python.

While I agree with most of your other points, I don't agree with this one. Why would writing it in purely Python, Ruby, or another scripting language be a bad choice? I sincerely doubt many of the people using such a driver will reach the point that they bypass the speed limitations of a scripting language. I will admit that if you are trying to Parse LPC as it currently stands you might end up with much higher processing costs than expected, but that could be mitigated downard -- I would suggest that if you use a scripting language to make a driver that you keep the MUD language in the same syntax as the script language, for ease of processing.

My previous project which was a Pike based implementation of a MudOS-esque/mostly compatible, driver worked out quite well and was load-tested very succesfully using scripted logins. I don't think it would limit people at all, since many muds are not going to even surpass the 100 user mark, I will note that I have seen MudOS laggard at 350 users (a while back, when technology wasn't as expanded), so you are probably going to reach a limitation somewhere -- I just doubt it will be  below the expectations of the user with today's technology.

My only issues with Pike were due to my misunderstanding, though you would still run into slight syntax errors, those could probably be over-ridden with Pike to match FluffOs compatibility. Then you would have a basically limit-less driver that didn't need compiling and worked on three major platforms at least.

Pages: [1]