You need to purge existing instances of that object, when you change the triggers attached to it, because the existing instances do not get "updated" with that changes. The inheritance of the object is only checked upon creation.

You can do this individually with PURGE <object>, or you can also reset the zone it is in with ZRESET <zone>.

Maya/Rudha

Thanks, I use purge often so that shouldn't be a problem, looks like I'm going to type help for every command in OLC, some commands don't have help.

Isn't there a object search or something, lets you know where every instance of that obj is what room its in so you can remove it?

At the moment the mud isn't large enough and I know where every object is, but in the future I would be good to have such a thing. as this mud is crawling along but I have learned a great deal then I did before.

Not to my knowledge; OLIST lists the prototypes, but it won't list instances. It would be trivial to write a command to list instances though; I'm not sure why NakedMud doesn't do this, since it would be easy to paginate excessive lists, just use sock.page() instead of sock.send()

Hrm, now that you mention that I feel an itch to implement that; it really wouldn't be all that hard and would be fairly useful.

Maya/Rudha

[edit]: You seem confused, let me clarify: PURGE is a command outside of OLC, you do not do it in the OLC editor.

right it is outside the editor. I agree that would be a cool thing to implement
I'd like to see your process too ;)

Or you could just do a copyover…

good point, I do copyovers often too

Copyover is fairly intrusive; you can get away with it on a non-production MUD, but in general I would not suggest getting into the habit of doing it - it will screw up a lot of things your players may be in the middle of doing, ie combat crafting, etc.

Maya/Rudha

While this is, of course, a matter of individual policy, I would suggest that there shouldn't really be much need to go through and reload every single instance of an object on a production server. Rather, changes should be made on a development/building server, migrated over to the production server and then introduced with a copyover at a particular, regular time (once a day/week/whatever).

Again, it depends on the individual, but I generally try to make my systems persist over copyovers so that I don't have to worry about screwing up the game if a copyover is necessary.

it sure would, I could imagine once I open the mud for the first time to the public I do a copyover and some person has just dropped their weapon for the moment then **poof** lol

Copyover is a convienent reboot. The real solution is scheduling and using them in moderation.

The idea that everything needs be persistent for the sake of basically skipping proper production stages only creates more bugs, work, and ultimately interruption.

Yeah, and I was thinking just a few minutes ago, what if I could impliment a module that is like copyover only it would send all items and weapons back to the owner only if they have dropped something like.
I would type something like sendback or something for a command. Then it would say
"thaolen's things suddely fly back to him" and then I would use copyover. But that wouldn't help their corpse lol.

Players don't drop corpses in my mud, and they have no real reason to drop gear other than in a store (which is persistent), however copyover can disrupt other things. Rather than make everything persistent, I decided to make my 'reboot' command check whether anyone is fighting, anyone is doing a quest, etc - and if so, it tells me it failed to execute. I can then type 'reboot info' to see what's blocking it, and 'reboot force' to override it.

This is much easier to implement than making everything persistent, although it does mean you sometimes have to wait a little while before you reboot. But if you don't reboot often, and/or don't have too many players, it shouldn't be a problem.

That is a really cool idea, so you wait ;)

I was thinking of that very thing the other day, but my coding skills are novice for the moment.