AFAIK, every other mud does it right. It's only DikuMuds that do it wrong.



You haven't seen hostility until you tell Unix users their OS's handling of /n violates ASCII-74 and ASCII-86 standards and Microsoft has always done it right.
And to add insult to injury, tell them their beloved GNU telnet doesn't handle /n correctly either, and most all other telnet clients do it right.

Regardless, the best bet is to follow Postel's principle.

Target basically lets you dynamically choose a string that will be substituted for $$ in your input.

So, if I set up an alias:

alias . cast sleep $$

then use target:

target fido

When I enter '.', it is expanded to

cast sleep fido

Obviously, I could target something else at any time.

It's pretty handy for fervent PKing… I grew dependent on it. I don't see it imposing anything upon admins, so I think it would be a good addition for the RaM base. It may be a bell or a whistle, but I guess some bells and whistles sound good to me. =)

Hmmm, ok. I never noticed such a thing because I've always done aliai in the client (tinyfugue or tintin), not in the server. :)

I don't mind in general, although the choice of "$$" is a bad one, as that's the escape sequence when you really want a "$" to show up. I believe act() uses "$t" to refer to the target (arg1 anyways), so that might be a reasonable choice.

I'm not against all bells and whistles, just the ones that give people extra power they can't get by using a client. scan gives you extra power, alias doesn't (since I can just make aliases in my client if the mud won't let me). Of course, if you're the admin and you want people to have "mob radar", by all means add it into your game, but I don't want people who don't like it to have to yank it out.

Hmmm, almost done with the OLC merge. As you probably guessed, I'm hand patching everything in. :)

One beef I have with this setup is the fact that it removed area-based resets and switches everything to room-based. I know it's much EASIER to load/edit/save resets when they're confined to rooms, and that 95% of the resets used in stock games involve rooms… but I don't want to rip out the area-based system entirely.

There are things I've done (or wanted to do) that really do apply to the whole area, such as loading mobs into random outdoor rooms, or placing a key quest object on a random mob in the zone. Those kind of resets are periodic, and do not belong in a single room, and I'd rather they be workable as resets rather than another special code loop to be run during update.

What about moving all the normal resets to save in the rooms, and then adding in special reset cases that save to the area itself? Kinda like mixing the two systems together.

Sure, that's fine. I just object to wholesale removal of the concept of an area level reset, as I think there are things you can do with them that you really can't do with room-level ones. The area-level resets would just get run before (or after, take your pick) you loop through the room based ones.

The only potential gotcha is if you provide a snapshot command to automatically add resets for a room based on what's currently IN it. Mobs/objects/etc that get loaded by an area reset probably need a flag so those kind of routines know they aren't part of the containing room's normal operation.

I don't know if THIS code has anything like that (yet), but I do remember you guys doing something similar in SmaugFUSS (the snapshot routine)?

One of the things I'd probably code in first (feature wise) with area-level resets is a reset to load a mob into either a random room in the zone, or (even better) load it into a room with a random radius around it.

IE: load orc 3001 into room 3000 random radius 3 if < 5

So, search the 3 room radius around room 3000 for instances of orc 3001. If there are less than 5, pick the (random) room with the lowest orc count and load him there.

My game always had many wandering mobs, and while we had flags to skip the loading on numbers in the zone, or skip if a player were in the zone, sometimes you just want to load mobs into rooms near the players. If you always use the same room, players figure out pretty quickly which room is the "spawn" room, and camp it.

Instaroom and Instazone have been features of Smaug since it was first released. The only thing we really did in FUSS was to switch the system to room based resets.

I'd have no objection if you wanted to do something similar for SmaugFUSS while you did it for RaM :P

Quix,

I like the idea about the random resets within a radius. Wouldn't it be a lot of work to implement area-based resets just for this scenario? Wouldn't it be possible to stick to the room-based resets, and having one of these radius-based random resets in a room, perform a depth-limited search of the interconnected rooms to find the best/random place to drop the mobile? Also, you could just place a reset in a room with a % chance of firing when the room reset, so a mobile may or may not load there. Seems it would be confusing / difficult to have area-based and room-based resets in the same system. Just my $0.02.

Oh, I actually wrote an iteratively-deepening depth-first search algorithm in Python to make a character in a mud fully explore an area automatically. I made it store the 3D offset of each room along with name / description into a MySQL database, and then visualized it in OpenGL. It was pretty badass… I had to do it after I saw this and thought it was awesome:

http://mundi.net/maps/maps_005/map_bay.h...

Anyway, I could write the actual random radius reset routine if you make the underpinnings for the new reset type. Let me know if you want, and also when I can pull the new version from SVN. *rubs hands in greedy anticipation*

Cheers.

You *could* do it that way, but then it's not really room based anymore. IE: Room 3201 had a mob spawned and loaded because of a reset line in room 3107? Have fun trying to trace that back if it something goes wrong with it!

Area-based resets were the normal way of doing things until OLC came around. At that point, the guys who did it apparently couldn't make it work cleanly with area level resets (saving a room didn't properly recheck the whole area reset list, so you'd get wacky things like the contents of chests ending up on the floor next to the chest). So, the switched everything to room-based ones to make it simpler – you only need to check the resets in the room you're saving.

Personally, I like the idea of everything (room/mob/obj) having their OWN reset list, and then letting each area have resets as well, for occasions when you want to do things on a larger scale. A chest can have a reset list to load the contents, and each object could have resets to set states if it wanted… each mob could have resets that load and equip its own gear. That way, the room just loads the mob, or the area loads the mob and selects a room for it… and the mob takes care of itself for gear/loot/states.

As for SVN… I shouldn't have promised to have stuff in… the day after I wrote that, I got a nasty sinus infection that's prevented me from wanting to stare at the screen very much for a good chunk of the week. :(

I AM almost done, but cmd_eval() is proving stubborn. It has a few shortcuts that want the same pointer to point to both const and non-const data, and we all know how gcc likes that. I should be around for the meeting, if anyone wants to pop on and chat a bit. NEXT week, we should be able to self-host the meeting with our actual driver, eh?

Quix,

I agree on all points. I see what you mean by a room having a reset that causes a reset in another room not actually being room based if that reset causes something to be loaded in a different room. What a stupid sentence that was.

I also _heartily_ agree about everything having their own reset lists. It really makes sense to have a room load a chest, and then have the chest load it's contents. This especially makes sense in a object-oriented environment, as we are pushing RaM into C++.

I hope you feel better. Sinus infections do indeed make computer displays vastly unappealing. Sometimes they make vision itself unappealing. Drink lots of tea and eat lots of soup, and we'll meet up this weekend hopefully under a RaM driven environ.

Hmm. Objects with their own resets. Interesting, and not entirely alien. The reset system that was introduced into SmaugFUSS as of 1.6 is room based, but the resets nest, so that if a chest is reset, that reset has child resets below it. I hadn't really thought to make the chest itself own the resets. :)

Resets on the entities themselves lets you get around the really annoying problem of resets involving moving mobs of the same vnum that spawn in different rooms. Really, the reset is logically associated with the entity, not the room/area/etc. – "one entity, one respawn" or something like that.

The trick is, you want to be able to reuse the same game objects for multiple resets.

If I make a room, I might want to ensure that a given quest object is always in the room… so a room-based reset to load a particular object makes the most sense. If I make a wilderness area, I may want there to always be around 20 wolves wandering the grasslands, but I don't care where they are – and in fact I don't want them to always be in the same place, so an area-based reset works for that.

If I load up a chest that was custom designed for a quest, odds are it's supposed to have some set of items inside it. Putting the resets on the object works there, since it allows you to do clever things like code a group of mobs that will pick the chest up and carry it to another location.

However, it won't ALWAYS be the case. Sometimes, I want to make a generic chest and load it with goodies. In one room that's easy to get to, I'll put a few common things in it… in another that's hard to find, I'll put more rare goodies. In those cases, you want the resets to be in the room, since you probably want to use the same generic chest object in both places.

This comes down to the fact that Diku doesn't store instances of objects, only prototypes. You can customize an instance, but unless it is in a player's inventory, next time it loads it will be a new copy of the prototype. You could solve that by allowing every instance in the game to be saved and restored, but you'd need a flag to indicate which ones to save – or you'd end up with a persistent world. A persistent world with resets is a tricky beast to manage!

Another good example is a mob. If I make Krazic the Orc Warlord, he's probably going to have his own resets that load up his own gear, and those will be 95% the same every time. If I make a generic orc, I might want to reuse the orc mob in a dozen places, which might use different gear or loot.

Soooo, just to be clear. I wasn't suggesting a carte blanche conversion, I was suggesting the addition of more places resets can live, so the one that is more appropriate can be used. If you want to code a dozen orcs so that every orc can have their own resets onboard, that's fine.. you should be able to do so… but you should also be able to load an orc from a room and have the room equip them…. or have an area load and place an orc, giving them random gear from the area.