675 réponses à ce sujet

[Tchos]

andysks wrote...
In any case, this "discovery", is very important for me. I just didn't know that the speak trigger could work without the gtr_speak_node, but with a cvustom as well.

Well, a speak trigger is just a generic trigger, but with a blueprint that has the gtr_speak_node script and appropriate variables for that script already applied.  You can make your own blueprints for triggers with your own scripts and variables already applied.

[andysks]

Journal          

• Much progress

Boy was today a productive day. I really don't know where to begin. As I said before, my mind got clearer by the speak trigger thing. This is one thing. That gave me a push I think, and I worked like a maniac after it. I decided to leave the quest with the hay piles for now, until I figure out what's wrong with the script I am using. That was a companion quest, so I thought: If I start, I might as well do all the companion quests first before I continue with the main plot. This is, because the main plot takes me to another module and didn't want to switch at the moment.
So today I did 2 companion quest lines. This includes: 3 areas(1 exterior, 2 interiors). about 3000 words written, 5 scripts, 2 unique NPCs, and work on the world map.

I have played many modules that had a battle system, that in order to defeat the enemy you have to interact with a placeable somehow. I always wondered how, but to day I did it myself... proved not so bad after all.

So after all this, before I call it a night, I also sat and did the excel calculation ColorsFade told me, about the quest xp rewards. It proves really helpful to have around, and not building blind.

I also got my hands today on some packages I didn't know before, one is the sls2(this I knew, I always wanted it but today was the day), and the effect package from Sorceress Ashura.
Tomorrow is a going back day, where I will go to the first areas of the campaign and fix some stuff the play testers suggested, implement sls2, and make them a bit nicer looking with some new placeables.

Andy.

[ColorsFade]

andysks wrote...

I also got my hands today on some packages I didn't know before, one is the sls2(this I knew, I always wanted it but today was the day), and the effect package from Sorceress Ashura.
Tomorrow is a going back day, where I will go to the first areas of the campaign and fix some stuff the play testers suggested, implement sls2, and make them a bit nicer looking with some new placeables.

Just a note on SLS2. I've been using it from day1 and have learned a lot, and there are some shortcuts one can take to make it work faster. 

All of the SLS2 fixtures, by default, include the p_sls2_fitting_ud script as the On User Defined Script abd a set of variables. This script, along with two scripts on your area, make the lights turn on off. 

If you want each fixture to control its own light source and fx, then each fixture, light source and fx needs to have a unique name (adding an int to the end is the easiest method). Like triel_lamp_1, triel_lamp_lt_1, triel_lamp_fx_1. This means every time you paint down a fixture, you need to setup the tags for each one individually. This takes time. My town of Triel, for instance, has 24 lampposts. That's a lot of tag editing and variable editing for each fixture (because you have to set the variables on the fixture to tell it the name of the light source and the fx, and the fx blueprint to use. Three variables to setup per fixture. Again, a lot of editing every time you paint one down). 

But there is an easier way. 

The easiest way to setup lights for an entire area is to have ONE controlling placeable! This should be an iPoint, as it's hidden. All you need to do then is set the p_sls2_fitting_ud script as the User Defined Script on the iPoint, and import the SLS2 variable set (if you don't have a set to import, just place down a SLS2 prefab and export). 

Here's where it gets easy. On the iPoint controller set the light tag name, fx tag name, and fx blueprint. So, for example, suppose you want to lay down 24 lampposts. You set the name of the light to be "triel_lt", and the name of the fx to be "triel_fx", and then the blueprint to whatever it is supposed to be (get it from the SLS2 blueprint you plan to use). 

Now lay down a blueprint prefab from SLS2 - the lamppost you want to use and "ungroup" it.  Click on the light source object set it's light tag to "triel_lt". Click on the fx object and set it's tag to "triel_fx". 

Select them all together and either make a blueprint and or copy. Now paint them down wherever you want. 

Every lamppost light fixture you paint down will have the same light source tag and fx tag. The controlling placeable, the iPoint, will cycle through these automatically and turn all of them on at the appropriate time, and off at the appropriate time. Instead of painting down each lamppost one at a time and editing several tags and variables, now you can just copy/paste a lamppost/light/fx. 

So, before, with each fixture controlling the light and fx, you end up with a tag list that looks like this  (in the toolset, when you're examining area contents, for example, and you want to check the lights)

triel_lt_1
triel_lt_2
triel_lt_3
triel_lt_4
etc... 

But when you use a single controlling placeable, you end up with: 

triel_lt
triel_lt
triel_lt
triel_lt
etc...

Besides being MUCH FASTER to setup, this also has another advantage: you use this SAME methodology to setup DAYLIGHT at windows in interiors, and to turn the daylight on/off based on time of day. 

And thus, a fast way to set things up is, once you have an iPoint for lights ,and once you have an iPoint controlling daylight, then you can save those two as blueprints (generally speaking, the iPoint blueprint for daylight has a start hour of 7 and a stop hour of 17, and the iPoint for lights is reversed). 

If you want a separate group of lights setup, you just lay down another iPoint for lights and set the appropriate tags. 

I have an iPoint in Triel for the lampposts, and another iPoint for the campfires that spring up at night. 

There are a couple other lights that aren't lampposts or campfires, and so for those unique lights, I lay down a SLS2 prefab and let the fixture conrol it's own light source and FX. 

Beware One Thing...

What you have to be aware of: You may think you don't need an iPoint and you can just lay down a whole bunch of SLS2 prefabs and leave them all named the same, like "triel_lt" and "triel_fx:" If each fixture is configured to toggle the light and fx and they are ALL named the same, guess what? Your lights will be REALLY BRIGHT! And this is because each fixture is turning on all the other fixture's lights, and they all stack up. 

This is why, if all your lights and fx's are namd the same, you need only ONE controlling placeable. 

I hope all of that makes sense. When I first did Triel I painted down 24 SLS2 prefabs for the lampposts and then individually setup their tag names and variable sets. it took a long time. It was only later when I was setting up daylight in an interior and noticed that a single iPoint was recommended in the documentation to control the lights and effects (window haze) that I realized you could do the same thing for all same-type lights. So after that, things got easier... 

SLS2 is really awesome. My guards whip out torches at night when they are on patrol, and campfires crop up, lampposts go on, daylight floods interiors... it's a cool thing. 

[andysks]

That was really comprehensive. Thanks a lot. I read already their documentation, so I got how the system works. But one thing that got into my head while reading was a simple: boy this will take time . Really cool this thing with the ipoint! Invaluable. Thanks.

[Tchos]

Another note on SLS -- if I recall correctly, at least some of its light blueprints have shadows set to 1 (which means 100% black). You don't want 100% black shadows in most cases (visible when point light shadows are on). Change the blueprints of any lights to have shadows between 0.3-0.6, unless there's some reason in your game that light wouldn't be bouncing off of surfaces to partially illuminate the shadowed areas.

[kamal_]

ColorsFade wrote...

 suppose you want to lay down 24 lampposts. You set the name of the light to be "triel_lt",

Warning, lights lose their tags when you save/reload the game. This is a game engine bug and not SLS's fault. It can however, be worked around. kamalpoe.blogspot.com/2012/11/fixing-another-sls-bug-for-usable.html

[ColorsFade]

kamal_ wrote...

ColorsFade wrote...

 suppose you want to lay down 24 lampposts. You set the name of the light to be "triel_lt",

Warning, lights lose their tags when you save/reload the game. This is a game engine bug and not SLS's fault. It can however, be worked around. kamalpoe.blogspot.com/2012/11/fixing-another-sls-bug-for-usable.html

Aye, I should have mentioned that. 

I remember finding your blog on this when I first started with SLS2. I just checked my scripts to be sure, and there it is: Work Around Tag Bug: kamal

[andysks]

So I did some SLS2 stuff today, but I had a weird moment where the vfx didn't spawn, while the light did. I read kamal's blog where he says about the resref, so I was careful with that. Maybe I missed something... will see.
In general, the system ColorsFade mentioned is really powerful. I was able to set a whole area in 5 minutes, something that could take half an hour at least with specific tags for each object. Thanks.

[ColorsFade]

Whenever something doesn't work, it usually comes down to a tag being misnamed.

Check your fx tag name that is set on the variable in the iPoint. Make sure there is not an empty space on the end of the variable name.

Empty spaces on the end of variables names and values are my nemesis.

[ColorsFade]

One thing I forgot to mention about the SLS2 stuff: 

If, like me, you started using it by importing it into a module, you'll have to import it into every module where you want to use it. That means a lot of duplicate files. 

The better way to make use of it is to copy all of the SLS2 files to the campaign folder, and clear them out of whatever module folder you might have imported them into first. 

I just transferred all of mine over to the campaign folder today because I need to use SLS2 in a lot of different modules. All of my lights in my first module were permanently "On" even though I had moved the scripts to the Campaign folder. It was because I had failed to move all the blueprints and prefabs and whatnot as well. Everything dealing with SLS2 needs to be moved to the Campaign folder if you want to use it across multiple modules without duplicating code (which will help keep the size of your overall download lower). 

[andysks]

Journal

• Companions

For the last couple of days, I am working on Companions. By working, I mean trying to figure out some basic stuff. For example, I had 5 companions in the Prologue, and they all had to play a part in the main story. The testers however, mentioned that they didn't get some of the companions. Maybe because they didn't find them, or simply not feel like it.
A good example would be the rogue, who is imprissoned somewhere. Later on chapter 2, he palys a major role in the story. But what if somebody doesn't find him? So far, the companion dialogues that have important plot, are built in a way that they'll join if you initiate a conversation with them. Roster is free though, and you can remove them afterwards if you want.
So instead of having a dialogue that the player has no option but to accept the companion, I thought I'd change it. Companions that are absolutely necessary to the main plot, will be forced into the party. This is the only way to go.
I am one of these gamers that like to do whatever I want, and choose what I want when I play an RPG. But sometimes there is no other way.
To sum up on the system I have in mind.

Roster is free. You can bring it up, wherever you are, and add or remove companions.
Companions that will play a part on the main plot, and not just a side quest are forced in the party, so that the player will at least know who they are. They can still be removed of course... just the knwoing them is important.
An influence system is not yet inside, and I am not sure if it will be. There are occasions though, when an important thing for a companion comes up, and you choose not to help, that they can get mad and leave you. Also, different alignments of companions might lead to conflict in the party.

So, yes. Many games have forced companions. Imoen, Morte etc. Dungeon Masters do it (this Paladin guy).
So I guess it's not so bad. I just have to be careful with the leaving and angry companions, that someone won't need them later. I tend to play good alligned characters, and I forget that some people might send their companions packing in a time of need . I should think of these people while building.

Andy.

[-Semper-]

andysks wrote...

So instead of having a dialogue that the player has no option but to accept the companion, I thought I'd change it. Companions that are absolutely necessary to the main plot, will be forced into the party. This is the only way to go.

i'm all against forced companions but that's completely your choice. what i don't get is the part how someone can be important to the story but could be tossed out of the party at any time after joining. why not use a npc to fill this role and save a personal story for the companion which could be interwoven with the main plot. it would be a nice bonus if you discover and resolve the quest, but at no point would it be mandatory.

this would also enable the option to create a custom party with story driven cohorts alongside. similar to soz but in fact with a story behind each hireling. it's also nice to discover something new the second time - in the example of the thief you could rewrite the story so that it plays out slightly different if you miss him. combined with different ending slides this would be aaa quality without that much additional work

Modifié par -Semper-, 07 novembre 2013 - 05:14 .

[andysks]

I may have said things wrong . The main plot, is the PC and only. What I meant by important, is that some of them might do some things to progress the main plot. Of course, you don't know these people before... they are not your siblings or anything. It's just how the story is, that some of them will do something to affect the main story. So I think, the minimum I can do is to force them in, even if for a little bit.
Kinda like Bishop. When I played the OC, I used him only this ONE time, that was impossible not to. But with this system, I at least knew him, and when he betrayed me, I didn't say :"Who the hell is this guy?".

[ColorsFade]

Forced companions do seem to irk people. I can kind of understand it. I think the best way to solve this problme is never to force a Companion into the party, and instead, look for other ways to do things. 
I think the key to providing companions is simply to use them as side-quest material or as optional ways to advance the main quest. 
Example: There's a quest, early on in my campaign that is optional (but the same idea would work with a portion of the main quest). 

For this quest, you don't have to take it at all to advance the main quest, but it certainly is beneficial in some very specific ways.

Anyway, there are two ways you can start this quest and advance it. One is by talking to the blacksmith in town, who will start the quest for you and send you on your merry way. The other is via an encounter with a companion you first meet at the local inn. When you meet the companion for the first time, there's a bit of skirmish, and afterwards you have some dialog. You can accept her into your party at that point and she will start the quest as well, or you can decline to take her. 

So there are two options for advancing that particular quest. If it were part of the main story arc, I'd approach it the same way. There should be a corresponding NPC (non-companion) who can advance the quest, or a companion could advance it in a different way. 

I had toyed with the idea mysel of making one particular companion mandatory, but I think I've read enough vocal support from folks who just don't like forced companions, so all of mine will be optional. It does make for some extra dialog work if you want to do it this way (is the companion in the party? no? then this node, otherwise that node) but I think, in the end, it's the best experience for the player. 

[-Semper-]

andysks wrote...

What I meant by important, is that some of them might do some things to progress the main plot.

what colorsfade said. always try to avoid such rigid plot forwarding systems. an optional or dynamic quest structure keeps the game interesting. if your story "dictates" that such a companion is needed i would try to keep those on a very minimal level, lets say only one forced encounter in the whole campaign. you could also spawn in the companion when the plot hits that crucial point - e.g. that thief was freed by the antagonist and therefore helps him now. the world ain't in stasis while you're away adventuring^^

if you only force them when something impotant happens your suspense curve will fall flat because of predictability.

Modifié par -Semper-, 07 novembre 2013 - 09:16 .

[andysks]

I think I get it now. My mind was thinking that, the rogue for example, that you recruit in the beginning, is going to help you later on with something crucial. Now as I read your posts, I got another idea. Introduce a completely new companion option that helps you in the same crucial point. After the help, for his reasons, he will offer to join as well, thus not forcing anything in the party.

However, companions like Bishop, there is no other way to introduce. Force in to progress the main plot.
If I remember correctly, that was the case with him as well. You needed to go to the forest and he was gonna scout for you. After that, you were free to kick him out.

I already have made my preparations for all these occasions. Every time I want the companions to swoop in and say a line, I make a line for every possible companion, with the conditional script, and one extra for the NPC speaker, just in case someone plays hardcore solo. So, conversations shouldn't be a problem.

Of course, I got to think of some stuff now, and go through some key convos to check if everything is in place. But I like this more than forced guys. And I mentioned Morte before, who was not just a companion... he was so crucial to the main plot that it actually didn't bother me that he joined from the first second.

Still, I think companions are a realy imporant part of these games, and the line between good system and bad is quite thin. If you have any more ideas or preferences about companions, please post .

Modifié par andysks, 07 novembre 2013 - 08:21 .

[ColorsFade]

andysks wrote...

However, companions like Bishop, there is no other way to introduce. Force in to progress the main plot.
If I remember correctly, that was the case with him as well. You needed to go to the forest and he was gonna scout for you. After that, you were free to kick him out.

The OC does force a couple Companions into your party at specific points in the story (and this is when they use the SetIsRosterMemberCampaignNPC() function call, so that the roster member, once forced into your party, cannot be removed via the party management GUI). 

That said, I think it was a mistake to do it that way. Usually this all comes about as a result of a cut-scene dialog in the tavern, and then when you go to form your party after clicking on the door to leave, you see the one forced member in your party and they are greyed out - cannot be removed. 

I think it would have been better to change the dialog during these cut-scenes so that more than one companion presents the PC with the opportunity to do a perform a certain task. 

For instance, in the scene you're referencing, Bishop is supposed to track, yes. And so he's forced into your party until that quest step is updated. 

But really, that role could have gone to others.

A better option, IMO, would have been to have Elanie speak up as well, and say she could also track. Then the player has the option of who to take with them. Each companion then just needs appropriate dialog lines for when the quest is updated.

You could even have the dialog during the cut-scene be such that Bishop offers to impart his wisdom on the specific area to the other companions, because you don't know who you're going to take with you. 

Anyway.. As stated before, I'd always look for another way to deal with the situation if it calls for forcing a companion into the party. 

andysks wrote...
I already have made my preparations for all these occasions. Every time I want the companions to swoop in and say a line, I make a line for every possible companion, with the conditional script, and one extra for the NPC speaker, just in case someone plays hardcore solo. So, conversations shouldn't be a problem.

And that's a good way to do it. I think. 

andysks wrote...
Still, I think companions are a realy imporant part of these games, and the line between good system and bad is quite thin. If you have any more ideas or preferences about companions, please post .

I prefer companions, myself. I just don't want them forced. What I prefer, as a player, is a lot of choices, and the ability to swap companions in and out as I see fit. To that end, I like lots of companions, because it means lots of choices. 

What I don't like.. is being introduced to a new companion in a place where I am unlikely to want to swap them into the group and swap someone out. The original Baldur's Gate was famous for this, putting companions in the middle of nowhere. Yeah, sure, we're in the middle of the woods, and all my good thief gear is on Imoen, but sure, I'll kick her out and take you intead! Not... 

[andysks]

I know what you mean. All my companions are in places like cities and stuff, except the prologue because you don't have so many options yet, so the party cannot be full anyway.

Let me ask you something else that has been troubling me. Do you use something like Sunken Flagon, or BG2 style, that the companion goes back to where he wants and you have to pick him from there, if you ever want him again? Or do they not even despawn after leaving the party? I'm really interested in how other people handle this situation.

[Tchos]

andysks wrote...
Let me ask you something else that has been troubling me. Do you use something like Sunken Flagon, or BG2 style, that the companion goes back to where he wants and you have to pick him from there, if you ever want him again? Or do they not even despawn after leaving the party? I'm really interested in how other people handle this situation.

In mine, if you ask them to stay behind, or use the guest book, they stay where they are, as in BG2.

[andysks]

But do you still use the roster? You can add and remove companions whenever you want? Or is it only by approaching them and talking to them?

[Tchos]

In mine, if you access the party roster without using the tavern guestbook or conversation with the companion, they will simply disappear, until you add them back through party roster, either with the same method or using the tavern guestbook.  (The tavern guestbook includes access to the party roster UI, and they don't disappear if you do it through the book.)

Modifié par Tchos, 08 novembre 2013 - 01:27 .

[andysks]

Ah so you have both options. You can talk to them to ask them to leave, or do it through the roster. If you talk to them they stay put, through the roster they disappear. This is, if you remove one through a dialogue, does he come back to you if you add him with the party roster? Kinda like... saving you the way of going to the spot where you left him?

[ColorsFade]

andysks wrote...

Let me ask you something else that has been troubling me. Do you use something like Sunken Flagon, or BG2 style, that the companion goes back to where he wants and you have to pick him from there, if you ever want him again? Or do they not even despawn after leaving the party? I'm really interested in how other people handle this situation.

I just solidified my own plan for this today actually, so timely that you asked. 

This is a bit tricky, so I'll try and be specific. 

Short Version: I am going to have three areas that act as a "home base" a la the Sunken Flagon. The first one during the prologue, the second during Act1, and then during Act1 the player gets their "stronghold", and that becomes the the last "home base" of the game. 

Part 1: the Prologue

There are only four possible companions in the prologue, and only one inn, so that is "home base".

In my module load function, I have a method that automatically adds all companions to the roster. Each roster member gets passed to InitializeCompanion(), which takes care of adding them to the roster. 

To accept a companion into my group when I meet then requires a dialog action of ga_roster_party_add, which behind the scenes calls AddRosterMemberToParty(). If I decline a companion when I meet them, they each have a hangout waypoint at the inn. Hangout WP's can be set with ga_set_hangout, so I can specify a different hangout waypoint later on. This is critical, because I need to change the hangout spots for companions as the story progresses and we move to new home bases. 

You can then call ga_rm_go_to_hangout to cause the companion to go to the hangout. ga_rm_go_to_hangout actually calls GoToHangOutSpot() from ginc_companion. This is a good function to call. If the hangout is in the same area, GoToHangOutSpot() causes the companion to leave the party and walk to the hangout waypoint. If the hangout WP is not in the area (most cases) then it causes the companion to be leave the party and be despawned with DespawnRosterMember(), which saves the character out of the game (which is what we want). 

To make this work, I need a script on my OnClientEnter of the inn which loops through all my game companions and then calls SpawnNonPartyRosterMemberAtHangout(). This then happens every time the PC enters the inn, so it puts any non-party roster members in place. However, it's actually more complicated than that.

The OnClientEnter script actually calls a custom script of mine which does some checking to determine who to spawn and when. For instance, by checking the journal and knowing it's the Prologue, I know I only need to check for those first four companions. Other companions haven't been met yet, so they shouldn't get spawned here. And if it's later in the game (after Act1 has started) I know not to spawn any Companions in this first inn, because they will be spawned somewhere else, at the second home base. 

Which brings me to... 

Part 2: Scornubel

In Scornubel I'm going to use an inn there as the 2nd home base for a little while. As soon as Act 1 begins, a script function fires that causes the hangout waypoints for the first four companions to change to the new inn. The other companions, which haven't been met yet, don't have to worry about. 

Same scenario here. Same function calls, etc. Anyone who gets kicked out of the party gets despawned and saved out. If they get kicked out while in the inn, they walk to their hangout spot. When the PC enters the inn, each time, an OnClientEnter script fires to figure out which companions have been met, which are already in the party, and thus which ones are left to spawn at their hangout points. 

Part 3: Stronghold

The last "home base". The player gets access to their stronghold. From here on out, any companions rejected when we meet, or kicked out of the group, show up here. Same deal. OnClientEnter script does the checking and spawning of appropriate non-party group companions. When the stronghold is acquired, a script fires to change all companion hangout spots to the hangout spots on the stronghold. 

And that's my plan... 

[Tchos]

andysks wrote...
Ah so you have both options. You can talk to them to ask them to leave, or do it through the roster. If you talk to them they stay put, through the roster they disappear. This is, if you remove one through a dialogue, does he come back to you if you add him with the party roster? Kinda like... saving you the way of going to the spot where you left him?

That's right.  You can leave the companion in a cave somewhere if you want, or go to a different tavern than the one you left them at, and then use a tavern guestbook or party roster and they'll "come to you" from the other place (appearing next to you). I never did assign them any hangouts.

[andysks]

ColorsFade,
I cannot even begin to explain how complicated this sounds to me. I know you explained it as good as it gets, but there is a limit to my scripting knowledge .
Some basic stuff though confused me. If the companions are added to the roster OnModuleLoad style, can't I as a player open the roster screen from the menu and add them to my party?

I did something today, with my rogue companion, but I know it's wrong. Thing is, I am generally really bad at handling companions. Meaning their spawning and what not.
I had him a forced companion as I mentioned earlier, and today I changed it. I added a line to the PC, to tell him I don't need you now.
Then the rogue says "Right then, I will be in my room at the Inn if you change your mind".This is one of the very first companions, 3rd area only, so there's not much of a stronghold. So I made a simple ga_jump to his room. The first line happens once a game, and if you talk to him again he starts with "What can I do for you"? And PC has an option to say "I need you to join me".

Here's where I feel it is wrong.

The companion scripts I use are: ga_roster_add_object, ga_roster_party_add, ga_selectable(Ithink it's called like that), and ga_rest_level.
I put all these together on the last line of conversation.

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?

Many thoughts like that go in my head. Perhaps I should start by defining a system in my head, about how I actually want the companions to be handled. I need this to be good, because I have plans for a lot of them, at least one of each class. At least...

So, I decided eventually to not have forced companions. Whenever I need an NPC to play an important role in the game+being recruit-able, I will introduce a new one. I am glad I have many ideas for their stories, and plan to exploit my head on this one.
I don't know if roster menu is mandatory in NWN2, but if I had a choice I would think a lot before I choose this option. It juts is weird, that you can travel somewhere, and change party members like that..
I like the idea of a dialogue for everything. If you need me, come get me. If you don't, I'm Ok to wait at a familiar spot where you can find me again.

Many thoughts.

The comforting thing is, that as I think of all this, I keep on with my areas making some real progress, and writing some dialogues. One needs the feeling of success in between dilemmas .

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