https://steamcommunity.com/games/704450/announcements/
An important update to release 1.80, with new lighting, additional premium module content for builders, conversation parameters (gasp), and much more.
Just read through it and had a look at the images. Wow !!!
Before anyone mentions it… Yes I am aware that I need to check through all my glowing placeables/creatures to adjust a certain setting. That is hundreds of models. Until I can get around to it, these will show up as being just white. It’s something to do with a slight difference between how NwN used to work and the new EE shaders.
BTW for me the download runs at about 60% of normal speed. My guess is that there’s a lot of people currently downloading it.
TR
Wow, that’s a huge update! Targeting, script/convo params, zwerkules’ tilesets, 16k limit removed etc. Good stuff!
Edit: Seems they renamed the medieval sets (trm02, tcm02) so that will be less useful. I was hoping to be able to get rid of them from my haklist…
Yes, I was wondering about that. How would the Zwerk’s tileset additions (congratz @Zwerkules!) conflict or not conflict with those of us that have already been using his fabulous versions of these tilesets from the Vault.
edit the *.are files of the areas using these tilesets with GFF editor in modules/temp0, change trm01 to trm02, open the area in toolset (might possibly need save&load the module) and if the toolset doesn’t crash it is compatible and you can keep it. If all your areas will be compatible then you will be able to remove the haks from your module, if not you will have to recreate them in the new core tilesets.
1 Like
It’s not just renamed from tcm01 to tcm02. The tilesets are different. All third party content was replaced with my own models and textures were replaced by ones from people from Ossian Studios and me. The only thing that wasn’t replaced is the round temple group (3x3). That temple was based on an NWN2 model. The empty tiles are still there, but the temple is gone. It is available as a placeable at the vault though.
What Shadooow said should work because the set files are basically the same. No tiles have been removed.
First of all, well done, Zwerkules! Well deserved recognition for your excellent work,
I’ve got the dev build on a partition on my iMac as I wasn’t sure what it would affect using the toolset on WINE but it seems so far to be okay.
I haven’t had a chance to tryout in game though. Has anyone given it a whirl in game to see if the sample images from Beamdog translate into making a difference in game ?
Yeah, I know that. Thanks though 
Briefly. It is a bit spooky at first, seeing saved games in a new light, literally. The most obvious change is that metal armours now look shiny. Torches etc look a bit different too.
The rest looks similar, but then I generally play with all the EE advanced visual options off, which might make a difference.
Ok, thanks.
As an experiment I have played my module “A is for Adventure 0” on both the current Retail and the new dev build. A good proportion of this adventure is set underground and, as intimated in the patch notes, I found that without adjusting the gamma it is way too bright. Setting it to 3.3 restored the gloom to about what it should be. That is quite a bit of change needed to restore the darkness to what it should be.
So what other differences did I notice. Quite a few things seem to be subtle. While I didn’t see any difference in the various bits of water shadows seemed to work very slightly better. Also my impression is that torch flames seem ever so slightly better animated (as long as its not wishful thinking on my part). I did notice that in certain circumstances that point light-sources (like lamps in a pit) seemed to cast a more localised light (sorry I can’t be more precise).
As far as armour goes I can’t really report as this is an adventure for a beginning level adventurer so the only really armour is leather/studded leather. After zooming right in, I think that the small amount of metal on the shoulder does exhibit a difference but I’m not quite sure what.
Actually, apart from the gamma, the biggest difference I noticed was on the large crystals in the starting area. These were definitely shinier but at the cost of the subtle details of the texture observable in the retail version.
FWIW I chose this module for a few reasons. Primarily because it is mine so I have a good idea of how it should look. That meant I could check that nothing had been broken which (gamma notwithstanding) I can happily report that nothing was. Also because it is short which lends itself to side by side testing of the retail vs the dev versions.
Hope that helps.
BTW, I did see in the patch notes that there are quite a few things that have changed as far as the toolset is concerned too. Anyone tried it since the patch? If so, anything to report?
TR
3 Likes
Having gone through my main glowing models so that they all still show colour instead of glaring white I have noticed something. Compared to Diamond/1.69/Retail EE the amount of glow varies more in this dev build. Some of my arcane circles (the thin blue ones in particular) are so dim as to be nearly invisible in darkness. Whereas some of my arcane runes really stand out. Also some of the floor runes are not as visible compared to the same runes in their wall versions. Odd.
Will post in a separate thread when I get around to editing the project pages to add these new versions.
TR
Regarding toolset, just did a quick test and seems to work fine.
The conversation parameters will come in handy when starting a new project.
Made a simple conversation check that will check module int X and return positive if X is true.
Just set a conversation paramter by the name of int_mod and give it the name of the int you’re checking.
I’m sure there are million better ways to do it, but this works
(I forget how to post code here…)
//::///////////////////////////////////////////////
//:: chk_int_mod_prm
//:://////////////////////////////////////////////
//:://////////////////////////////////////////////
//:: Created By: Script Wizard
//:: Created On: 26-09-2002 15:21:14
//:://////////////////////////////////////////////
int StartingConditional()
{
string sParameter = GetScriptParam(“int_mod”);
// Inspect local variables
// if Module int sParameter isn't true, then false
// now set conv parameter "int_mod" to the name of the mod int you wish to check
if(!(GetLocalInt(GetModule(), sParameter) == 1))
return FALSE;
return TRUE;
}
I meant to ask about this, and perhaps I’m too dense or too tired from working graveyards or just information overloaded from all of my projects, but what is the intent behind the new script parameters? Under what circumstances should they be used, and/or how are they to be used?
For my part I will use it to cut down on the number of checking/setting variables scripts in my conversations, by writing som sets of scripts like the one in my previous post (and others for pcspeaker/object_self, instead of module variables) and then just setting the variables in the conversation-editor
/Pap
Just to give one scripting example, if the PC has to choose one of n options in conversation, hitherto it took n scripts to detect which option was chosen. Now it takes one script.
Another example - when awarding XP, you previously needed one script for every XP value, now you only need one. Skill checks required (no of skills x no of skill ranges) scripts, now only one. The list is endless.
Having fewer scripts makes debugging quicker, code easier to find / change, and the toolset faster (though that last point is not such a bugbear in EE as it was in 1.69).
2 Likes
I’ve been going over my own modules to brighten up areas that have become darker, which may be the case for any builder still active to go through and do some touching up.
The screenshot is from using a lot of the new Enhanced Edition content Zwerkules, Dafena, LB, and NWIC have made.
FP!
2 Likes
I’ve reported two bugs:
- Greyscale portraits render as red & black (PC & NPC)
- Huge fps hit in SoU. The module starts off at 23.8 fps (83 in stable), drops to 16.4 immediately after the henchman convo (71.4 fps in stable), and goes up to 20 fps right before going down the stairs (77 fps in stable).
I have no idea why the fps hit is so much in the first area of SoU. It’s not that bad in my custom modules, but there it is.
@Tarot_Redhand - Instead of changing the gamma value, I changed Lighting Max Intensity to 1.0 which helped tremendously. I’m also trying out Lighting Intensity at Range = 0.10 which has a more subtle impact. By comparison, when I tried changing gamma, I did not like the look at all. For me, it overemphasized the blacks.