You could also expand the arguments for GetLevelByPosition as int GetLevelByPosition(int nClass, object oPC, int nLimit = 3) so it only truncates if classes are over the limit.
I'd honestly like to see the game improved in some way other than just shadows, interface etc, cosmetic. EIther 4 classes, or new classes, or sub races, following icewind dale 2s 3.0 sub race system would be fine. Yes allowing modders to exceed The class limit etc is a option, but I would prefer it to be official through beamdog as it just feels uncannon and like im cheating through.mods
I'd honestly like to see the game improved in some way other than just shadows, interface etc, cosmetic. EIther 4 classes, or new classes, or sub races, following icewind dale 2s 3.0 sub race system would be fine. Yes allowing modders to exceed The class limit etc is a option, but I would prefer it to be official through beamdog as it just feels uncannon and like im cheating through.mods
That's entirely your warped perception. Then again, BD could release extra premium modules with higher level cap, more classes etc.
NWN is a terribly balanced game and I don't believe that giving players more options will change that much. As others have said, it's primarily martials that get the most out of multiclassing, and they need all the help they can get in 3.PF. There's also the fact that a lot of servers already change how classes work, so a change to the core game doesn't effect them as much anyway.
NWN is a terribly balanced game and I don't believe that giving players more options will change that much. As others have said, it's primarily martials that get the most out of multiclassing, and they need all the help they can get in 3.PF. There's also the fact that a lot of servers already change how classes work, so a change to the core game doesn't effect them as much anyway.
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".
You've misunderstood me. I do not want the INI option to be added, because I want the class limit to be increasable only by module builders, in order to provide the highest level of backward compatibility.
In case of an INI option, I still would prefer it to be 3 by default, because backward compatibility should be the default option before new features. This way players could turn it on at their own risk of potentially bugging any old modules.
Nevertheless, whether it's 3 or 4 by default is not that important.
You've misunderstood me. I do not want the INI option to be added, because I want the class limit to be increasable only by module builders, in order to provide the highest level of backward compatibility.
NWN has survived many "backward's compatibility" breaking. The expansions, Purple Dragon Knight, the removal of Sap, etc.
Many modules don't have any special considerations for Purple Dragon Knight, but does that really bring a large concern?
I honestly am not sure why you think putting the setting on the module makes it a better change. I would be interested to hear your reasoning, but somehow I imagine it is because you wish to determine how the player will utilize your module. Of course, you must consider that if a player wants to use 4 classes, they will circumvent your attempts to prevent them from doing so.
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.
No, I really do understand. An ini option is a global setting and would apply to all modules. What I am suggesting is a setting local to each module. The ini option/menu option is only for the single player campaigns (e.g: HOTU,SOU and the original campaign) - a "I would like to play the game as it was originally released" option.
My suggestion is that modules have some metadata property that says "I support EE feature X" (in this case >3 classes). This makes any change from the standard edition opt-in. Any module that doesn't have this metadata is assumed to have opted out. This helps with backwards compatibility because the assumptions the modules make is still true.
Obviously if there is a concern for breaking concern, making it truncate the extra classes would alleviate that.
If you have 3/4/4/4
GetLevelByPosition(3, oPC) returns 8
I think this is even worse than just flat out ignoring backwards compatibility concerns. It doesn't fix the example I raised above (1 quest with 2 scripts, 1 checks for 4th class using GetLevelByClass, other uses GetLevelByPosition, quest is broken). It actually breaks GetLevelByPosition even more.
Here's an example where it would break. Assume you have a series of scripts to make a prestige class like Daggerspell Shaper. Daggerspell Shaper is a class that advances Sneak Attack and Wildshape. It requires 1d6 Sneak Attack, Wildshape, Two Weapon Fighting, Weapon Focus Dagger and some skill points to enter.
Let's also assume that the scripts use GetClassByPosition to handle Sneak Attack and Wildshape advancement. Two issues crop up with the following build:
Firstly, as far as the scripts which advance class features are concerned, there are 14 levels of Daggerspell Shaper. This is problematic because Daggerspell shaper is a prestige class and you're only allowed 10 levels pre-epic. You could easily abuse this with classes that have a class feature with DC that scales by class level (e.g. Assassin's Death Attack).
The second issue is a bit more insidious. If Turn Undead progression is handled via GetLevelByClass (or is hard coded) then you've effectively got Cleric levels advancing Sneak Attack, Wild Shape AND Turn Undead. It's basically a repeat of the Alertness Theurge bug in NWN 2.
--EDIT--
For reference, the Theurge Bug in NWN 2 was where a prestige class that advanced spellcasting could be coerced into advancing 1 class it is able to advance and 1-2 classes it could not.
It happened because prestige class spell casting advancement was implemented in engine with a special 2da file that would map classes to a feat. On the first level of a prestige class you would pick one of several of these feats to define which spellcasting class you would advance.
However, the 2da files had "I cannot advance this class" set as 0 instead of ****. Feat ID 0 is Alertness. Whoops.
I might be misremembering - I remember Spirit Shaman being heavily used so it could have only applied to Spirit Shaman because the above happened when it was added in Mask of the Betrayer, but that's basically how it worked.
No, I really do understand. An ini option is a global setting and would apply to all modules. What I am suggesting is a setting local to each module. The ini option/menu option is only for the single player campaigns (e.g: HOTU,SOU and the original campaign) - a "I would like to play the game as it was originally released" option.
My suggestion is that modules have some metadata property that says "I support EE feature X" (in this case >3 classes). This makes any change from the standard edition opt-in. Any module that doesn't have this metadata is assumed to have opted out. This helps with backwards compatibility because the assumptions the modules make is still true.
It is a nice idea, but such mechanism will require to update older mods. And because we can't expect that happens is why you guys require backwards compatibility right?
But I guess it could be done another way though. Any module saved in EE thus having the version 1.74 would then get the extra features and modules saved with lower version not.
Still, such system would be a lot of work for almost no benefits. I agree with @Rifkin on this matter. The backwards compatibility is important, but these are minor issues that can easily be solved by community. Several tilesets and few modules were already updated to work properly with EE. If such feature breaks another module we can update it and repost on vault.
It is a nice idea, but such mechanism will require to update older mods. And because we can't expect that happens is why you guys require backwards compatibility right?
Any module that doesn't have this metadata is assumed to have opted out.
That sentence is there specifically to deal with older mods that haven't been updated. Module doesn't have the setting we added in EE? Must be an old mod - don't enable EE feature.
But I guess it could be done another way though. Any module saved in EE thus having the version 1.74 would then get the extra features and modules saved with lower version not.
I considered this idea before settling on having a switch in the module for it. The downside I saw with it would be that it would create more work for people who are just making tiny changes in their modules (like bugfixing etc.).
If someone edits their module in EE, they'd suddenly need to add a bunch of scripts to turn off EE features that might be counter to their intended vision/balance (like >3 classes). We shouldn't needlessly punish people for using the EE module builder. If they have to opt-in for these features they don't need to do anything and the module still works like before.
I agree with @Rifkin on this matter. The backwards compatibility is important, but these are minor issues that can easily be solved by community.
This may come as a surprise based on my earlier comments, but I'm actually in favour of breaking backwards compatibility in exchange for new goodies. However, I stress the issue for two reasons;
Beamdog have stated that they are vehemently against breaking backwards compatibility if they can possibly avoid it. To me, this statement implies that they are more likely to implement any approach that doesn't break backwards compatibility that one that does.
I'm a computer programmer who has spent most of his working life maintaining systems that are never, in any circumstances, allowed to break other peoples' code. Every solution I think up, every piece of code I write is always tempered with the thoughts: "What will this break?", "What can I do to prevent that?" and "How much of a pain will this be to change in future?".
It's my opinion that with a conceptually very simple guard - making features opt-in - backwards compatibility can be maintained AND you get the new features.
I honestly think it's a good approach for not just for maintaining compatibility with classic NWN modules, but with modules made in older EE releases as well. Potentially breaking changes aren't all going to come at once, they'll be introduced piecemeal. Every time a potentially breaking change is made Beamdog are probably going to get false bug reports that are some variation of "my module makes an assumption that isn't true anymore and now it's broken". Guarding these changes behind an opt-in switch means they don't get those false bug reports.
@JuliusBorisov I assume there is enough now in this card to move it from "needs further discussion"? Perhaps change title to "more classes and higher level cap"?
I am one of the developers for the Salvation server, when we get the ability to make custom classes (when HAK's can be downloaded automaticly in game) we would like to make some custom prestige classes that you can only take like 3-5 levels in. but with only 3 class slots that would be very limited.
but if we could change the class slot limit we would be able to create a lot of interesting build options!
I am one of the developers for the Salvation server, when we get the ability to make custom classes (when HAK's can be downloaded automaticly in game) we would like to make some custom prestige classes that you can only take like 3-5 levels in. but with only 3 class slots that would be very limited.
but if we could change the class slot limit we would be able to create a lot of interesting build options!
Ah yes, I'm all for a flexible gui and a higher level cap. Let's see if BD is the same.
Comments
Yes allowing modders to exceed
The class limit etc is a option, but I would prefer it to be official through beamdog as it just feels uncannon and like im cheating through.mods
Then again, BD could release extra premium modules with higher level cap, more classes etc.
In case of an INI option, I still would prefer it to be 3 by default, because backward compatibility should be the default option before new features. This way players could turn it on at their own risk of potentially bugging any old modules.
Nevertheless, whether it's 3 or 4 by default is not that important.
Many modules don't have any special considerations for Purple Dragon Knight, but does that really bring a large concern?
I honestly am not sure why you think putting the setting on the module makes it a better change. I would be interested to hear your reasoning, but somehow I imagine it is because you wish to determine how the player will utilize your module. Of course, you must consider that if a player wants to use 4 classes, they will circumvent your attempts to prevent them from doing so.
My suggestion is that modules have some metadata property that says "I support EE feature X" (in this case >3 classes). This makes any change from the standard edition opt-in. Any module that doesn't have this metadata is assumed to have opted out. This helps with backwards compatibility because the assumptions the modules make is still true. I think this is even worse than just flat out ignoring backwards compatibility concerns. It doesn't fix the example I raised above (1 quest with 2 scripts, 1 checks for 4th class using GetLevelByClass, other uses GetLevelByPosition, quest is broken). It actually breaks GetLevelByPosition even more.
Here's an example where it would break. Assume you have a series of scripts to make a prestige class like Daggerspell Shaper. Daggerspell Shaper is a class that advances Sneak Attack and Wildshape. It requires 1d6 Sneak Attack, Wildshape, Two Weapon Fighting, Weapon Focus Dagger and some skill points to enter.
Let's also assume that the scripts use GetClassByPosition to handle Sneak Attack and Wildshape advancement. Two issues crop up with the following build:
Druid - 5
Rogue - 1
Daggerspell Shaper - 1
Cleric 13
Firstly, as far as the scripts which advance class features are concerned, there are 14 levels of Daggerspell Shaper. This is problematic because Daggerspell shaper is a prestige class and you're only allowed 10 levels pre-epic. You could easily abuse this with classes that have a class feature with DC that scales by class level (e.g. Assassin's Death Attack).
The second issue is a bit more insidious. If Turn Undead progression is handled via GetLevelByClass (or is hard coded) then you've effectively got Cleric levels advancing Sneak Attack, Wild Shape AND Turn Undead. It's basically a repeat of the Alertness Theurge bug in NWN 2.
--EDIT--
For reference, the Theurge Bug in NWN 2 was where a prestige class that advanced spellcasting could be coerced into advancing 1 class it is able to advance and 1-2 classes it could not.
It happened because prestige class spell casting advancement was implemented in engine with a special 2da file that would map classes to a feat. On the first level of a prestige class you would pick one of several of these feats to define which spellcasting class you would advance.
However, the 2da files had "I cannot advance this class" set as 0 instead of ****. Feat ID 0 is Alertness. Whoops.
I might be misremembering - I remember Spirit Shaman being heavily used so it could have only applied to Spirit Shaman because the above happened when it was added in Mask of the Betrayer, but that's basically how it worked.
3 classes please.
It is a nice idea, but such mechanism will require to update older mods. And because we can't expect that happens is why you guys require backwards compatibility right?
But I guess it could be done another way though. Any module saved in EE thus having the version 1.74 would then get the extra features and modules saved with lower version not.
Still, such system would be a lot of work for almost no benefits. I agree with @Rifkin on this matter. The backwards compatibility is important, but these are minor issues that can easily be solved by community. Several tilesets and few modules were already updated to work properly with EE. If such feature breaks another module we can update it and repost on vault.
If someone edits their module in EE, they'd suddenly need to add a bunch of scripts to turn off EE features that might be counter to their intended vision/balance (like >3 classes). We shouldn't needlessly punish people for using the EE module builder. If they have to opt-in for these features they don't need to do anything and the module still works like before. This may come as a surprise based on my earlier comments, but I'm actually in favour of breaking backwards compatibility in exchange for new goodies. However, I stress the issue for two reasons;
- Beamdog have stated that they are vehemently against breaking backwards compatibility if they can possibly avoid it. To me, this statement implies that they are more likely to implement any approach that doesn't break backwards compatibility that one that does.
- I'm a computer programmer who has spent most of his working life maintaining systems that are never, in any circumstances, allowed to break other peoples' code. Every solution I think up, every piece of code I write is always tempered with the thoughts: "What will this break?", "What can I do to prevent that?" and "How much of a pain will this be to change in future?".
It's my opinion that with a conceptually very simple guard - making features opt-in - backwards compatibility can be maintained AND you get the new features.I honestly think it's a good approach for not just for maintaining compatibility with classic NWN modules, but with modules made in older EE releases as well. Potentially breaking changes aren't all going to come at once, they'll be introduced piecemeal. Every time a potentially breaking change is made Beamdog are probably going to get false bug reports that are some variation of "my module makes an assumption that isn't true anymore and now it's broken". Guarding these changes behind an opt-in switch means they don't get those false bug reports.
We also need gui support for post 40 level up.
Thank you.
but if we could change the class slot limit we would be able to create a lot of interesting build options!
"Icebox List
Cards in the Icebox list are features we've investigated and want to tackle but they are not the highest priority yet."
Anyway, if you questions about this feature request, feel free to ask them during a livestream(s).
Closing the thread for now. Thanks for the feedback, everyone! It is very valuable for the team.