NVScript v1.2.7

[Nameless Voice]

The documentation is missing for NVPhysMessages.

<h1><a name="NVPhysMessages" id="NVPhysMessages"></a> NVPhysMessages</h1>
<p>The object with this script will receive physics-related messages: <u>PhysMadeNonPhysical</u>, <u>PhysMadePhysical</u>, <u>PhysCollision</u>, <u>PhysContactCreate</u>, <u>PhysContactDestroy</u>, <u>PhysEnter</u>, <u>PhysExit</u>, <u>PhysFellAsleep</u>, <u>PhysWokeUp</u>.</p>

[Haplo]

Another suggestion: It seems NVDeleteTrap only works with the control device links and TDest parameter is ignored. Would it be too much work to add this feature?

I find NVDeleteTrap very useful; it is not affected by DeathStage12 bug whereas TrapDestroy and NVSlayMeTrap are. In my case there is a junk object that is created on the fly and given to the player, and I want it to be deleted when the player frobs it. I have given the archtype the NVDeleteTrap script and the following design note, but it doesn't work:

NVDeleteTrapOn="FrobInvEnd";NVDeleteTrapTDest="[Me]"

[R Soul]

TDest only applies to triggers, not traps (NVRelayTrap is both).

For traps we can set a Target parameter, e.g.
NVDeleteTrapTarget="[me]"

However, it might be simpler to set the FrobInfo property: InvAction: Delete.

[Haplo]

TDest only applies to triggers, not traps (NVRelayTrap is both).

For traps we can set a Target parameter, e.g.
NVDeleteTrapTarget="[me]"

However, it might be simpler to set the FrobInfo property: InvAction: Delete.

Yes, you are right. Thanks.

[Haplo]

I put NVDeleteTrapTarget="[me]" on the archetype but it didn't work. If I replace "[me]" with the object ID of a nearby table the table gets deleted fine. It looks like the problem only occurs when "[me]" is used.

[LarryG]

I suspect the problem is with the fact that item is in inventory at the time you are trying to delete it. Try NVDeleteTrapTarget="[me]" with something that isn't in inventory.

[Haplo]

Ok, I created two tables, gave table1 the NVDeleteTrap script, the NVDeleteTrapTarget="[me]" design note and connected a button to it. Pushing the button did not delete the table.

Then I replaced "[Me]" with the object ID of table2 and pushed the button. Table2 disappeared.

It seems NVDeleteTrap does not like [Me].

[Nameless Voice]

NVDeleteTrap is actually (apparently!) coded specifically to not delete itself.

Maybe to prevent it from deleting itself before it's finished deleting the other linked objects, or something?

Use the NVDeleteTrapDeleteSelf=1 parameter to get it to delete itself instead.


Added to documentation!

Note that an NVDeleteTrap will not delete itself even if it is specified as the target. Use NVDeleteTrapDeleteSelf=1 to have the trap delete itself after it has finished deleting other objects.

[Haplo]

Thanks for the clarification.

I have two suggestions:

1. Is it possible to make NVSlayMeTrap check its object (or its target object(s) if NVSlayMeTrapTarget is a valid parameter) and remove DeathStage12 if it exists before the slaying?

2. Assuming NVSlayMeTrapTarget="&ControlDevice" is not a valid parameter, can you please add a new script NVSlayTrap or extend NVDeleteTrap with a parameter that would slay instead of destroy (such as NVDeleteTrapSlay=1), along with the DeathStage enhancement mentioned above? This will not only provide a better alternative over TrapDestroy because it will have the NVScript flexibility, but also it will not be prone to the DeathStage12 bug.

Thanks.

[Nameless Voice]

Have you tried NVDeathStageFix? That was supposed to prevent the death stage 12 bug, but I don't think it was ever proven if it worked or not.

[Haplo]

Have you tried NVDeathStageFix? That was supposed to prevent the death stage 12 bug, but I don't think it was ever proven if it worked or not.

Yes I have tried it many times, and I have always ended up with DeathStage12 objects even with that script present.

Are my suggestions possible/practical to implement?

[Nameless Voice]

Did anyone ever come up with a way to reliably reproduce the deathstage 12 bug? It would be nice to find out what causes it and maybe fix it once and for all.

That script was supposed to monitor all deathstage properties on any object and automatically remove them, but apparently it doesn't work, and I never had a reliable test case to test it with.

[Haplo]

Did anyone ever come up with a way to reliably reproduce the deathstage 12 bug? It would be nice to find out what causes it and maybe fix it once and for all.

That script was supposed to monitor all deathstage properties on any object and automatically remove them, but apparently it doesn't work, and I never had a reliable test case to test it with.

I have a way of reproducing it, but it happens once every 100 DromEd hours or so. Not frequent enough to be useful for any testing/debugging.

If you can make NVSlayMeTrap check its target for this bug before the slaying it will be a big help. Also a generic NVSlayTrap would be quite useful.

[Nameless Voice]

Updated to v1.2.3.

This release is mostly just to share a number of NVTrigQVar bugfixes with the public.
See the first post for download links.

1.2.3

• New script: NVJointControl
• NVConvEnhancer: Added SetQVar action.
• Fixed a bug in NVGenericScalarTrap which would make it never reach 0.00 in a property.
• Fixed several bugs in NVTrigQVar, including one where the " operator was not working, and one where quest variable lookup was not working for quest variables with names starting with the letter 'r'.
• Updated the documentation to reflect the fact that NVLinkBuilder supports multiple versions.

[Yandros]

Thank you NV.

[ZylonBane]

quest variable lookup was not working for quest variables with names starting with the letter 'r'.

Okay, you have got to explain how that one happened.

[LarryG]

Maybe he meant that it wasn't working during months with an "r" in their name, you know, like oysters.

[Nameless Voice]

Okay, you have got to explain how that one happened.

There's an 'r' operator in the quest variable maths. The script was looking at the first character of the next token (e.g. the quest variable name "right"), seeing the 'r', and trying to find the operands to apply it to (which didn't exist, because the 'right' was meant to be an operand itself.)

[sNeaksieGarrett]

NV, any chance of you updating NVScript to be compatible with thief 2 multiplayer? Without that update it makes it impossible for me to finish my fan mission, unless I completely change the way AI spawn. (Currently they use NVScript to respawn, but in multiplayer they never respawn since the script isn't working properly.)

[Nameless Voice]

Extremely unlikely, as I have no idea what that would entail and have no real interest in the multiplayer mod.

[sNeaksieGarrett]

I'm sorry to hear that because I can't imagine it being that hard, but then I admit I'm not really good at programming personally so it may be more complicated than I think.
Well, Tos, the developer of the Thief 2 multiplayer patch could help you (and I can try to get into contact with him), provided that he's still interested in thief 2 stuff.

[Daraan]

Ah the JointControl how long have I waited for this...

The description the the .html is a bit off wrong - the # has to be behind the On (thats why it never worked here the corrected version:

NVJointControl

A script for controlling joints.
This script can have up to 99 joint configuration sets, each of which is activated by a message specified by NVJointControlOn# (where the # is the configuration set number, from 1-99; numbers must be sequential.)
Each configuration set can specify the desired position and speed of any of the 6 joints, using the NVJointControlOn#Joint# and NVJointControlOn#Joint#Speed params, where the first # is the number of the configuration set, and the second # is the joint to control. If no speed is specified, the curent value from the property is used.
The joint will always take the shortest route to its destination. You can specify extreme destination angles (such as -90 instead of 270) if you want to force it to take a different route.
When a joint starts moving, a JointStarted# message will be sent to the object, and when a joint reaches its destination, a JointComplete# message is sent, where the # is the number of the joint whose movement has started or completed.

Example design note params:

NVJointControlOn1="TurnOn";
NVJointControlOn1Joint1=180;
NVJointControlOn1Joint1Speed=30;
NVJointControlOn1Joint2=90; NVJointControlOn1Joint2Speed=3;
NVJointControlOn2="JointComplete2";
NVJointControlOn2Joint3=-180; NVJointControlOn2Joint3Speed=30;
NVJointControlOn2Joint4=270;
NVJointControlOn2Joint4Speed=3

This example will activate joints 1 and 2 on TurnOn, moving joint 1 to 180 degrees at a speed of 30, and joint 2 to 90 degrees at a speed of 3. Once joint 2 reaches its destination, the second set of joints will activate, moving joint 3 to -180 degrees at a speed of 30, and joint 4 to 270 degrees at a speed of 3.

____
Example use for moving and reseting 2 joints at the same time: See here

[TypeRED]

i didnt read all pages right now... but is it possible to create a smooth swinging joint?
(one that not just swings like a regular jointed pendulum on a clock with -10 and +10 degrees and a specified speed)

a pendulum usually gets slower as it reaches its maximum position on one side.... then it stops...... and goes backwards (while getting faster) and the same on the other side...

[Daraan]

Easier way without script(thanks to 1.19)

New Tweqs CurveC -> Pendulum
that really looks a bit more realistic

X in swings per second, Y,Z like normal

only bad thing Y/Z must be between[-31..0]/[0...31]
(so it should work for your clock

[Nameless Voice]

The description the the .html is a bit off wrong - the # has to be behind the On (thats why it never worked:

Noted.