Skip to content

SetTransitionTarget... still less than useful for doors. Chances of getting a 'fix'?

MermutMermut 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.

Comments

  • MermutMermut Member Posts: 44
    I was able to 'fake it' by creating a dummy _FlatLanding zone with a door and linking all 'dynamic' flat doors to that and putting a custom OnTransitionClick script on those dynamic doors.
    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.
  • MermutMermut Member Posts: 44
    For anybody interested, I finished and posted the dynamic flat system over on the NWN vault
    https://neverwintervault.org/project/nwn1/script/dynamic-flat-system
  • KethaKetha Member Posts: 10
    Thank you. I have grabbed it up to learn from. :)
  • MermutMermut Member Posts: 44
    If you've got any questions, post them here or on the Vault and I'll do my best to answer
  • MermutMermut Member Posts: 44
    Ketha said:

    Thank you. I have grabbed it up to learn from. :)

    If you're interested, I could probably put a package together that would spin up a new 'instance' of dungeons if the destination is 'too full' if you wanted something like that.
  • KethaKetha Member Posts: 10
    Mermut said:

    Ketha said:

    Thank you. I have grabbed it up to learn from. :)

    If you're interested, I could probably put a package together that would spin up a new 'instance' of dungeons if the destination is 'too full' if you wanted something like that.

    I would absolutely love that! Thank you again, Mermut!
  • MermutMermut Member Posts: 44
    Ketha said:

    Mermut said:

    Ketha said:

    Thank you. I have grabbed it up to learn from. :)

    If you're interested, I could probably put a package together that would spin up a new 'instance' of dungeons if the destination is 'too full' if you wanted something like that.

    I would absolutely love that! Thank you again, Mermut!
    Been busy recently. I'll start working on this after the holiday weekend.
  • nivniv Member, Moderator, Developer Posts: 410
    edited May 2018
    Sorry, @Mermut, I'm confused. How does the object cache prevent you from hooking up doors?

    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.
  • MermutMermut Member Posts: 44
    niv said:

    Sorry, @Mermut, I'm confused. How does the object cache prevent you from hooking up doors?

    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.

    I tested it when making my dynamic flat system.
    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.
  • nivniv Member, Moderator, Developer Posts: 410
    Thanks, I see what you mean. Tracking internally: #37398
  • nivniv Member, Moderator, Developer Posts: 410
    This should now be fixed in 8175: https://steamcommunity.com/games/704450/announcements/detail/1656642383190198217

    If I could bother you to test?
  • MermutMermut Member Posts: 44
    Will I need a separate install for the dev build?
  • nivniv Member, Moderator, Developer Posts: 410
    Yes, but you can copy/paste your install directory to avoid the extra download. Just start the install, then stop it; open the Beamdog Games directory, and copy/paste your current install over. Then let it install/verify.
  • MermutMermut Member Posts: 44
    I just ran my dynamic flats demo mod..
    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!
  • MermutMermut Member Posts: 44
    Ketha said:

    Mermut said:

    Ketha said:

    Thank you. I have grabbed it up to learn from. :)

    If you're interested, I could probably put a package together that would spin up a new 'instance' of dungeons if the destination is 'too full' if you wanted something like that.

    I would absolutely love that! Thank you again, Mermut!
    I've been laying the groundwork for this and there are waaaaay more variables to consider. I'd like to get your thoughts.
    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.
Sign In or Register to comment.