Looking for inspiration

[vexcesban]

Hey all, I rarely post but browse occasionally. Just looking for ideas or theory on how to go about coding 2 things. I've been running a h7 lib thats 100% modified out the wazoo for a few years now and have decent experience coding, self taught.

I'm looking for an efficient way to make all my monsters have setable respawn timers that will save thru reboots. Currently I do have code for setable respawn that basically just voids out clean_up and uses a mapping for each room, the time for next respawn is adjusted by code in monster death. My room code has a function in the reset code that clones the monsters and sets each one to 'object ob' so I can use find_object to find it if it's wandering or just in general. I have thought about using save_object to save each room but I really wouldn't want all the extra junk other than the mapping.

The other thing I'm looking to do is have a 'rested experience' system. This means a monster will give bonus experience when It's killed based on how long It’s been since last killed. Specifically, if a monster is untouched for an hour, a pool of experience will slowly build as time progress to a cap of some #. Example, guard is untouched for an hour, rested experience starts building. Every 10 minutes 100 bonus experienced is added to the monsters worth in experience capping at 4 hours time past or whatever the cap is.

Appreciate any feedback, just looking for ideas on how someone who actually is a programmer and not a hobbyist would go about something like this.. These two things seem to be a huge pain in the *** so you could call me crazy

[Camlorn]

The first issue is beyond me, sorry, but it sounds like a good place for a daemon and is probably mudlib specific.

    The second issue isn't.  In the heartbeat of all mobs, increase the xp value by 1.  When the mud boots, they all load at the default value, but as people -don't- kill mobs, their exp value increases.  Go find the default mob in your mudlib and add it in--depending on balancing, you may need something bigger or smaller than 1, and there's probably other places to put this that'll make it happen slower if you need that, but there you go.  When the mob is killed and reloaded, the exp value resets and begins incrementing by 1 every heartbeat.

    If you want this to save over boot or only work on specific mobs, that's slightly harder.  In the first case, you probably need a daemon with all mobs and their time since last kill, in the second, just make a new base object inheriting from the default mob that implements the functionality, call it exp_mob or something, and inherit from that one for mobs that are supposed to do this.

    Someone can probably provide more details--I consider this post more inspirational than informative, heh.

[vexcesban]

Yeah, I tend to do ridiculous things that aren't necessary at all and hurt my brain. Using heartbeat for the second thing would work great, except my monsters don't load at boot and neither do my rooms. They load on init by players and monster heartbeats are turned off when nothing happens in the room, unless of course it does something special like wander. I have a relatively small mud, about 2500 monsters and I am using ldmud 3.2.1 I believe. I'm not sure of the ramifications of having every monster in the game constantly having a heart_beat i.e. the load on the driver. These things are above my head and porting this lib to the newest ldmud is something also a little above me and also a huge pain in the ass as I made a half ass attempt at it once. I tried to stress test my mud by cloning 3000 monsters with constant heart_beat and It seems to slow down my mud, thought maybe I'm crazy! so I'm sure It's not a good idea

     Thanks for the reply, sometimes hearing someone else's input just makes something click randomly.

[Camlorn]

Well, that can, yes.  It depends rather greatly on what you're doing in the heartbeat.

    Another option is, again, the daemon.  You've got to make a choice: memory overhead or cpu overhead; the second causes lag, the first probably isn't as big a deal as it is.  Perhaps, store all mobs in a daemon or (now that I think about it) on the mob directly the time at which it spawned.  Simply take the time at which it died and the time it which it spawned, subtract, and apply a formula--say, 20 xp per minute, for instance.  That should be good until 2038, unless you're using something other than what I want to say is umt--that thing that started on new years 1970 and counts the number of seconds (and which rolls over, because of integer overflow, sometime in 2038).  But, I'm probably the only person in the world worrying about the time problem in 2038 in my code now, heh.  I'm also good at going off on a side-topic and not quite convincing myself to remove it...

    Anyhow, storing mob spawn time and using that to do the calculation would work.  Whether or not to put it on the mob directly depends on how much of the world you save and whether or not you want it to persist across reboots.

[quixadhal]

If you are spawning your NPC's to specific rooms, why not just set/increment a property in the room saying they've been spawned, and clear/decrement it when they are killed or dest'd?  That way the room's code can spawn a new one if fewer than the target value exist, even if they wander.

If you spawn them into random locations from a daemon, you can do the same thing in the daemon itself.

The only issue you might have is creators hand cloning them, but... don't do that.  Or have the npc code itself check the environment/daemon for a counter.

[vexcesban]

That is really simple quix, thanks. I think that's the only way I'm going to do it efficiently. Currently my clean_up code just destructs rooms that haven't been used. Not sure why it's like that, either laziness or lack of memory back then. I will have to modify it to just collect any garbage instead of desting the room. I'm not too worried about the 2038 problem at the moment !

[Camlorn]

I knew that when I posted it.  I'm really, really thorough, which is why my projects never get off the ground, and I couldn't bring myself to take it out of the post.  Now, when you come back in 2038 and complain, we can all point to this thread and have a good laugh...or not, as this forum may not still be around.