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

Pages: 1 ... 9 10 [11] 12 13
Dead Souls Support / Re: daemon creation
« on: February 02, 2008, 04:32:29 PM »
Hello Capo,

I hope you dont mind me chiming in here- but I suspect that the system you would like to have would probably consist of three components.

a module in player.c which tracks data specific to the player for skills. i.e. which skills he possesses and what levels they are at.

a daemon for skills which would keep track of the skill tree/hierarchy and which skills are related to which other skills and in what manner.

and some manner of skill/commands which might be tied to the above skill hierarchy either directly or indirectly indicating which players may execute which skills.

So perhaps 3 mappings

mapping 1 (inside the player object) this would keep the current level, points of each skill.

mapping 2 (inside the daemon) would be the skill dependencies tree

mapping 3 (inside the daemon) would consist of rules indicating which checks needed to be passed in order to execute a given skill.

I suspect there could be otherways to decompose the system but that seems to me to be the simplest way to implement it. Good luck!

Design Lab / Re: design of lambda for dgd
« on: January 25, 2008, 02:05:02 PM »
Thanks Tricky. I think I get the idea now. It has some similarities with what I have planned but I hope to have some additional features as well (some of which I listed). These should be similar to the LPC4/MudOS stuff but hopefully a bit nicer as well.

Design Lab / Re: design of lambda for dgd
« on: January 25, 2008, 02:36:53 AM »
Hi Tricky,

I am actually not too familiar with Pike. Could you perhaps elaborate? I was looking over the documentation and couldnt find too much describing the features of the lambda subsystem and how it works.

Thanks in advance,


Design Lab / design of lambda for dgd
« on: January 24, 2008, 02:07:50 PM »
I am currently trying to build a lambda functions type module on top of dgd and this is a call for features sort of for such a module. It's part of a language extensions package I have planned for dgd LPC which will include (hopefully) stuff like reflection capabilities and metaprogramming features among other things.

For the lambda system my idea is not to go with something that looks exactly like anonymous function pointers in mudos LPC but something that exploits some of the features of dgd compile_object and lwo's better. Basically I would like to see three additional things.

1) a more elegant function argument signature syntax which allows passing of arguments into the lambda expression in a more succinct manner. Currently Mudos has two syntaxes the function(x,y) syntax and the (: :) syntax. I would prefer one syntax that captures both cases.

2) a means of decompiling and converting function objects so they can be examined more easily and augmented and recompiled ala continuations in an efficient manner. This is actually a bunch of related ideas. But the general idea is that it should be possible to inspect the contents of an anonymous lambda object and determine what it does with minimal fuss on the one hand and for efficiency reasons make continuations possible through recompilations rather than having a series of linked lwo objects.   

3) closure variables which are sort of like object variables which are preserved between calls. I am really unsure about a syntax for this which meshes with LPC well. but i suspect this feature would be quite desirable since you could create co-routine like yield behavoir.

Thanks for any input.


Code Vault / Re: partition_array sefun
« on: December 27, 2007, 02:35:14 PM »
Hi Daelas,

If you are using MudOS there is an efun unique_array which creates an equivalence class type partition similar to partition_array (when I wrote this function I didnt realize that this efun existed). This however might not solve your problem. You might have to wrap the function to reinsert the missing empty sets. The problem is that given some partition function f and some set to partition y a priori its impossible to know how many empty partitions should be there.

There are ways to fix this but I cannot off the top of my head think of one which has an elegant implementation. One thought might be to modify the function so instead of returning an values(m) (which i think now isnt so nice since it doesn't preserve order) - to have it return m so you have the key,value pairs and thus know which partitions you have and which ones are null.

Perhaps someone else has some better ideas.



Design Lab / Re: security- what should determine resource/user access?
« on: November 25, 2007, 12:59:10 AM »

Design Lab / Re: security- what should determine resource/user access?
« on: November 22, 2007, 04:33:15 AM »
Are they available? Under what names? I could do some significantly nicer design work with my security module if i had the equivalent of what chaos mentioned under MudOS.

Design Lab / Re: security- what should determine resource/user access?
« on: November 15, 2007, 05:22:48 PM »
Unfortunately the latter two might not be possible in MudOS but they are available in DGD from previous_program(), function_object, call_trace etc as you may well know.

Design Lab / Re: security- what should determine resource/user access?
« on: November 14, 2007, 03:28:02 PM »
Unfortunately the question is necessarily vague since I am taking about a general system. It's sort of a variation of two systems I found in a couple research papers which can be used to secure in principle all function calls in and out of objects- though I have not done this because of performance considerations (at least under MudOS thus far I might try it for DGD). Given the fine granularity of the system it can trap almost any type of call in a uniform manner thus-

The system can secure most resources and has traps designed to cope with valid_shadow, valid_bind. As for an external daemon I think it is simply cleaner. I dont see why you cannot delegate these sorts of tasks to an external book keeping system. Lima does this and so does DGD's kernel library.

I will release the code and probably will at some point once it's finished and cleaned up- but right now it's missing a critical portion which i mentioned- the policy design section. Basically the question is a theoretical one given some security system S which can allocate permissions to objects on an individual basis i.e.

object_id_user x object_id_resource +read +write

(indicating that user x has access to resource y in terms of reading and writing) or something like

object_id_user x object_id_resource +can_shadow +can_bind

what factors should contribute to the resource access of the ordered pair (user,resource). I can only think of three factors who cloned or created the object and the path of the object and maybe whether the object is a clone.

As for the encapsulation issue this for me really depends again on granularity. I can think of situations i think where you might want to control access to certain functions which are part of the public interface in such a way that only certain classes of objects should be able to access them- but again the cost of doing this might be quite high at least if implemented at the mudlib level.

Design Lab / Re: security- what should determine resource/user access?
« on: November 13, 2007, 06:06:30 PM »
Well I was trying to come up with a relatively generic scheme to cope with the access issue and I think with the daemon code for the most part I might have succeeded. i.e. the current implementation does not have the fine granularity of checking each function call but it potentially could do that if the performance constraints were not a limiting factor.

The problem now is how to determine which permissions to assign to which objects. I decided to leave that as sort of an open question. Since it's more of a policy decision than anything i can think of a number of different policies depending on the situation. The question then becomes which parameters to supply to the policy managment functions. Currently I am supplying two parameters- the objectid and the creator of the object.

The question I have is is this sufficient to cover all cases?

Design Lab / security- what should determine resource/user access?
« on: November 13, 2007, 01:50:02 AM »
I have finished writing a prototype daemon for a security module which can be plugged into an existing mudos library with minimal hassle. The main problem I am having is determining what policy is appropriate for resources and users in the system. I intend to leave these decisions up to a policy daemon or customized policy functions inside the existing daemon.

The question is what parameters should be passed to these functions? i.e. what information is relevant to the object in question and what should determine user/resource access. So far I only know of two simple systems one is primarily file based line *nix where user/resource access for the most part is determined by the objectid path only. The other is DGD's kernel lib where there is a fixed policy in most cases and only certain parts of the path have significant meaning (outside of /kernel and maybe to some extent /System)  and access for the most part is determined by who clones the object (this affects ownership and various things like management of resource pools).

So thus far we have two parameters the object_id (or file path) and the "creator". But should there be others? and can there be a systematic uniform policy that makes sense if you do per object access permissions?


Design Lab / Re: initialization code and persistent servers
« on: October 19, 2007, 08:52:50 AM »
I guess the primary point I was trying to make was that in theory it might be possible to get rid of initialization code or scripts in alot of cases since 90% of the code we do write for muds is initialization code- this might be a great "savings" in some sense in the code volume which makes up the average mud.

The main limitations of the approach are that in certain cases in the traditional H&S LP designs such as reset() situations the items typically you wish to generate are not unique data wise and thus you might need some sort of init script still in order to generate said NPC or items. However I wonder if it's possible to design a H&S style mud to overcome this objection as well. i.e. instead of having pure copy a fixed template resets to have some sort of "generator" or "factory" produce a range of different types of items or npcs depending on the situation and save the init script cloning for cases where you absolutely require it.

As for the issue concerning locking I suspect what I meant here is if you dont have initialization scripts you would need some other method of protecting the object data since you could not regenerate it from a protected script "file". So some method must exist to ensure data integrity. 

Design Lab / initialization code and persistent servers
« on: October 18, 2007, 02:23:40 AM »
Alot of code on most muds consists of data initialization code- but I am curious with persistent servers now (or people running servers with persistence modules or DB's for backends)- whether as some people have begun suggesting it might be safe in many cases to use an init once scheme throw away the initialization code scheme.

Of course there are certain things in terms of security you would have to be able to guarantee. For example data integrity becomes a critical issue in this situation since you no longer have the script for redundancy in case the data is deleted.

I suspect even in a traditional LPmud with persistence builtin you could perhaps take advantage of this to some extent. For example things like rooms would only have to be generated once using a system like Dead souls QCS perhaps without modifying the underlying script but instead by just cloning a copy of some base object and linking it into the system configuring it's properties until you are satisfied then locking it. For other certain types of items which do not need resets this would be true as well.

As for the reset() issue I wonder if it is possible to some extent to do away with it. This seems more a limitation of current area design than a problem with the general scheme of discarding initialization code. Not sure if anyone has any thoughts on this but it came up when I was working with DGD.


Dead Souls Support / Re: Shadow experiment
« on: October 11, 2007, 06:53:03 PM »
Actually that is an interesting one. Shadows only mask call_other() type calls according to the documentation so my suspicion is since you are trying to mask a driver apply nothing happens since message efun will invoke the receive_message directly without using call_other. This is speculation since I have never tried it, but I suspect you could conduct another experiment and see if it is possible to mask the init function with a shadow and if the driver invokes it whether the shadow gets checked. My suspicion is it probably does not.

Hope that helps,


Design Lab / Re: new server design- call for features
« on: September 24, 2007, 10:59:04 PM »
Well since it's a server design I am looking for I suspect that I will use the database primarily as a more robust form of datastore for files and objects. An added plus if I can somehow fit it into the design would be to have queries be able to run against this database of objects to find out certain properties rather than just having to filter objects(), livings(), users(). Of course some builtin security mechanism would have to exist to make sure that you cannot get at data which you do not have permissions for.

Some other thoughts would be to track version information and have histories of how objects/files have changed over time or also meta data associated with files instead of using an extensions based system which would allow restriction of operations by file type.

As for exploiting concurrency- something like A* seems like a perfect candidate since it has a long execution time which currently often bumps into the eval cost ceilings. Other possible applications are things like reasoning threads for A.I. where it needs to explore a large search space or anything else which is numerically intensive- perhaps certain physics calculations for a 3D mud.

Pages: 1 ... 9 10 [11] 12 13