Nameless Voice on 10/6/2011 at 21:52
It should be turning blue, right?
You could try it really quickly in an OM.
Open Running Interference, load NVScript, link up a button and a marker with the design note I mentioned earlier, and see if that works?
Edit: Looks like you have the most recent build, too. The exact same timestamp as I tested with.
Edit #2: Do you need more than five copies? It's a simple copy-paste-change-three-characters job to add more.
LarryG on 10/6/2011 at 22:05
Something is wrong with this instance, but I can't see what. NVMapTrap can't be at fault because it is working properly with the higher numbered map pages. I'm revealing map pages at both ends during the mission. When the player finds a physical map, I am trying to add the map page at the front end and draw in an outline. Then when the player walks the area the map represents, the rooms visited get filled in. If the physical map is not found, the outline is never drawn, just the room by room as they are walked. It worked fine at one time, but now I can't get the outline to be drawn when the physical map is picked up. Very annoying ... I may just get rid of that bit if I can't get it to work reliably.
LarryG on 10/6/2011 at 22:38
OK. This is what I have learned. If I trigger NVMapTrap with
[INDENT]NVMapTrapOn="FrobWorldBegin";[/INDENT]
it works. But if I trigger it with
[INDENT]NVMapTrapOn="FrobInvBegin";[/INDENT]
it doesn't. There must be something about the triggering object being in inventory which mucks this up. But that's OK, I'll treat the physical map like a book instead of a scroll that you can pick up. That should solve the problem.
NV if you get a chance to investigate this and can explain why this matters to NVMapTrap, I would be interested in hearing about it. Meanwhile, I have a workaround.
Nameless Voice on 10/6/2011 at 23:08
That's really strange, the script doesn't even do anything. It's one single line:
Code:
pDarkSrv->SetAutomapLocationVisited(iPage, iLocation);
That's all it does (apart from initialise some variables and get some params); everything else is just standard NVTrap behaviour.
Wait a second, I know why. I don't think you get FrobInvBegin messages at all. You should probably be using FrobInvEnd. I always use ...End messages, never ...Begin ones.
LarryG on 10/6/2011 at 23:11
The NVTrapSetQVar is triggering on the "FrobInvBegin" ... ??? Actually I had an NVRelayTrap that triggered on "FrobInvBegin" that sent a TurnOn to another object with both NVTrapSetQVar and NVMapTrap. It may b e something inherent in the engine about the inventory environment ... ???
Nameless Voice on 11/6/2011 at 00:03
Well, you could try FrobInvEnd anyway? It really makes more sense for something to happen after you let go of the mouse button anyway, that's usually how things work?
LarryG on 11/6/2011 at 01:56
The setup:
A scroll with NVRelayTrap to an object with NVMapTrap and NVTrapSetQVar.
When I use either "FrobInvEnd" or "FrobInvBegin" to trigger the NVRelayTrap to send "TurnOn" to the other object, NVTrapSetQvar works, but NVMapTrap doesn't. If I use either "FrobWorldEnd" or "FrobWorldBegin" to trigger the NVRelayTrap (after changing Engine Features > FrobInfo to use scripts when frobbed in world), the same thing happens, the "TurnOn" is sent, NVTrapSetQvar works, but NVMapTrap doesn't.
BUT >>>
If I get rid of the 2nd object and put NVMapTrap and NVTrapSetQVar directly on the scroll, triggered by either "FrobInvBegin" or "FrobInvEnd", everything works. :eek:
So something must be wrong with my intermediate object. What? I don't know or care. I've eliminated the need for it and will move on. :weird:
Sorry to put you all through my personal trauma. :o
Edit:
Quote Posted by Nameless Voice
Well, you could try FrobInvEnd anyway? It really makes more sense for something to happen after you let go of the mouse button anyway, that's usually how things work?
The reason I use FrobInvBegin sometimes is to force it to happen before something else I'm triggering with FrobInvEnd.
Nameless Voice on 11/6/2011 at 02:35
Weird question: what happens if, instead of just clicking the mouse button as usual, you hold it down for a more significant length of time?
Maybe when you end the frob, the engine aborts what it was doing with the FrobInvBegin message, or something truly bizarre like that?
Entirely theoretical, of course.
LarryG on 11/6/2011 at 04:16
I've done that and never noticed a difference.
LarryG on 12/6/2011 at 09:37
The documentation is missing for NVPhysMessages.
