qolelis on 19/12/2008 at 19:57

---

While making plans for a certain mechanism I got some ideas for new custom scripts that would solve my problems in less convoluted ways. I'll try and define the scripts for more general uses, though:

* A general listener script: This script would, as a default, listen to each and every message sent (you could also specify which ones to listen to in a list in the design note). This script would be very useful together with GayleSaver's Spy-script.
Example: Say that you need to listen to a certain message that only one script listens to. Adding that script could create unwanted side-effects, since it most likely reacts in some way to the message it's listening to. The listener script would be safe, since it wouldn't do much else than listen.
* A resetter script: This script would reset its object to the exact same state it had when the game started (some properties could be optionally excluded).
Example: Say that you need to listen to the PhysWokeUp message. This seems to be sent when an object starts moving, but it also seems to be sent only the first time. The resetter script would than be used to fool the object into believing that it has just entered the game world and the PhysWokeUp message could be sent again.
* A script that could take advantage of the extra information that accompanies some script messages. The script could then send a specified message through ScriptParams-links with link data set to the same value as the received message's extra information (the link data could be a vector to support the possibility of more than one piece of extra information). This script would probably need to be able to convert between object IDs and object names. Perhaps with the added possibility to put the extra information in QVars (prefixes could be specified and added to the QVar names).
Example: The FrobWorldEnd message is sent together with the ID of the one who frobbed the object. The suggested script could then be used to create different results for each person who frobbed the object (for example reacting only when the player frobs the object).
* A script that would add extra functionality to receptrons. It would be for receptrons what NVConvEnhanced is for conversations.
Example:
Say that you want to add or remove a link between the source and the receiver of some stim. In a receptron you do have access to both objects (Source and Me), but there is no action called "Add/Remove link". The flavor and link data of the link could be stored in the design note of either the source or the receiver.
* A way to make "[source]" in NV's scripts be the same as the source in a receptron when using the action "Send to scripts".
Example:
This would solve the problem described in example #4.


Disclaimer:
These are merely suggestions of course, I am not expecting or demanding anyone to fulfill my wishes.

qolelis on 21/12/2008 at 02:44

---

Yes, I know that and I have been using NVRelayTrap with other messages, but I am still having trouble with PhysFellAsleep and PhysWokeUp.

I added NVRelayTrap to a crate and added the following design note:
NVRelayTrapOn="PhysFellAsleep";
NVRelayTrapOff="PhysWokeUp";
NVRelayTrapTDest="[me]"

Then I added AnimLight to the crate and the property "Anim Light".

This should be enough to activate the light when the crate stops moving and deactivate it when it starts moving. Nothing happens, though. Then when I add the Mine-script, it works. I also added GayleSaver's Spy-script to the crate, and PhysWokeUp was only displayed with the Mine-script added. That's why I drew the conclusion that NVRelayTrap doesn't listen to all messages.

About PhysWokeUp
------------------
I did a few more tests and this time I used a Potted1 flowerpot:
Scripts: NVRelayTrap and NVRelayTrap2
NVRelayTrapOn="PhysWokeUp"; NVRelayTrapTDest="Awake";
NVRelayTrap2On="PhysFellAsleep"; NVRelayTrap2TDest="Sleeping"
Then I setup two odometers to count the number of the two messages respectively.

To test, I picked up the flowerpot and then both dropped it and threw it on a solid brush and on an object. I also bumped into the flowerpot (and then "unbumped" off of it).

I first tried it without the Mine-script and nothing happened. The Spy-script didn't report any of the wanted messages (neither on-screen nor in the monolog) and none of the odometers moved.

I then added the Mine-script and now something did happen:
* PhysFellAsleep was reported everytime the flowerpot stopped moving on top of a solid brush or on top of an object.
* PhysWokeUp was reported only when the flowerpot was picked up from on top of an object. When picking it up from a solid brush, nothing happened.
* Both messages were reported when I bumped into (and unbumped off of) the flowerpot.

I'm using NVScript 1.1.0, the DromEd Toolkit and a patched copy of Thief 2 (version 1.18).



Yes, I know all this, but unfortunately, "[source]" isn't set to the same source as in the receptron when using "Send to Scripts".

My test-setup:
I created a crate with scripts NVLinkBuilder and NVrelayTrap:
NVLinkBuilderOn="PokeStimStimulus"; NVLinkSource="[me]"; NVLinkType="Contains"; NVRelayTrapOn="PokeStimStimulus"; NVRelayTrapTDest="StimLite"
and a PokeStim-receptron with "Send to Scripts"

Then I created a flowerpot with a PokeStim-source and an LCLite named "StimLite". The LCLite is for testing that the stimming works.

I first used NVLinkDest="StimLite" to make sure that the linking works, which it did; when I dropped the flowerpot on the crate, StimLite disappeared, because it got contained by the crate.

Then I used NVLinkDest="[source]". When I dropped the flowerpot on the crate, StimLite lit up, so the stimming worked, but the flowerpot didn't disappear, so "[source]" appears to not be the same as the receptron source (the flowerpot in this case). I used "set game_mode_backup 0", just to make sure, and there was no Contains-link from the crate or to the flowerpot.

(I also used NVLinkDest="Poker" (which is the flowerpot) just to make sure that there wasn't anything wrong with the flowerpot, which it wasn't.)

So, what is "[source]" pointing to when used with "Send to Scripts"? It's obviously not the stim-source (which I wish it was) and since there was no Contains-link created whatsoever one is tempted to draw the conclusion that "[source]" is pointing to "nothing" in this case (whatever this "nothing" might be).

What I want is to be able to create a certain link from the receiver of a stim to the sender of said stim. Both the receiver and the sender can be any object, so I cannot use absolute names nor IDs. I have a setup in mind that should work - in theory; I havent tested it yet. I'm not really seeking advice on how to solve it - yet.

qolelis on 22/12/2008 at 00:05

---

My wording may have been wrong; I called it "listener", you call it "subscriber". Is there an existing script that would do that for me, without side-effects? Or more general: Is there an existing script that subscribes to all script messages?

Yes, these somewhat rephrased questions were of a rhetorical nature: There doesn't seem to be such a script, but I hope that I am wrong.

These are the scripts I have to choose from if I want to listen/subscribe to PhysFellAsleep/PhysWokeUp (as far as I know):
ActiveMine
ActiveFlashMine
CamGrenade
Mine
MossLump
All these have side-effects, some severe. MossLump is the least bad one; it only shoots a bit of moss at the start. I could live with that, if only I could get PhysWokeUp to always be received when expected. I'll keep on experimenting.

Anyway, now I know that my suggested scripts probably would be impossible or at least very hard to implement. Oh well, I'll do it myself then... :p :ebil: ;)

qolelis on 22/12/2008 at 02:43

---

"Aha, a secret script..." Yep, that did the trick :D

* Or you could add a parameter to optionally turn off the displaying?
* Does it eat a lot of resources to be listening/subscribing to all messages?
* Would it be possible to add parameters that would allow the user to specify which messages (or groups of messages) to listen/subscribe to?

I would be happy just to have a script that would listen to physics messages, but a more general script (if possible) could be of even greater use to everyone (that would mean more work for you, though :o ).

Using the MossLump-script I would have to first create all affected objects in a blue room, wait for the moss to be shot off and then teleport the objects to their respective places. That would mean 4 extra objects for each affected object, so a more precise script would be of much help.

http://img185.imageshack.us/img185/8374/puppyeyes2smallerxv7.jpg



I guess I could just pretend that PhysWokeUp is received every time I pick up the flowerpot. That would solve the problem as PhysWokeUp seems to be received for all other cases.

qolelis on 22/12/2008 at 22:27

---

Nope.



The subscription obviously has a purpose in itself, and the subscription wouldn't stop just because your users could turn off the displaying, or would it? I don't think it would be strange.



Thank you! :D That's 1 step done out of three five.