[snowfruit]

I have been looking for this info all over the web, ith no results, so I'll ask you lot instead

How/what happens when an LP mud loads/resets a room?
In what sequence do things happen?

I'm trying to create a system that will create a series of rooms from a single file, 'virtual' rooms as it were that only exist in memory...

any ideas?

[cronel]

Originally Posted by I'm trying to create a system that will create a series of rooms from a single file, 'virtual' rooms as it were that only exist in memory...

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

Originally Posted by I have been looking for this info all over the web, ith no results, so I'll ask you lot instead How/what happens when an LP mud loads/resets a room? In what sequence do things happen?

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.

Originally Posted by I'm trying to create a system that will create a series of rooms from a single file, 'virtual' rooms as it were that only exist in memory...

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

[Alastair]

5 am-->

Originally Posted by (kaylus1 @ Nov. 13 2002,04[img http://www.topmudsites.com/iB_html/non-cgi/emoticons/wow.gif[/img]5 am)]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).

If my LPC memories haven't degradated too much, you'd do something like this:

[code] children(this_object())->destruct();
destruct(this_object());
new("Object_path");
[/quote]

I haven't been coding for almost a year, though, so be careful when trying it out (as usual).

Originally Posted by children(this_object())->destruct(); destruct(this_object()); new("Object_path");

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.. kevkay@REMOVE.charter.THIS.net

Kaylus@Solice

[Alastair]

Originally Posted by (kaylus1 @ Nov. 14 2002,3:35 pm) Plus, I'm not sure if children(this_object())->destruct would work, It may, but children() returns an array of objects.

Well, thinking back, two things:

children()->destruct does work, at least in Lima. I'm pretty confident about that, at least.

And trying to remember the rest, I think I actually never used children(this_object()) in this context but rather always children(Object_path) instead, both in code or command line format.

I'm not sure about the notion of destructing yourself in that case, though, since I doubt you'd be in the inheritance trail of any room. However, a player body would end up environmentless (in Lima, moved to the void).
This is easily avoided, though, if you add a check that prevents the reset if a user is in any of the v-rooms.

Where it gets more complex, obviously, is if you want to reset the whole vrooms except those currently occupied by players.

You'd have to scan all children to see if any of them is occupied by a player, place a hook on the player to prevent them from moving until the reset is complete (fake lag ), register all children numbers of occupied rooms and finally parse the total children list to renew the empty ones against your exception list. Then removing the no_move hook on all concerned players.

Which may take a long time to complete (couple of seconds), depending on the amount of vrooms you're actually using.

[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.

[Loriel]

Originally Posted by Plus, I'm not sure if children(this_object())->destruct would work, It may, but children() returns an array of objects

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 :

Originally Posted by How/what happens when an LP mud loads/resets a room? In what sequence do things happen?

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".

Originally Posted by 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.

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

[Loriel]

Originally Posted by 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 =)

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).

Originally Posted by 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,

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.

Originally Posted by 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.

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.

Originally Posted by 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).

Agreed

About to everything else, i'm mainly pointing to the example I've given. The bloat i'm talking about is not physical disk space. But memory and speed loss.

Pretend we are using the example I gave and put it in the base room inheritable, it would perform the seeking of all the children, destruction, loading the data from file, parsing everytime ANY room reset. Which is not really negligible. We all know of course you can toss a few checks in and change that to work.

It all depends on which way you choose to do it, I admit that the way I described may not be the most optimized but I was giving an example I wrote in a few minutes. Daemonizing it would probably be the best solution IMO.

In regards to the grid server though, (if it's the same type as in TMI) I was under the impression Snowfruit was trying to retrieve it all the props from the same file. Most grid servers I have seen read from multiple files for input. Disregard if i'm mistaken.

Originally Posted by 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.

Honestly, depending on your own personal experience of anything determines which way is the easiest. But LIMA is a good mudlib, i've looked it over once or twice. I just had to use a better driver than MudOS.

About the compile_object, i've not used it before care to explain it a little, since you use it? The different docs I read
on it had basically the same concept but explained it slightly differently.

Kaylus@Solice

[Loriel]

Originally Posted by Pretend we are using the example I gave and put it in the base room inheritable, it would perform the seeking of all the children, destruction, loading the data from file, parsing everytime ANY room reset. Which is not really negligible. We all know of course you can toss a few checks in and change that to work.

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).

Originally Posted by Most grid servers I have seen read from multiple files for input. Disregard if i'm mistaken.

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.

Originally Posted by About the compile_object, i've not used it before care to explain it a little, since you use it? The different docs I read on it had basically the same concept but explained it slightly differently

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.

Originally Posted by I just had to use a better driver than MudOS.

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).

Originally Posted by Talking at cross purposes again, I think

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 =)

Originally Posted by I've written similar systems with all the code in the single "server" file - which is probably similar in nature to your daemon proposal

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.

Originally Posted by 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

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

[Loriel]

Originally Posted by 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)".

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).

Originally Posted by 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).

Heh. Funny thing is that I was just doing the same thing, I have an Afun "find_or_load()" which basically attempts to find the object and if it can't loads the object. I use it mainly for moves and for other oddities. I just tossed the code into there.

Sad thing is that i'm probably never going to use virtual rooms, I just added them because of this thread. Oh well, time to make it generic and put it in the archives! Although using it would make On line creation easier..... hmm.

Well Snowfruit, hope you got your answer somewhere in the jumble

Kaylus@Solice