675 réponses à ce sujet

[ColorsFade]

Andy,

I spent quite a bit of time figuring this out in the last couple of days, so let me collect my thoughts and I'll get you a proper answer.

[andysks]

Hey thanks so much. You give me the feeling that you also had some trouble on the matter. However, there is no rush to complete this. Companions are created, and have convos and everything. When I this figured out, I just have to go back to their convos and adjust them accordingly. In the meanwhile, I go on with building the areas .

[ColorsFade]

andysks wrote...

Hey thanks so much. You give me the feeling that you also had some trouble on the matter.

Yes, and only because I had a very, very specific idea of how I wanted to do companions, and it turns out you can't do it the way I wanted to do it (because the Roster GUI doesn't work the way I want it to work). 

The biggest problem with my first plan is that the Roster GUI despawns all non-party roster members and saves them out of the game when you close the GUI. This is why the only place you use the roster GUI in the OC is when you exit the Sunken Flagon, so you never see the non-party roster members disappear. 

I wanted to have the roster GUI be selectable from a book within the inn, and for my party members to walk to their hangout spots when I finished with the GUI. You can't do it if you use the Roster GUI, however. But you can with conversations. 

I still want to use the Roster GUI for one spot on my campaign however, and I am going to test this scenario soon. 

Basically, I want to use the Roster GUI when the PC gets their final home base, the stronghold. 

The Stronghold will have a World Map Transition in it, and what I want to do is, when the PC clicks on the World Map Transition to exit the Stronghold and go somewhere else, first pop the Roster GUI so the PC can form their team, and then transition the team. 

Meanwhile, each time the user zones into the stronghold, all party members are dismissed and every available roster member is spawned at their hangout spot. This has the same effect as the Crossroad Keep,with your party members scattered around your home base. 

The PC in my mod would then be free to use conversations to add/remove party memebers while inside the Stronghold, In this way, the PC can switch gear between companions without having to zone in and out of the stronghold, like you had to do in the OC (which was really, really annoying to me). 

So, you go around and use the familiar conversation interface to add/remove companions, swap gear, ect. Then when you are ready to leave and hit the World Map Transition, the Roster GUI pops up and you have one last chance to form your party before leaving the Stronghold. 

I'm sure this will work given my current understanding of the companion system and necessary conventions and scripts, but I want to test it first to make sure.

andysks wrote...
However, there is no rush to complete this. Companions are created, and have convos and everything. When I this figured out, I just have to go back to their convos and adjust them accordingly. In the meanwhile, I go on with building the areas .

Do you have a clear idea of how you want to handle companions? Because that's really the first question to answer. If you know how you want to do it, I think I can guide you to a solution.

[ColorsFade]

andysks wrote...

Thing is, I do not know exactly how the scripts work, how items and status are saved and so on.
So i am generally confused. If I add a companion, and then remove him through a convo do I just need one script? Does ga_jump work? if I add him again through a convo do I need all 4 scripts again, if it's the second time?

If you set it up correctly, then yes, you pretty much just need one script call in each spot in a conversation. You need one script to accept a companion into your party, and one script to make them go away. 

I know - it seems confusing and it is because BioWare left so many scripts into the engine for backward compatibility. Each time they improved things, the old stuff is left in, and you really have to dig and trace through the code to figure out what the functions are doing. 

The trick is: you have to get things set up correctly so that these single functions work. And this is why I will probably end up writing another guide, like I did for the Wandering Monster system, so that it's a bit clear what needs to be done. 

There are some conventions at work here with the naming of waypoints and such, and if you follow them and know how to do it, then everything just works. 

[andysks]

How I want it is like this:

• Finding them

 
You find the companion somewhere, after an introduction, he offers to join. PC gets two options
"Come with me"
"I don't need you".

In case of the "I don't need you", the companion will say "I'll be in that inn".
The given inn, is the gathering point.

In the case the PC meets the companion in a time of need like: "My farm has been invaded by ogres etc", and he wants to join you, you get a third, fourth and fifth option.
"Come with me, but I need some equipment first etc".
"I cannot help you right now, but will do soon. Wait for me in that inn".
"I have no interest in your story":

On 1st and 2nd, what happens is what would normally happen, with companion joining or travelling to the inn.
On the 5th though, he is lost, the quest ditched.

• Roster GUI

I kinda dislike the Roster GUI. Not generally, but the fact that you can add or remove them whenever. So if it's possible, I'd like it to be available only in the hangout inn.

Here is where it gets most complicated for me. If you have a full party, and you meet a new one, does the gui opens automatically when you accept him, even if it's only supposed to open in the gathering spot? That should be no problem... in that case, I want the gui to pop up.
And in the case of the full party as well, the one left out, I guess dissapears, and appears at the inn next time the PC visits it.
I guess the OnEnter script of the inn, circles through the roster, and picks the ones not in party, and spawns them.

• Many hangouts

There is a city, where the first hangout point will be introduced. But later on, you loose access to this city. So another hangout should be introduced. How I transition it... no idea.


And something else, that could prove helpful. Does it matter if a companion is a placed creature or a spawned via a ClientEnter event?


I hope I've given a clear idea of how I want this to work .

Modifié par andysks, 08 novembre 2013 - 03:17 .

[ColorsFade]

andysks wrote...

Here is where it gets most complicated for me. If you have a full party, and you meet a new one, does the gui opens automatically when you accept him, even if it's only supposed to open in the gathering spot? That should be no problem... in that case, I want the gui to pop up.

There is a slightly different version of the GUI for when a character is met and your party is full. 

I thought about this too. What I do is handle it through conversation. I have a script I wrote that allows me to check to see if the part is full. If it is, and you try and accept the companion into the party, the companion returns with a line that says, "It looks like your party is full. Come back and speak to me when you have room." 

Now, the GUI pop should also work, but I haven't tested it and I wanted to handle it through conversation if I could. 

andysks wrote...
And in the case of the full party as well, the one left out, I guess dissapears, and appears at the inn next time the PC visits it.

Every time you want a companion to leave your group and reappear at the inn, you can do that. Setup properly, it just takes one script call. 

andysks wrote...
There is a city, where the first hangout point will be introduced. But later on, you loose access to this city. So another hangout should be introduced. How I transition it... no idea.

At the moment you lose access to that city, I would swap hangout waypoints. 

andysks wrote...
And something else, that could prove helpful. Does it matter if a companion is a placed creature or a spawned via a ClientEnter event?

Yes, it matters. Never place them. Ever. The documentation in the scripts is pretty clear on this. 

When you have a location where you want to put a companion, you need to lay down a waypoint and you need to name it "spawn_companionname", It has to be lower case and formatted just like that. Then, you can make a call to SpawnNonPartyRosterMemberAtHangout("companionname") to spawn the companion correctly. 

There's a bit more to it than that, as far as setup goes, but that's the gist of it. 

Never place a companion. 

andysks wrote...
I hope I've given a clear idea of how I want this to work .

Yep! Basically, just the same way I am doing it, only I am moving the hangout waypoints around one more time than you are. 

I'll get it tested fully over the next couple of days and write up a guide. Then you can implement and get what you're after

[andysks]

Yes, it matters. Never place them. Ever. The documentation in the scripts is pretty clear on this.

I thought so. Since they need to have a saved state, and so on. Plus be able to come and go... and this only can happen safely with no multiple copies of them if they are spawned.

I guess this is simply an OnClientEnter script right?
But what happens if a companion needs to appear during a cutscene via the ga_create_object script? Would that work?

Yep! Basically, just the same way I am doing it, only I am moving the hangout waypoints around one more time than you are.

I might also change it one more time, when they party leaves for the Outlands, or make some kind of meeting where the PC will have to choose witch ones he want's with him. Any maybe some of them don't even want to go there .

I'll get it tested fully over the next couple of days and write up a guide. Then you can implement and get what you're after

I'll be waiting for that. Your documentation of wandering monsters was extremely helpful. I couldn't stand the 5 second rest of the OC, and I am glad I won't be using it in my work .

Modifié par andysks, 08 novembre 2013 - 03:46 .

[ColorsFade]

andysks wrote...

I guess this is simply an OnClientEnter script right?

Yes. I have custom OnClientEnter scripts for basically every area in my mod. I spawn pretty much everything. I learned, early on, that spawning was the superior route to placement of creatures, because it makes it easy to update the blueprint to change a creature's features/scripts/variables and not have to re-paint them. The first time I had to repaint creatures I decided spawning was best. Companions or not - I just spawn everything. 

I have a pretty easy script template for OnClientEnter scripts, so I basically copy and paste it and then modify it. 

andysks wrote...
But what happens if a companion needs to appear during a cutscene via the ga_create_object script? Would that work?

There's a script for that. Again, if you're using the "system" for companions then you can call ga_roster_spawn. Here's what the documentation says: 

//Takes a roster name and script location and places an instance of the//NPC there if possible.  If the NPC already exists somewhere in the//module, it will move that NPC to the given location. If the NPC does//not exist, it will spawn in a new instance of the NPC from the roster//and place them at the given location. The return value is//the object ID of the newly spawned NPC, or INVALID_OBJECT if there//was some error encountered

So, if you left your companion at the inn, this script will move them to the location you specify for us in the cut-scene. Once the cut-scene is over, I'd make a call to ga_rm_go_to_hangout to send the NPC back to the inn (they don't go to the inn, of course; they despawn and get saved out of the game, and the OnClientEnter script at the inn is responsiblef or spawning them back in at their hangout spot when you re-enter). 

I wouldn't use ga_create_object for companions. Ever. Just the roster and hangout functions. ga_create_object is just a wrapper around CreateObject, which is what you don't want to do to create a companion. 

[andysks]

I get it now. But the scripts says If the NPC does//not exist, it will spawn in a new instance of the NPC from the roster//and place them at the given location.
What happens if the given NPC is not yet in the roster, but a totally newly created NPC that takes part in a cutscene, and then joins the roster?

About the spawning of everything, I think even the people that made the game realized that, and MoTB is all spawned NPCs. There is almost no placed instance if you open the areas in the toolset. However, I don't really get the scripts, so I place my creatures. I know it shouldn't cause a problem... maybe less freedom to do changes, but no problems.

I just thought of a solution to the cutscene thing. I could possibly add the companion to the roster on the first line of the conversation, since it's not hers, and then when her time to come is, she gets spawned with the companion script.

Modifié par andysks, 08 novembre 2013 - 04:42 .

[ColorsFade]

andysks wrote...

What happens if the given NPC is not yet in the roster, but a totally newly created NPC that takes part in a cutscene, and then joins the roster?

The way the OC does it, and the way I am doing it, you add all companions in the entire game to the roster when the module first loads. WIth the initialization function, all the companions are set to "Campaign NPC's", which means they do NOT show up in the party GUI. Per the documentation: 

The Campaign NPC flag is set to true for all of them so that they will not show in the party selection screen.

So, first thing - add all the companions to the roster. It only has to happen once. This is why I have a modified K-mod_load file (I call mine dk_mod_load). There's a spot in that file when it does things only one time for the entire campaign. That is where I call a function that initializes all the companions. 

Thus, no need to add a newly minted NPC. They're already in the roster. 

Later on, when you need them to show up in the Roster GUI, you change their Campaign NPC flag with another call. 

That doesn't mean they're going to show up in the roster GUI or anywhere else, for that matter. Think of the roster as a list that is off-screen. The game maintains it. 

andysks wrote...
About the spawning of everything, I think even the people that made the game realized that, and MoTB is all spawned NPCs. There is almost no placed instance if you open the areas in the toolset. However, I don't really get the scripts, so I place my creatures. I know it shouldn't cause a problem... maybe less freedom to do changes, but no problems.

For me, it's all about flexibility and the ability to continue making changes easily as I work in the toolset. I find I make a lot of changes to creatures/NPC's/Companions over time. Having to re-paint them every time to update the game is not fun. 

Scripting it out is pretty easy. I could help you with it you like. Once you have a template script, it becomes really easy to modify it and reuse it for other areas. 

andysks wrote...
I just thought of a solution to the cutscene thing. I could possibly add the companion to the roster on the first line of the conversation, since it's not hers, and then when her time to come is, she gets spawned with the companion script.

Yeah, this is solved by adding all companions to the roster on mod_load. 

Modifié par ColorsFade, 08 novembre 2013 - 05:47 .

[andysks]

I am just going to write my thoughts now, to see if I got everything correct.

My module load scripts is also custom, but it's actually made by you . It's the one for the wandering monsters.
Lines 137-139 are commented out.

   137  // Add all campaign companions to roster for easy access
   138  //InitializeNX1Companions();
   139  //SetupDefaultDestinations();

What I get is that line 138 needs to change.

Lines 180-181.

    // need to call after AddCompanionsToRoster so it will work in the first module.
    //SpawnNX1CompanionRosterMembersAtHangout();

No change needed. Leave them commented out.
This I guess needs to be in every module the same, since companions might appear in different modules.
Or actually... since it has the campaign flag, maybe it does it only on the first module.
So even if all modules have the same load script, the companions will be added to the roster once?

So, once this is done somehow, when the module loads, companions are added to the roster, but not available for selection yet! This will happen when you meet them, and accept them through the convo, where the convo line should have the  ga_roster_party_add , ga_roster_selectable, and ga_reset_level.
I think, the most important note here is the ga_roster_selectable. What I understand is that it makes the companion available for party selection.

Spawning them.

I took a look at the ginc_companion. Quite comprehensive. I need to have a global variable on the companion, set when first met or accepted to join. The OnClientEnter of the area, that the given companion is supposed to join, will check for this variable, and if it's not met, will spawn the guy on a spawn_* wp. That way, it should happen only once, and not get one spawned every time I enter.

Hanging out place.

Once they have joined, global variables are not needed anymore for this to work. The script will check automatically, for if they are already in the roster as selectable, or in the party, and spawn them accordingly.

That's all I got!
Brain needs some coffee now.
There's always a possibility some of the things I said now are wrong... but, it's just my thoughts on the matter, to get things in order in my head .

Modifié par andysks, 08 novembre 2013 - 05:36 .

[Tchos]

So much to respond to in such a short time.

ColorsFade wrote...
This is why the only place you use the roster GUI in the OC is when you exit the Sunken Flagon, so you never see the non-party roster members disappear. 
I wanted to have the roster GUI be selectable from a book within the inn, and for my party members to walk to their hangout spots when I finished with the GUI. You can't do it if you use the Roster GUI, however. But you can with conversations. 

I believe this is why SoZ's tavern guestbook opted for dismissing all cohorts before allowing access to the Party Roster.  If you try to adjust the cohorts at all, it first dismisses them, which makes them walk to their hangout points, and then gives you the roster UI so you can add back the ones you want (or you can walk over and talk to them if you prefer).  I used that system, except that I never made hangouts for the companions, since I'm happy with the BG2 style.

andysks wrote...
Here is where it gets most complicated for
me. If you have a full party, and you meet a new one, does the gui opens
automatically when you accept him, even if it's only supposed to open
in the gathering spot? That should be no problem... in that case, I want
the gui to pop up.
And in the case of the full party as well, the
one left out, I guess dissapears, and appears at the inn next time the
PC visits it.

You're asking if it normally pops up the UI if you have a full party?  It doesn't.  You have to script that to happen and give it appropriate conditions.  If you don't script it, then if you try to add the party member, nothing will happen.

For mine, if you have a full party and try to add another member, the conversation first checks to see if you have room, and if you don't, the companion will complain that there's not enough room and will offer to wait until you free up some room.  You can then exit that conversation and either use the party roster or a conversation with your companions to ask one to leave, then talk to the new companion again.  So you could do it without the roster at all, if you wanted.

ColorsFade wrote...
Yes, it matters. Never place them. Ever. The documentation in the scripts is pretty clear on this. 
Never place a companion.

Explain this, please?  Which script says this?  In my tests, I've used placed companions alongside spawned companions, with no apparent trouble, though I took the step of setting up their scripts individually.  Typically I design my companions as placed instances, and then convert them to blueprints for spawning once I'm satisfied, but I run many tests with them as placed companions before that point, and I've never encountered anything that warranted such a warning, unless it was something that came up so early that I fixed it and forgot it.

[andysks]

I used that system, except that I never made hangouts for the companions, since I'm happy with the BG2 style.

For mine, if you have a full party and try to add another member, the
conversation first checks to see if you have room, and if you don't, the
companion will complain that there's not enough room and will offer to
wait until you free up some room.  You can then exit that conversation
and either use the party roster or a conversation with your companions
to ask one to leave, then talk to the new companion again.  So you could
do it without the roster at all, if you wanted.

This is clear, a simple script to check the room. If you use hangouts, you can have a line after the complain that says "Wait, I'll make room for you", Then you bring up the UI, to adjust your party. He could even wait there, while you remove the other from your party, who in his turn will travel to the hangout. Then adding the "complaining" one by talking to him again.

Explain this, please?  Which script says this?

The ginc_companion states it in the first comments. Got me as well.

In my tests, I've used placed companions alongside spawned companions, with no apparent trouble, though I took the step of setting up their scripts individually.  Typically I design my companions as placed instances, and then convert them to blueprints for spawning once I'm satisfied, but I run many tests with them as placed companions before that point, and I've never encountered anything that warranted such a warning, unless it was something that came up so early that I fixed it and forgot it.

I even playtested for months my campaign with placed companions, and no problem occured at all. Of course, they were just simple NPCs then, with no hangouts or stuff like that. Or convo lines for removing them. Just the UI was available at all times.

Modifié par andysks, 08 novembre 2013 - 06:05 .

[ColorsFade]

[quote]andysks wrote...
What I get is that line 138 needs to change.
[/quote]

Yes. What you want to do is point to a script of our own that performs the initialization. 

[quote]andysks wrote...
This I guess needs to be in every module the same, since companions might appear in different modules.
[/quote]

That line, 138, that calls InitializeNX1Companions(), only happens inside a campaign check. So just once. I make sure all my modules use the same scripts (no confusion). The check makes sure it only happens once. And it's easy to export module script sets and import into the next module you make. 

[quote]andysks wrote...
So even if all modules have the same load script, the companions will be added to the roster once?
[/quote]

Exactly. That campaign flag gets set and that line is never called again, no matter how many modules load. 

[quote]andysks wrote...
So, once this is done somehow, when the module loads, companions are added to the roster, but not available for selection yet! This will happen when you meet them, and accept them through the convo, where the convo line should have the  ga_roster_party_add , ga_roster_selectable, and ga_reset_level.
[/quote]

Right. 

In my case, I took all the stuff that happens behind the scenes in those scripts and combined them into a single script that perform all those actions at once (adds the roster member to the party, makes them selectable, and then grants them XP). I do that because it's faster to set one conversation action than three every time. 

[quote]andysks wrote...
I think, the most important note here is the ga_roster_selectable. What I understand is that it makes the companion available for party selection.
[/quote]

Yes. It makes it so they can show up on the Roster GUI. Without it, they won't show. You can still add/remove them to the party through conversation, but not the GUI. Since we intend to use the GUI at specific points in time, they should be flagged as selectable. 

[quote]andysks wrote...
I took a look at the ginc_companion. Quite comprehensive.
[/quote]

Yep. That's what I've been doing, is analyzing that and figuring it all out.

[quote]andysks wrote...
I need to have a global variable on the companion, set when first met or accepted to join.
[/quote]

Don't set it on the companion. Set it on the PC. This ensures it gets saved properly and that a copy of the companion doesn't accidentally overwrite it. 

When I "meet" a companion I immediately set a variable on my PC called "MET_COMPANIONNAME". The only reason this variable is necessary is for when you go the inn/hangout spot and your OnClientEnter script fires. You don't want to spawn ALL of the non-party companions at their hangouts - ONLY the companions that the PC has already met. And the only way to do that is to track who the PC has met. Hence a local variable on the PC for each companion they meet. 

[quote]andysks wrote...
The OnClientEnter of the area, that the given companion is supposed to join, will check for this variable, and if it's not met, will spawn the guy on a spawn_* wp. That way, it should happen only once, and not get one spawned every time I enter.
[/quote]

You don't have to worry about duplicate spawns. The SpawnNonPartyRosterMemberAtHangout() call handles it. All your OnClientEnter script has to worry about is spawning anyone the PC has met that is NOT currently in the party and HAS been met by the PC. 

[quote]andysks wrote...
Once they have joined, global variables are not needed anymore for this to work.
[/quote]

The OnClientEnter script of every hangout you use will always check the local var on the PC to determine who to spawn and who not to spawn. It has to, otherwise it will spawn all the non-party NPC's, which is not what we want to happen. 

[quote]andysks wrote...
The script will check automatically, for if they are already in the roster as selectable, or in the party, and spawn them accordingly.
[/quote]

Roster selectable only matters with the Roster GUI. Scripts bypass the selectability variable. 

[quote]andysks wrote...
That's all I got!

[/quote]

There's one other piece of information I should pass you now. 

I don't know how  you're handling module transitions, but I use the World Map, and I call a custom script of my own that performs the travel. You may be making a call to LoadNewModule() when you need to transfer to a new module. If you are using the ginc_companion system, then you need to call SaveRosterLoadModule() instead. It takes care of despawning companions and saving their state out before it makes the call to LoadNewModule(). 



I know it's a lot to take in. I just started writing some notes to make a guide and see that there is just a lot of information to take in. 

However, the end result is that it becomes fairly easy to manage companions. I have mine setup now so that in a dialog I only need one script to add a party member and one script to remove them. They spawning of first-time companions works, they go to hangouts, and the Roster GUI works. So I think it's worth the effort to figure the system out. 

[ColorsFade]

Tchos wrote...
Explain this, please?  Which script says this?  In my tests, I've used placed companions alongside spawned companions, with no apparent trouble, though I took the step of setting up their scripts individually.  Typically I design my companions as placed instances, and then convert them to blueprints for spawning once I'm satisfied, but I run many tests with them as placed companions before that point, and I've never encountered anything that warranted such a warning, unless it was something that came up so early that I fixed it and forgot it.

From ginc_companion: 

Companion Spawns:ga_roster_spawn(string sRosterName, string sTargetLocationTag)Use this when you want to have the companion appear, but not be put into the party just yet.  Instances of companions should be spawned in from the roster.  They should not be placed as instances via the toolset or created in script using CreateObject().Since all companions are initialized at the beginning of the game to be in the roster, this script allows us to create or move the companion as necessary with a single call.

I think there are a couple reasons for this warning and I think it has to do with how the internal code manages the roster list. I've done a lot of debugging and printing out to figure out who is in the roster, when, etc., using the Roster functions, and my experience is that placed companions don't get managed by the roster very well. It could have just been glitches at the time, but coupled with the ginc_companion documentation, I just avoid it at all costs and blindly parrot the warning. 

Considering how many bugs there are in the various scripting systems, etc., I figure better safe than sorry. 

[andysks]

ColorsFade wrote...

I don't know how  you're handling module transitions

I use the world map as well. I use a script that came with the guide I read. I believe it is called sj_world_map_travel
made by sunjammer.

Never really looked at it... but never failed me.

I don't really get how to change line 138.
I will wait on the matter, until maybe a documentation comes. If you never find the time for it, I'll just not use a hangout and go normal with the companions . That is, come in... you go out, disappear! End of story .

Then they wonder why they get the worse loot while the PC wears all the goodies!

[Tchos]

I wish I had taken notes on why I went about things a certain way. I would have read that warning, since I most certainly scoured the ginc_companion at the time. I think I had a reason for discounting it, but it would have been because of the somewhat different system I'm using from the OC's. I started with Kaldor Silverwand's companion system, and combined it with the SoZ system. At any rate, I agree that it's better safe than sorry, and there are so many advantages to spawning NPCs rather than placing them, that it doesn't hurt to heed it.

[ColorsFade]

Tchos wrote...

and there are so many advantages to spawning NPCs rather than placing them, that it doesn't hurt to heed it.

Aye, and that's where I come down on this topic as well. 

Just spawn.  Be safe. Eliminate one more potential problem and make things a bit easier down the road as well. 

[andysks]

Now this was a day. I learned so much... that was a marathon of knowledge Colors. Sometimes I really wonder how you managed to learn all these aspects of the toolset so fast.

I hope the conversation here helped you as well a bit on understanding more aspects of the companion system .

I did some testing, to try and spawn my companions instead of placing them. Didn''t work. I guess it's this line 138 on the OnModuleLoad event. InitializeNX1Companions. I have no idea what this command is... but for today I've done enough!

Cheers!

Modifié par andysks, 08 novembre 2013 - 08:41 .

[ColorsFade]

andysks wrote...
I did some testing, to try and spawn my companions instead of placing them. Didn''t work. I guess it's this line 138 on the OnModuleLoad event. InitializeNX1Companions. I have no idea what this command is... but for today I've done enough!

Yeah, it's because you're not initializing your companions. That line - InitializeNX1Companions - only initializes the companions for (I think) MotB campaign. You need a function to initialize the companions for YOUR campaign. 

I have a script library I call d_party. It contains party-related functions. It has this function: 

// For use in dk_mod_load
// Loads all companions into the roster
// Sets all companion starting spawn points to "spawn_rostername"
// 
// You must call SpawnNonPartyRosterMemberAtHangout on the OnClientEnter
// script when you load an Area for the first time where there is a 
// companion needing to be spawned. 
void InitializeCompanions()
{	
	InitializeCompanion("wurdy","wurdy","wurdy");	
	InitializeCompanion("kayne","kayne","kayne");	
	InitializeCompanion("celeste","celeste","celeste");	
	InitializeCompanion("doxie","doxie","doxie");
}

You need to write a similiar script, with a similar function, and just use your companion tags instead. 

Then, in your modified k_mod_load script, instead of uncommenting line 138, you put this line in there: 

InitializeCompanions();

And that will initialize them one time, at the start of the campaign. 

From there, you need to spawn the companions with your OnClientEnter scripts. 

I have another method called PutCompanionInPlace("companionnamehere") and it is responsible for spawning the companion in the area with SpawnNonPartyRosterMemberAtHangout(). It only does that after it checks the local variable on the PC to make sure the PC has met the character ,and when it is sure the companion is not already in the group. Then it calls SpawnNonPartyRosterMemberAtHangout() and the companion spawns. 

andysks wrote...
Sometimes I really wonder how you managed to learn all these aspects of the toolset so fast. 

I'm a software developer. This is 2nd nature. The hard part is just tracing through the code to see what calls they are really making, and then deducing what is going on in the code I can't see (blue functions). 

andysks wrote...
I hope the conversation here helped you as well a bit on understanding more aspects of the companion system .

It did. Tryng to teach someone else is always a good way to refine your own knowledge. I try and test this stuff to make sure I'm not giving you bad advice. 

It helped me a lot in that now I know exactly how I want my own system to work too, and I have clear path for implementation.

I'll probably put together a sample module to go with the documentation, just so it's easy to see all the various things in play for real. 

[Tchos]

That's right. Except the module load script I started with initialised the SoZ companions. I swapped them to the IDs of mine, also in triplicate. I use their classes and the prefix "co_", such as "co_wizard", "co_barbarian", etc. I did not, however, initialise them in the k_mod_load script. The InitializeNX2Companions line is commented out and there's nothing to replace it. I'm looking for where I did it, but posting this now before it's no longer relevant.

[andysks]

One last thing. Is the script you posted here, meant to be an include on the mod_load script?

[Tchos]

To follow up, I do not initialise the companions at the module beginning in mine. I use the companion's conversation to manually activate the functions that are included in that commented-out line for each companion when you invite them to join your party the first time (and only then). This way, I can dynamically add any additional companions that I want to add in any expansions to the campaign.

Modifié par Tchos, 08 novembre 2013 - 11:52 .

[andysks]

Well, it still is complicated to me. I just did this function like Colors said, it compiled and everything, but when I try to set it on my module load script it doesn't compile. I am sure I'll get there, but in order not to lose my brain and burn out, I need to put some placeables around. This, I can manage .

[ColorsFade]

andysks wrote...

One last thing. Is the script you posted here, meant to be an include on the mod_load script?

Yes.