This card now has the UI Refactor label on the Roadmap board, just like the UI Refactor Investigation card.
It should show the dependency between feature requests - other requests with this label cannot be done unless we do the full UI refactor first.
@Plok Your comment got caught in the spam filter, I've verified you, this shouldn't happen again (you can see your comment above).
Okay so it's not that it was removed but "incorporated" in another card? quite right? If so and then everything, is fine We can continue to discuss the topic .
I don't know what the game code looks like, but i do know my way around some of the scripting code,
scripts relying on GetLevelByPosition() will need to be rewritten to support additional classes.
but is that function even still useful? when we have functions like GetHitDice() or GetLevelByClass()?
Some servers even had systems to work around the limit by allowing you to get new feats and stuff from other classes but you never actually got any actual levels in those classes, but it was a pain to go through dialogues or whatever to level, would be so much nicer if the game just supported it.
@Plok Your comment got caught in the spam filter, I've verified you, this shouldn't happen again (you can see your comment above).
Thankyooouuu!
Looking back I kinda prefect the terse version, even if it might be construed as me being rude to Shadooow. Just goes to show how much better your writing can be when you're not making it up as you go along and editing it like crazy.
Level adjustment shouldn't have anything to do with classes. In D&D 3rd edition and 3.5 the experience needed for your next level is current ECL * 1000, total experience for next level is (1 + ECL) * ECL * 500. It's simple arithmetic so you don't need to give class levels to find the value. Racial HD on the other hand are essentially weak class levels.
It was an idea off the top of my head for the thought "what could you do if you didn't have to worry about class slots". There's all kinds of problems with it as an approach to implementing ECL, but I did feel that it has a rather attractive neatness to it. Like a really elegant hack to do something nifty that was never intended.
The only other way I see to do ECL via script is to have a script constantly massage a player's EXP and separately keep track of it. While this approach would be correct (unlike my off the cuff idea), it doesn't feel neat at all. In fact, it strikes me as the kind of thing that would just randomly go wrong for no discernable reason.
I think a UI refactor would be needed for a lot of things anyway. It should really be one of the main priorities in my humble opinion.
@Plok Case in point with a customizable UI you can just feed the correct experience values to the character sheet. Either with LA as an engine coded value or with custom content scripting.
It feels like Beamdog is all about customization when it comes to NWN:EE. Therefore I do not see a problem with adding the ability to multi-class in to 4 classes. Simply allow servers to customize the limitation.
The more freedom, the better, I say, especially when you give that freedom to persistent world builders who can apply the restrictions they want, rather than be forced by a hardcoded game.
It feels like Beamdog is all about customization when it comes to NWN:EE. Therefore I do not see a problem with adding the ability to multi-class in to 4 classes. Simply allow servers to customize the limitation.
Again. We already have the ability to limit number of classes. At least two methods to do that too. 1) delevel after levelup something that you don't want player to have (feat, skill, spell, multiclass) 2) use cls_pres_*.2da and then variable to restrict access to classes after some condition is met (such as already has 2 classes)
The cls_pres_*.2da doesn't exist normally for base classes but can be added and was added in my unofficial patch.
We certainly don't need another *.ini option or something to enable/disable 4th class (if made). If BeamDog decide to add this functionality it should be turned on by default and those who think 4th class is unbalanced or a problem can use the already existing mechanics to restrict it. If anything then BeamDog could adopt mine cls_pres_*.2das for base classes and add them into core game resources.
We certainly don't need another *.ini option or something to enable/disable 4th class (if made). If BeamDog decide to add this functionality it should be turned on by default and those who think 4th class is unbalanced or a problem can use the already existing mechanics to restrict it.
The purpose of an .ini option (or similar) is backwards compatibility. As mentioned before, a lot of peoples' scripts are of the pattern:
int i = 1;
int char_class;
while (i <= 3){
char_class = GetClassByPosition(i, oPC);
...
i++;
}
If someone adds a forth class to their character it would break scripts using this pattern. The purpose of an .ini setting is to make this feature opt-in rather than opt-out. If it's opt-in, then the assumption of 3 classes still holds true for old scripts.
Personally, I would think that having some property in the module would be the best way to do it from a community standpoint and maybe save the .ini switch for the single player Campaigns. This allows people to play the game as it was shipped or opt-in for quality of life improvements like this.
I'd also add a GUI for the single player switch in the options menu personally. Some sort of "enhancements" tab. Temple+ (an open source reimplementation of Temple of Elemental Evil) has a set of "House Rule" options for this kind of thing.
As explained before if you allow 4 classes but check for 3 there's no way to fix it except checking for 4. An ini option doesn't change that any more than checking for 2 classes when you allow 3.
As explained before if you allow 4 classes but check for 3 there's no way to fix it except checking for 4. An ini option doesn't change that any more than checking for 2 classes when you allow 3.
If I may say so without coming across as rude; I don't think you're understanding this.
The point of an ini/module option (or similar) is to not break it in the first place. If the new behaviour is opt-in then the script still works because its assumption of a maximum of 3 classes is still correct (because the module it's in hasn't opted in for >3 classes). New modules - with scripts that won't break - can opt-in for >3 classes.
Just adding >3 classes without any form of opt-in is effectively opt-out and will break old scripts/modules.
I don't think it will break any scripts because the above example will just never check for the 4th class. So if they wanted to use a fourth class they would have to change the script to look for the 4th class (opt in).
A module designed for 3 classes would never check for the 4th class if a player chose to have one.
It would affect conversations, custom items and custom scripts. Otherwise it should work as intended as a game mechanic.
I think you might be thinking about it back to front.
Consider how you can break a script with the current version and then consider how you fix that.
Sorry, I'm honestly not following. I've not done much scripting beyond hacking on the PRC compendium for single player. NWScript is C-like so I can jump into it with no problems. What exactly do I have back to front?
Just so you know where I'm coming from, my thinking on this is summarised by the following steps:
Existing modules must continue to work without modification (which, according to the streams, is Beamdog's core policy)
Adding >3 classes will break some modules.
Ergo it must something that a module opts into once the appropriate changes are made to its scripts
????
Profit (sorry, couldn't resist).
This is fundamentally the same problem as trying to change a web/network interface to a system - you don't know who's depending on it so you can't just change your interface/behaviour recklessly. The correct way to go in these circumstances is to leave the old behaviour as is and let people opt in for the new behaviour. Ideally you'd also deprecate and eventually remove the old behaviour, but that's not really practical here.
Why yes! I am a programmer who's had to maintain poorly written HTTP/REST APIs, thankyou for asking.
The purpose of an .ini option (or similar) is backwards compatibility. As mentioned before, a lot of peoples' scripts are of the pattern:
int i = 1;
int char_class;
while (i <= 3){
char_class = GetClassByPosition(i, oPC);
...
i++;
}
Okay, but there are few flaws on this example.
1) This is crucial. What you need to understand is that the ini option is player's choice. You as a module creator have no controll whether the player will or will not have this said option set or not. And 99% players will want to play with 4 classes. So this would solve nothing, just pointless option. Only place where this option matters is multiplayer, but there are no problems with compatibility as everyone running persistent world should be updating their module to latest standards and therefore impose limit on number of classes using those two techniques I mentioned (if they don't like players to get 4). If they don't it is not BD fault.
2) If BD allows 4th. class, technically it won't break this script as you claim so. What happens is that the script will work incorrectly if the player has 4th class. This is no different to the script checking all vanilla classes and you playing with class from PRC. This might or might not have fatal consequences based on the purpose of the script. However, I dare to claim that checking levels by position is not that common and it is rarely used and when it is used it probably won't be anything crucial.
3) Even if your said ini option would prevent player to picking 4th class it would not prevent him to bring character with 4 classes already.
Backward compatibility = it will work. And that it will. With faults, but it will work regardless. And if it happens that some module got broken with 4th class then it is player's responsibility just as if player would be using PRC in some random singleplayer module. Furthermore, community can apply a fix for such module that is not a problem. We already made fixes to some tilesets that were crashing on NWN:EE.
1) This is crucial. What you need to understand is that the ini option is player's choice. You as a module creator have no controll whether the player will or will not have this said option set or not. And 99% players will want to play with 4 classes. So this would solve nothing, just pointless option. Only place where this option matters is multiplayer, but there are no problems with compatibility as everyone running persistent world should be updating their module to latest standards and therefore impose limit on number of classes using those two techniques I mentioned (if they don't like players to get 4). If they don't it is not BD fault.
Ini file also applies for server, so you can certainly control a PW. As a module creator, you have no control over the player playing your module as they please. It's been like this since day one. Don't want me to play RDD? Too bad, I can open up the toolset and remove your scripts that target to ban this class. So it is, so it shall always be.
2) If BD allows 4th. class, technically it won't break this script as you claim so. What happens is that the script will work incorrectly if the player has 4th class. This is no different to the script checking all vanilla classes and you playing with class from PRC. This might or might not have fatal consequences based on the purpose of the script. However, I dare to claim that checking levels by position is not that common and it is rarely used and when it is used it probably won't be anything crucial.
This could be mitigated if need be, to have the subsequent classes truncated to the 3rd. This would allow previously used functionality to determine levels to function properly, but I don't really see a need for it.
3) Even if your said ini option would prevent player to picking 4th class it would not prevent him to bring character with 4 classes already.
Once again, any player can bring whatever they want to a module. Such is the power of NWN. As a module creator, you can offer an experience, but there is nothing stopping the player from deviating from it.
Backward compatibility = it will work. And that it will. With faults, but it will work regardless. And if it happens that some module got broken with 4th class then it is player's responsibility just as if player would be using PRC in some random singleplayer module. Furthermore, community can apply a fix for such module that is not a problem. We already made fixes to some tilesets that were crashing on NWN:EE.
Agreed, I think NWN community is quite flexible in terms of changes. We've seen it with each expansion, and even the final addition of Purple Dragon Knight from the premium module.
I don't see why this couldn't be implemented, opening up options that have little to no consequence to those who don't wish to use them should not be frowned upon.
Ini file also applies for server, so you can certainly control a PW. As a module creator, you have no control over the player playing your module as they please. It's been like this since day one. Don't want me to play RDD? Too bad, I can open up the toolset and remove your scripts that target to ban this class. So it is, so it shall always be.
Yes but PWs doesn't need such ini setting as they can limit classes already and they always could have. So no need for such ini setting - the whole argument was single player module compatibility which as I shown cannot be guaranteed by such ini since we can assume 4th class would be enabled by such ini by default and module itself cannot controll ini settings.
I think dehardcoding the class number limit is fine, but the default should remain 3. It should be up to a module builder to increase that limit.
I think the Importance of backward compatibility is being neglected here. I've read comments that the GetLevelByPosition function is "rarely used anyway" so it's no big deal if scripts using it are broken by introducing the fourth class.
But breaking compatibility is the deadly sin we should avoid like a plague, even if only 0.01% of modules break by modifying or introducing something. And if each new feature causes incompatibility issues with some modules, then soon every tenth old module will be bugged when played in the NWN:EE. Hardly what we want to achieve.
So even if it seems like a tiny issue, any issue at all should put a stop to an idea that can cause it. Thus, unless a solution to this problem is found, a fourth class option should be implemented only for builders if it's implemented at all.
Coincidentally, my module utilizes this function in order to enforce the minimum number of levels in each class by level 40. Sure, I can update the module - but not every module is so lucky.
I think dehardcoding the class number limit is fine, but the default should remain 3. It should be up to a module builder to increase that limit.
I think the Importance of backward compatibility is being neglected here. I've read comments that the GetLevelByPosition function is "rarely used anyway" so it's no big deal if scripts using it are broken by introducing the fourth class.
But breaking compatibility is the deadly sin we should avoid like a plague, even if only 0.01% of modules break by modifying or introducing something. And if each new feature causes incompatibility issues with some modules, then soon every tenth old module will be bugged when played in the NWN:EE. Hardly what we want to achieve.
So even if it seems like a tiny issue, any issue at all should put a stop to an idea that can cause it. Thus, unless a solution to this problem is found, a fourth class option should be implemented only for builders if it's implemented at all.
Coincidentally, my module utilizes this function in order to enforce the minimum number of levels in each class by level 40. Sure, I can update the module - but not every module is so lucky.
Rather than 100% backward compatibility Beamdog could make it like for TES5EE: you need to open again the module and save it with the new toolset. Such softcoding would also pave the way for true divine feats and abilities.
The purpose of an .ini option (or similar) is backwards compatibility. As mentioned before, a lot of peoples' scripts are of the pattern:
int i = 1;
int char_class;
while (i <= 3){
char_class = GetClassByPosition(i, oPC);
...
i++;
}
Okay, but there are few flaws on this example.
1) This is crucial. What you need to understand is that the ini option is player's choice. You as a module creator have no controll whether the player will or will not have this said option set or not. And 99% players will want to play with 4 classes. So this would solve nothing, just pointless option. Only place where this option matters is multiplayer, but there are no problems with compatibility as everyone running persistent world should be updating their module to latest standards and therefore impose limit on number of classes using those two techniques I mentioned (if they don't like players to get 4). If they don't it is not BD fault.
An ini option specifically is what I'm thinking of for the single player campaigns (with a GUI option to set/unset it). Community modules should have some property they set themselves to opt-in for it.
Even given the above, you are correct that the player can always just go around the module creators intentions via the toolset (as Rifkin pointed out). As far as I'm concerned the second you start editing something your warranty is void.
2) If BD allows 4th. class, technically it won't break this script as you claim so. What happens is that the script will work incorrectly if the player has 4th class. This is no different to the script checking all vanilla classes and you playing with class from PRC. This might or might not have fatal consequences based on the purpose of the script. However, I dare to claim that checking levels by position is not that common and it is rarely used and when it is used it probably won't be anything crucial.
Like the last pseudocode example I posted, you have taken an illustration of a pattern to be a concrete example. This is not the case and was not intended to be the case. If we're talking in concrete examples, consider the following:
Imagine that there is a module that has a quest inside it. This quest is only accessible to characters with levels in the Fighter Class. This quest has 2 scripts associated with it; one to start the quest and one to finish it. The start quest script checks for levels in Fighter using GetLevelByClass(CLASS_FIGHTER, oPC). The second script uses GetClassByPosition (the hypothetical author copied and pasted examples off the internet without understanding them too deeply).
In such an example, if you had Fighter as your forth class, you could start the quest but not finish it. Yes, it's a contrived example and probably an example of very sloppy scripting but can you say, with absolute certainty, that there isn't a module somewhere that has something similar? Can you say with certainty that there aren't other edge cases where things break?
Also, in retort to the "no-one uses GetClassByPosition" argument, the PRC Compendium uses it extensively for all of its newspellbook systems to handle "progresses spell casting for your highest level arcane/divine class".
Backward compatibility = it will work. And that it will. With faults, but it will work regardless. And if it happens that some module got broken with 4th class then it is player's responsibility just as if player would be using PRC in some random singleplayer module. Furthermore, community can apply a fix for such module that is not a problem. We already made fixes to some tilesets that were crashing on NWN:EE.
I have two problems with this sentiment.
Firstly, comparing PRC to the core game isn't an applies to applies comparison. When you play a game you've paid money for you expect it to work. When you install a load of stuff, apply a load of patches to files and then have to muck about with a personal_switches.2da file you're very much in "some assembly required, use at your own risk, we are not responsible for voiding your warranty" territory.
Secondly, making everyone update their modules for the enhanced edition is just... not good. You potentially start running into problems of forwards compatibility (e.g. making a module that works on both the standard game and the EE) and potentially end up having to maintain two seperate versions of a module. Not ideal, really.
I think dehardcoding the class number limit is fine, but the default should remain 3. It should be up to a module builder to increase that limit.
I think the Importance of backward compatibility is being neglected here. I've read comments that the GetLevelByPosition function is "rarely used anyway" so it's no big deal if scripts using it are broken by introducing the fourth class.
But breaking compatibility is the deadly sin we should avoid like a plague, even if only 0.01% of modules break by modifying or introducing something. And if each new feature causes incompatibility issues with some modules, then soon every tenth old module will be bugged when played in the NWN:EE. Hardly what we want to achieve.
So even if it seems like a tiny issue, any issue at all should put a stop to an idea that can cause it. Thus, unless a solution to this problem is found, a fourth class option should be implemented only for builders if it's implemented at all.
Coincidentally, my module utilizes this function in order to enforce the minimum number of levels in each class by level 40. Sure, I can update the module - but not every module is so lucky.
Rather than 100% backward compatibility Beamdog could make it like for TES5EE: you need to open again the module and save it with the new toolset. Such softcoding would also pave the way for true divine feats and abilities.
It's not a bad idea that; just have some module property that let's the creator opt in for all extended edition features and script away anything they don't want. The only problem I see (and it's a minor one) is in the case of Beamdog adding more potentially backwards compatibility breaking features after releasing the game.
@Dark_Ansem - I agree, but I also think it's a false dichotomy. All you need to do is make new features opt-in at the module level and the backwards compatibility is almost free (depends on the feature, would definitely be in this case). Why break it if you don't need to?
The only way not to break anything would be not to change anything. I'd rather BD keep modifing the game and leave it up to the community to update the custom content.
An ini option specifically is what I'm thinking of for the single player campaigns (with a GUI option to set/unset it). Community modules should have some property they set themselves to opt-in for it.
Even given the above, you are correct that the player can always just go around the module creators intentions via the toolset (as Rifkin pointed out). As far as I'm concerned the second you start editing something your warranty is void.
Again, you don't understand that there is no such thing as "set ini option in module". You are a singleplayer module creator cannot set or change player's ini setting. Which makes such ini option absolutely worthless to begin with.
To be fair this is usual mistake. When developing community patch and nwnx_patch plugin, peoples wanted ini option for everything as they were used to that from other plugins such as nwnx_fixes. However, my plugin was special in it worked for client and you cannot control client's ini setting. The only way to do this would be using module switches.
I think dehardcoding the class number limit is fine, but the default should remain 3. It should be up to a module builder to increase that limit.
I disagree. If the ini option gets added, and I am strongly against it, the default value should be a value which will be used by majority and that is "on".
Comments
It should show the dependency between feature requests - other requests with this label cannot be done unless we do the full UI refactor first.
@Plok Your comment got caught in the spam filter, I've verified you, this shouldn't happen again (you can see your comment above).
scripts relying on GetLevelByPosition() will need to be rewritten to support additional classes.
but is that function even still useful? when we have functions like GetHitDice() or GetLevelByClass()?
Some servers even had systems to work around the limit by allowing you to get new feats and stuff from other classes but you never actually got any actual levels in those classes, but it was a pain to go through dialogues or whatever to level, would be so much nicer if the game just supported it.
just unhardcode the cap
same with max level cap, its a pain to use systems like https://neverwintervault.org/project/nwn1/script/higher-ground-legendary-level-system-levels-41-60-v21-hgll
so much better if it was just possible without such crazy workarounds.
Looking back I kinda prefect the terse version, even if it might be construed as me being rude to Shadooow. Just goes to show how much better your writing can be when you're not making it up as you go along and editing it like crazy.
The only other way I see to do ECL via script is to have a script constantly massage a player's EXP and separately keep track of it. While this approach would be correct (unlike my off the cuff idea), it doesn't feel neat at all. In fact, it strikes me as the kind of thing that would just randomly go wrong for no discernable reason.
@Plok Case in point with a customizable UI you can just feed the correct experience values to the character sheet. Either with LA as an engine coded value or with custom content scripting.
It would be only like a little cherry on top of the cake.
When adding ability for more classes best way to do so would be to add absurd/unlimited number of class slots. Due to nescessary ui reworks.
Therefore I do not see a problem with adding the ability to multi-class in to 4 classes. Simply allow servers to customize the limitation.
The more freedom, the better, I say, especially when you give that freedom to persistent world builders who can apply the restrictions they want, rather than be forced by a hardcoded game.
1) delevel after levelup something that you don't want player to have (feat, skill, spell, multiclass)
2) use cls_pres_*.2da and then variable to restrict access to classes after some condition is met (such as already has 2 classes)
The cls_pres_*.2da doesn't exist normally for base classes but can be added and was added in my unofficial patch.
We certainly don't need another *.ini option or something to enable/disable 4th class (if made). If BeamDog decide to add this functionality it should be turned on by default and those who think 4th class is unbalanced or a problem can use the already existing mechanics to restrict it. If anything then BeamDog could adopt mine cls_pres_*.2das for base classes and add them into core game resources.
int i = 1; int char_class; while (i <= 3){ char_class = GetClassByPosition(i, oPC); ... i++; }If someone adds a forth class to their character it would break scripts using this pattern. The purpose of an .ini setting is to make this feature opt-in rather than opt-out. If it's opt-in, then the assumption of 3 classes still holds true for old scripts.
Personally, I would think that having some property in the module would be the best way to do it from a community standpoint and maybe save the .ini switch for the single player Campaigns. This allows people to play the game as it was shipped or opt-in for quality of life improvements like this.
I'd also add a GUI for the single player switch in the options menu personally. Some sort of "enhancements" tab. Temple+ (an open source reimplementation of Temple of Elemental Evil) has a set of "House Rule" options for this kind of thing.
The point of an ini/module option (or similar) is to not break it in the first place. If the new behaviour is opt-in then the script still works because its assumption of a maximum of 3 classes is still correct (because the module it's in hasn't opted in for >3 classes). New modules - with scripts that won't break - can opt-in for >3 classes.
Just adding >3 classes without any form of opt-in is effectively opt-out and will break old scripts/modules.
Consider how you can break a script with the current version and then consider how you fix that.
A module designed for 3 classes would never check for the 4th class if a player chose to have one.
It would affect conversations, custom items and custom scripts. Otherwise it should work as intended as a game mechanic.
Just so you know where I'm coming from, my thinking on this is summarised by the following steps:
- Existing modules must continue to work without modification (which, according to the streams, is Beamdog's core policy)
- Adding >3 classes will break some modules.
- Ergo it must something that a module opts into once the appropriate changes are made to its scripts
- ????
- Profit (sorry, couldn't resist).
This is fundamentally the same problem as trying to change a web/network interface to a system - you don't know who's depending on it so you can't just change your interface/behaviour recklessly. The correct way to go in these circumstances is to leave the old behaviour as is and let people opt in for the new behaviour. Ideally you'd also deprecate and eventually remove the old behaviour, but that's not really practical here.Why yes! I am a programmer who's had to maintain poorly written HTTP/REST APIs, thankyou for asking.
1) This is crucial. What you need to understand is that the ini option is player's choice. You as a module creator have no controll whether the player will or will not have this said option set or not. And 99% players will want to play with 4 classes. So this would solve nothing, just pointless option. Only place where this option matters is multiplayer, but there are no problems with compatibility as everyone running persistent world should be updating their module to latest standards and therefore impose limit on number of classes using those two techniques I mentioned (if they don't like players to get 4). If they don't it is not BD fault.
2) If BD allows 4th. class, technically it won't break this script as you claim so. What happens is that the script will work incorrectly if the player has 4th class. This is no different to the script checking all vanilla classes and you playing with class from PRC. This might or might not have fatal consequences based on the purpose of the script. However, I dare to claim that checking levels by position is not that common and it is rarely used and when it is used it probably won't be anything crucial.
3) Even if your said ini option would prevent player to picking 4th class it would not prevent him to bring character with 4 classes already.
Backward compatibility = it will work. And that it will. With faults, but it will work regardless. And if it happens that some module got broken with 4th class then it is player's responsibility just as if player would be using PRC in some random singleplayer module. Furthermore, community can apply a fix for such module that is not a problem. We already made fixes to some tilesets that were crashing on NWN:EE.
I don't see why this couldn't be implemented, opening up options that have little to no consequence to those who don't wish to use them should not be frowned upon.
Yes but PWs doesn't need such ini setting as they can limit classes already and they always could have. So no need for such ini setting - the whole argument was single player module compatibility which as I shown cannot be guaranteed by such ini since we can assume 4th class would be enabled by such ini by default and module itself cannot controll ini settings.
I think the Importance of backward compatibility is being neglected here. I've read comments that the GetLevelByPosition function is "rarely used anyway" so it's no big deal if scripts using it are broken by introducing the fourth class.
But breaking compatibility is the deadly sin we should avoid like a plague, even if only 0.01% of modules break by modifying or introducing something. And if each new feature causes incompatibility issues with some modules, then soon every tenth old module will be bugged when played in the NWN:EE. Hardly what we want to achieve.
So even if it seems like a tiny issue, any issue at all should put a stop to an idea that can cause it. Thus, unless a solution to this problem is found, a fourth class option should be implemented only for builders if it's implemented at all.
Coincidentally, my module utilizes this function in order to enforce the minimum number of levels in each class by level 40. Sure, I can update the module - but not every module is so lucky.
Even given the above, you are correct that the player can always just go around the module creators intentions via the toolset (as Rifkin pointed out). As far as I'm concerned the second you start editing something your warranty is void. Like the last pseudocode example I posted, you have taken an illustration of a pattern to be a concrete example. This is not the case and was not intended to be the case. If we're talking in concrete examples, consider the following:
Imagine that there is a module that has a quest inside it. This quest is only accessible to characters with levels in the Fighter Class. This quest has 2 scripts associated with it; one to start the quest and one to finish it. The start quest script checks for levels in Fighter using GetLevelByClass(CLASS_FIGHTER, oPC). The second script uses GetClassByPosition (the hypothetical author copied and pasted examples off the internet without understanding them too deeply).
In such an example, if you had Fighter as your forth class, you could start the quest but not finish it. Yes, it's a contrived example and probably an example of very sloppy scripting but can you say, with absolute certainty, that there isn't a module somewhere that has something similar? Can you say with certainty that there aren't other edge cases where things break?
Also, in retort to the "no-one uses GetClassByPosition" argument, the PRC Compendium uses it extensively for all of its newspellbook systems to handle "progresses spell casting for your highest level arcane/divine class". Surely if we have either an ini option or some module option (or whatever), the NWN client can just go "nope" when you try and load the character. I have two problems with this sentiment.
Firstly, comparing PRC to the core game isn't an applies to applies comparison. When you play a game you've paid money for you expect it to work. When you install a load of stuff, apply a load of patches to files and then have to muck about with a personal_switches.2da file you're very much in "some assembly required, use at your own risk, we are not responsible for voiding your warranty" territory.
Secondly, making everyone update their modules for the enhanced edition is just... not good. You potentially start running into problems of forwards compatibility (e.g. making a module that works on both the standard game and the EE) and potentially end up having to maintain two seperate versions of a module. Not ideal, really. It's not a bad idea that; just have some module property that let's the creator opt in for all extended edition features and script away anything they don't want. The only problem I see (and it's a minor one) is in the case of Beamdog adding more potentially backwards compatibility breaking features after releasing the game.
If you have 3/4/4/4
GetLevelByPosition(3, oPC) returns 8
To be fair this is usual mistake. When developing community patch and nwnx_patch plugin, peoples wanted ini option for everything as they were used to that from other plugins such as nwnx_fixes. However, my plugin was special in it worked for client and you cannot control client's ini setting. The only way to do this would be using module switches. I disagree. If the ini option gets added, and I am strongly against it, the default value should be a value which will be used by majority and that is "on".