34 réponses à ce sujet

[Jackson Flynn]

I had this idea for my campaign, but it might be too much of a ball-ache.

The story goes that after you make a name for yourself in town, your character is invited to lead a mission, when you come back alive, you are asked to take a permanent position as "trouble shooter" and each of the guilds and churches provide a team member so you have access to a wide range of supplemental skills.
These guys all remain at your base of operations, and when you go out you go through the whole, "Who would you like to take?" scenario...
What I would like is to be able to limit the player to not tanking up on heavies by having discord between the guilds/churches so that certain followers won't work with others, so if you pick the priest of the goddess of the night the girl from the Thieves Guild won't work him, and vice versa.

Has this ever been done by anyone, and how much scripting spine ache can I expect to have to do?

is it possible to achieve through convos?

[kamal_]

Seems to be pretty straightforward. Exactly how you'd implement it would depend on how you have the pc pick their party, conversation or the OC style popup screen. The OC has sections where companions are both forced, and unavailable for use.

[andysks]

If you use the gui for party selection you might want to check the force scripts of the OC. Also the world map ginc. You can't use the same, since that ones are meant for clicking object and the tags of the companions are the ones of the OC, but you might get an idea. You might need a library defining the pairs of companions... but I don't know how to make it so that once one companion is selected on the gui, another one gets greyed. Don't know if possible...

If you use just conversation, you just need a gc_is_in_party... or how is called. If the good cleric is already in party, then maybe the assassin can have a response after offered to join saying: I won't travel with this dude. The conditional goes there.

[Jezla]

@andysks - Which ones are the force scripts?  There's a quest or two in my project that will need to force a companion, and I'm curious how it's done.

[andysks]

I don't remember and I'm npt in the PC right now. Open any OC module and search for script with force keyword. I think something like force convo hotspot something. Migjt be a campaign script and you might need to redirect to the ginc_worldmap as well. However, the OC does it by setting global vars, which many people dislike.

[Jackson Flynn]

I was hoping to use the "companions hang out in base then use the GUI as you leave" for ease, simply because it would be quicker in gameplay to just select them.
Unfortunately, I don't see a way of doing that without a serious amount of bespoke scripting, which I doubt I can manage.

I think what I will do initally is use the convo approach.  Using gc_is_in_party sounds easy enough. (I wasn't aware that was a condition, I must have missed it when I scanned the list.)

I'll have a look at the OC and see if I can't figure out how the bits where they manipulate the character selection. Maybe when I get beter at scripting it will make more sense.

Thanks guys.

[andysks]

I have posted a guide on the nexus about companions. Written by ColorFade. Yoy should look at it. It explains how to set a base peoperly and many more. Link not available at the moment sorry .

[ColorsFade]

I'm happy to answer any questions about the Companions guide. Using the GUI as you exit the base of operations is very easy to do to handle party management. 

 

However - if you want to limit party creation based on factions that don't like each other, the GUI will NOT work. And the reason is because you cannot manipulate the necessary variables to control a companion's eligibility once the GUI is open. 

 

Example: Evil Wizard doesn't get along with Goody Paladin. You click the door to exit, and select the GoodyPaladin to be in your party. At that point you need the EvilWizard to NOT be selectable - grayed out and unavailable - but you cannot control the property to do that once the GUI is open The property you need to set to make the companion not-selectable has to be set before you pop the GUI open. So... the control you'd need just isn't there. 

 

In order to do it you'd have to handle it through conversation. The PC would have to walk up to each companion individually and ask them to join the party. At that point in time, you can do a check to see who is already in the party, and companions would then have a chance to decline your invitation by saying they won't work with so-and-so. 

 

It would be REALLY EASY to do this through a conversation, and would provide you with the control you need. And I think it would actually be pretty neat (I would have loved it, in the OC, if some companions would have refused to work with Bishop, for instance. Like everyone... Because he was a ******). 

[Dann-J]

I have companions in my current module who will refuse to join the party if it already contains someone they don't like, and I do it entirely through conversations. The conversation trees get quite complicated as they're also checking various other conditions, like maximum party size, or whether you're in the middle of a companion-specific quest. I've stopped the party GUI from working by making all companions non-selectable in the roster, so they can only be added or removed via conversation.

[andysks]

http://www.nexusmods...ter2/mods/858/?

There's the guide. However what Colors said is true. Once the gui is open, there's no more going on. Can't change anything. So I guess through convo it is, which is actually fine. You can give the reason as to why not traveling together.

[Jackson Flynn]

That's fabulous guys thanks a lot.
I had hoped to use the GUI just from the point of view of it saving time every time you go out, but form what CF says, it's not feasible. And like Andy says, it allows for more information, and one thing I am pretty keen on is stuff making sense to the player as WELL as to the character. 

I'm sure I can manage it through the convo's, I'm having a lot of fun at the moment experimenting with the convo system, making a pretty cinematic mod. It might not even make it into the campaign proper, but I'm certainly honing my cutscene/camera skills.

But I'll have to have a good check of that guide to set up the base properly.

 

Cheers

[Jackson Flynn]

I'm even going to be cheeky, and use variables to make companions refuse to actually work with the PC if he/she has pissed them off, unless its a mainline plot issued by the Town Council, where the PC might redeem themselves and win back favour.

[Jackson Flynn]

Just a quick question for ColoursFade...
Reading through your "How To" on companions as kindly linked by Andy, I'm kind of stuck at the first hurdle.
You mention creating your own script library.

I could do with that explaining a little, it's probably, (like most things in this game) actually quite easy, but should I be creating a new override folder, or is there a way to do it through the toolset, or... what?
I'm also using Powerbar, so how would I get the library to show up in that, if that's even possible?

 

Thanks for your patience, and by the way, the guide is great!

[Tchos]

A script library is just a script with custom functions that you link to in other scripts through the #include statement.  You make custom functions to do several things at once, and you include the library in your scripts so that you don't have to type or paste the function in each script you want to use it in.  You can create them in the toolset like any other script.

[ColorsFade]

Tchos has it. 

 

The difference between a regular script and a script "library", to make this perfectly simple, is that a regular script has a main() function, and a script library does not. A script library only has custom scripts you write, with custom named functions. 

 

A regular script might look something like this: 

 

// function declarations

int GetCharacterLevel(string sTag);

string GetCharacterName(string sTag);

 

// script's main function - this is the entry point when the script is called

void mainI()

{

  int iLevel = GetCharacterLevel("Dynaheir");

  // a bunch more code that does stuff...

}

 

 

// function definitions

int GetCharacterLevel(object oCharacter)

{

  // a bunch of code

}

 

string GetCharacterName(object oCharacter)

{

   //a bunch of code

}

 

 

A "library" script would just have the function declarations and definitions, with no "main()" method in it. And that is because you never call the library directly, like a normal script. Instead, as Tchos points out, you "include" it into a regular script so you can call the functions it contains. 

 

Libraries exist to reduce duplication in code. Instead of pasting a function in several different scripts, you include a library, and call the function it in your script. In this way you have ONE and only ONE place where that function exists. 

 

And here's why: 

 

Suppose you have a function called GetCreatureLevel(), and you paste it into a script. You need to use it a few more times, so you paste it into some other scripts. Then you find a bug with your function, or you just want to change the way it works. Now you have to go hunt down EVERYWHERE that you copied that function. 

 

But if you keep that function in a library, then it only exists ONCE. So you only have to change it ONE time. And then everywhere that function is called is affected by your one change. 

 

Code duplication is the fastest way to a spaghetti-code base. Quickest way to disaster, because it mains maintenance (change over time) nearly impossible. 

[kevL]

But if you keep that function in a library, then it only exists ONCE. So you only have to change it ONE time. And then everywhere that function is called is affected by your one change.

note to OP: only after the various scripts where the function is called from are recompiled. But it's still a lot easier, safer, faster, and more consistent than copy-pasta ...

[Dann-J]

If you change the function in the script library, you then have to recompile every script that calls it as an include. That's still easier than having to actually alter and code in all those scripts though.

 

[Edit: ninja'd by kevL!]

[kevL]

 

bandito'd ?

[Kaldor Silverwand]

Personally I like controlling the party using conversations.  However, if you want to use the party roster I would think you could use the heartbeat script to check for incompatible companions and have it select someone to quit the party.

 

Regards

[ColorsFade]

Personally I like controlling the party using conversations.  However, if you want to use the party roster I would think you could use the heartbeat script to check for incompatible companions and have it select someone to quit the party.

 

Regards

 

That might be possible (on the PC, to handle cross-area), but the difficulty is user experience. If you use the GUI to insert two companions into your party, you expect them to stay there once you accept. And acceptance on the GUI means existing the area (since it's typically triggered from a doorway, because acceptances causes the non-party roster members to despawn and get saved out of the module). So.. as a user, I'd be pretty peeved if I accepted a party of four companions, zoned to the next area, and then watched as one of those companions left my party. Now I have to zone back into the inn/stronghold/whatever area and reconfigure my party. Just a bad user experience. 

 

A conversation would be better, and that's really the only clean way to do it. 

[ColorsFade]

note to OP: only after the various scripts where the function is called from are recompiled. But it's still a lot easier, safer, faster, and more consistent than copy-pasta ...

 

I often forget this fact, because I am accustomed to working with a real programming language every day

[Morbane]

i dont profess to understand xml coding but hard coding the selection gui may be a solution for a specific set of potential party members - then i think greying out bad matches might indeed be possible.

[Jackson Flynn]

CF,
I *think* I get what you mean, and as someone whose 9 yr old daughter has better programming skills than I do, still find scripting as daunting as trying to conduct a conversation in Swahili, I always fear I won't be able to get my head round it.
But damned if I'm not going to give it a try!
 

I'm a semi-professional writer, with a series of fantasy novels on the go at the moment, and having been an AD&D DM for well over 30 years, and having written more Live Roleplay campaigns than you can shake a pointy stick at, my strength lies in the plot, character, and interaction stuff far more than the nuts of bolts of gaming.

 

The fact that this forum, (and it's predecessors) exists has made it possible for someone like me to be able to develope my ideas into a workable game that the guys who I've reff'ed for, for decades seem to enjoy. And for the snippets of advice I've been given that to some must seem like leading a child through the park are something that I will be forever grateful...

 

Thanks guys.

[ColorsFade]

These forums are the best. I wouldn't have been able to make any progress if not for these forums and the users who are willing to spare their time and knowledge to answer questions. 

 

When I opened the toolset last year and decided to give it a go, I expected an older engine like this to have a dead community. I was pleasantly surprised at the number of folks actively creating content, and continuing to share their knowledge and wisdom. 

[andysks]

These forums are the best. I wouldn't have been able to make any progress if not for these forums and the users who are willing to spare their time and knowledge to answer questions. 

 

When I opened the toolset last year and decided to give it a go, I expected an older engine like this to have a dead community. I was pleasantly surprised at the number of folks actively creating content, and continuing to share their knowledge and wisdom. 

True. When I first came to the forums I thought that the newest post will be like a year ago, since that time. I was so surprised to get answers to my questions. It is intimidating. CF can tell you more than anyone how bad I was, still am in scripting. But with help and willpower everything is possible.