Where exactly is the Party Size setting found using the toolset?

Jidokwon

The terribly bad AI bot has been telling me that it should be found in the module properties. I'm not seeing anything at all relating to the party found in the module settings. This is with the toolset found in NWNEE's current state and for any modules that I've attempted to edit. The AI bot also claims that two console commands should add companions to my party: AddToParty and dm_moveto NPC tag. The AddToParty and dm_moveto commands don't appear to exist on my end. Any assistance would be greatly appreciated.

Edit: Using an AI tool to search for anything relating to NWNEE most definitely wasn't my brightest idea. Now I'm seeing that there should be Campaign Settings and Game Settings that are found using the toolset. These certainly don't exist with the very basic Aurora Toolset that came packaged with my install here. Might there be a completely different and highly upgraded toolset that is specifically for developers? Or might there be a more appropriate place to find answers relating towards the NWNEE Aurora Toolset?

Melkior

Never rely on an AI tool. More often than not, it will mess things up.

So far as I am aware, there has never been a party size setting on any version of NWN, so whoever or whatever told you that is giving you completely false information. It may be that it's mistaking the setting which determines the maximum number of players who can join a server for a party size setting, but that server setting only determines the maximum party size indirectly, effectively making it be the number of players who can join the server at one time.

The scripting commands AddToParty and RemoveFromParty exist but they're not intended to be used to control party size. So far as I am aware, no scripting is triggered by someone joining or leaving a party, so there is no way to force a person to leave a party when it grows beyond a certain size.

Generally, module makers cope with large party sizes by either using encounters with differing CR creatures and allowing the encounter to determine what to spawn in, or by using custom OnSpawn scripting for the monsters which are created by the encounter so that the originals will create copies of themselves to help balance the encounter for a larger than expected party size.

Doing it the latter way requires some way of preventing the copies from attempting to spawn in more copies, which would attempt to spawn in even more copies and so on until the server crashes. One reliable method I've seen for preventing the problem is to spawn in the copies with the new tag of "COPY" so that the OnSpawn script can check for that and skip creating more copies.

Jidokwon

Thank you. So, just to be clear, it won't be something as simple and convenient as going to the module properties/event/OnModuleLoad, then editing the SetMaxHenchmen(xxx) setting (changing xxx here to any number up to 100)? I'd be likely forced to edit custom conversations and all kinds of custom scripts that check party member counts on top of this? Just changing the xxx number in that setting would likely break the module(s) in question completely?

Melkior

It's worse than that (he's dead, Jim). There really is no reliable way (that I know of) to restrict party size. (There isn't even any way to determine exactly who last joined the party.) There are no settings for it in the game, there is no scripting command for it, and there are no event triggers (such as there are for players entering or leaving the game) which would trigger when someone joins or leaves a party.

While it would be possible to make a module heartbeat script which could determine whether each PC was in a party or not, and if so how many parties there are and how many PCs in each party, determining which PC should be removed from the party would be entirely random since there is no way to flag the PC who last joined a party due to the aforementioned lack of any event trigger or any associated commands regarding the event having happened. There would also be the danger of such a script causing a lot of server lag since it would need to do a lot of work.

The only way around it might be if someone produced an add-on for the server, designed for the purpose, but since you're the first person I have ever heard of who asked about such a function, I think it's unlikely that anyone will make such an add-on.

So the short answer is that with the current game mechanism, what you were hoping to do is as close to impossible as I can imagine.

If you're attempting to make sure that two teams are of equal size in a PvP server, then I'd suggest using a different mechanism, such as each PC needing to use a placeable object in order to "register" their membership on a particular team, and they cannot enter the arena until they have "registered" and nobody can enter the arena until the numbers on each team are even, and once one person enters, nobody else can "register" in order to keep the numbers balanced, and only someone who has "registered" can enter the arena.

ForSerious

If you are just thinking of changing the number of allowed henchmen in, say, the original campaign, then you are correct. That would take modifying several scripts. You probably wouldn't need to modify the conversations at all to get it working though.

Jidokwon

Thank you for the answers here! I was just rather hoping that there might be a reasonably feasible way of having the basic henchmen features work pretty universally and consistently in single player mode. Bioware and Beamdog never considered updating or "enhancing" the original campaign and sou expansion, just an example. They've basically never been updated from the times that they were released. So far as how the henchmen basically work, I'm meaning. The task of updating the basic gameplay here for single player content so that it's reasonably consistent across the board is likely going to be well out scope for my abilities here. Thank you both again!

Melkior

There is a setting for max henchmen which I believe can be changed via either a module setting or a scripting command.
The problem with multiple henchmen is that they're allotted in a "chain" where the first henchman is the henchman of the PC, but the second henchman is actually a henchman of the first henchman, then the third henchman is a henchman to the second and so on down the chain.
This means that GetMaster() won't reliably return the PC in a multi-henchman module, and you instead have to custom-make a routine to reliably return the PC who is at the top of the chain of henchmen. I call mine GetTrueMaster();

// GetTrueMaster
// Returns the true ultimate master in a multi-henchman module.
object GetTrueMaster(object oSummon=OBJECT_SELF)
{
  if(GetObjectType(oSummon)!=OBJECT_TYPE_CREATURE) return oSummon;
  object oMaster=GetMaster(oSummon);
  while(oMaster!=GetMaster(oMaster))
    oMaster=GetMaster(oMaster);
  return oMaster;
}

Non-creatures are always their own master.
The loop keeps on getting the next master up the chain until the "master" is the same object as the summon, which means that we've reached the top of the chain and we should return the last object obtained as the master of the summon.