![]() |
#1 |
New Member
Join Date: Jun 2002
Posts: 12
![]() |
![]() 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? |
![]() |
![]() |
![]() |
#2 | |
New Member
Join Date: Apr 2002
Posts: 17
![]() |
Quote:
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 |
|
![]() |
![]() |
![]() |
#3 | ||
Posts: n/a
|
Quote:
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. Quote:
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 |
||
![]() |
![]() |
#4 | |
Member
|
![]() Quote:
[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). |
|
![]() |
![]() |
![]() |
#5 | |
Posts: n/a
|
Quote:
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 |
|
![]() |
![]() |
#6 | |
Member
|
Quote:
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 ![]() Which may take a long time to complete (couple of seconds), depending on the amount of vrooms you're actually using. |
|
![]() |
![]() |
![]() |
#7 |
Member
|
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. |
![]() |
![]() |
![]() |
#8 | ||
Member
Join Date: May 2002
Posts: 49
![]() |
Quote:
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 : Quote:
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". |
||
![]() |
![]() |
![]() |
#9 | |
Posts: n/a
|
Quote:
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 |
|
![]() |
![]() |
#10 | |||
Member
Join Date: May 2002
Posts: 49
![]() |
Quote:
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). Quote:
Quote:
|
|||
![]() |
![]() |
![]() |
#11 | ||
Posts: n/a
|
Quote:
![]() 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. Quote:
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 |
||
![]() |
![]() |
#12 | ||||
Member
Join Date: May 2002
Posts: 49
![]() |
Quote:
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). Quote:
Quote:
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. Quote:
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). |
||||
![]() |
![]() |
![]() |
#13 | |||
Posts: n/a
|
Quote:
Quote:
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. Quote:
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 |
|||
![]() |
![]() |
#14 | |
Member
Join Date: May 2002
Posts: 49
![]() |
Quote:
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). |
|
![]() |
![]() |
![]() |
#15 | |
Posts: n/a
|
Quote:
Sad thing is that i'm probably never going to use virtual rooms, ![]() Well Snowfruit, hope you got your answer somewhere in the jumble ![]() Kaylus@Solice |
|
![]() |
![]() |
Thread Tools | |
|
|