Transferring characters from NWN EE to NWN Diamond seems to work fine, so I assume the opposite is true as well. Portraits seems to be the same, in any case the one transferred from EE displayed correctly in NWN Diamond.
Savegames from NWN EE are not compatible with NWN Diamond, even if they’re from a module that works with both editions. I haven’t tried transferring savegames from Diamond to EE yet. Incidentally, I found out NWN Diamond and EE seem to make use of the same savegame folder. I’ve got both editions installed on my harddisk and was under the impression that they are completely independent of each other, since the EE uses a folder in My Documents for everything, while Diamond puts everything in the game folder. But apparently that’s not he case and when it comes to savegames, they interfere with each other. EE savegames suddenly appeared in my NWN Diamond list (despite not being compatible and me not even trying to transfer these savegames - Diamond just seems to access the same folder).
NWN EE is theoretically supposed to be compatible with modules created with NWN Diamond, but in actuality there’s a chance that something goes wrong and breaks the game. I just ran into a missing transition issue with an old module in the EE, and when I checked the same module in NWN Diamond, the transition was there and working fine. So play old modules with the EE at your own risk.
If you enter the city, at the other end of the map, to the left, there’s a Temple of Oghma where you’ll get a quest to enter the crypts. The first level is just two chambers to pass through, then there’s a staircase transition to the second level, and when you’re in the second level, the transition back to level one is missing in the EE. You can test it without having to fight and you can quickly click through the conversation by always choosing option “1”, doesn’t take more than a couple of minutes to see, right at the start of the module.
Unfortunately I only found out after clearing most of the crypt levels below. D’oh! But I decided to start over in NWN Diamond anyway; didn’t feel like fixing my game only to run into similar issues later on. I’m glad I still have alternatives to the EE.
Thanks! I do not have Beamdog Enhanced Workshop Items or the CPP installed. Just the Customize Character Override Hak (CCOH), the Prisoner of the Mist GUI and the NPC soundsets unlocked, as far as I know.
Having looked into it, I have a solution for EE. It is so simple it is not worth posting a fixed version of the module. Just follow these instructions -
Open the module in the toolset
Open the level 2 of Ogma’s crypt in the toolset
Find the OghmaTemple2to1 door and open its properties
Select area transition and press the setup area transition button
Select waypoint and open the dropdown box
Scroll up 1 place and select that area (and not the one with the same name above it)
Select POST_OghmaWP1_Cutscene and press ok repeatedly until the dialogue closes (ignore messages/warnings)
Save the module and that’s it.
The reason why you have to do this is because the area transition is controlled by a script. Apparently EE needs an actual area transition to make this work while Diamond it would appear doesn’t.
Oh, thanks for taking all the time to investigate and post the solution, it’s interesting to learn what caused the issue, but I wasn’t really looking to fix it. I just thought you were interested in finding out why these things happen. I hope you didn’t waste too much time on it on my behalf. I’ve already transferred my character to NWN Diamond and played the module from scratch.
The thing is, even though these issues can be fixed, I don’t want to keep running into them, so I’ll just play the old modules with NWN Diamond from now on.
But in order to find out why it works in one and not the other I need to find a fix that works. Just so happens that as soon as I looked at the properties for that door I noticed that there wasn’t a tag for the target which was pretty suggestive of what the problem was.
Sadly, I’ve completely forgotten what little I had learnt about the toolset ten years ago, so I can’t be of much help, but I think the transition is meant to check whether the player has already defeated the boss in level 3 or not. If not, it should lead back to the default level 1 area, if yes, it should lead to the level 1 area with the cutscene. The cutscene uses a lot of creatures as extras that are absent from the default area. Maybe that’s why the author chose to handle it like that? I haven’t checked, but maybe the creatures are already placed in the cutscene area and not spawned in by script?
You mean it’s a shame that the module does not work correctly with the EE, or that I’m taking the easy way out?
I see your point, but I’m currently just playing to relax and don’t want to have to worry about running into issues and wondering whether they are caused by the EE or not. And truth be told, I’m not really a fan of the EE yet.
Is there a lively and constructive exchange between Beamdog and the modding community? Do they provide frequent updates/builds, and do you see significant progress on the EE? As a player who’s not that involved in the community anymore and who bought the EE on GOG and not on Steam, I don’t really witness any of it, so from this external perspective it can seem like work on the EE is stagnating, or as if Beamdog is prioritizing Steam customers (e.g. with Tyrants of the Moonsea).
@Olivier_Leroux There’s a fairly healthy dialogue between Beamdog and builders, with reasonably frequent updates to the development build (and some other beta activity). We get feedback on reported bugs and suggested improvements.
The most visible progress until recently has been on Android (which might not help everyone, but is useful to me). Now we have the PC 64 bit version in Development, which is surely a major enabling milestone, albeit light on new features. Understandably, there is frustration that major graphic improvements are still to come, but we hear that they’re in the pipeline.
I appreciate that players might not have the skills to fix the occasional issues with older modules in EE, but the community does. Given that the problems are few and far between, it would make sense to find them now, while both Beamdog and builders are still doing fixes.
If EE is the only version on the market, it’s wise to ensure that the old modules still work (which to a very large extent they already do).
I’m really glad and thankful that NWN Diamond is still available through GOG, even if only as bonus content to the EE, and even though I dislike the disparity between the shops where NWN is concerned.
Anyway, I’ll consider switching back to EE for Chapter 3. It’s not fun to run into these issues and I don’t want to tinker with the toolset or wait for others to do so when in the midst of an adventure, but on the other hand, NWN is all about the community, so I do feel a certain responsibility and obligation for me to make these small sacrifices for the sake of future players. We’ll see,
I skimmed the thread and there’s a bit of misinformation and missing info, so I’ll spell it out entirely:
NWN:DE (1.69) and NWN:EE compatibility
It is not possible for a server to serve both EE and 1.69. There have been some attempts to make this work, but they’re incomplete and they will never work for EE version 8188 or later.
Single player modules
Modules made for 1.69 should work with EE. Any breakage of this compatibility should be reported to Beamdog as a bug (though some are intentional, see below). @Tarot_Redhand - Can you summarize what this transition is, and file an issue on redmine?
Modules made for EE will not work out of the box with 1.69. This is because a .mod file has a “Minimal required game version” switch in it. This switch can be manually overridden to force compatibility. If you force open an EE module in 1.69:
Any shader based logic (animations, scaling, visual transforms) will revert to basic form (e.g. scaled placeables will have normal size)
Any scripts that use new EE functions will break
As a general rule, moving characters 1.69 -> EE will work, while the other way will not.
For EE versions up to (and including) 8187, full compatibility between characters is maintained. (8186 is the current stable)
Starting with 8188, Palemaster and RDD characters lose some of their hardcoded stats (AC and stat bonuses). Importing these characters to 1.69 will make them weaker, and possibly illegal.
Later EE patches may extend these changes to other classes
It is possible to write an external tool that imports EE characters to 1.69 without breakage.
A savegame is nothing more than a module+character, so the same rules apply
If you have played a module made for 1.69 in EE, with a non-broken character, you could just modify the “minimum game version” field and the save will work in 1.69.
If you are playing a module made for EE in EE, importing it to 1.69 will likely break various parts
BIK movies do not work in EE. They need to be converted to WebM format.
Various broken CC models will crash EE immediately upon load. These models have caused unpredictable instability in 1.69.
EE has many new features for CC (e.g. shaders, fancymaps, etc), which will not work in 1.69. Some might gracefully degrade appearance/performance, others will fail to load entirely or even crash.
Up to and including EE version 8187, database files are compatible both ways.
Starting with EE build 8188, database files may only be imported from 1.69, but not the other way.
NOTE: further EE versions will likely further break compatibility in the EE->1.69 direction. That is, any content made with/for EE is more and more unlikely to work on 1.69. 1.69->EE compatibility should generally remain stable, with possible exceptions (like bik->webm change)
I think you’ll agree that there is a bit of tension within Beamdog’s position. For example, legacy modules “should work”, but “broken CC models will crash EE” (even though they are required by legacy modules and didn’t crash before).
So, in practice, while it’s good to report all such problems to Beamdog in the hope of a fix, it also behoves the community to fix stuff, too.
Ideally, broken models would never crash the game, and instead would just fail to render (or be rendered as a red cube or something). However, there’s almost an infinite number of ways a model can be broken, and catching all of them is practically impossible.
On the other hand, if we make a list of broken models - ideally as a hak+mod that repros the issues - specific crashes can be patched.
I firmly believe that EE behavior of crashing immediately (and thus breaking the module) is much better than the 1.69 behavior of usually working, with an off chance of crashing, corrupting the save, subtly breaking your character, etc… or in case of an evil author, hijacking the process and installing malware.