15 réponses à ce sujet

[andysks]

Hi all. I have a couple of weird situations here, and no idea why they occur.

 

1: A journal update doesn't complete on the journal, however xp and reward are all there.

 

2: A journal update is only recongnized by the player created PC but not by a companion.

 

Detailed

 

1: This was due to a change I did in the process of the quest. The journal used to complete at ID 21, then added an ID 31. It's like

NPC: Bring me some potion

Used to be: You loot the potion and it completes at 21

Now: You loot the potion it updates to 31 saying something like "You found the potion"

         You go back and it completes at 21 by the NPC.

 

However it will not get updated to the completed entries. Is this because it goes to an earlier ID? Or what? I only use the node option for updating journals and not ga_journal.

 

There is no potion by the way .

 

2: NPC: Go talk to that guy.

    We talk to him and update journal.

    We go back and check for gc_journal_entry.

    If we talk to the giver with a companion, he won't talk back. Meaning the conditional doesn't fire(?!)

    If we talk with the player created PC everything is smooth.

 

Thanks a lot.

[Tchos]

Well, I would first suspect that it won't update the journal because it's an earlier number, but I haven't been using the node setting for a long time, so I don't recall its behaviour.  Why not insert a quest stage between (presumably) 11 and 21?  That's the purpose of counting by tens -- so you can go back and insert things where they need to be.

 

As for the other, your NPC must be set to "Can speak to non-PC companions" or something like that.  It's in the properties, but to avoid having to set it on every NPC, you could just drop in Kaldor's default On Spawn script into the campaign folder to override the On Spawn script with one that sets that flag on every creature that uses the default On Spawn script.

[kevL]

1. Tchos has the best way. But if you absolutely need to override a higher entry, use ga_journal w/ bAllowOverrideHigher=1

(and face consequences if it's a complicated quest..)

[Dann-J]

Another thing to be wary about is tag case. The journal will update a quest regardless of whether the tag you pass is uppercase or lowercase, however if you change the tag case between conversation nodes you can end up with two journal entries for the same quest - one for the uppercase tag and another for the lowercase tag. It seems that some aspects of quest tag are case-sensitive, while others aren't (consistency would have been nice!).

 

In fact, you can end up with lots of duplicate journal entries for the same quest:

• Quest1
• quest1
• QUEST1
• QuEsT1, etc

[andysks]

I thought of doing Tchos' method . But I didn't want to start changing a lot of things and adding stuff. Now that I think about it, not going that way from the start caused way more confussion.

 

As for the Can speak to non player characters...

What if I have an NPC that HAS to talk to the created PC? My work is like the OC. Imagine going to Daeghon or how the uncle was called with Khelgar, and he says to him "Yes, a shard in your chest..." etc. It makes no sense. So some of my NPCs do not need this property.

 

Now, the node option. Does it update for the speaking PC? Can a companion speaking have a journal? And then when I talk with another companion or the created PC and want to check the journal it won't, but only if I speak with the one that got the quest? It cannot be like that... If it is like that I have some workload to do, going back to all my convos that are quest related and use ga_journal instead with the Update for all players in the party set to TRUE. Is this why you don't use the node option Tchos?

[kevL]

here's the lowdown for ga_journal (and sorry to say yeah you shoulda gone with it from the start)

string sCategoryTag = tag of quest
int nEntryID = ##
int bAllPartyMembers = TRUE for PC+Companions (not sure what this means, tbh)
int bAllPlayers = TRUE for all players(!) (but would that be controlled companion or... doh)
int bAllowOverrideHigher = see above.


It sounds like you should have a 'gc_isplayerchar' script. This way you could do dialog-nodes individually, eg:

NPC: "I need to talk to the guy with the shard in his chest."

[Tchos]

I believe a companion can have its own journal, yes.  There's a setting somewhere to keep all journals synced to the main PC -- maybe that's the one you were talking about.  There are several reasons I don't use the node option.  First because I've become used to looking for journal updates only in the Actions column of the conversation nodes, and not the Quest column.  Looking for it in two places can make me miss one.  Another reason is that I wrote my own journal update script that adds the additional code for my quest system, and also always checks the party leader for the journal information instead of the PC speaker.

 

Kaldor's scripts have a solution to the other issue (discussed here), where you sometimes want an NPC to speak only to the main PC.  With his setup, you just need to set a variable on the NPC to disable the "Can talk to..." setting.  However, I think that means that the NPC would simply not say anything at all to the companions.

 

I was about to suggest the alternative, but I saw kevL beat me to it.

[andysks]

Right. Well... what one can learn huh? Point is, I don't mind companions talking and taking quests. I even use SoZ dialogues. But it can get confussing. I guess the ga_journal with its bAllPartyMembers solves it and whoever talks gets the update for the whole party. That's for side quests. And this way one can forget about CanTalkToNonPlayerCharacter and have it on. Now as for some main quest convos where the PC shoud be the only one talking, I guess there is no workaround. He has to take the update with a warp... probably and also with a ga_journal same method. That way even if a companion tries to talk, the condition will check but the NPC will still talk to the PC only.

my brain feels like butter.

 

Edit: Question is, do I want to go back to all the places a quest is involved and do it via script ?

How do they actually do update the journal in the OC, and does the PC warp if I try to talk with a companion? I always lead with my PC so I don't know.

[kevL]

i don't think we should look to the OC as the way ahead here ...

 

[Tchos]

Definitely not.

[Lance Botelle]

string sCategoryTag = tag of quest
int nEntryID = ##
int bAllPartyMembers = TRUE for PC+Companions (not sure what this means, tbh)
int bAllPlayers = TRUE for all players(!) (but would that be controlled companion or... doh)
int bAllowOverrideHigher = see above.

Hi,

bAllPartyMembers and bAllPlayers allow differentiation between different parties on the same server. e.g. Two parties of PCs run by different players. The first updates the journal for every PC in the player's group, while the second would update the journal for all players on the server.

I found simply making the journal update for all party and players and override to be the safest passage with some other checks to make sure I definitely needed the update. That way, it did not matter what order I wrote the journal entries. I have at least one that goes backwards where I ran out of "room" on the nodes. It was simpler (and safer) than trying to track down all the place where the entry is updated and/or checked.

Cheers,
Lance.

[kevL]

that makes sense, Tks Lance.

 

so i don't suppose there actually is a "companion journal "

[Tchos]

There can be.  Since journal entries are just local variables on the PC, if you're consistent about applying updates in a manner that supports it, you could have a custom journal UI display different journals for different companions, or an item that does the same thing.

[kevL]

ah i get it: there's the journal itself ( .JRL )

 

and then what shows to the player depends on which entries (variables) have been set on a currently controlled character ....

[Tchos]

Right, I shouldn't have used the word "entries", since that implies that the text content of the journal is a variable on the PC, when in fact it's just what number to pull the text from in the .jrl file.