Just discovered a little annoyance that will self-correct when this (fixed?) patch moves into the retail branch. Fixing the brightness in the dev branch also affects the retail branch and vice versa. Why? It's down to there being only one settings.tml that is used by both branches. That means that I have to keep adjusting the gamma whenever I switch between them. So if I don't want to go completely insane I'll have to choose to either continue testing the patch or go back to creating stuff for general release. Couldn't BD have a temporary settings.tml for the dev branch in the BD folders somewhere?
Anyone any ideas how to fix the lighting issues I seem to have with this latest patch? I'll use the very beginning area of my module "A is for Adventure 0" to illustrate it. This is how it looks in the retail version (i.e. how it is supposed to look) -
whereas this is how it now looks using the latest dev build -
As you can see in the first image the column of light just illuminates a very limited area of the area. This is a representation of daylight streaming in through the hole the PC just fell through. It is supposed to instantly create the visual atmosphere of the area.
For some reason, the new lighting model makes the light beam now illuminates the whole of the room, which destroys that atmosphere of mystery and removes the need for the PC to pick up the torch in order to explore. Before anyone says use the gamma setting to reinstate the lighting see my previous comment on that. Oh, and having to set it to 3+ is a bit extreme.
If I were to guess I would say that the above disparity is the result of one or both of two changes. Perhaps the new lighting model erroneously reflects too much light from the beam of light which is in reality only supposed to reflect from a very small area of the floor. On the other hand, maybe HDR compression is being used to the detriment of this area.
Whatever the reason I think this either needs to be fixed or at least a scriptable solution offered.
Thanks for sharing. Our position is that it's impossible to make it work for all existing custom content out of the box. It might look well enough, but if exact precision is desired, some edits might be needed, content-creator side.
This is development build 8193.15, which stabilises the previous .14 release. This is in all likelihood the last release before a stable patch, right around the corner.
@JuliusBorisov In response to your comment about cc, I created a module using standard assets in its entirety. The lighting setting used in all cases is "Reset to Black". While, to a degree, not quite so pronounced, the problem still persists -
Retail
Development
Note. The dev version this is done in is the very latest (8193.15).
One thing that might help to alleviate this would be to have a small standard gamma setting utility like most games with areas of light and dark have. That is one where there are graduated figures that range from dark to light and where the user clicks on the one that is only just visible on their system. This would need to be created by BD to help to ensure that we all sing from the same hymn sheet.
And still no fix to the pc/npc aura AI and targetting issue that has been plaguing us since BD began releasing updates? What is the point of any of these updates if you can't fix this huge glaring one, the one that renders NPCs into combat dummies, which, by the way, was Beamdog introduced. This has been reported by multiple people, from multiple platforms and environments, reproduced, corroborated, substantiated, test modules submitted, for over two years now.
What's the point of shiny lights and nuanced shadows when the core functionality is rendered useless? Does anyone check the bug reports for BD or is it just an abyss now,?
I hear your pain, @Old_Gith. There are only so many hours in the working day of our developers-- we cannot possibly do all the work. It's a question of priorities and handling issues step by step. We use the reporting sites very actively for NWN:EE, and everything we do is the result of many bug & feature reports and our subsequent work on them.
@TarotRedhand I've found that changing the area from Reset to Black to Interior, Torch-Lit Only, and changing the appearance of your light shaft from "Shaft of light" to "Lightshaft, Yellow Large" gets things back closer to your original atmosphere.
I see the stable patch has been released today. For those interested the patch notes are, as usual, on Steam. I'm liking a lot of the things I noticed right up front, and it warms my heart to see such changes. However, some of the very basic core things that have been broken (and please note these things were not broken in 1.69) still have not been fixed in spite of my attempts at creating tickets, submitting bug reports, etc:
auras and AoE effects wreaking havoc on NPC AI; NPCs are unable to target PCs with spells or even complete simple combat queues
wands completely devalued economically, which creates a rather substantial imbalance in favor of the player vs. the npc/bad guy/world
Lightning Tileset group from Dungeon tileset still inoperable -- all graphic/special fx have been scrubbed
Server Description field still parsed and truncated in the Server List Interface
the CONSTANT, "DAMAGE_POWER_PLUS_SIX" is still PLUS_SEVEN
Disappointed that the dev version has been released without the issue this introduces that I am talking about being fixed. Following on from the comment made by @JFK I have done further additional experiments. All use the same area. Here are the results -
First here is the result of using a yellow shaft of light with an area setting of Torchlight Only.
Next is a Large Yellow Lightshaft with an area setting of Reset to Black.
Finally here is a Large Yellow Lightshaft with an area setting of Torchlight Only.
Compare these to the image obtained using the same area with a yellow shaft of light and an area setting of Reset to Black in the previous retail version in my previous post. You should be able to see that none of these experimental settings really work to achieve the same effect.
While I appreciate that there are loads of improvements in this latest patch, the issue that I am illustrating here is going to adversely affect a lot of modules both new and old. I just wish there was some way to control the radius of the excessive light scatter introduced in this patch.
@JuliusBorisov Download speed is dire again. Currently at < 30k a second. To put it another way, it is downloading with all the speed of an arthritic snail going in reverse.
Just did a quick playthrough of the Prelude, and I have this to report. There is periodic lag during gameplay. Something is causing the game to literally freeze for all of 1-2 seconds until it finally cycles up to real time.
And of course, the ever-present attack bonus miscalculation bug is still in my single-player game. In my latest combat with a couple of goblins, I started off with an unarmed attack of opportunity while Flurry of Blows was activated. That attack was done at my monk's full base attack bonus -2 from FoB as it should have been. It scored a hit which killed the first goblin and activated a Cleave attack on the second goblin. That attack was done at a -5 penalty to my monk's BaB in addition to his -3 unarmed attack penalty and the -2 penalty already applied by FoB. That attack resulted in a miss. My next unarmed attack, a normal unarmed attack, was done at a -10 penalty to my monk's BaB in addition to his -3 unarmed attack penalty and the -2 penalty already applied by FoB. Of course, that attack also resulted in a miss.
"Free attacks or extra attacks are the attacks that can be made in addition to those granted by a character's base attack bonus and dual-wielding. (So a case such as whirlwind attack, where attacks are made instead of regular attacks does not fall into this classification.) They are usually made with the main hand weapon, and are not reported on the character sheet. In most cases, sources of free attacks describe them as "at full base attack", but this is only accurate when there is a single free attack in a given round.
For the most part, free attacks form their own progression, starting at full base attack and proceeding at -5 (even for those qualifying for UBAB), and they occur between the regular main-hand attacks and the off-hand attacks. However, there are times when a free attack is inserted in the middle of the main- or off-hand attack sequences. If this happens, the attack progressions can appear rather strange, sometimes to the benefit of the attacker, sometimes to the detriment thereof (compared to what would take place if the free attack was inserted between main- and off-hand attacks). However, the end result is always better than the case without the free attack.
When a free attack is inserted in the main-hand sequence or free attack sequence, then an attack gets "promoted" to full base attack and a "true" free attack is added to the free attack progression to make up for the lost regular attack. When a free attack is inserted into the off-hand sequence there is no promotion, but an additional off-hand attack is still gained. (So with improved two-weapon fighting and a free attack inserted into the off-hand sequence, a character could end up with three off-hand attacks, with the second at -5 and the third at -10.) These insertions only occur when the free attack is generated by some combat action, such as an attack of opportunity or cleave.
Free attacks in the usual sequence (between main- and off- hand attacks) ignore dual-wielding penalties."
Per the D&D 3rd Edition Player's Handbook, "There is no such thing as an off-hand attack for a monk striking unarmed." So, why in The Nine Hells is there an off-hand attack sequence for a monk in unarmed combat? The same thing could be said about Druids in their Wildshape forms. These additional penalties were not a part of the game until the release of Patch 1.6H8 for NWN Classic, and they should not be a part of the game now and forever. Their attack sequence is absolutely asinine. For the love of God, please stop the combat UI from applying an off-hand attack progression to what are clearly not off-hand attacks. Thank you for reading, and happy (healthy) gaming to all.
Just did a quick playthrough of the Prelude, and I have this to report. There is periodic lag during gameplay. Something is causing the game to literally freeze for all of 1-2 seconds until it finally cycles up to real time.
I thought it was just me. I've been experiencing that one since the summer, but I thought it was something on my end. Brief 1-3 second lag, things are still happening (like combat for instance), because it catches up with itself and sometimes you're dead and sometimes it's your opponent.
Hi! Please report the stutters/lags as a bug at https://beamdog.atlassian.net/servicedesk/customer/portals including information about your system, haks you use, other programs that you run on the same PC at the same time etc. In order to fix something, we need to first understand what is going on. We haven't got similar reports yet.
@JuliusBorisov My report has been sent, sir. In the meantime, would you please have the Beamdog devs focus their efforts into fixing NWN:EE's combat UI the BioWare devs broke when they released Patch 1.6H8 14 goddamn years ago? Thank you for reading, and happy (healthy) gaming to all.
I see that .21 stamps saves as version 1.83 (as we might expect, as there are new script commands) which means that the saves won't load in the Retail version. Not a bug, just for the record.
I see that .21 stamps saves as version 1.83 (as we might expect, as there are new script commands) which means that the saves won't load in the Retail version. Not a bug, just for the record.
Comments
TR
Or to Auras completely wrecking NPC AI (to include being able to target with spells)?
whereas this is how it now looks using the latest dev build -
As you can see in the first image the column of light just illuminates a very limited area of the area. This is a representation of daylight streaming in through the hole the PC just fell through. It is supposed to instantly create the visual atmosphere of the area.
For some reason, the new lighting model makes the light beam now illuminates the whole of the room, which destroys that atmosphere of mystery and removes the need for the PC to pick up the torch in order to explore. Before anyone says use the gamma setting to reinstate the lighting see my previous comment on that. Oh, and having to set it to 3+ is a bit extreme.
If I were to guess I would say that the above disparity is the result of one or both of two changes. Perhaps the new lighting model erroneously reflects too much light from the beam of light which is in reality only supposed to reflect from a very small area of the floor. On the other hand, maybe HDR compression is being used to the detriment of this area.
Whatever the reason I think this either needs to be fixed or at least a scriptable solution offered.
Thanks.
TR
TR
Hello, dear community!
This is development build 8193.15, which stabilises the previous .14 release. This is in all likelihood the last release before a stable patch, right around the corner.
https://steamcommunity.com/games/704450/announcements/detail/2879445149918174795
Retail
Development
Note. The dev version this is done in is the very latest (8193.15).
One thing that might help to alleviate this would be to have a small standard gamma setting utility like most games with areas of light and dark have. That is one where there are graduated figures that range from dark to light and where the user clicks on the one that is only just visible on their system. This would need to be created by BD to help to ensure that we all sing from the same hymn sheet.
Thank you.
TR
What's the point of shiny lights and nuanced shadows when the core functionality is rendered useless? Does anyone check the bug reports for BD or is it just an abyss now,?
First here is the result of using a yellow shaft of light with an area setting of Torchlight Only.
Next is a Large Yellow Lightshaft with an area setting of Reset to Black.
Finally here is a Large Yellow Lightshaft with an area setting of Torchlight Only.
Compare these to the image obtained using the same area with a yellow shaft of light and an area setting of Reset to Black in the previous retail version in my previous post. You should be able to see that none of these experimental settings really work to achieve the same effect.
While I appreciate that there are loads of improvements in this latest patch, the issue that I am illustrating here is going to adversely affect a lot of modules both new and old. I just wish there was some way to control the radius of the excessive light scatter introduced in this patch.
TR
strength
wisdom
intelligence
This didn't used to be a problem; not sure what happened.
Thank you for reading, and happy (healthy) gaming to all.
TR
CopyArea() crashes when called multiple times on Build .17 and .18. It does not crash on .16.
Bug report and example module submitted.
Thanks! We're looking into it already.
And of course, the ever-present attack bonus miscalculation bug is still in my single-player game. In my latest combat with a couple of goblins, I started off with an unarmed attack of opportunity while Flurry of Blows was activated. That attack was done at my monk's full base attack bonus -2 from FoB as it should have been. It scored a hit which killed the first goblin and activated a Cleave attack on the second goblin. That attack was done at a -5 penalty to my monk's BaB in addition to his -3 unarmed attack penalty and the -2 penalty already applied by FoB. That attack resulted in a miss. My next unarmed attack, a normal unarmed attack, was done at a -10 penalty to my monk's BaB in addition to his -3 unarmed attack penalty and the -2 penalty already applied by FoB. Of course, that attack also resulted in a miss.
The description of Free Attack at NWNWiki states:
"Free attacks or extra attacks are the attacks that can be made in addition to those granted by a character's base attack bonus and dual-wielding. (So a case such as whirlwind attack, where attacks are made instead of regular attacks does not fall into this classification.) They are usually made with the main hand weapon, and are not reported on the character sheet. In most cases, sources of free attacks describe them as "at full base attack", but this is only accurate when there is a single free attack in a given round.
For the most part, free attacks form their own progression, starting at full base attack and proceeding at -5 (even for those qualifying for UBAB), and they occur between the regular main-hand attacks and the off-hand attacks. However, there are times when a free attack is inserted in the middle of the main- or off-hand attack sequences. If this happens, the attack progressions can appear rather strange, sometimes to the benefit of the attacker, sometimes to the detriment thereof (compared to what would take place if the free attack was inserted between main- and off-hand attacks). However, the end result is always better than the case without the free attack.
When a free attack is inserted in the main-hand sequence or free attack sequence, then an attack gets "promoted" to full base attack and a "true" free attack is added to the free attack progression to make up for the lost regular attack. When a free attack is inserted into the off-hand sequence there is no promotion, but an additional off-hand attack is still gained. (So with improved two-weapon fighting and a free attack inserted into the off-hand sequence, a character could end up with three off-hand attacks, with the second at -5 and the third at -10.) These insertions only occur when the free attack is generated by some combat action, such as an attack of opportunity or cleave.
Free attacks in the usual sequence (between main- and off- hand attacks) ignore dual-wielding penalties."
Per the D&D 3rd Edition Player's Handbook, "There is no such thing as an off-hand attack for a monk striking unarmed." So, why in The Nine Hells is there an off-hand attack sequence for a monk in unarmed combat? The same thing could be said about Druids in their Wildshape forms. These additional penalties were not a part of the game until the release of Patch 1.6H8 for NWN Classic, and they should not be a part of the game now and forever. Their attack sequence is absolutely asinine. For the love of God, please stop the combat UI from applying an off-hand attack progression to what are clearly not off-hand attacks. Thank you for reading, and happy (healthy) gaming to all.
I thought it was just me. I've been experiencing that one since the summer, but I thought it was something on my end. Brief 1-3 second lag, things are still happening (like combat for instance), because it catches up with itself and sometimes you're dead and sometimes it's your opponent.
TR
The default font looks good, but the high resolution font looks like a 1950s typewriter for some reason.
Thanks a lot for this feedback!
Not immediately. You, can, however, try experimenting with putting in TTF files in override.