I admire the fact that you've created an elaborate string event system to encode your events but I can't help but wonder why you didn't use objects. Having a closed system like an enum for the event cases seems more natural to me because it's less open to ambiguation.
I mean if you have to parse the event string anyway why not use a typed object in the first place?
It can be a matter of performance, but events that don't fire thousands of times every second don't seem prone to this performance boost to me. Maybe you just really dislike flash’s native event flow.
Rustygames
Why have you got the event payload in the name of the event? Just have a nice lovely typed object for it?
Are they literally magic strings or are you using constants? Otherwise later I guarantee you'll forget what strings you've made up :)
The excluding bit seems a tad bonkers to me. The problem lies deeper I think. If there is a different outcome for the first time you enter then perhaps it should be a different event. If that isn't what you want then I suppose some sort of internal reasoning within the listener could be okay, but it will be a little bit difficult to keep track of the state with so many "local" decisions being made.
MSGhero
The event prefixes are constants, the suffixes are mainly numbers that I have to write out. I have the event data there because a lot of the commands are strings coming from a json cutscene object. They get parsed into the prefix and suffix that get sent out.
Maybe for entering a city I could use a different event the second time, but talking to an NPC who says the same thing each time, it would be weird to see two events.