17 réponses à ce sujet

[Happycrow]

Hey folks.

After eons in PW-land, I'm laying the groundwork for making a module, and need to know how one would add an NPC to a team's roster *without* making them a full companion NPC (aka, so that they can be issued commands, but they don't get to level up).

I'm just past the noob stage in terms of scripting (PW I used to be with had a dedicated scripter, so I did custom content instead, much of which I hope to integrate into said module) and working with the various tuts. If I've overlooked an obvious link please excuse  my ignorance.

[kamal_]

You mean henchmen?

[Happycrow]

More or less: an NPC who can travel with you and thus be available for dialogue at various points if the given person is with you, but who won't be racking the level-ups (the tension between the prowess of the adventuring PC/NPCs and the relative fragility of these guys being an important part of the story).

[Dann-J]

You could give them a user defined event script that removed their XP every time they're able to level up. You might get the level-up effect and sound firing, but you wouldn't be able to actually level them up once the XP was leeched away.

Another approach would be to give them a custom hearbeat script that constantly sets their XP to zero.

[M. Rieder]

the script "ga_add_hench" or maybe "ga_add_henchman" (can't remember exactly) can be called from a conversation and will add an NPC as a henchman. The henchman will be like a summon. You can give it commands, but you will not be able to control it directly. It should not level up either.

[Happycrow]

Perfect.
Thanks, gents! Seriously doubt I'll get this out by Halloween as I want to (it's horror-based, but will use a lot of CC in it), but that's just a HUGE help.

[Tchos]

I hope you can -- I love a good horror-themed adventure around Halloween.

[Happycrow]

Do what I can as fast as I can - my PW used *no* scripted quests, so I've literally never scripted one before and have some learning curve to hurdle.

[Claudius33]

ga_henchman_add to add a henchman
ga_henchman_remove to remove him/her from your party
ga_henchman_replace to replace one henchman by another
ga_henchman_setmax should you need more than one henchman in your party.

Caution :

• Don't forget to associate the henchman scripts to your henchman (import properties ... group of scripts) or force them when using ga_henchman_add (there is a parameter).
• A henchman can't move to another module of your campaign. Your party must stay is the same module while s/he is in the party. If you need a henchman to follow the party in another module, you must create a new instance of the henchman in the second module and add him/her to the party by script.

[Happycrow]

Thanks, Claudius -- is there anything pre-existing to duplicate variables set on said henchmen from one module to another?

[Claudius33]

No, as far as I know. Use globals variables to move variables from instance #1 module 1 to instance #2 module 2. BTW, in that case you don't need to attach variables to the henchman. Globals are always available whatever the module.

[Morbane]

On a related topic - is there a henchman maximum?

I remember from an older module (fergit th' name) there were like 8 or 9 monks and soldiers following my party into a fight with a dragon.

I s'pose it might be limited according to interface realestate - but I have this idea of acquiring a lot of henchman to follow him/her whilst outdoors.

[kamal_]

Well, in the OC you get everyone in your party at one point. That was what, 12-15 people? I've personally done 5 henchies at once, as well as 5 party members plus 2 henchies.

[diophant]

Claudius33 wrote...

No, as far as I know. Use globals variables to move variables from instance #1 module 1 to instance #2 module 2. BTW, in that case you don't need to attach variables to the henchman. Globals are always available whatever the module.

Be careful with global variables and campaign variables. AFAIK, they are stored in an xml file and can be accessed from any module. That also means that they are not persistent with regards to a save, i.e. if you load an older savegame, you might end up with the variable values of your last game. You can use them to transfer information from one module to the next on a module transition in your campaign, but write them immediately before leaving module A, and read them immediately after loading module B and store them into local variables again.

[Claudius33]

diophant wrote...

Be careful with global variables and campaign variables. AFAIK, they are stored in an xml file and can be accessed from any module. That also means that they are not persistent with regards to a save, i.e. if you load an older savegame, you might end up with the variable values of your last game. 

Globals are consistent regarding the saves. There is one global.xml file in each save folder, i.e. if you load an older savegame, the globals will be in the state they were at the time of the save.
For instance that is how the only one time conversation nodes in a campaign companion conversation are handled. 

Actually globals and local varioables attached to the PC or a companion work the same way except that in a save folder, you find the corresponding variables in :

• global.xml for globals
• playerlist.ifo for local variables attached to the PC (including the journal), VarTable section
• rostername_of_a companion.ros for the locals variables attached to a companion.

You find an instance of these files in every save folder consisent with the time of the save.

Modifié par Claudius33, 20 juillet 2013 - 11:01 .

[diophant]

Claudius33 wrote...

diophant wrote...

Be careful with global variables and campaign variables. AFAIK, they are stored in an xml file and can be accessed from any module. That also means that they are not persistent with regards to a save, i.e. if you load an older savegame, you might end up with the variable values of your last game. 

Globals are consistent regarding the saves. There is one global.xml in each save folder, i.e. if you load an older savegame, the globals will be in the state they were at the time of the save.
For instance that is how the only one time conversation nodes in a campaign companion conversation are handled. 

Actually globals and local varioables attached to the PC or a companion work the same way except that in a save folder, you find the cooresponding variables in :

• global.xml for globals
• playerlist.ifo for local variables attached to the PC (including the journal), VarTable section
• rostername_of_a companion.ros for the locals variables attached to a companion.

You find an instance of these files in every save folder consisent with the time of the save.

Good to know, thanks for the info :-)

[Tchos]

There's been a problem I've been seeing recently with a lot of newer players with the game being unable to write to the globals.xml for some reason, leading to dozens of complaints on this forum and the GOG NWN forum that quests and conversations are being reset in the OC. I could be barking up the wrong tree and globals aren't really where the problem lies, but it's one of the things that has made me more wary of using globals. When I want something stored persistently, I've been storing them on the PC or in the campaign journal.

[kevL]

dio,

what you were saying *is* true for campaign variables ... they get stored in the /database folder. hence an older save game would pick up their most recent, 'persistent' state.