Builds that combine 8 classes

Posted virtually the same thing on reddit also but I’d like to hear some opinions from builders here.

What is the purpose of this? Is this something the community asked for? I don’t play PW so maybe it’s something PW players wanted?

For SP modules, I think it would exponentially increase the play testing that would be needed to balance combat. I just don’t see any reason to do this. Also, yes, you can do such things in pnp but the vast majority of players don’t and it’s a videogame, not everything in pnp translates well.

Do any builders have any plans to make use of all 8 classes either for PCs or enemies?

What do you mean balance, this is not enabled by default, and if you are playing SP modules it wont be enabled unless you specifically edit ruleset.2da and then dump it in override/development folder.

It also ruins balance that you can go DM mode and insta kill any enemy, which is also something that needs enabling like multi classing more than 3

Players always wanted to multiclass more than 3 classes. Some builders might have asked for this too.

I suppose that the .35 patch team decided that to allow as many as the engine can eventually handle so it won’t happen that someone will ask for more. Ie. if they just allowed 4 classes, then there will be still players/builders asking for more. So I guess that is why.

There are some prestige classes that really loses a lot without the 4th class. But more than 4 classes is an overkill imo.

If you allow it, it will just lead to builds that are abusing every class with free feat or strong ability at first levels like monk for AC, paladin for saves, fighter/wizard/ranger (taken at epic) for extra bonus feat, 8-10 rdd, 7wm, SD for HIPS etc.

Yes it is disabled. And in SP it will stay disabled because players generally won’t know about this and a module cannot override player settings.

In multiplayer however, I have a hunch that some PWs going to allow all 8 and then players will go there. This will then change a “meta” where every other server will have to allow more than 3 in order not to lose players…

I understand its not enabled by default, just curious how/if it will be used by any builders.

Unlike what Shadooow says I strongly suspect any PW will be either sticking with 3 classes or slowly extending past that (it’s reasonably easy to lock the client to 3 classes and allow only particular ones for a 4th, 5th etc.)

For singleplayer depends on the project, no doubt PRC will be looking at the option even if they don’t enable it by default, and my own project will probably enable it since SP “balance” as noted is a bit of a meme, and it’s not like players have to use it (and if they wanted to they can just enable it anyway). Main thing with > 3 classes is fixing any scripts that assume the player can only have 3 classes. That’s the gotcha bit.

Some time ago I played the Swordflight series with 8 classes enabled. I ended up with a Rogue(13)/Monk(9)/Fighter(8)/WM(7)/Shadowdancer(1)/Ranger(1) (and yes, the ranger at level 40 was for the bonus feat only :D). Haven’t player the series with three classes only but I don’t think it would have been much of a difference.

Well, the difference would be that you’d be using a character that the combat is balanced against.

As far as SP balance, what I mean is that an 8 class character(built correctly even if not optimally) will be very powerful and any existing modules wouldn’t be much of a challenge in terms of combat though I assume players that would use the option want faceroll combat anyways.

I doubt the author of swordflight has tested with every possible 3 classes build.
Have you made a 8 class character? How do you know it would be very poweful? The number of levels does not change (actually might be less because of multiclass XP penalty).

Rogueknight333 can speak for himself but as far as I know, the module was thoroughly play tested to be a doable challenge for all builds. That doesn’t necessarily entail playing every possible 3 class combination but the module was play tested with a variety of builds.

How do I know it would be very powerful? Its common sense to anyone that understands the basics of multiclassing.

You also could have 8 classes without taking an xp penalty. As far as I know, the rules on mutli class xp penalties would be the same as when you have 3 classes.

I’d be interested to read the thoughts of any experienced player/builder as to how a character with 8 classes would be equal in power to a character with 3 outside of coming up with a terrible build.

If a player enables it and somehow that makes it super easy (as others have mentioned this is not always the case), they could equally just use a level 40 character to faceroll anything in a module.

I really think you’re worrying too much over nothing here.

Out of interest, is that correct?

Normally, a 2da file in a module hak trumps anything the player does (except development folder).

Is ruleset.2da different? I ask because, after reporting a line numbering error, I understand that it actually works more like a .ini file than a 2da.

I’m not worried at all, wondering what the purpose of it is. Judging from the responses, there’s not much utility to it until someone makes a module with 8 classes in mind.

Also, are you saying that an 8 class character that’s built even half way decently wouldn’t be absurdly powerful?

I don’t care how other people play, it just seems like this is an RP thing. As it stands, there’s no legitimate challenge for an 8 class build.

… This is sounding like an excuse for someone to find a way to get the Neutronium Golem all statted out

1 Like

Ah okay, I don’t have .35 installed so I just incorrectly assumed it will be implemented in settings.tml like many of the new functionalities like party control.

If it is 2DA based, then module should be able to enable this functionality.

Psst, from .35 patch notes:

  • Modules may now specify party control mode that takes precedence over server settings.
    • No GUI option yet, but you can set "Mod_PartyControl" INT in module.ifo: 0=Server default, 1=enabled, 2=disabled.

Great, didn’t notice that. That was definitely a huge downside of this feature till now.

Prepared more pathfinding issue repro modules.

pathfinding4.zip (10.0 KB) - 2 issues can be reproduced here
#1 - click on goblin, notice that the character will first run into niche in wall before running to him, additionally compared to 1.69 if that character has ranged weapon he will stop right there with error message “Unable to reach target!”. This does not happen in 1.69, but maybe this is intented, the pathfinding for ranged weapon users sucks completely (which is something I expected to be improved by that pathfinding improvement, but nope…). Anyway, this issue happens from more angles and spots, the one I chosen is probably not that “wrong”, so try to move closer to goblins, the same happens, character will go backwards into that niche in wall first. This is a regression - it does not happen in vanilla.
#2 - click on door from the starting point. Character will go all around the area in twice as long path. This is also a regression.
pathfinding5.zip (8.2 KB) - This is related to issue #2 in previous module. Load the module, click on the flag placeable WAYPOINT 1, then click on doors. You might ask what is wrong there so I will explain. The path chosen is probably just as long or maybe even shorter than the path backwards. However, player did not explore the room via which this path leads to and does not know if it is walkable. Game obviously knows so it will allow player to go there, but in my opinion this is not a correct behavior. This is not regression, happens in vanilla as well.

this requires DOA Rural City Base tileset which is included in zip. Load the module, click on the anvil. Character will run into building and get stuck there. I tested this in vanilla and sadly this is not a new issue it happens in vanilla as well. Maybe it is even tileset related, but pathnode and aabb looks fine to me hard to say.

FYI, pretty much all pathfinding improvements were performance improvements, making it do the same thing much faster. But pathfinding has a maximum time it will spend on finding a path before returning the best option, so now because it works faster it will try more options and sometimes find a better one. Also what often happens is that in 1.69 it will fail to find any path in the time allocated and then just give up and do nothing. In EE, because it’s faster, it will find some insane super long and convoluted path and start going there. You could argue that if a path if too insane it’s better to give up than to go that way, but “too insane” is not something you can really properly define in code.

…I think we can stop derailing this thread… :slight_smile: feel free to make a new one or just reach out in PMs.