Parse error prevents .tp2 installation

[berelinde]

Aha, CHAIN operates outside APPEND blocks. That said, you cannot initiate a dialogue file with a CHAIN.

 

You need BEGIN EP#MelB before you can call that file for anything, so unless you initiate all dialogue files in the first file you compile, you will need that at the top of her banter file.

 

This works.

 

BEGIN EP#MelB

//your commented lines

CHAIN
~blah blah~
== etc
EXIT

APPEND EP#MelB

//etc.

 

And this works

BEGIN EP#MelB

APPEND EP#MelB
//stuff
END

CHAIN 
~blah blah~
== ETC
EXIT

 

This does not work

BEGIN EP#MelB

APPEND EP#MelB

//commented stuff

CHAIN 
~blah blah~ 
==etc
EXIT

[ericp07]

Aha, CHAIN operates outside APPEND blocks. That said, you cannot initiate a dialogue file with a CHAIN.

 

You need BEGIN EP#MelB before you can call that file for anything, so unless you initiate all dialogue files in the first file you compile, you will need that at the top of her banter file.

 

This works.

 

BEGIN EP#MelB

//your commented lines

CHAIN
~blah blah~
== etc
EXIT

APPEND EP#MelB

//etc.

 

And this works

BEGIN EP#MelB

APPEND EP#MelB
//stuff
END

CHAIN 
~blah blah~
== ETC
EXIT

 

This does not work

BEGIN EP#MelB

APPEND EP#MelB

//commented stuff

CHAIN 
~blah blah~ 
==etc
EXIT

 

This is another case where I've copied examples from some on-line sources, trusting that they were written to be functional (no, I don't recall exactly where the source is). EP#Mel.d has BEGIN EP#MelB.d as one of the first instructions. I believe that file gets COMPILEd before EP#MelB.d. Thus, the file is already initialized. Based on the above examples, it looks to me like all I need to do is either move the APPEND down, so it appears after all the CHAINs (which doesn't make sense to me, but then again I'm not as clear about this as I'd like to be), or leave it where it is, at the top, and follow it with an END before any of the CHAINs (which also doesn't make sense to me). I'm obviously struggling with the whole CHAIN set-up. I know what it's for, I'm just having trouble following how it's supposed to be coded.

 

May I please have some further detail, or is it time to head back to the tutorials?

 

Thanks,

Eric

[berelinde]

You're right, either move the APPEND after the CHAIN or add an END before the CHAIN.

 

CHAIN doesn't need to be included in an APPEND because it's like it's own little APPEND block.

[ericp07]

You're right, either move the APPEND after the CHAIN or add an END before the CHAIN.

 

CHAIN doesn't need to be included in an APPEND because it's like it's own little APPEND block.

 

In that case, at this point, it makes more sense to me to move APPEND to the bottom (the other way just doesn't look right to me, but that's just me).

 

Thanks!

Eric

[cmorgan]

erocp07, as a heads up, several tutorials (including a bunch of Aran's stuff) assumes you have grabbed and read the starter tutorials, and unless it says something like 'final code' it may be in sketched code. Most of Aran's second or third drafts are true working code; just be careful to check first. Warning - if you copy and paset stuff from early in an Aran thread, it may also have missing tildes (~). If it is listed as "tested and installed" or has actual numbers (a123) then it should work fine.

 

berelinde has all the structures - if you want a set of working templates to build within, there are some in Aran's stuff. She already has that set up for you, but if you are having trouble you can copy, paste, and modify. The only hassle is making sure you understand what operates on what.

 

In the context of a .d file,

 

BEGIN = create a new dialog reference, blowing away an existing one if it is named the same

 

APPEND = add dialog to the already existing file

 

CHAIN = a self-contained shortcut designed to create a series of APPENDs that EXTERN between multiple existing .dlg files

 

SAY = speaker's text - must be followed by a transition and be within the framework of a state

 

STATE = self-contained structure that needs a start, speaker text, transition, and end

 

IF something THEN BEGIN newstate SAY ~speakertext~ IF ~~ THEN EXIT END

 

 

Berelinde's second example is the most commonly used one. BEGIN, then all the APPENDs, then all the CHAIN.

[ericp07]

erocp07, as a heads up, several tutorials (including a bunch of Aran's stuff) assumes you have grabbed and read the starter tutorials, and unless it says something like 'final code' it may be in sketched code. Most of Aran's second or third drafts are true working code; just be careful to check first. Warning - if you copy and paset stuff from early in an Aran thread, it may also have missing tildes (~). If it is listed as "tested and installed" or has actual numbers (a123) then it should work fine.

 

berelinde has all the structures - if you want a set of working templates to build within, there are some in Aran's stuff. She already has that set up for you, but if you are having trouble you can copy, paste, and modify. The only hassle is making sure you understand what operates on what.

 

In the context of a .d file,

 

BEGIN = create a new dialog reference, blowing away an existing one if it is named the same

 

APPEND = add dialog to the already existing file

 

CHAIN = a self-contained shortcut designed to create a series of APPENDs that EXTERN between multiple existing .dlg files

 

SAY = speaker's text - must be followed by a transition and be within the framework of a state

 

STATE = self-contained structure that needs a start, speaker text, transition, and end

 

IF something THEN BEGIN newstate SAY ~speakertext~ IF ~~ THEN EXIT END

 

 

Berelinde's second example is the most commonly used one. BEGIN, then all the APPENDs, then all the CHAIN.

 

I think I'm on board with these things, but sometimes I forget to go over copied code carefully. I did find and alter some of the coding in some of the Aran examples I borrowed. Maybe it's time to stop trying to install the mod, and just look over everything again more closely...

 

Thanks!!!

Eric

[berelinde]

Nah, you'll never find coding errors by looking at them. Trust me. You will only be able to find them by trying to install the mod with WeiDU 7000 times. It's true.

 

And while the tedious process of installing a mod for the first time does gradually become less tedious after a while, you will always have parse errors. I average about 3 hours getting a mod to install the first time.

[ericp07]

Nah, you'll never find coding errors by looking at them. Trust me. You will only be able to find them by trying to install the mod with WeiDU 7000 times. It's true.

 

And while the tedious process of installing a mod for the first time does gradually become less tedious after a while, you will always have parse errors. I average about 3 hours getting a mod to install the first time.

 

I thought I was making things more difficult for myself, as is my habit. Looks like the best way is indeed to keep installing, then knock down each error in turn, till they're all gone So be it, then; I'll trust WeiDU to spot what I can't.

 

Thanks,

Eric

[Ardanis]

Looks like the best way is indeed to keep installing, then knock down each error in turn, till they're all gone

Unfortunately, that's one and absolute truth. If anything, it's faster than checking your code over and over again, because you just can't spot that you've typed D0 instead of DO. Possible to sort it out manually on a single block, but when you've got dozens of those... better let WeiDU point out errors for you.

[ericp07]

Looks like the best way is indeed to keep installing, then knock down each error in turn, till they're all gone

Unfortunately, that's one and absolute truth. If anything, it's faster than checking your code over and over again, because you just can't spot that you've typed D0 instead of DO. Possible to sort it out manually on a single block, but when you've got dozens of those... better let WeiDU point out errors for you.

 

That's still reassuring to me, and makes perfect sense. Even better than having someone else look over the code, because one pair of eyes can spot only so much

 

Thanks to everyone for putting up with such a thick-skulled individual!

Happy holidays,

Eric

[cmorgan]

Definitely true on the use of the install as the troubleshooting - and then after install works, there is the exploration of decompiled files so you can catch the " installs but to the wrong file " problems!

 

My favorite is the mistypes or copy/paste DO DO errors!

[ericp07]

Two errors in one this time...

 

Weidu is complaining about this when install my mod:

 

[trigger list near line 505, column 33 of Meleryn/dialogue/EP#MelB.d] PARSE WARNING at line 510 column 1-25
Near Text: "MISC5X"
	syntax error
WARNING: cannot verify trigger ~InParty("EP#Mel")
Global("EP#MelJah3","LOCALS",0)
!AreaType(DUNGEON) 
CombatCounter(0)
!See([ENEMY])
HasItem("Jaheira""MISC5X")~: Parsing.Parse_error

[Meleryn/dialogue/EP#MelB.d] PARSE ERROR at line 2478 column 1-2
Near Text: IF
	syntax error

[Meleryn/dialogue/EP#MelB.d]  ERROR at line 2478 column 1-2
Near Text: IF
	Parsing.Parse_error
ERROR: parsing [Meleryn/dialogue/EP#MelB.d]: Parsing.Parse_error
ERROR: compiling [Meleryn/dialogue/EP#MelB.d]!
Stopping installation because of error.

 

Here's what the code looks like around line 505 of EP#MelB.d:

 

~InParty("EP#Mel")
Global("EP#MelJah3","LOCALS",0)
!AreaType(DUNGEON) 
CombatCounter(0)
!See([ENEMY])
HasItem("Jaheira""MISC5X")~ THEN ~EP#MelB~ EP#MelJah3
 ~Jaheira, I see by the pin you wear that you're a Harper.~
DO ~SetGlobal("EP#MelJah3","LOCALS",1)~
== ~BJAHEIR~ ~So, you recognize the symbol. What of it, Meleryn?~
== ~EP#MelB~ ~Well, you already have my service. I'd like to offer you my friendship as well.~
== ~BJAHEIR~ ~No harm in that, if you offer it sincerely, and not simply to be able to boast about it to your other friends.~

 

And around line 2478:

 

// Woundwort
IF
AreaType(OUTDOOR)
!AreaType(CITY)
!AreaType(FOREST)
Global("EP#MelWoundwort","GLOBAL",0)
THEN DO ~SetGlobal("EP#MelWoundwort","GLOBAL",1)~ BEGIN ~EP#MelWoundwort~

 

What's gone wrong in these sections? And, while I'm at it, I'll mention that this second part is one of several little exchanges that happen if Meleryn spots certain herbs growing in whatever area the party happens to be passing through, but I'd like to give a "percentage chance" of her doing so (and thus firing the dialogues), rather than having these dialogues fire whenever the party is in an area that meets the conditions.

 

Please adivse.

Thanks and happy holidays,

Eric

[Mike1072]

Two errors in one this time...

Sometimes multiple error reports can be resolved by fixing a single problem, so as a general rule of thumb, it's best to go about fixing the first error mentioned and reinstalling before getting too worried about any others.

 

HasItem("Jaheira""MISC5X")

Isn't the parse error here obvious? Here's a hint: look at any usage of HasItem anywhere. Check other mods, check IESDP, check a vanilla script. All of these resources will tell you two things: the error is caused by a missing comma, and the check is unlikely to work with the order of the two parameters swapped.

 

There's nothing wrong with making either of these mistakes, but there is something wrong if you haven't learned by now how to correct them on your own. Maybe asking for help will get you the right answer quicker (or maybe not), but if you spend the time to resolve these issues yourself, you'll be better equipped to handle similar issues in the future, and you'll save the community the effort of correcting the same mistakes over and over again. I can only speak for myself, but I'd much rather spend 2 hours teaching you how to fix your own problems than 2 minutes fixing them for you. If you need assistance interpreting the WeiDU docs or the IESDP, just let me know. With those skills mastered, you should have no problem correcting parse errors or figuring out where to start when you're thinking about doing something you've never tried before.

 

And around line 2478:

// Woundwort
IF
AreaType(OUTDOOR)
!AreaType(CITY)
!AreaType(FOREST)
Global("EP#MelWoundwort","GLOBAL",0)
THEN DO ~SetGlobal("EP#MelWoundwort","GLOBAL",1)~ BEGIN ~EP#MelWoundwort~

Here you are missing tildes around the string containing your conditions for the dialogue. However, that's probably not what WeiDU is choking on. Since it says it encountered a problem when it started to read the IF statement, that implies that there's something wrong in your dialogue before that IF statement.

[ericp07]

Two errors in one this time...

Sometimes multiple error reports can be resolved by fixing a single problem, so as a general rule of thumb, it's best to go about fixing the first error mentioned and reinstalling before getting too worried about any others.

 

HasItem("Jaheira""MISC5X")

Isn't the parse error here obvious? Here's a hint: look at any usage of HasItem anywhere. Check other mods, check IESDP, check a vanilla script. All of these resources will tell you two things: the error is caused by a missing comma, and the check is unlikely to work with the order of the two parameters swapped.

 

There's nothing wrong with making either of these mistakes, but there is something wrong if you haven't learned by now how to correct them on your own. Maybe asking for help will get you the right answer quicker (or maybe not), but if you spend the time to resolve these issues yourself, you'll be better equipped to handle similar issues in the future, and you'll save the community the effort of correcting the same mistakes over and over again. I can only speak for myself, but I'd much rather spend 2 hours teaching you how to fix your own problems than 2 minutes fixing them for you. If you need assistance interpreting the WeiDU docs or the IESDP, just let me know. With those skills mastered, you should have no problem correcting parse errors or figuring out where to start when you're thinking about doing something you've never tried before.

 

And around line 2478:

// Woundwort
IF
AreaType(OUTDOOR)
!AreaType(CITY)
!AreaType(FOREST)
Global("EP#MelWoundwort","GLOBAL",0)
THEN DO ~SetGlobal("EP#MelWoundwort","GLOBAL",1)~ BEGIN ~EP#MelWoundwort~

Here you are missing tildes around the string containing your conditions for the dialogue. However, that's probably not what WeiDU is choking on. Since it says it encountered a problem when it started to read the IF statement, that implies that there's something wrong in your dialogue before that IF statement.

 

This was the first time I encountered more than one error at the same time. Yes, not spotting the missing comma was my own fault, and yes, I'd much rather learn how to troubleshoot and solve problems than have anyone else do the work for me. My goal is to become as independent a modder as I can be in that respect, so I can bring other sorts of issues to the community. In the first bit of code, it said ("Jaheira","MISC5X","Jaheira"), which looked wrong to me, so I changed it, but I guess I wiped out the comma by accident). As for anything wrong in the dialogue before the IF statement, hmmm...I'll look at what's in the file before that part. I'll see how much progress I can make before bringing any more errors up here. I do look things up, and try to fix them myself, before coming to the forums, by the way. The learning curve is still a bit steep, though, at this point.

 

Thanks,

Eric

[berelinde]

And around line 2478:

 

CODE

// Woundwort

IF

AreaType(OUTDOOR)

!AreaType(CITY)

!AreaType(FOREST)

Global("EP#MelWoundwort","GLOBAL",0)

THEN DO ~SetGlobal("EP#MelWoundwort","GLOBAL",1)~ BEGIN ~EP#MelWoundwort~

WeiDU doesn't like it when you try to rearrange the order of a dialogue state. A dialogue state has three phases, the trigger section, the dialogue section, and the transition.

 

The trigger section contains the triggers for that state and the state label, in this case, the trigger section is this.

IF
AreaType(OUTDOOR)
!AreaType(CITY)
!AreaType(FOREST)
Global("EP#MelWoundwort","GLOBAL",0)~ BEGIN ~EP#MelWoundwort~

 

You don't give the dialogue section, but it will be the part that goes SAY ~blah blah blah~.

 

You don't give the transition(s), but the action HAS to go there. You cannot put actions in the trigger section, only in the transitions(s).

 

Keep in mind that since this dialogue state has conditions, it will function as either PID or random banter, depending on whether it's in the J file (in which case it would be PID) or in the B file (in which case it would be random banter). If it's random banter between Meleryn and another NPC, you will need checks to make sure the other NPC is in the party and available for dialogue. Without them, the game will crash.