149 replies to this topic

[Azkyroth]

It's a little hard to determine character quests without really fleshing out your character and their background first. I do not like character-specific quests in general unless they add to and develop the character-some mod npc's have pointless quests that do nothing but give that character a moment in the spotlight and get the party some loot and experience, and others have more personal quests that add to and shape the character in question. For example, Xan's quest with Elhan in SoA is a good example of the former-there's really no point to it in terms of character development. Adding another layer to the siege of Suldanessellar is good, but there's really no grounds for it being a Xan quest, as it adds little to nothing to Xan's character and what the player knows/thinks/feels about him. A good example of the latter type of personal quest would be Sarah's quest, which doesn't really have any gameplay point, but resolves some important issues in Sarah's past and really helps shape her as a character. Or for non-mod examples, Nalia's quest string is an example of the former, and Jan is an outstanding example of the latter (much as I might hate all the to-ing and fro-ing of Jan's quest).

I would write a character quest if and only if it serves a purpose in developing Emmeline as a character, and if you do decide a quest is in order, think of it from a character development standpoint first. Everything else, a player can alter as they choose with the console and Shadowkeeper.

It occurs to me that another viable approach is to set up a quest so that it initially stems from the NPC's being in the party but rapidly ceases to be a quest specifically for that NPC (I'm more or less doing this with Arkalian and a couple of her major quests; she doesn't actually need to be in the party to complete them after a certain point, though they lose quite a bit without her).

[Choo Choo]

That's also a good way to put it in, Azkyroth - for now, though, only two quests are even planned, and I might end up ditching the second one. The first one, however, is the reason she joins the party in BG1.

As for her romance restrictions, I've ultimately decided that she won't romance halflings or gnomes in BG1. She's simply too immature, and she won't feel drawn to them at all.

BG2, however, is a different matter.. ok ok ok, I won't, I won't! Focus on BG1 now, yes, focus on BG1..

[Choo Choo]

I am none too pleased to announce that WeiDu hates me.

Le sob. *sigh*

Edited by Choo Choo, 19 October 2007 - 03:09 AM.

[berelinde]

Don't get discouraged. It hates everyone at first, and takes a while to get to know you. Once you start speaking its language, though, you'll find that you can get along just fine!

[Choo Choo]

*sigh* I know, but patience was never one of my virtues. Oh well, I'm learning, slowly. Not particularly steady, but oh well.

Hm, by the way, why does WeiDu dislike this?

CHAIN IF
WEIGHT #1
~
InParty("CCEmme")
!StateCheck("CCEmme",CD_STATE_NOTVALID)
!StateCheck(Player1,CD_STATE_NOTVALID)
Range(Player1,30)
CombatCounter(0)
!See([ENEMY])
!Race(Player1,Dwarf)
~
THEN CCEmmeInit01
SAY ~So, <CHARNAME>... Who are you?~


Oh, and for clarification - It's the "SAY" WeiDu doesn't like.

EDIT: Okay, removed the SAY which seemed fine with WeiDu, but now it complains about ++ and + instead.. And when I try exchanging it with IF ~~ THEN REPLY and GOTO, that won't work, either.

Edited by Choo Choo, 19 October 2007 - 03:29 AM.

[Miss Sakaki]

Just get rid of the SAY. When you have a block starting IF ~~ THEN BEGIN BlockName you need SAY, but not when it's CHAIN.

edit: just saw your edit!

At the end of the CHAIN you need to have an END, like so:

~So, <CHARNAME>... Who are you?~
END
++ ~Blah.~ + SecondBlock
++ ~Blah2.~ + ThirdBlock

Edited by Miss Sakaki, 19 October 2007 - 03:37 AM.

[Choo Choo]

Thank you. I'm going to write down every little itty-bit of advice people give me about coding. It's going to save my life.

Edited by Choo Choo, 19 October 2007 - 03:36 AM.

[berelinde]

*sigh* I know, but patience was never one of my virtues. Oh well, I'm learning, slowly. Not particularly steady, but oh well.

Hm, by the way, why does WeiDu dislike this?

CHAIN IF
WEIGHT #1
~
InParty("CCEmme")
!StateCheck("CCEmme",CD_STATE_NOTVALID)
!StateCheck(Player1,CD_STATE_NOTVALID)
Range(Player1,30)
CombatCounter(0)
!See([ENEMY])
!Race(Player1,Dwarf)
~
THEN CCEmmeInit01
SAY ~So, <CHARNAME>... Who are you?~


Oh, and for clarification - It's the "SAY" WeiDu doesn't like.

It's because you haven't specified a dialogue file before the state label. In it's unscripted banter incarnarnation, CHAIN acts like this

CHAIN
IF ~InParty(Myself)
!StateCheck(Myself,CD_STATE_NOTVALID)
!StateCheck(Player1,CD_STATE_NOTVALID)
See(Player1)
CombatCounter(0)
!See([ENEMY])
!Race(Player1,Dwarf)
~
THEN BCCemme CCEmmeInit01
~So, <CHARNAME>... Who are you?~

I prefer to use Myself rather than the DV of the first speaker, because it prevents me from accidentally running a check on the wrong person. Not a big deal here, but it can be for unscripted banter between two party-joinable NPCs. I also prefer See(Player1) to Range(Player1,30), because I've found Range() to be a bit flaky. If I want the banter to happen only when within sight distance, then I want it to happen when Player1 is visible, too. If I just want it to happen when they're in the same area, I'll use InMyArea(Player1). You're also going to need a check variable to prevent this from repeating.

Also, you don't use SAY with CHAIN!

If you're writing nothing but unscripted banter in this file, you don't need state weights. If you're planning on putting scripted banter in here, too, you're going to either have to put the scripted banter first in the order, or include state weights.

CHAIN
IF ~InParty(Myself)
!StateCheck(Myself,CD_STATE_NOTVALID)
!StateCheck(Player1,CD_STATE_NOTVALID)
See(Player1)
CombatCounter(0)
!See([ENEMY])
!Race(Player1,Dwarf)
Global("CCPCTalk1","LOCALS",0) //you could use a GLOBAL here instead, if you plan to refer to it again
~
THEN BCCemme CCEmmeInit01
~So, <CHARNAME>... Who are you?~
DO SetGlobal("CCPCTalk1","LOCALS",1)

[Choo Choo]

Ooookay. It *is* scripted, though, so it's going into CCEmmeJ. But I think I get it, now. Thank you very much!

[berelinde]

If it is scripted, that's a different kettle of fish. You want to keep that as simple as possible, and keep all the conditions in the script, not the D.

You can look here for a thorough discussion on dialogue scripting, or here at Rastor's Romance Authoring tutorial for some pointers.

To use the J file for scripted banters, just substitute StartDialogueNoSet(Player1) for Interact(Player1). I prefer to use the J-file for scripted banters myself, to keep the scripted banters and the unscripted ones separate, but there are others that thow it all in the B.

Good luck, and keep us posted!

Edited by berelinde, 19 October 2007 - 03:53 AM.

[Choo Choo]

Alright. Thanks!

[Choo Choo]

*sigh* And now WeiDu complains at something else - something which compiled just fine in another d file! I'm talking about ++/+

++ ~I suppose it'll take quite a while to respond, but here's the basics - my name's <CHARNAME>, as you know, and I was raised in Candlekeep by my foster father Gorion. I hit the road rather recently and I've survived so far.~ DO ~IncrementGlobal("CCEmmeInitTalk","GLOBAL",1) RealSetGlobalTimer("CCEmmePCTimer","GLOBAL",3200)~ + CCEmmeInit01NameCandle

WeiDu says "Parse error at line 16, col 1-1" but the ++/+ worked just fine earlier.

[berelinde]

The first + means IF, the second + means THEN REPLY, and the third + means GOTO. If you're using CHAIN structure, GOTO is tricky. You're better off using EXTERN FILENAME state than GOTO state. You have to spell out EXTERN.

Edit: also, when you are using CHAIN, you need an END between the NPC line and the PC responses, because you are leaving CHAIN mode.

Edited by berelinde, 19 October 2007 - 05:07 AM.

[Choo Choo]

THANK YOU! Thank you thank you thank you! I am THIS close to declare my unyielding love for you.

[Choo Choo]

Nevermind, solved it.

Edited by Choo Choo, 19 October 2007 - 05:34 AM.

[Tempest]

Poor Berelinde. Is everyone using you as their personal proofreader these days?

[Choo Choo]

Mmmph, seems like it. I'm trying to not be such a bother (and failing miserably), but I just feel like screaming "Where is my TESCS?!" each time I try to dabble in WeiDu stuff. ._. Oh well, I'll learn with time, I suppose.

[Choo Choo]

Lop one head off and five other appear..

Now, the parsing errors are out of the way, but now WeiDu goes on about empty tokens and unverified actions and that resource CCEmmeJ isn't found for chain3 and resource not found in chitin.key and.. *sigh* I need a short break, methinks.

Edited by Choo Choo, 19 October 2007 - 06:57 AM.

[berelinde]

(shrugs) It's what I signed up for. If I can answer it, I will. If I can't, then maybe I can point you toward someone who can.

Unverifiable actions are missing quotation marks 99% of the time. It's usually something like DO ~SetGlobal("CCMetBassilus,"GLOBAL",1), which, in case you're wondering, is missing a closing quote after Bassilus.

CHAIN3 errors are usually because you aren't beginning your file before you start adding to it. You can do this by putting the following at the beginning of the first dialogue file to compile, usually the pre-joining dialogue:

BEGIN CCEmme /* prejoin */
BEGIN CCEmmeJ /* joined dialogue */
BEGIN BCCEmme /* banter */
BEGIN CCEmmeP /*Post */

After that, you can just carry on with your dialogue file.

Keep in mind, though, that you should only begin your files once! If you begin it again, after you've already compiled some dialogue, you'll start over, wiping out anything that was there already!

I know I've seen "empty token" error messages before... trying to remember where. Maybe it will come back to me later, or maybe somebody else remembers.

CHITIN.key error messages are often a case of spelling the name of a resource wrong. For example, calling it _arrow1 instead of _arow01. Since you're modding Tutu, it's going to be a little different, naturally. Most of the time, it's just an underscore added to the front of the BG (or BG2) resource name, but there are exceptions. For example, the dialogue file for Durlyle is durlyle1.dlg in vanilla BG, durlyle1.dlg in BGT, and _urlyle1.dlg in Tutu. NI is your friend!

[Choo Choo]

I'll read through the entire dialogue (and write up that silly script of hers ) as soon as I've 1. Gotten rid of this headache, 2. Eaten something, 3. Convinced my mom to stop prodding me about homework.

Thank you!