LarryG on 5/9/2017 at 16:00
I have an object which is supposed to emit something when frobbed. My setup included the scripts TrapTweqEmit and NVRelayTrap with a Design note of NVRelayTrapOn="FrobWorldEnd"; NVRelayTrapOff="Null"; NVRelayTrapTDest="[Me]".
Other things also are supposed to happen on "FrobWorldEnd", and I also had NVSpy on the object, so I was certain that "FrobWorldEnd" was getting received and a "TurnOn" was generated to my object. But the something to be emitted wasn't getting emitted. So I hooked up a button to my object with a CD link, and lo and behold, when the button is pressed, the something does get emitted.
So I created a marker called BounceRelay with an NVRelayTrap and a Design note of NVRelayTrapTDest="[Source]", which just bounces "TurnOn" and "TurnOff" messages back to the sender. I updated my original object's Design note to have NVRelayTrapTDest="BounceRelay" instead of NVRelayTrapTDest="[Me]", and tested it. Everything worked! The something was emitted just on cue.
So, I deduced from that that TrapTweqEmit does not pay attention to self-generated "TurnOn" messages. Is this common knowledge of which I was ignorant, or is this new to most of you too? I don't recall this issue with any other script that inherits from StdTrap, but maybe I never noticed. Does anyone know if this is a general limitation for inheritors from StdTrap?
R Soul on 5/9/2017 at 18:33
Same effect for me too, but I can't think of an explanation.
LarryG on 5/9/2017 at 20:30
There is secondary data which goes along with messages which identifies the sender. Maybe the script just ignores all messages sent by its host to itself for some internal reason? But maybe the (
http://thiefmissions.com/telliamed/scripts.html#traptweqemit) script description should be updated to note this limitation?
LarryG on 6/9/2017 at 10:33
No. Not in my situation.
If I understand the documentation correctly (always debatable with tnhscript), that script doesn't address sending the message to itself (ref. (
http://dromed.whoopdedo.org/tnhscript/generictrigger)). So another object would be needed to bounce back the TurnOn anyhow. Additionally, TrigFrobber only can send via a CD (or maybe ScriptParams) link to another object, and those links don't copy from an archetype to a concrete. My object is dynamically created and needs to work without needing explicit CD (or ScriptParams) links.
Honestly, I consider most of tnhscript to be depreciated since the release of NVScripts. As an example, NVRelayTrap can do the work of TrigFrobber with the right design note. And more. Much more. And with easier to understand documentation. I only use tnhscript when there is no NVScript functional analog. Which means hardly ever.
