The door transitions in EE work. After reverting to 1.69, they no longer work. If the game is started in 1.69 the door transitions work.
Seems to me that in addition to minimum version, something else needs to be changed or it is just not possible to edit an EE saved game to play in 1.69 (my current conclusion).
@sherincall As far as I can tell this was a case of where EE thought there was an error with the area transition that 1.69 knew there was not. As I mentioned in the first post in this thread, when EE detects an error (whether real or not) with an area transition it simply doesn’t show the transition or alter the cursor. 1.69 on the other hand shows both but nothing happens when you click.
I verified that it was EE falsely(?) detecting an error by creating a simple module (in the 1.69 toolset) with just two identical areas. In one I placed a waypoint and in the other drew an area transition trigger on the floor. I placed a simple script in the OnClick event of the trigger to handle the actual area transition. I did not set-up an area transition for the trigger. I then did three test runs (1.69, EE Retail and EE Development). It worked in all three. Removing the reference to the script on the other hand produces the behaviour noted in the first paragraph. Hence I knew it wasn’t a bug that used to be in EE but was fixed ages ago.
TR
Oh, right! Edited.
Regarding the transition, you’re saying that EE will not draw the blue transition if:
SetTransitionTarget() function). Why is this an issue though? If there’s no transition, and no script to do anything, how does anything happen in 1.69?Not exactly. That was to point out a difference between EE and Diamond that I noticed while confirming the issue with the above module was not a case of a previous (but since fixed) bug in EE returning. For some reason the scripted transition in this module works fine in 1.69 but not at all in EE. The thing is as far as I can tell, EE appears to think there is an error in the transition and therefore doesn’t show the transition or change the mouse cursor. Try as I might, I haven’t been able to duplicate this in a small test module.
If so, that is an unnecessary change for an unnecessary function. Why is the change unnecessary?
Why is the new function unnessary?
Look at this script -
// Simple script to enable area transition to one of two areas
// Choice of destination depends on local boolean variable
// Choise of destination is via waypoints
void main()
{
object oPC = GetClickingObject();
if(GetIsPC(oPC))
{
if(GetLocalInt(oPC, "GoTrueArea"))
AssignCommand(oPC, JumpToObject(GetObjectByTag("NW_Arrived")));
else
AssignCommand(oPC, JumpToObject(GetObjectByTag("NW_Arrived02")));
}
}
or this one -
#include "x0_i0_transport"
/*
// Transport a player and his/her associates to a waypoint.
// This does NOT transport the rest of the player's party,
// only their henchman, summoned, dominated, etc.
void TransportToWaypoint(object oPC, object oWaypoint);
*/
void main()
{
object oPC = GetClickingObject();
if(GetIsPC(oPC))
{
if(GetLocalInt(oPC, "GoTrueArea"))
TransportToWaypoint(oPC, GetWaypointByTag("NW_Arrived"));
else
TransportToWaypoint(oPC, GetWaypointByTag("NW_Arrived02"));
}
}
They’re simple and they work. Not only that but there are already different ways to achieve this functionality (just look in x0_i0_transport.nss for a start). Put simply I would rather have new functionality than a new function that duplicates that which is already achievable by simple means.
TR
Don’t quite follow the logic. Every EE addition can be considered unnecessary simply because 1.69 shipped successfully without it. The function is very useful, and arguably necessary to complement the area instancing - when you create multiple instances of a house, you want to make the door point to the correct one based on script logic.
I also consider not drawing the transition to be a (IMO very useful) feature. In 1.69 you had no way to disable a transition such that it is not shown at all. You could add logic to your script so that it doesn’t do anything when clicked, but it would still be there an clickable. The EE logic is clear:
if (HasTransitionTarget(oTrans) || HasOnClickScript(oTrans))
SetIsVisibleAndClickable(oTrans, TRUE);
else
SetIsVisibleAndClickable(oTrans, FALSE);
There is absolutely no reason IMO for a trans to be clickable if that click does not do absolutely anything. The playtester scenario is a bit of a stretch honestly. There’s a million other ways you can make a mistake that the playtester would not know what to expect.
There are some difference between a transition and a jump from a script. Most are encoded in scripts (e.g. horse related stuff) and can be replicated, or they’re just a matter of speed. But, the server pathfinding understands transitions, while it cannot understand script logic. So if you have a set of transitions that lead through areas A->B->C->D, you can tell an NPC to walk from A to D and they’ll know how to use them. If it requires them to enter an arbitrary trigger or use a placeable that will teleport them, they won’t know that unless you script.
@Tarot_Redhand are you slightly at cross-purposes with @sherincall? I’m not clear whether the transition you describe has neither transition script nor target?
I’m hazy about what other builders might have done in the past, but, as I recall, there is always a default script nw_g0_transition, and 1.69 didn’t show a transition unless it had a target? I found I had to set a dummy target, then hook nw_g0_transition to script a different one… but probably I missed something…
P.S. @sherincall As a matter of interest, it was possible to hide a transition in 1.69 by applying a cutscene invisibility effect. That still works in EE.
It would appear so. The transition in Saleron’s Gambit - Chapter Two is controlled by a script. It works with 1.69 but not with EE. I posted a simple fix earlier in this thread (I am not really willing to post an altered version of a Hall of Fame module). Thing is while I surmised a number of possible reasons why it fails in EE, I don’t really know why. I tried making a number of different test modules but couldn’t replicate the failure.
@sherincall Given that you apparently know more about this subject, please would you take a look and see if you can figure out why the particular transition fails (instructions for finding it in game are at the top of this thread). The module is Saleron’s Gambit - Chapter Two. Thank you.
TR
EE has long had a variety of bugs associated with transitions, This, for example. I do not know anything about the relevant Saleron’s Gambit transition, but if it also did not explicity use a “Jump” command it might be related.
@Tarot_Redhand I looked at that module, it is an EE bug that happens when a door without a transition, but with a valid OnClick script is destroyed, it does not leave behind a clickable blue transition. Rather than using invisible doors, that module places a regular door with a custom OnClick script (Specifically to have different targets based on script logic), and then destroys the door on HB. When destroying, the game didn’t check for OnClick scripts, just valid transitions.
This has been fixed in nwn 8187, from patch notes:
- We fixed some doors becoming unclickable after having been destroyed, despite having a scripted transition present.
So I advise not really fixing anything in these modules, just using a later version of the game to play them.
I might have found another of these transition issues. I’m playing Ravenloft: Beyond the Gate with EE, and in the area Justine’s Mercantiles, accessible from Forlorn: The Old Town, there are stairs without transitions, e.g. to the basement. According to the walkthrough there is a chest with a quest item in the basement, but I can’t access it due to there not being a visible transition.
And apparently I’m not the only one that happened to:
https://neverwintervault.org/comment/48100#comment-48100
EDIT: To clarify, these are in-area transitions to different waypoints on the map. In the toolset they look like wooden doors but in-game there are no doors. Sadly, I don’t know enough about the editor to understand what’s wrong.
I made do with the dm_jumptopoint command, but for future players it would be helpful if someone more knowledgeable could have a look at the issue and see whether it’s connected to EE and whether the upcoming patch will fix it or not.
Just to confirm, I loaded the module with NWN Diamond 1.69, and the transitions are visible and working there (as vertical blue surfaces in the frame of open doorways), so this is indeed another case of current NWN:EE incompatibility.
EDIT: And yeah, it’s caused by doors with OnClick script being destroyed.
This is easier said than done when you bought the game from GOG where later versions than 8186 are not available (and I’ll certainly not rebuy the game for the fourth time or so just to be able to play it on Steam).
But if this is already fixed (and so far this seems to be the only compatibility issue I ran in), I guess there’s not much point in me playing modules with EE instead of 1.69 just for the sake of finding outdated bugs that are still in my version but not the current builds. The game is more fun without having to deal with that. 
Bumping this thread because I have a question that may be related:
Does the transition bug noted above also affect secret doors? I have noticed in my PW mod, that all of the secret doors are simply visible, and no longer hidden.
I’m using the GoG version if that makes a difference. I really hope there’s a way to make this work and not have to buy another version from Steam instead of GoG.
Not familiar with that specific bug but it’s probably a custom content issue and solvable.
The GOG and Steam versions of the game are identical in functionality, but the Steam version might get development branch patches earlier, I’m not sure the GOG version does at all tbh, but if your concern is bugs then don’t bother with the dev branch at all anyway.
And even then the Steam version is usually on discount and the base price is hardly high.
I gifted 3 copies on steam for less than 10 USD a few weeks back, combining the regional pricing and discount at the time, can’t even get a mildly decent pizza for 10 bucks here. And these discounts are not infrequent.
I know I am replying to old post, however I don’t follow the logic here. If you copy area, all the objects in it will have same tag as original, so how are you supposed to re-link transitions then?
Or maybe I am doing something wrong when I use the OnClick script to do it?
I am not trying to say that the SetAreaTransition function is useless, it has it uses but @Tarot_Redhand is right about that you could already do that via scripting. What EE allows is to “remove the area transition highlight” when the transition is disabled which is “cleaner” if you do really want that.
And that happened after you migrated to EE? Either way I doubt this is game issue, are you even using vanilla scripting for it?
What are you using to allow players reveal them, trigger or invisible placeable? And are the doors placed inside area by default, or there is just waypoint? Answering this will give us an idea about which secret doors scripting system are you using.
I haven’t done any thing to ‘migrate’ the mod to EE. Skimming a few sources here and at the Beamdog forums indicated that if it was running in 1.69, it >should< work ok in EE.
There have been a few minor glitches I’ve found, like placeables that moved from their locations to inaccessible parts of a tile, but so far, they’ve all been pretty easy to fix.
I’ll go open the mod in the toolset again to verify, but I’m pretty sure it uses the standard ‘generic’ secret doors that were introduced in SoU.
Any ideas what I should look for (what script, any special tags) to see if it’s anything other than the standard secret door?
I haven’t messed around in the builder in years, and only recently picked it up again, so I’m having to re-learn a lot of the ins and outs. So I apologize in advance if I seem to be asking dumb or very basic questions, and I’m more than willing to accept a link and ‘go read this’ as an answer. 