Question Detaching triggers

I'm not sure that triggers are meant to be zedited in as opposed to being set. Here's the problem, as I see it. A zedit is supposed to happen every time the zone resets. As a troubleshooter, I've often seen zedit problems with objects. I'm sure it happens with other things but objects are the easiest to catch. Ever walked into a room and found 50 whatevers there? The correct procedure is to remove the object and then replace the object.

Example of bad zedit:
room 27430 - Smurfville (Yes, I know you can't check this, just go with me on it)
Load blue ring [27402], Max : 120
then Load a curved dagger [27403], Max : 120
then Load a bag [27404], Max : 400
(18) [27404] A small bag is here.
(18) [27403] A curved dagger is lying here. ..It emits a faint humming sound!
(18) [27402] A small blue ring lies here. ..It emits a faint humming sound!

Example of correct zedit:
room 6424 - Rand's Tower
Remove some food [6420] from room.
Load some food [6420], Max : 10
Contents: some food

Now the problem is, there's no way to remove a trigger, only to add one in. No, I don't understand it, either. Since the detach doesn't actually remove the trigger, the zedit only adds to it, once per reset.

Would it be possible to modify the trigger into a mob or object trigger? Or would it be possible for you to post the trigger or a mockup that does the same basic thing? Since I've only used detach for testing purposes and the example of detach is an object trigger, I have no experience with it.

Would part of fixing this be to prevent adding duplicate triggers onto things?

All the different routes to add a trigger appear to go through void add_trigger() at some point, so we can add a check:
Perhaps then removing the option to add triggers using redit / medit / oedit?

I'm just going to point out that I've advised duplicating the elevator triggers anywhere the triggers are attached. I suppose though that if you were using this anti-duplication, it's probably easy enough to copy the elevator trigger to another number and then put both of them in. It detracts from the basic idea that I was only using one trigger to run the elevator but I think I stuffed in enough things that you would potentially have vnums left over for the copy.

The main limitation, as far as I can remember, is that you can look at the display and see where the elevator is but if you've pushed the button, the display disappears. This is because the trigger is already in use.

I was telling a friend about this and he asked why I didn't just add the trigger twice to each room. Of course I answered something like, (condescendingly) "Well, because you can't attach a trigger twice to the same...ro...um...why CAN'T you attach a trigger twice to the same room?"

Ok, understood.
In which case the better option is to add a command for removing triggers in zedit. Which keeps it consistent with how we'd remove mobs and objects..

Oh, I don't think you'll see many cases where a builder actually wants duplicate triggers. As you can see, I didn't think it was even possible until I tried it.

However, to overly complicate things, as I so often do, how about putting in a message...hmm, I see that I'm looking at this wrong. We're not talking about builder triggers here. We're talking about programmed triggers in which case your way is better than changing zedit since it would also work for items that might potentially have the same problem.

My original thought was that if it was code that affected building, it would be really handy to make it check the other attached triggers for same type as well as duplicate triggers since we've probably all seen builders who wonder why the five speech triggers on that mob (reflecting different words that you say to it) won't work.

In the original situation, I'd just make a mob or object, zedit it into the room, give it a load trigger to attach the trigger. I'm not sure it could check for the presence of the trigger but it could probably detach and then attach it, then purge itself. I've never tried it so I don't know if it would work but it sounds familiar. I may be thinking of a different base though. Depending on the trigger itself, there are other ways to handle it.

Personally, rather than having a way to remove the trigger in zedit, I'd prefer to remove the ability to zedit a trigger at all unless someone can describe a situation where the only way possible is to use zedit. I think that it makes more troubles than it's worth.

I'd rather have a "remove trigger" and "add trigger" kind of thing, much like we have "remove object from room" and "add object to room" setup. However, I forgot to post my solution to my original post.

I made a trigger to remove and add the other trigger at zone reset. LOL. I know, I know, it's clunky but it works!