Thread: LPC Help
View Single Post
Old 11-15-2002, 08:03 PM   #12
Loriel
Member
 
Join Date: May 2002
Posts: 49
Loriel is on a distinguished road
Talking at cross purposes again, I think.
You are putting a "destruct children" in the reset in your "parent file".
I am suggesting you put a "destruct me" in the reset of the inheritable, so all rooms just handle themselves at reset (actually Lima uses clean_up() rather than reset(), but the logic is similar).
The Lima grid server, which is the only one I'm familiar with, uses two external files - one is the room file, and the other is for a map which lays out the different rooms to fit into the grid. Simplifying it, you put a "0" on the map where you want a "type 0" room, and in the room file you set up an array of room details, so that a "type 0" room uses the first item from the array (for long desription etc). I've written similar systems with all the code in the single "server" file - which is probably similar in nature to your daemon proposal.
I'll try to keep this short and simple, using Lima's implementation for the concrete details - ask again if you would like more info.
When the driver fails to find the file the lib has asked it to load, it calls compile_object(filepath) in the master - which should return 0 if it can't solve the problem, or the object concerned if it can find/construct a suitable object to load.
This is implemented by parsing the path name, and trying each possible split of the path, calling part_1->virtual_create(part_2).
To use a simplified example, suppose you set up a naming scheme for a forest area, as /forest/x/y (where x and y represent the coordinates of the rooms). If you then go to the room /forest/0/0 (assuming the file does not exist) it will look for a file /forest.c, and try calling virtual_create("0/0") in that - so you write a suitable virtual_create(string coords) in /forest.c which extracts the coords, checks they are valid, and returns a suitably configured room.
It's thus a very easy system to use where the rooms are all similar, or where a simple algorithm based on coordinates determines the characteristics of the room. For example, I've used it to create a 3-d forest, where the "up" dimension takes you "up" the trees into different types of rooms.
As I said before, choose the one that suits you, and use it. I've not used DGD, and can only judge by its reputation - which is that the differences are
a) DGD tends to be disk-based rather than memory based, hence uses less RAM
b) it is "leaner" (ie has less efuns)
c) it allows commercial usage.
Additionally I know it has some features MudOS doesn't (support for multithreading, and atomic functions), but on the other hand there are very few mudlibs that use it (though I assume they could be converted with a suitable rewrite).
Loriel is offline   Reply With Quote