Installer reports parse error, but I don't see it

[ericp07]

Why does weidu choke on this?

 

From EP#Mel.d

IF ~~ EP#MelJoined
 SAY ~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~ DO ~SG("EP#MelJoined","LOCALS",1) JoinParty()~ EXIT
END

 

The install error:

[Meleryn/dialogues/EP#Mel.d] PARSE ERROR at line 152 column 1-94
Near Text: DO
	syntax error

[Meleryn/dialogues/EP#Mel.d]  ERROR at line 152 column 1-94
Near Text: DO
	Parsing.Parse_error
ERROR: parsing [Meleryn/dialogues/EP#Mel.d]: Parsing.Parse_error
ERROR: compiling [Meleryn/dialogues/EP#Mel.d]!
Stopping installation because of error.

 

Any idea what's wrong, and how to fix?

 

Thanks!

Eric

[Wisp]

It is not a valid state because it lacks a complete transition.

[ericp07]

It is not a valid state because it lacks a complete transition.

 

EXIT is not a complete transition? Should I move that down a line, and write it as IF ~~ EXIT instead?

 

- E

[ericp07]

I've seen identically written code in other mods, and they work. Maybe there's just a modding curse on me

[cmorgan]

Just missing your kickoff of the transition; IF ~~ THEN

IF ~~ EP#MelJoined
 SAY ~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~
 IF ~~ THEN DO ~SG("EP#MelJoined","LOCALS",1) JoinParty()~ EXIT
END

 

This next is bad but happens - you probably saw something coded like this:

 

CHAIN ~yourdlgfile~ EP#MelJoined
~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~ DO ~SG("EP#MelJoined","LOCALS",1) JoinParty()~ EXIT

 

This last teh suxxor - bad abuse of chain as opposed to an "ok" abuse of chain like this:

 

CHAIN ~yourdlgfile~ EP#MelJoined
~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~ 
DO ~SG("EP#MelJoined","LOCALS",1)~
== yourdlgfile IF ~Gender(Player1,FEMALE) Class(Player1,MAGE_ALL)~ ~Lead on, oh mistress weaver of the Weave.~
== yourdlgfile IF ~Gender(Player1,MALE) Class(Player1,MAGE_ALL)~ ~Lead on, oh master weaver of the Weave.~
END
IF ~~ THEN DO ~JoinParty()~ EXIT

[ericp07]

OK, if the word THEN absolutely must appear in the line, in order to transition to what comes after DO, I'll make the change and see what happens.

 

Still learning the difference between using shortcuts (which I greatly favor, whenever possible) and omissions by mistake This is how I troubleshoot, running the installer and letting it go through till it chokes on something. Better than trusting my eyes!

 

Thanks,

Eric

[ericp07]

Still no joy; the installer still doesn't like the script block If it matters, I'm using weidu-mac v.227.

 

This portion of EP#Mel.d...

IF ~~ EP#MelJoined
 SAY ~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~
 IF ~~ THEN DO ~SG("EP#MelJoined","LOCALS",1) JoinParty()~ EXIT
END

 

...results in this, when I attempt to install the mod:

[action list near line 153, column 60 of Meleryn/dialogues/EP#Mel.d] PARSE WARNING at line 153 column 1-29
Near Text: )
	Too many arguments to [SG]. Recovering.

[Meleryn/dialogues/EP#Mel.d] PARSE ERROR at line 154 column 1-2
Near Text: IF
	syntax error

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

 

I can't move forward at all till this is solved, and it's driving me mad, because it looks like it should work, but clearly I'm still missing a vital detail. What is it?

 

Thanks,

Eric

[berelinde]

What happens when you try SetGlobal() instead of SG()? "Too many arguments" usually means that you have one too many parameters. SG() is almost exclusively used to set global variables.

 

SetGlobal("Whatever","GLOBAL",1) = SG("Whatever",1)

[ericp07]

What happens when you try SetGlobal() instead of SG()? "Too many arguments" usually means that you have one too many parameters. SG() is almost exclusively used to set global variables.

 

SetGlobal("Whatever","GLOBAL",1) = SG("Whatever",1)

 

Ooh, I was unaware of that (about SG being used only with GLOBAL variables, or that we could code it as "SG("Whatever",1)").

 

However...changing the code to this:

 

IF ~~ EP#MelJoined
 SAY ~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~ DO ~SetGlobal("EP#MelJoined","LOCALS",1) JoinParty()~ EXIT
END

 

results in this:

 

[Meleryn/dialogues/EP#Mel.d] PARSE ERROR at line 152 column 1-94
Near Text: DO
	syntax error

[Meleryn/dialogues/EP#Mel.d]  ERROR at line 152 column 1-94
Near Text: DO
	Parsing.Parse_error
ERROR: parsing [Meleryn/dialogues/EP#Mel.d]: Parsing.Parse_error
ERROR: compiling [Meleryn/dialogues/EP#Mel.d]!
Stopping installation because of error.

 

So, I've gone from a parse error to a syntax error *L* Still don't have the solution to this yet...and I'm looking several lines above and below line 152, but everything looks the way it should, to me.

 

What else can we try?

Thanks,

Eric

[Kulyok]

Each state that begins with

 

IF ~~ State

SAY ~~

 

should have EITHER replies (

++ ~Wonderful!~ + State2)

OR an "IF ~~ EXIT" line beneath. (And END in both cases). No exceptions.

 

In short,

 

Should I move that down a line, and write it as IF ~~ EXIT instead?

 

Yes.

[ericp07]

Each state that begins with

 

IF ~~ State

SAY ~~

 

should have EITHER replies (

++ ~Wonderful!~ + State2)

OR an "IF ~~ EXIT" line beneath. (And END in both cases). No exceptions.

 

In short,

 

Should I move that down a line, and write it as IF ~~ EXIT instead?

 

Yes.

 

Acknowledged. I'll look for any more instances where I need to set it this way, and do so...and keep up the habit going forward.

 

Thanks!

Eric

[cmorgan]

ericp07, my man...

 

IF ~~ EP#MelJoined
 SAY ~Excellent! Buion na 'ell! I serve with joy! I'm ready to move out whenever you are.~
 IF ~~ THEN DO ~SetGlobal("EP#MelJoined","LOCALS",1) JoinParty()~ EXIT
END

 

The whole thing that is going to get you going crazy is not the structure, it is the understanding. I know, I have been there, too. Smoketest and Grim Squeaker were extremely helpful when I started up. Here is the breakdown stated another way. Hopefully it will help.

 

the structure of a state does not vary from the following:

 

tell weidu to start the state

set up what the state owner is going to say

set up where the state is going to lead

exit the state either via exit or via goto or via extern

tell weidu to end the state

 

So, as a minimum, you are going to have a sandwich. IF ~~ statename will be the top slice of bread, END will the the bottom.

 

In the middle, you will always, always always without exception bar none can't happen will not parse if you don't have at least two lines*, one of which is the actual state and the second of which sets up a transition. The transition can be "do nothing and exit dialog", or it can be "do something and then exit dialog" , etc.

 

IF ~~ myState // tells weidu this is a new snippet, attached from somewhere else in the file

 

SAY ~text~ // sets up the string that has the text you want the speaker to say

 

// then you get to choose from one of the following, telling weidu where you want the state to lead; each one of these containns a 'transistion, whether it be EXIT or GOTO or EXTERN:

 

IF ~~ THEN EXIT // do nothing, lead nowhere, dump out of dialog

 

IF ~~ THEN DO ~something~ EXIT // set a variable, then do nothing, leave, quit dialog

 

(in this and the following entries, you can add in a "do" by putting it right before the transition, e.g. EXTERN/GOTO/EXIT, so just like this format from now on for any transition)

 

// just jump to another state, like splitting up sentences or paragraphs

IF ~~ THEN GOTO newstate

 

// allow PC to say something; taking it will go within the file to a new state

IF ~~ THEN REPLY ~text~ GOTO newstate

 

// shortcut for the same thing.

++ ~text~ + newstate

 

// allow PC to say something and then bring in a third party to talk; taking it will go within the file to a new state in another dialog file

IF ~~ THEN REPLY ~text~ EXTERN newfile newstate

 

// if the condition you set is met, show this line - taking it will lead to a new state within the file

IF ~condition~ THEN REPLY ~text~ GOTO newstate

 

// shortcut for the above

+ ~condition~ + ~text~ + newstate

 

// if the condition you set is met, show this line - taking it will lead to a new state in another dialog file

IF ~condition~ THEN REPLY ~text~ EXTERN newfile newstate

 

END //

 

* technically, these do not actually have to be on separate lines to be valid. I have some space-saving stuff like this in Aran:

IF ~~ c-aranstate SAY ~[ARAN] My, it is warm in here~ IF ~~ THEN DO ~condition~ EXIT END

 

but don't use this. It has all of the elements just run all into the same line. bad construction. real moddarz use indentation in their code so that they can scan the construct and check for errors, and actually see them.

[ericp07]

cmorgan, you are my hero!

 

I've copied your entire response for reference, as I know I'll need to look at it again...several times...

 

OK, so apparently I can't write IF ~~ EXIT, but instead I must write IF ~~ THEN EXIT. Is this correct, and an absolute rule?

 

Interestingly, I'm now getting errors in EP#Mel.d when I try to install the mod that exist *before* the portion that's been giving me all this grief. Makes no sense to me, but I'll keep trying to fix things as they come up. Meanwhile, I'll see if I can burn the concept of state structure into my mind, as I thought I had it down before, but clearly I didn't

 

Thanks very, very much!

Eric

[ericp07]

Why is it considered bad construction to load a bunch of stuff onto one line? That's a fundamental part of the problem for me, at this point: learning and remembering correct format. It's more helpful for me to gain a sense of how and why things work the way they do, too, rather than blindly trusting things. The theory side balances the practice side

 

- E

[cmorgan]

You can use IF ~~ EXIT (I may go back and change it in my stuff, since it becomes non-trivial when you add tons of stuff like I am).

 

Many mods use the following shortcuts that I don't; they work, but they need to be placed within the structure wisp, berelinde and Kulyok were all pointing to.

 

from Angelo, coded by Kulyok

IF ~~ tt10.1
SAY @1243
IF ~~ EXIT
END

 

from bg1npc's SharTeel romance, coded by Domi:

 

IF ~~ SHRO7.1
SAY @288 
+ ~CheckStatGT(Player1,14,CON)~ + @289 + SHRO7.5
+ ~CheckStatGT(Player1,14,CON)~ + @290 + SHRO7.5A
IF ~!CheckStatGT(Player1,14,CON)~ THEN DO ~ActionOverride(Player1,PlayDead(90))~ EXIT
END

IF ~~ SHRO7.2A
SAY @291 
IF ~~ GOTO SHRO7.2
END

 

from Faren, by Feuille and Miss Sakaki

IF ~~ BEGIN FHFarenBodhi2
SAY ~Think of your feelings for Faren. How terrible it would be if you were to be separated - and so soon after discovering how you felt...~
IF ~~ EXTERN FHFRNJ FHFarenBodhi3
END

 

The problem isn't that this stuff is wrong or doesn't work - it is that the original "long form" without shortcuts makes you think in terms of the structure when you aren't as conversant. SConrad has this posted somewhere - he had some great arguments about why writing things in CHAIN makes it hard to understand the structure because it does most of the work behind the scenes.

 

You can use any of the shortcuts you want. That isn't the syntax thing that is tripping you up. It is that a

 

SAY ~x~

 

is a state, separate, complete - an island unto itself. It needs a second thing added to it to be able to move on. Doing things like

 

SAY ~x~ DO ~y~ EXIT

 

*looks* like a logical construction, but it is like creating

 

engine+body+tires = car

 

when what you need is

BEGIN CAR
  BEGIN BODY
		ADD ENGINE
  END BODY
  ADD TIRE
  ADD TIRE
  ADD TIRE
  ADD TIRE
END CAR