Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 10-22-2002, 01:56 PM   #1
snowfruit
New Member
 
Join Date: Jun 2002
Posts: 12
snowfruit is on a distinguished road
Lightbulb

snowfruit is offline   Reply With Quote
Old 10-22-2002, 05:01 PM   #2
cronel
New Member
 
Join Date: Apr 2002
Posts: 17
cronel is on a distinguished road
The traditional LPC approach to this problem is to make a base room that is configurable. Then have a server of some kind that maps "coordinates", or whatever keys you use, into room properties (extracted from your single file, a map, or whatever); and then clones the base room and configures it with those characteristics. These cloned rooms are used while needed and then destroyed.

Modern drivers (MudOS for sure) have a master apply (i.e. one of those functions that the driver calls on master.c for special things) that is supposed to help you do this mapping for any objects it can't find on disk. It's called "compile_object" in MudOS. Notice that the apply is not strictly necessary to create the effect.

--cronel
cronel is offline   Reply With Quote
Old 11-12-2002, 10:05 PM   #3
kaylus1
 
Posts: n/a
Not sure about Amylaar, so I will go with MudOS first, in MudOS you have a config file when you start the driver ("driver ./config.mud") or whatever. Inside that file is the options for how long till reset and how long till swap out in seconds.

Each object in your Lpmud carries variables you never see that are defined in the driver, like when it's next reset time is, whether it is resetting etc. All the reset will do is reset the object back to it's original state. That's why it's good to keep a moderate number (1200-1800 seconds is usually good for a decent sized mud).

  Another good thing to note is if you put your swapout lower than your resets it never will reset. I always tend to use this as a rule: SWAP_TIME = RESET_TIME+(RESET_TIME/2), that way if no one enters the room, or "touches" an object (causes it to be accessed) within half the time after the reset than it swaps it out of memory.

 Anyway back to the topic, an interesting feature of the resets is that if your object has a reset() function in it, that function will be what is called.

To do this as was stated above you will need to create a new
room object (in addition) that has it's own reset command and on it's reset reloads from the file and destructs all children of it. (do a search of the MudOS efuns docs to find out how to do this). Do not recreate all the "virtual"-rooms in the reset. Have it load the file into some sort of mapping of arrays.. here is an example...
(don't look at the ****ty descs, just the concept
vr_room.dat
VR1:entrance to swamp:the swamp is to the north.:VR2:\rooms\world\street.c:X:X:
VR2:swamp:this swamp smells nasty:VR3:VR1:X:X:
VR3:swamp:you are deep in the swamp:X:VR2:X:X:

Notice the format is
NAME:short:long:north:south:east:west:

code to read it:
[code]
mapping vr_rooms;

void reset() {
  string *input_file, *this_room;
  object *rooms;
  int i;

  /* Whatever this file name is */
  rooms = children("/obj/vr_room");

  for(i = 0; i < sizeof(rooms); i++) {
      /*maybe put a check here to make sure a player isn't in the room*/
     rooms[i]->destruct();
  }

  vr_rooms = ([ ]);
  /* Read vr_room.dat and save the array of properties to a mapping reference */
  /* by the rooms name */
  input_file = explode(read_file("vr_room.dat", 1), "\n");
  for(i = 0; i < sizeof(input_file); i++) {
       this_room = explode(input_file[i], ";");
       vr_rooms[this_room[0]] = ({ this_room });
  }
}
[/quote]
That is some reset code, it may or may not work.. not tested, it should except for
maybe if I typoed =) But it helps get the picture, now what you need to do is add
a check to the move() function wherever you have it.
It needs to see if the exit is an actual file, if it is load it like regular, if it is not, run
the exit through the mapping of vr_rooms (ie if you have set_exits(({ "west" : "VR2" })); )
it obviously won't find a file named that so make it check vr_rooms["VR2"] and if it does
exist do a find_object to see if it's loaded and if not, clone a vr_room and set it's properties
based on the array in vr_rooms["VR2"];
Hope that helps?

Kaylus@Solice
  Reply With Quote
Old 11-13-2002, 05:46 AM   #4
Alastair
Member
 
Join Date: Apr 2002
Location: Switzerland
Posts: 120
Alastair is on a distinguished road
Send a message via Yahoo to Alastair
Alastair is offline   Reply With Quote
Old 11-14-2002, 09:35 AM   #5
kaylus1
 
Posts: n/a
This will work, but the only problem that you will have using this in a reset is that you will destruct yourself. Plus, I'm not sure if children(this_object())->destruct would work, It may, but children() returns an array of objects.

That's why I looped it in the code example I showed (though using this_object() for the children would work and is cleaner =)

[code]
rooms = children(this_object());

for(i = 0; i < sizeof(rooms); i++) {
rooms[i]->destruct();
}
[/quote]

I'm sorry my previous letter was so mangled, I was half asleep and drugged on migraine meds.

Anyway the code I showed in the last letter would be good to put in the vr_room.c object. What you need to do is create that by basically inheriting your room.c (or appropriate one) file, and if your move() function is in your ROOM object file,
let that just be inherited or call from inheritance "::move()".

If you anyone needs clearer instructions or personal help feel free to email me..

Kaylus@Solice
  Reply With Quote
Old 11-15-2002, 08:12 AM   #6
Alastair
Member
 
Join Date: Apr 2002
Location: Switzerland
Posts: 120
Alastair is on a distinguished road
Send a message via Yahoo to Alastair
Alastair is offline   Reply With Quote
Old 11-15-2002, 08:19 AM   #7
Alastair
Member
 
Join Date: Apr 2002
Location: Switzerland
Posts: 120
Alastair is on a distinguished road
Send a message via Yahoo to Alastair
BTW, I just remembered, but Lima has already a vroom inheritable, in /std/grid_server.c if my memory is none too shabby.

Never used it myself, but just in case you're Lima, check it out, it could be useful.
Alastair is offline   Reply With Quote
Old 11-15-2002, 10:43 AM   #8
Loriel
Member
 
Join Date: May 2002
Posts: 49
Loriel is on a distinguished road
The problem is not with the array - it won't work because destruct is an efun, and its syntax is destruct(object), not object->destruct().

There may be a lfun in the lib (eg remove() in lima) which achieves a similar effect, and in that case you can use the syntax quoted - ie children(this_object())->remove().

But I don't think you need to go to all this trouble - just put whatever reset() function you want into your base room object, and it will be inherited into all these virtual rooms, which will take care of themselves.

To go back to the original question :
This depends on the mudlib, so you need to read the code for create() and reset() in the room, and also in any objects it inherits- but I don't really see how this relates to virtual rooms.

And yes, the Lima implementation (via /std/grid_server.c) works fine - you'll find a couple of examples of virtual rooms in the lib, one of which uses that and the other (a random maze) works directly via compile_object() in the master being used to call virtual_create() in the "master room".
Loriel is offline   Reply With Quote
Old 11-15-2002, 03:11 PM   #9
kaylus1
 
Posts: n/a
Why on earth do that? It will also be inherited by EVERY regular room you create, that's alot of unnecessary hassle.. It's best IMO to keep base objects seperate, Why have extra BS for resettable vr_rooms in the inheritable for regular rooms.. all that makes is BLOAT objects. (This is the same reason alot of libs put doors in different files than the room files.. i.e. not every room has doors)

You are right though one could download a premade mudlib (Lima, Tmi-2, whatever) and have it done for them.. if they are using MudOS. I personally use DGD so i'm trying to help from a create it yourself point of view. But what trouble? Snowfruit was asking for a way to create virtual rooms from a single file, trying to give help on how to do it himself instead of having to download LIMA to do it for him.

You are right it is destruct(), I use it as a local function in my mudlib so ignore my ->destruct(). (as the Disclaimer states I wrote it on the board without testing), but as to your other statement, no matter how you mistype the EFUN, the problem -is- in the array. destruct(children(this_object())); WILL NOT WORK since destruct accepts object or string, not *object or *string =)

Also conceivable way of having this run is in a Daemon which controls the Virtual Rooms. In fact that to me seems like a better way. But anyways like I said feel free to email me, I have a lot of tested generic code examples that can be perused.

I also looked at compile_object() and though it does slightly different things than DGD it doesn't seem like it's worth the extra work to code it's usage into your own VR system.

Kaylus@Solice
  Reply With Quote
Old 11-15-2002, 06:14 PM   #10
Loriel
Member
 
Join Date: May 2002
Posts: 49
Loriel is on a distinguished road
I think we are talking at cross purposes here, and actually agreeing :
destruct(objects) will not work (as you say, destruct takes an object or a string, not an array), whereas objects->destruct() would work (if destruct were a lfun).
I don't see why you want a different reset in your "virtual" rooms than in your "real" rooms, and the "bloat" involved would in any case be negligible - the extra code would lie in one blueprint, not in all the clones, so the only case it would exist is where you have "real" rooms loaded and no "virtual" ones. However, as you say, if you want a different reset system in your virtual rooms, or want it only in the virtual rooms, put it into your intermediate inheritable.
I wouldn't wish to force its use on anybody (nor would I wish for force anybody to use Lima or MudOS) - however, my own experience of using it is that it makes virtual rooms easy. Choose whatever suits you, and use it.
Loriel is offline   Reply With Quote
Old 11-15-2002, 07:06 PM   #11
kaylus1
 
Posts: n/a
  Reply With Quote
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
Old 11-16-2002, 10:52 AM   #13
kaylus1
 
Posts: n/a
Probably. I just like to argue for the sake of it, so in fact my original description could suffer an icky fate if it were not a daemon. Which I wrote last night by the way and it works good that way. The reset() concept is too froggy =)

Yep, sure is. All I did was take something similar to that reset() code I posted a few notes back and use it in the create of the daemon, and have it autoloaded with the driver and handle things in a similar way to MudOS' compile_object. All I had to do was stick a little line in my movement code, after it failed finding the object and failed loading it, that told it do run the "find_load_vr(string)".

As to snowfruit's question though, I'm pretty sure I read in another board that he/she prefers LDMud. I don't think it has compile_object, so he/she will probably have to write the VR server.

I had not used it before a few months ago, and to tell the truth had a hard time getting used to it after being so used to Mudos efuns..

There isn't alot of mudlib support out there, only two good libs that I can think of "phantasmal" by Noah Gibbs which is very nice, and "Melville" by Steven Schmidt (Mobydick, whom most remember from TMI). Melville is in fact reminiscent of TMI-2, just a cleaner, tighter, version without all the extra junk.

Despite the lack of Mudlib support, there is alot of driver support and I like that =)

Kaylus@Solice
  Reply With Quote
Old 11-16-2002, 11:37 AM   #14
Loriel
Member
 
Join Date: May 2002
Posts: 49
Loriel is on a distinguished road
Looks like we are largely in agreement then.
Just a word of warning though, that you might need to load virtual rooms in circumstances other than "move" (eg using a "spy" ability to see into the next room), where the compile_object() approach would be better. Perhaps you could emulate that by overloading the load_object() efun with a sefun to handle virtual rooms in a similar manner (making whatever changes you might need to for DGD or LDMUD in Snowfruit's case).
Loriel is offline   Reply With Quote
Old 11-16-2002, 12:43 PM   #15
kaylus1
 
Posts: n/a
  Reply With Quote
Reply


Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 01:49 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2022