Severe class restrictions in a module

So in building my module one side quest gave me the idea for an intriguing setting and I am about to scrap the whole thing and start over (we have all been there at least once, haven’t we?).

The only problem is, that for gameplay and story reasons the player shouldn’t play spellcaster and that would include not only the usual suspects but even paladins and rangers .

Essentially only fighter, rogue, barbarian and monk would be left with the later two not making much sense so fighter/rogue it would be from start to end. Which perfectly matches the setting of a no-magic steampunk medieval world and also would make an equipment/trade/alchemy heavy gameplay enjoyable - but I am not sure if players will
a) outright dismiss the module because of that
b) play along nicely
Regarding a) the module is not supposed to be a crowdpleaser anyway because of difficulty, extensive story and conversations and reagarding b) I can put scripts in place that simply kill the PC as soon as any other classes are decteted after level up but I don’t think that would go down well on the average players who just love their personal class combo. On the other hand even a single cleric or wizard level can kill the game gameplay wise (turning undead/summoning/healing) or storywise (spells/gods) and would make the whole module pointless.

Myself, I have of course played “A Dance with Rogues” and had no issue with the restrictions but that’s just me.

Any thoughts?

Sometimes I would actually seek out modules specifically made for certain classes, so all this sounds cool to me. You just got to know your intended audience and stick to that.


If I were to go down this route I would provide 2 pre-made 1st level characters (1 male & 1 female) and strongly suggest to players that they select one or the other as the module won’t run otherwise. If the necessary level to play is higher than 1st then that is an advantage for the player as long as you provide a level up mechanism. That way the player still has control of the actual build.



Good advice.

However the main problem is to prevent the player in adding caster levels on level up after the module has started. Best solution would be a script in OnPlayerLevelUp that only leaves rogue & fighter as an option but so far I haven’t found one and I don’t think I can pull off that one myself.

Creating a giant trigger in every area that kills the PC OnEnter if class levels beside fighter/rogue are detected would solve the problem but that is literally a “nuclear option”.

EDIT: Unfortunately OnPlayerLevelUp triggers AFTER the process is finished so the only thing I could come up with thge idea of a script that uses GetPCLevellingUp and GetLevelByClass to check for anyting beyond fighter/rogue then use GetXP, SetXP, floating text string “Choices not valid, please choose fighter or rogue level” and GiveXPToCreature to reimburse the PC. Rince repeat for the stubborn ones :joy:

1 Like

There is always the “witchfinder” option coupled with the “torches & pitchforks mob” :japanese_ogre:



You can edit classes.2da and set the PlayerClass column for the caster classes to 0, then put classes.2da in your hak.

Personally I wouldn’t try too hard to prevent cheats for SP modules as there is always Debug Mode and the Toolset. If your module gets popular enough there will be people wanting to play it with PRC and such anyway.


Since I use ProjectQ I realized that adding any haks means I had to merge them with ProjectQ and that is something I’d rather avoid.

But…thanks to the feedback so far I found, that could just make the module VERY HARD if players insist on taking caster levels (most factions hostile, sparse loot for casters, regular resting restrictions making it worse, etc. ). Telling the players beforehand, that they can play their usual caster- killer-combo if they are willing to endure the gameplay changes might be the right way.

After all I have to agree, those who want to cheat… will cheat.


q_2da.hak doesn’t have its own copy of classes.2da so there is nothing to merge. :slight_smile:

1 Like

Thanks a lot for the info!

What about items with casting capabilities?

There will be no such items and also no scrolls or wands but “magic” items which get their power from the incorporation of some “strange material” p.e.:

  • Jewelery that emits light
  • Armor with protective abilities
  • Weapons with extra damage
    and to give it a little extra twist those items will also have disadvantages. The background has a kind of “All magic comes with a price” vibe :smirk:

And in addition lots of alchemy-based items like potions, grenades, poisoned ammunition etc.

Loot will never be randomly generated of course.

1 Like

You could use the spell hook to block all spells.

1 Like

What about something like this added to your on enter (module, or the first area)?

void main()
object oPC = GetEnteringObject();
effect eFail;

//Only fire for real PCs.
if ( !GetIsPC(oPC)  ||  GetIsDMPossessed(oPC) )

eFail = EffectSpellFailure(100);

//Apply the spell failure effect to the PC.
ApplyEffectToObject(DURATION_TYPE_PERMANENT, eFail, oPC);


You know Black powder has been around on this world for almost two thousand years. Poison has been used for at least three thousand years. Grenades have been around for thousands of years. Greek Fire, poison darts, daggers, arrows. Assassins have been using these items for a very long time. These do not have to be magical, they can be made thru chemistry or alchemy. It depends on ones prospective. I’m not suggesting you use these just giving you something to think about.

I have no problem with class restrictions either if it looks good I will give it a go. I also will rate it accordingly. Make the module to please you first the rest of us will like it or not, but if there is a good story you can’t go wrong in my opinion. Good Luck with your module.:grinning:

The restriction for base classes can be scripted however it would require community patch, in vanilla you can disable prestige classes by scripting but not base classes.

And I suppose you want to make it work regardless player has community patch or not in which case modifying classes.2da and putting it into custom hak on top is the way to go.

I have thought creating a classes.2da hak and I asked myself if I still could create caster NPCs in the toolset.

Because I will need those for several enemy types.

Set the “PlayerClass” column value to “0” rather than “Spellcaster”. In this way, players cannot take the class upon creation or level-up but you can make as many NPCs in the toolset as you wish.

And Project Q uses a custom classes.2da because of the added “plant” class. So just take a copy of the classes.2da from Project Q, change the “PlayerClass” value to “0” for the classes you don’t want, save it in a top hak and presto! Problem solved.

I might dismiss it outright because of restrictions like that.

My perspective is that this is D&D and I associate that with a lot of (but not total) freedom of choice when creating characters.

I might also play it. I’d need a description with some good justification of why your world bars access to 85%~ of the classes normally available.

Sometimes a lack of options is a good thing.

You can also use the Use Magic Device script to see if the PC is casting a spell. This is how the Trickster/Rabaut Spell Component system works. At the front end of the UMD script “x2_pc_umdcheck”, there are these lines:

object oItem = GetSpellCastItem();
object oCaster = OBJECT_SELF;
int nSpellID = GetSpellId();

Right here you can add:
if (!GetIsObjectValid(oItem))//if the PC didn’t use a magic device, then they cast the spell
if(GetIsPC(oCaster))//get if they are a PC
// is a DM? Spell work
return TRUE;//DM’s can cast
else return FALSE://Everyone else fails

That will make spellcasters unable to cast spells

As for limiting classes, I use a trainer system which requires the PC to train with an NPC or appropriate device before successfully leveling up. In this way I can limit which classes PCs can advance in.
However, I imagine you could script a way to check what classes the PC is leveling in and if not acceptable, remove the leveling by resetting the XP and returning it. When I get a chance at the tool set, I will see what is available by scripting.