A very long time ago there was mention of Beamdog providing us modders with a 3d to 2d sprite tool that was used for SOD. Any chance you could ask about that. I'm a give and take kind of person, so in return I can give Beamdog my pink haired M'Khiin sprite ?
@TarotRedhand You're welcome, sir. Again, my apologies for any role I may have played in the derailment of this thread. Please understand, this issue I have with the current state of NWN's combat UI has been grating on me for a very long time. The only other time I remember being this upset by a change in a computer game's mechanics is when Sony Online Entertainment (now Daybreak Games) released the Combat Upgrade followed by their "New Game Enhancements" for the long-deactivated Star Wars Galaxies. I've finally reached the point where I can't stand playing NWN:EE while that bug persists in wreaking havoc on my character's attack rolls. You have no idea how much I loathe its existence. That thing is a compromise between a revolving door and a rollercoaster gone bad. It just needs to die. Thank you for reading, and happy (healthy) gaming to all.
Edit: It has been brought to my attention that the analogy I used was a little extreme. I have since reworded it. My apologies. It was never my intent to show disrespect towards anyone with behavioral disorders. I, for one, have OCD like a Mike Foxtrotter. I guess that explains why I find this particular bug so antagonistic. Its miscalculation of attack bonuses is both chaotic and erratic to the point of literally screaming at me. There is neither anything I can do to tune it out nor stop it from reproducing, except stop playing NWN:EE altogether. It is imperative this bug be fixed as soon as humanly possible. Please. As someone suggested in a PM, I will be more careful in the future. Again, my apologies.
@JuliusBorisov
Just realized this functionality was broken in the v2.3 -> v2.5 patch:
Opcode 12: Special Field: BIT1
In v2.3, this bit caused the damage to drain hp from the caster, giving to the target.
(Transfer HP from caster to the target.)
This worked opposite to BIT0, which caused the damage to drain hp from the target, giving to the caster.
(Transfer HP from target to the caster.)
In v2.5, BIT1 still causes hp to be drained from the caster, but it is then given back to the caster, rendering it useless.
(Transfer HP from the caster to the caster.)
@JuliusBorisov
Just realized this functionality was broken in the v2.3 -> v2.5 patch:
Opcode 12: Special Field: BIT1
In v2.3, this bit caused the damage to drain hp from the caster, giving to the target.
(Transfer HP from caster to the target.)
This worked opposite to BIT0, which caused the damage to drain hp from the target, giving to the caster.
(Transfer HP from target to the caster.)
In v2.5, BIT1 still causes hp to be drained from the caster, but it is then given back to the caster, rendering it useless.
(Transfer HP from the caster to the caster.)
Any chance this was caught for the v2.6 patch?
The life drain flags in opcode 12 have seen a fix and a revamp in 2.6. Temporary hp is only added if the normal maximum is exceeded. Furthermore, effects carried by the recipient of the temporary hp bonus have resource, mschool, msectype and resist_dispel (types 2 or 3 depending on parent damage effect resist_dispel) fields properly set. So they can be dispellable like a normal effect.
The bits now work as follows:
- bit0 (1) - Normal HP Drain (cumulative)
- bit1 (2) - Reversed HP Drain recipient and target (cumulative)
- bit2 (4) - Fist damage only (unchanged)
- bit3 (8) - Normal HP Drain (noncumulative)
- bit4 (16) - Reversed HP Drain recipient and target (noncumulative)
- bit5 (32) - Suppress damage feedback (unchanged)
- bit6 (64) - HP drain number limited to amount available by target (checks stat MINHITPOINTS)
- bit7 (128) - HP drain number limited to amount necessary to heal recipient to full HP
- further bits unchanged
Bits 0,1,3, and 4 are mutually exclusive. Bit7 prevents temporary hp gain.
Notice there are essentially 2 modes the bonus temporary hp are calculated: cumulative and non-cumulative. Cumulative works as you'd imagine: extra hp are simply added on if recipient of the drain is at maximum hp (including any previous temporary hp). Noncumulative hp drain calculates extra hp gain based on where the current hp of the recipient is relative to the normal (unextended by noncumulative hp bonus) maximum. Furthermore, all noncumulative hp drain effects are treated as a coexisting group, where the highest extra hp roll is added to the maximum hitpoints without dispelling any lower rolls. So the recipient will still benefit if the lower rolls have a longer duration than the higher roll.
Here's an example: if the caster gains 4 temporary hp from a previous noncumulative hp drain, suffers 5 damage, then drains 2 hit points, (s)he will be cured 2 hitpoints of which 1 hp will be "stored" as an extra hitpoint for a certain duration set by the damage effect.
Vampiric Touch (SPWI314A.spl) and most other life draining spells have bits 3 and 6 set to allow for multiple castings with noncumulative coexisting benefits and to limit the hp drained to however many hp the target has. So no more gaining 30 hp from a 5 hp kobold. Meanwhile, Shadow Pact (BDSHPACT.spl in SoD, SPIN195.spl in IWD:EE) uses bits 1,6, and 7 in conjunction to a 0-duration set min hp to 1 for the caster to limit the hp transfer between the caster and the target to either one of: 1. up to target's normal maximum or 2. down to the caster having 1 hp remaining.
Modding in the old IE engine was incredibly basic and very restricted. Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding.
This is an overstatement (speaking as someone who's modded very extensively in both vanilla and EE). The EE has some very nice features that make some things possible that were impossible, and some things simple that were difficult, but it doesn't fundamentally change things. SCS, for instance, leans significantly on EE (or ToBEx) features, but mostly to refine things, not change them dramatically. I could achieve 90% of what SCS does without them (and did: SCS long predates EE and ToBEx).
Similarly, if you're producing content (NPCs, new areas, new combat encounters, new quests) then modding for the EE is not dramatically different. You get really dramatic differences only for mods that mess with the rulesets (new kits, new spells). There the EE really does open up new vistas. But even then, there were very extensive kit and spell mods before EE.
Modding in the old IE engine was incredibly basic and very restricted. Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding.
This is an overstatement (speaking as someone who's modded very extensively in both vanilla and EE). The EE has some very nice features that make some things possible that were impossible, and some things simple that were difficult, but it doesn't fundamentally change things. SCS, for instance, leans significantly on EE (or ToBEx) features, but mostly to refine things, not change them dramatically. I could achieve 90% of what SCS does without them (and did: SCS long predates EE and ToBEx).
Similarly, if you're producing content (NPCs, new areas, new combat encounters, new quests) then modding for the EE is not dramatically different. You get really dramatic differences only for mods that mess with the rulesets (new kits, new spells). There the EE really does open up new vistas. But even then, there were very extensive kit and spell mods before EE.
You should look at some of the crazy stuff subtledoctor's mods do that are outright impossible in vanilla. Multiclass bards, sorcerors, shamans, etc. Any caster class can cast spontaneously, etc. A lot of hardcoded class stuff is now either outright editable, or a has workarounds that aren't hacky.
Of course, this ignores the initial context of the discussion in which it was claimed that direct dev support of mods is somehow bad. My point was that BG modding suffered for a LONG time because of how inherently un-moddable IE was before Weidu. Look at early IE modding versus something like SKyrim or games that are designed by the devs to be modabble from either day 1 or early in the titles' life.
Modding in the old IE engine was incredibly basic and very restricted. Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding.
In fact, it was @Shin who mentioned Weidu alongside things like BWP showing a tons of mods made before Beamdog's EE were even a thing. Your response to that was: "That entire post is wrong" and And that he should educate himself about "what modding for IE was ACTUALLY like before the EEs and after". So, no. You were not talking about Weidu there. You specifically mentioned Beamdog and the EEs.
And now your reply to @DavidW to support your argument "incredibly basic and very restricted" is just a couple of classes and kits (things he himself mentioned). Sure, there are lot of new possibilities but modding being incredibly basic and very restricted? That's a little too much. The originals/tutu/bgt also has lots of kits mods variety. And some of those are not converted to EE yet. I'm still waiting for Paladins of Faerun Kitpack for example.
If modding was so restrictive and basic, it would not have generated modding communities (in plural and even in other languages!) creating content for the games years and years after release. It would have been a niche thing with a couple of sites and a dozen of mods, at best, and that's it.
You should look at some of the crazy stuff subtledoctor's mods do that are outright impossible in vanilla. Multiclass bards, sorcerors, shamans, etc. Any caster class can cast spontaneously, etc. A lot of hardcoded class stuff is now either outright editable, or a has workarounds that aren't hacky.
I am well aware of this. (I was design consultant on IWD:EE, which introduced most of the features relevant to the 'crazy stuff' you're discussing, in particular opcodes 318, 321, 324 and 328.) And as I said before, for kits and spells it genuinely opens new vistas - though the pre-EE spell-mod/kit-mod scene still had a huge amount of content. My point stands: a significant improvement in modding potential for that class of mods doesn't imply an across-the-board sea change.
Of course, this ignores the initial context of the discussion in which it was claimed that direct dev support of mods is somehow bad.
I wasn't engaging with the 'initial context', just with the statement that 'Modding in the old IE engine was incredibly basic and very restricted', which (as a fifteen-year participant in the pre- and post-EE modding scenes, and a contributor to the EEs) I think is very overstated. (Put it this way: from a modder's point of view the difference between the EE and vanilla BG2 engines is very small compared to the difference between the BG2 and BG1 engines, or the BG2 and IWD engines. Modding in the latter really is 'incredibly basic and very restricted', at least for large classes of mods (AI/tactical, kit, spell, NPC) which is why you don't see a lot of BG1 or IWD mods.)
My point was that BG modding suffered for a LONG time because of how inherently un-moddable IE was before Weidu.
Weidu is wonderful; I yield to no-one in my admiration for it. (There are at most 5-10 people worldwide who know its workings better than I do.) But:
(a) it's a tool, not an engine; Weidu doesn't tell you anything about how moddable the IE engine is;
(b) Weidu was a fan creation, with no input from developers;
(c) Weidu released in 2002, eighteen years ago and less than a year after Throne of Bhaal. Some interesting mods were produced in the pre-Weidu era, but the vast majority of IE modding history happened under Weidu.
So to sum it up:
the BG trilogy and BG:ee are awesome games in their own right.
Thank you all for the insight and the many mods we can enjoy . And all the devs for making some truly wonderful games.
But back to the questions:
1) We have seen the 2.5 version of IWD:ee for iOS made unmodable by accident. Will this be remedied in the 2.6 version?
2) and will you promise to not introduce the 2.5 IWD:ee unmodable feature in the other versions ? It would be a major let down..
3) The iOS version of NWN:EE is apparently easier to mod. Will you take this into consideration when updating the iOS version of the other games in the series? I know you don’t openly support mod support - but in reality you have been very forthcoming so far.... and thank you for that as well
@_DD_ "Sorry, I was just reading this and you actually never mentioned Weidu. Your posts were very specific:"
I didn't mention it, because I didn't think I had to. Everyone on this forum is at least aware of Weidu. Did you think I was talking about hex editing as improvements or something?
@DavidW "I wasn't engaging with the 'initial context', just with the statement that 'Modding in the old IE engine was incredibly basic and very restricted'"
My entire point about BG's modding was in direct comparison to other games, not in a vacuum. So you're 'point' isn't even relevant here.
My point was that dev supported modding makes games much easier to mod, and makes more things possible easier and quicker. I am COMPARING BG's mod support to things like Skyrim or A Hat in Time. So yes, IN COMPARISON BG's modding scene WAS a lot more restricted out the gate. You can stop ignoring the context just to crap on me now.
Hi guys. How about giving the vanilla versus the new engine discussion a rest?
The discussion easily comes off topic since this is the “ask beamdog” thread.
And you are overshadowing my super relevant questions about iOS modding that at least 1-2 other forumites find moderately interesting...
@_DD_ "Sorry, I was just reading this and you actually never mentioned Weidu. Your posts were very specific:"
I didn't mention it, because I didn't think I had to. Everyone on this forum is at least aware of Weidu. Did you think I was talking about hex editing as improvements or something?
Are you gonna pretend you were talking about weidu all along?
@Shin " If you have to depend on dev support and bottom-up design in order to mod your game, you're already at a disadvantage."
That's almost exactly how it works though. Modding in the old IE engine was incredibly basic and very restricted. Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding.
@Shin That entire post is wrong. I'm sorry, but this discussion is just going to go around in circles until you actually educate yourself on what modding for IE was ACTUALLY like before the EEs and after. And then compare that to absolute EASE that something like Torchlight 2 or how literally anything Bethesda DEPENDS on mods to succeed.
Where is it? I have to assume since "I didn't mention it, because I didn't think I had to." that is somehow implied there? Where? In the "Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding." or in the "educate yourself on what modding for IE was ACTUALLY like before the EEs and after"?
What happened to the project of making new high poly models like the weapons and hall of justice that were released? Was it cancelled or continued?
We're not ready to comment about them. Right now, we're fully focused on the Dev build that is available and work with the feedback to it we're getting.
Please don't take this the wrong way. I love the game and I'm willing to toss more coin at Beamdog for anything they release for NWN.
But. It's been 2 years since the first enhanced models were released on Steam.
Beamdog if you need more money to enhance NWN:EE with more models, modules ecc. ecc. why don't you create a kickstarter or something else. I want to help advance this game and i know that there are many people who wants the same things. Please ... give us the possibility to help ... NWN:EE is a great project and have great potential and i hate to see all dump to nothing.
@_DD_ "Are you gonna pretend you were talking about weidu all along?"
Are you going to pretend that BG modding DOESN'T involve weidu? Its ubiquitous and I've already explained myself.
"Where is it? I have to assume since "I didn't mention it, because I didn't think I had to." that is somehow implied there? Where? In the "Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding.""
I already explained this in response to DavidW's post.
So its clear you aren't actually reading what I'm saying. I don't see any point to your posts other than to be insulting.
A very long time ago there was mention of Beamdog providing us modders with a 3d to 2d sprite tool that was used for SOD. Any chance you could ask about that. I'm a give and take kind of person, so in return I can give Beamdog my pink haired M'Khiin sprite ?
Thanks for the reminder. We're revisiting this subject.
@JuliusBorisov Just thought I should drop a line here and inform you that I have opened issue #155 at https://github.com/Beamdog/nwn-issues/issues. Maybe you and the devs can mosey on over and take a look? Appreciate it. Thank you for reading, and happy (healthy) gaming to all.
Thanks to Prince_Raymond's comment I discovered that there was a Beamdog organization on Github... with useful code in it! :-)
@JuliusBorisov could you please ping the developers also to look into https://github.com/Beamdog/bgfileformats/issues/1? It's just about the lack of a license statement on the code. Most likely it won't be a problem to add some standard OSS license so we can look at it without worrying.
I did not mean an issue on the "NWN-issues" project/repository on Github.
What I mean is that I want to know if it's possible to put a formal license on that code which was done some years ago (according to the commit dates), but that I don't know when or why it was published (the repository could be in private mode for a while, and released yesterday, but I don't know how I can find out).
I filled an issue in the specific repository, but then I realized that maybe that is not the proper way to ask Beamdog to do that, hence my comment here. ;-)
@JuliusBorisov Just scanned the patch notes linked to your post here from top to bottom, twice, with no mention of the attack bonus miscalculation bug being fixed. I have since updated the "Specifics" section of my open issue on GitHub to reflect the current build of NWN:EE Development. I will keep updating it to match the current build this bug remains within. With every new patch release not containing this fix, I grow more disappointed and disgusted. Why in the Nine Hells has this 14-year-old bug been left to run rampant in my single-player game? SMDH
Thank you for reading, and happy (healthy) gaming to all.
@Prince_Raymond The attack bonus miscalculation report of yours has been studied by developers for a few days. This is being looked at. They also remembered how the issue was raised and investigated several years ago. For the time being, that is the status of your report, so additional reminders won't help much.
@JuliusBorisov Yes, sir, the issue was seemingly raised and investigated right up to the point where the original investigators were no longer employed by Beamdog. Based on the initial response I got from Mr. Greg Holmes at your new/current customer support site, I was under the impression that my issue among many others had been swept aside during a heavy NWN:EE development cycle. That, I can understand. What I can't understand is why an issue as glaring and obviously wrong as this one could be ultimately dismissed as its own thing, when this thing didn't even exist until the release of Patch 1.68 for Neverwinter Nights Classic 14 years ago. Please, try to help me understand that misstep. I will cease my reminders as I await further news. Thank you for reading, and happy (healthy) gaming to all.
To clarify: what I meant is that your report has been studied lately. You brought that issue up, I made the devs aware about your request to look into it again. Even while Andrew G is no longer at Beamdog, others remember your issue.
As for why there hasn't been any solution which would please you,-- it's because bug reports and feature requests go through a triage system. To fix or change something, the developers first need to understand whether there is an issue and if the behaviour is working by design or not. This is not related to any particular issue-- this approach works for any potential bug or feature.
We don't "sweep aside" tickets. We have to prioritize some issues. This is normal for any development / post-release support.
@JuliusBorisov I can honestly tell you, sir, I truly believe in my heart of hearts that a base attack bonus perpetually falling into negative digits during every combat round is anything but working by design. Someone at BioWare made a mistake in the release of Patch 1.6H8, point blank and period. That mistake has been festering and making my single-player gaming experience an absolute nightmare for 14 years. Is it any wonder why I held on to my NWN Classic game patched to 1.67 for as long as I could before eventually fully transitioning to NWN:EE?
Before his departure from Beamdog, Mr. Andrew Gauthier or Shaiden (if we are talking about the same person) was the one who showed me all the links to nwn.fandom.com that I never knew about. If he had access to that information since it is a public domain, then it would be fair to say that the devs at both BioWare and Beamdog had access to it as well. Someone somewhere down the road knew better, yet someone somewhere down the road didn't do better. That mistake should have been rectified long before this point.
This makes me think of a bit of flavor text I read in a journal page of one Athrikus Narassin, whom my Warrior had to kill as part of a quest series in WoW Classic. The last line of the journal page reads as follows: "It is the things you dismiss which will hurt you the most, left to fester."
Thank you for reading, and happy (healthy) gaming to all.
Comments
TR
Edit: It has been brought to my attention that the analogy I used was a little extreme. I have since reworded it. My apologies. It was never my intent to show disrespect towards anyone with behavioral disorders. I, for one, have OCD like a Mike Foxtrotter. I guess that explains why I find this particular bug so antagonistic. Its miscalculation of attack bonuses is both chaotic and erratic to the point of literally screaming at me. There is neither anything I can do to tune it out nor stop it from reproducing, except stop playing NWN:EE altogether. It is imperative this bug be fixed as soon as humanly possible. Please. As someone suggested in a PM, I will be more careful in the future. Again, my apologies.
Just realized this functionality was broken in the v2.3 -> v2.5 patch:
Opcode 12: Special Field: BIT1
- In v2.3, this bit caused the damage to drain hp from the caster, giving to the target.
- In v2.5, BIT1 still causes hp to be drained from the caster, but it is then given back to the caster, rendering it useless.
Any chance this was caught for the v2.6 patch?(Transfer HP from caster to the target.)
This worked opposite to BIT0, which caused the damage to drain hp from the target, giving to the caster.
(Transfer HP from target to the caster.)
(Transfer HP from the caster to the caster.)
@kjeron Thanks, I've passed it around.
The life drain flags in opcode 12 have seen a fix and a revamp in 2.6. Temporary hp is only added if the normal maximum is exceeded. Furthermore, effects carried by the recipient of the temporary hp bonus have resource, mschool, msectype and resist_dispel (types 2 or 3 depending on parent damage effect resist_dispel) fields properly set. So they can be dispellable like a normal effect.
The bits now work as follows:
- bit0 (1) - Normal HP Drain (cumulative)
- bit1 (2) - Reversed HP Drain recipient and target (cumulative)
- bit2 (4) - Fist damage only (unchanged)
- bit3 (8) - Normal HP Drain (noncumulative)
- bit4 (16) - Reversed HP Drain recipient and target (noncumulative)
- bit5 (32) - Suppress damage feedback (unchanged)
- bit6 (64) - HP drain number limited to amount available by target (checks stat MINHITPOINTS)
- bit7 (128) - HP drain number limited to amount necessary to heal recipient to full HP
- further bits unchanged
Bits 0,1,3, and 4 are mutually exclusive. Bit7 prevents temporary hp gain.
Notice there are essentially 2 modes the bonus temporary hp are calculated: cumulative and non-cumulative. Cumulative works as you'd imagine: extra hp are simply added on if recipient of the drain is at maximum hp (including any previous temporary hp). Noncumulative hp drain calculates extra hp gain based on where the current hp of the recipient is relative to the normal (unextended by noncumulative hp bonus) maximum. Furthermore, all noncumulative hp drain effects are treated as a coexisting group, where the highest extra hp roll is added to the maximum hitpoints without dispelling any lower rolls. So the recipient will still benefit if the lower rolls have a longer duration than the higher roll.
Here's an example: if the caster gains 4 temporary hp from a previous noncumulative hp drain, suffers 5 damage, then drains 2 hit points, (s)he will be cured 2 hitpoints of which 1 hp will be "stored" as an extra hitpoint for a certain duration set by the damage effect.
Vampiric Touch (SPWI314A.spl) and most other life draining spells have bits 3 and 6 set to allow for multiple castings with noncumulative coexisting benefits and to limit the hp drained to however many hp the target has. So no more gaining 30 hp from a 5 hp kobold. Meanwhile, Shadow Pact (BDSHPACT.spl in SoD, SPIN195.spl in IWD:EE) uses bits 1,6, and 7 in conjunction to a 0-duration set min hp to 1 for the caster to limit the hp transfer between the caster and the target to either one of: 1. up to target's normal maximum or 2. down to the caster having 1 hp remaining.
This is an overstatement (speaking as someone who's modded very extensively in both vanilla and EE). The EE has some very nice features that make some things possible that were impossible, and some things simple that were difficult, but it doesn't fundamentally change things. SCS, for instance, leans significantly on EE (or ToBEx) features, but mostly to refine things, not change them dramatically. I could achieve 90% of what SCS does without them (and did: SCS long predates EE and ToBEx).
Similarly, if you're producing content (NPCs, new areas, new combat encounters, new quests) then modding for the EE is not dramatically different. You get really dramatic differences only for mods that mess with the rulesets (new kits, new spells). There the EE really does open up new vistas. But even then, there were very extensive kit and spell mods before EE.
Thank you.
You should look at some of the crazy stuff subtledoctor's mods do that are outright impossible in vanilla. Multiclass bards, sorcerors, shamans, etc. Any caster class can cast spontaneously, etc. A lot of hardcoded class stuff is now either outright editable, or a has workarounds that aren't hacky.
Of course, this ignores the initial context of the discussion in which it was claimed that direct dev support of mods is somehow bad. My point was that BG modding suffered for a LONG time because of how inherently un-moddable IE was before Weidu. Look at early IE modding versus something like SKyrim or games that are designed by the devs to be modabble from either day 1 or early in the titles' life.
Sorry, I was just reading this and you actually never mentioned Weidu. Your posts were very specific:
In fact, it was @Shin who mentioned Weidu alongside things like BWP showing a tons of mods made before Beamdog's EE were even a thing. Your response to that was: "That entire post is wrong" and And that he should educate himself about "what modding for IE was ACTUALLY like before the EEs and after". So, no. You were not talking about Weidu there. You specifically mentioned Beamdog and the EEs.
And now your reply to @DavidW to support your argument "incredibly basic and very restricted" is just a couple of classes and kits (things he himself mentioned). Sure, there are lot of new possibilities but modding being incredibly basic and very restricted? That's a little too much. The originals/tutu/bgt also has lots of kits mods variety. And some of those are not converted to EE yet. I'm still waiting for Paladins of Faerun Kitpack for example.
If modding was so restrictive and basic, it would not have generated modding communities (in plural and even in other languages!) creating content for the games years and years after release. It would have been a niche thing with a couple of sites and a dozen of mods, at best, and that's it.
I am well aware of this. (I was design consultant on IWD:EE, which introduced most of the features relevant to the 'crazy stuff' you're discussing, in particular opcodes 318, 321, 324 and 328.) And as I said before, for kits and spells it genuinely opens new vistas - though the pre-EE spell-mod/kit-mod scene still had a huge amount of content. My point stands: a significant improvement in modding potential for that class of mods doesn't imply an across-the-board sea change.
I wasn't engaging with the 'initial context', just with the statement that 'Modding in the old IE engine was incredibly basic and very restricted', which (as a fifteen-year participant in the pre- and post-EE modding scenes, and a contributor to the EEs) I think is very overstated. (Put it this way: from a modder's point of view the difference between the EE and vanilla BG2 engines is very small compared to the difference between the BG2 and BG1 engines, or the BG2 and IWD engines. Modding in the latter really is 'incredibly basic and very restricted', at least for large classes of mods (AI/tactical, kit, spell, NPC) which is why you don't see a lot of BG1 or IWD mods.)
Weidu is wonderful; I yield to no-one in my admiration for it. (There are at most 5-10 people worldwide who know its workings better than I do.) But:
(a) it's a tool, not an engine; Weidu doesn't tell you anything about how moddable the IE engine is;
(b) Weidu was a fan creation, with no input from developers;
(c) Weidu released in 2002, eighteen years ago and less than a year after Throne of Bhaal. Some interesting mods were produced in the pre-Weidu era, but the vast majority of IE modding history happened under Weidu.
the BG trilogy and BG:ee are awesome games in their own right.
Thank you all for the insight and the many mods we can enjoy
But back to the questions:
1) We have seen the 2.5 version of IWD:ee for iOS made unmodable by accident. Will this be remedied in the 2.6 version?
2) and will you promise to not introduce the 2.5 IWD:ee unmodable feature in the other versions ? It would be a major let down..
3) The iOS version of NWN:EE is apparently easier to mod. Will you take this into consideration when updating the iOS version of the other games in the series? I know you don’t openly support mod support - but in reality you have been very forthcoming so far.... and thank you for that as well
I didn't mention it, because I didn't think I had to. Everyone on this forum is at least aware of Weidu. Did you think I was talking about hex editing as improvements or something?
@DavidW "I wasn't engaging with the 'initial context', just with the statement that 'Modding in the old IE engine was incredibly basic and very restricted'"
My entire point about BG's modding was in direct comparison to other games, not in a vacuum. So you're 'point' isn't even relevant here.
My point was that dev supported modding makes games much easier to mod, and makes more things possible easier and quicker. I am COMPARING BG's mod support to things like Skyrim or A Hat in Time. So yes, IN COMPARISON BG's modding scene WAS a lot more restricted out the gate. You can stop ignoring the context just to crap on me now.
The discussion easily comes off topic since this is the “ask beamdog” thread.
And you are overshadowing my super relevant questions about iOS modding that at least 1-2 other forumites find moderately interesting...
Are you gonna pretend you were talking about weidu all along?
Where is it? I have to assume since "I didn't mention it, because I didn't think I had to." that is somehow implied there? Where? In the "Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding." or in the "educate yourself on what modding for IE was ACTUALLY like before the EEs and after"?
Please don't take this the wrong way. I love the game and I'm willing to toss more coin at Beamdog for anything they release for NWN.
But. It's been 2 years since the first enhanced models were released on Steam.
When will you be ready to talk about them?
Are you going to pretend that BG modding DOESN'T involve weidu? Its ubiquitous and I've already explained myself.
"Where is it? I have to assume since "I didn't mention it, because I didn't think I had to." that is somehow implied there? Where? In the "Mods are only able to do what they can do now BECAUSE Beamdog specifically opened up a lot of the coding.""
I already explained this in response to DavidW's post.
So its clear you aren't actually reading what I'm saying. I don't see any point to your posts other than to be insulting.
Thanks for the reminder. We're revisiting this subject.
@JuliusBorisov could you please ping the developers also to look into https://github.com/Beamdog/bgfileformats/issues/1? It's just about the lack of a license statement on the code. Most likely it won't be a problem to add some standard OSS license so we can look at it without worrying.
What I mean is that I want to know if it's possible to put a formal license on that code which was done some years ago (according to the commit dates), but that I don't know when or why it was published (the repository could be in private mode for a while, and released yesterday, but I don't know how I can find out).
I filled an issue in the specific repository, but then I realized that maybe that is not the proper way to ask Beamdog to do that, hence my comment here. ;-)
@JuliusBorisov Just scanned the patch notes linked to your post here from top to bottom, twice, with no mention of the attack bonus miscalculation bug being fixed. I have since updated the "Specifics" section of my open issue on GitHub to reflect the current build of NWN:EE Development. I will keep updating it to match the current build this bug remains within. With every new patch release not containing this fix, I grow more disappointed and disgusted. Why in the Nine Hells has this 14-year-old bug been left to run rampant in my single-player game? SMDH
Thank you for reading, and happy (healthy) gaming to all.
As for why there hasn't been any solution which would please you,-- it's because bug reports and feature requests go through a triage system. To fix or change something, the developers first need to understand whether there is an issue and if the behaviour is working by design or not. This is not related to any particular issue-- this approach works for any potential bug or feature.
We don't "sweep aside" tickets. We have to prioritize some issues. This is normal for any development / post-release support.
Before his departure from Beamdog, Mr. Andrew Gauthier or Shaiden (if we are talking about the same person) was the one who showed me all the links to nwn.fandom.com that I never knew about. If he had access to that information since it is a public domain, then it would be fair to say that the devs at both BioWare and Beamdog had access to it as well. Someone somewhere down the road knew better, yet someone somewhere down the road didn't do better. That mistake should have been rectified long before this point.
This makes me think of a bit of flavor text I read in a journal page of one Athrikus Narassin, whom my Warrior had to kill as part of a quest series in WoW Classic. The last line of the journal page reads as follows: "It is the things you dismiss which will hurt you the most, left to fester."
Thank you for reading, and happy (healthy) gaming to all.