SetTransitionTarget... still less than useful for doors. Chances of getting a 'fix'?
Mermut
Member Posts: 44
The notes on this function read:
// - Transition target objects are cached: The toolset-configured destination tag is
// used for a lookup only once, at first use. Thus, attempting to use SetTag() to change the
// destination for a transition will not work in a predictable fashion.
This makes a dynamic area creation system clunky at best.. as you can't actually hook up doors or transitions to newly created areas.
I'm working on a system to allow creating multiple flats off a single base area instead of requiring a unique flat for very single door.
I can create the area, set the tags, but the doors won't hook up due to this 'feature'.
Note: The doors don't initially have any transitions set up.. so it's not overwriting a new target.. it's attempting to set ANY target.
It would be great if there was some way to force a refresh on transition target objects.. or even have this function itself force a refresh for the objects it's passed.
// - Transition target objects are cached: The toolset-configured destination tag is
// used for a lookup only once, at first use. Thus, attempting to use SetTag() to change the
// destination for a transition will not work in a predictable fashion.
This makes a dynamic area creation system clunky at best.. as you can't actually hook up doors or transitions to newly created areas.
I'm working on a system to allow creating multiple flats off a single base area instead of requiring a unique flat for very single door.
I can create the area, set the tags, but the doors won't hook up due to this 'feature'.
Note: The doors don't initially have any transitions set up.. so it's not overwriting a new target.. it's attempting to set ANY target.
It would be great if there was some way to force a refresh on transition target objects.. or even have this function itself force a refresh for the objects it's passed.
0
Comments
The transition then worked properly in both ways... the new flat correctly goes to the exit door and the OnTransitionClick script 'fakes' the transition to the newly created flat.
The transition on the dynamic door MUST be to a valid location for this to work. Having it start with no transition doesn't work..
Putting the tag of the door that the script will assign to the 'new flat' doesn't work.. since that object isn't valid when the area the door is in gets loaded.
A fix that allows transition caches to be refreshed would be great, but there is a workable kludge.
https://neverwintervault.org/project/nwn1/script/dynamic-flat-system
I would absolutely love that! Thank you again, Mermut!
All you need to do is call SetTransitionTarget() explicitly on the other side to force an update.
You need to look up the target object (not tag), like so: SetTransitionTarget(myOutsideDoor, GetDoorByTag("myInnerDoor"));
This is basically what the engine does too at first click (when no object is cached). It just fetches the first matching door or waypoint by that tag name, with no ordering guarantees given.
There's no point removing the cache (and it can't be done: the OC, some premiums and surely a lot of custom content depends on this behaviour) because tags are never guaranteed to be unique. You usually want the door to be predictable after all in the face of new objects spawning.
You can also call SetTransitionTaget(INVALID) to explicitly invalidate the cache and unlink the transition (it will clear the "destination tag" field on the object, so future transition attempts will not re-link). This should be expected behaviour.
If the existing door doesn't have a valid transition when it is first 'clicked', the player is not given the 'blue plane' to click for transition. The door in the COPY works just fine, because it's destination was set at it's 'creation', before a player interacted with it.
If it IS valid at creation, using SetTransitionTag doesn't change it's destination. You have to fudge it with variables and the OnTransitionClick event to get the existing door to go to the newly created copy/instance.
If I could bother you to test?
I took out the OnTransitionClick script and the transition correctly went to the new target.
I then ran it again, taking out the dummy transition (still no trans click script) and I correctly got the 'blue plane' and transitioned to the correct new zone.
It looks like the change/fix did the job perfectly.
Now I just have to redo the notes on my dynamic flats system and have the package ready for update when the current code goes live.
Thanks for the excellent fix!
I've made a new thread about the system I'm working on here. If you've got ideas, i'd appreciate your posting them there.