Weird OUTER_SPRINT translation in the game - creates Str-Ref. and put in the number?

[jastey]

I have the following problem: In my mod's tp2, I have

 

ALWAYS

OUTER_SPRINT "SOLAUFEINTIMER" "1800"
OUTER_SPRINT "SOLAUFEINTIMERTOB" "900"

END

and I use it in my baf file with

 

RealSetGlobalTimer("C#SolauDialogTimer","GLOBAL",%SOLAUFEINTIMER%)

and

 

RealSetGlobalTimer("C#SolauDialogTimer","GLOBAL",%SOLAUFEINTIMERTOB%)

in the tp2 I do "COMPILE EVALUATED_BUFFER". The variable name is only used once.

 

But installed in the game, this translates to

 

 

RealSetGlobalTimer("C#SolauDialogTimer","GLOBAL",90573)

and

 

RealSetGlobalTimer("C#SolauDialogTimer","GLOBAL",90350)

because what happened, is that it created a StringRef "SOLAUFEINTIMER" and then puts in the StringRef number!! Which makes, like - no sense?

 

I use the exact same way for the ToB-romance timer of my Ajantis mod, too, and it works fine there - as do all OUTER_SPRINT variables I use for my other mods.

 

I guess it's something really obvious but I don't see where the error is... please help!

[CrevsDaak]

Use OUTER_SET (it has the same syntax), since they are numeric variables

[jastey]

OK, I didn't know this was important,

 

..Still inserts the Str.-Ref. number. I changed it to

 

ALWAYS

OUTER_SET SOLAUFEIN_TIMER = 1800
OUTER_SET SOLAUFEIN_TIMERTOB = 900

END

 

(Changed the names in the baf-file, too).

 

I definitely need a second pair of eyes. EDIT: OK, now it's working. Seemed to have been late-night weirdness. Thank you!

[Wisp]

SET vs. SPRINT is not important (in this case). It's a variable either way. This is the behaviour you get without EVAL (because % moonlights as a string delimiter). You wrote you used EVALUATED_BUFFER (it's EVALUATE_BUFFER), but that should have lead to a parse error, so I guess you mistyped?

[jastey]

That's been it! No, there is no parse error, I just checked. Using "COMPILE EVALUATED_BUFFER" leads to no parse error, but the variable is added to the dialog.tlk and the Str.Ref. number is filled into the variable instead.

 

Indeed, I deleted the (misspelled) E_B this morning and then put it (correctly) in again, that's why it "didn't work" yestereve but today. Sharp eyes! Thank you! (And maybe you could have a look why WeiDu doesn't give a parse error? I am not using the MODDER mode, I have to admit.)

[Wisp]

(And maybe you could have a look why WeiDu doesn't give a parse error? I am not using the MODDER mode, I have to admit.)

Well, naturally, WeiDU tries to compile EVALUATED_BUFFER as a file. Because why not? I can only recommend to get into the habit of using the shorthand EVAL instead, as it is harder to mistype.

[Mike1072]

I can only recommend to get into the habit of using the shorthand EVAL instead, as it is harder to mistype.

Syntax highlighting helps a lot here too.

[jastey]

*hangs head in shame* Yes, and yes But still weidu didn't give a sytax error.

[Wisp]

But still weidu didn't give a sytax error.

I'm sorry If I wasn't clear. What I meant was that I can't make this result in a parse error, because the syntax is ambigous that way. The best I can offer is advice to minimise the risk of mistakes.

[jastey]

But if it expected a file, wouldn't it give a parse error if the file didn't exist? I admit I am not deep enough into the syntax to see why there is no syntax error. You don't have to explain it, though, I'll take your word for granted.

[Mike1072]

Parsing is the step that analyzes text to verify that it conforms to the expected structure of the language.

 

Your code was syntactically correct (with EVALUATED_BUFFER presumed to be a file to be compiled), so no parsing error is to be expected.

 

However, you would expect WeiDU would produce an error when installing the component on a system where there is no file or folder named EVALUATED_BUFFER. Strangely, it seems to chug along fine even when it can't find anything to compile.

[Wisp]

But if it expected a file, wouldn't it give a parse error if the file didn't exist? I admit I am not deep enough into the syntax to see why there is no syntax error. You don't have to explain it, though, I'll take your word for granted.

Addressing the broader point of why isn't there an error, it's because COMPILE does nothing with files of types other than D and BAF unless there are patches. EVALUATED_BUFFER passes because there were no patches and it's not a recognised file type, so COMPILE does not try to do anything with it. I can't change this or badly coded mods will start crashing like Gripen air planes.

[jastey]

Ah! Thank you both, that made it clear.