mudlet-makers team mailing list archive

[Heiko <1132260@xxxxxxxxxxxxxxxxxx>]

1. tempTrigger types in general have an overall worse performance than 
regular triggers for various reasons - especially if they are the create 
to  hit once and then kill type.
2. tempTrigs always run after regular mudlet objects (this has to be 
fixed in the package and module manager) because you have no control 
over matching order which you do for regular trigs so this is a necessity
3. I'm currently writing a technical reference manual that has all the 
necessary technical details behind Mudlet. Going to send you a copy to 
add to the mapper chapter and write a chapter on your module mananger.

Am 08.03.2013 04:26, schrieb Chris:
> Are we adopting the notion in general that temporary triggers are 2nd
> class citizens to perm?  I'm fine if so, just want to be clear since
> this doesn't actually strike me as a bug as much as a "this is how we'd
> like things to work".
>

-- 
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1132260

Title:
  Perm triggers created after temp triggers run after temp triggers

Status in Mudlet the MUD client:
  Confirmed

Bug description:
  Temp triggers normally run after perm triggers, however but not if the
  perm trigger was created later. For example, when you reinstall a
  package or a module, its perm triggers will be running after existing
  temp triggers.

  This creates an issue where perm triggers rely on the original MUD
  colors to do their work, which temp triggers later modify. If those
  perm triggers start running after temp triggers, they won't work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1132260/+subscriptions