Skip to content

The Add the ability to have a fourth class card discussion

12346»

Comments

  • ShadooowShadooow Member Posts: 402
    Rifkin said:

    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

    That is elegant solution that would fix any potentional issues. +1
  • FreshLemonBunFreshLemonBun Member Posts: 909
    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.
  • jameskerjamesker Member Posts: 99
    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
  • Dark_AnsemDark_Ansem Member Posts: 992
    jamesker said:

    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.
  • DurendalDurendal Member Posts: 32
    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.
  • Dark_AnsemDark_Ansem Member Posts: 992
    Durendal said:

    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.

    You didn't mean "terribly imbalanced", did you?
  • Taro94Taro94 Member Posts: 125
    Shadooow said:

    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.
  • RifkinRifkin Member Posts: 141
    Taro94 said:

    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.
    Shadooow
  • PlokPlok Member Posts: 106
    edited February 2018
    Shadooow said:

    Plok said:

    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.
    Rifkin said:

    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:

    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.
    Post edited by Plok on
    Taro94
  • SynnBlackdaggerSynnBlackdagger Member Posts: 1
    I just pre-ordered so I wanted to say something. YEAH!
    3 classes please.
    HunterRayder93
  • robomagonrobomagon Member Posts: 1
    I think this is pretty important. With 40 levels to work with, I always seem to be one class short when thinking up new builds to try.
    Proontildaron
  • ShadooowShadooow Member Posts: 402
    Plok said:

    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.
    Proontildaron
  • PlokPlok Member Posts: 106
    edited February 2018
    Shadooow said:

    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?

    Umm....
    Plok said:

    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.
    Shadooow said:

    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.
    Shadooow said:

    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;
    1. 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.
    2. 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.
    Proont
  • RifleLeroyRifleLeroy Member Posts: 77

    robomagon said:

    I think this is pretty important. With 40 levels to work with, I always seem to be one class short when thinking up new builds to try.

    which means we also need a higher level cap.
    couldn't agree more.
    We also need gui support for post 40 level up.
    DerpCityProontMizzajl
  • UndeadWizardUndeadWizard Member Posts: 9
    Would you please add the ability to have four or more classes? Would be awesome with the NWN PRC.

    Thank you.
    ProontRifleLeroyMizzajl
  • Dark_AnsemDark_Ansem Member Posts: 992

    robomagon said:

    I think this is pretty important. With 40 levels to work with, I always seem to be one class short when thinking up new builds to try.

    which means we also need a higher level cap.
    couldn't agree more.
    We also need gui support for post 40 level up.
    A flexible GUI means fixing this.
    ProontMizzajl
  • Dark_AnsemDark_Ansem Member Posts: 992
    @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"?
    Mizzajl
  • MizzajlMizzajl Member Posts: 35
    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!
    ProontKymus
  • Dark_AnsemDark_Ansem Member Posts: 992
    Mizzajl said:

    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.
    Proontildaron
  • Dark_AnsemDark_Ansem Member Posts: 992
    So apparently this Trello card has been moved to the "icebox". What does this mean?
  • JuliusBorisovJuliusBorisov Member, Administrator, Moderator, Developer Posts: 22,714
    edited March 2018
    From here:

    "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.
    dunahanKymus
This discussion has been closed.