traify-ing question

[jastey]

Thank you!

[jastey]

Current status: v238 traify-ing chokes on %tutu_var% (used in combination with dlg or item names, for example) and also %(UN)SOLVED_JOURNAL% (used instead of (UN)SOLVED_JOURNAL, obciously).

It produces d/tra pairs for any kind of OUTER_SPRINTs used for triggers or transactions (with error messages, but they have no influence), like %ERASEJOURNALENTRY_xx%, Class(Player1,MAGE%_ALL%), ActionOverride("Ragefast",%STARTDIALOGNOSET%([PC])), %ISGABBERPLAYER1%, CreateCreature("c#lcba02",[3452.3736]%FACE_9%)

I guess there is nothing you can do to make traify not stopping for %tutu_var%? I can live with replacing the journal commands before and after traify-ing, but removing and adding the %tutu_var% has a high risk of introducing errors into the d by forgetting some instances (mass replace would be even worse. Maybe it's my way of naming my dialogue states and variables.)

[The Imp]

CreateCreature("c#lcba02",[3452.3736]%FACE_9%)

Errhm, is that a typo ? Of one "," ...
As there  needs to be a , before the %FACE_9% .... assuming you make it with some sort of logic that doesn't assign the comma and a value to the integer. So...
CreateCreature("c#lcba02",[3452.3736],%FACE_9%)

In this:
Class(Player1,MAGE%_ALL%) ... erhm, shouldn't it be either: Class(Player1,%MAGE_ALL%) or just Class(Player1,202) ... and the others might have similar things as well.

[jastey]

Those are OUTER_SPRINTs I defined for my BG1 mods: %FACE_9% is, indeed ",Face(9)" because the whole thing needs to be gone for vanilla BG1, and %_ALL% is "_ALL" for BGII engine but nothing for BG1, where no "MAGE_ALL" exists. Sorry for the confusion.

[Wisp]

This sounds familiar, but I can't remember what it was about. I'll try to have a look sometime soon-ish.
Please provide an example of D code which can't be traified.

[Wisp]

Current status: v238 traify-ing chokes on %tutu_var% (used in combination with dlg or item names, for example) and also %(UN)SOLVED_JOURNAL% (used instead of (UN)SOLVED_JOURNAL, obciously).

Variables can be used in dlg references like so

Code: [Select]

EXTERN ~%tutu_var%aldeth~
Not enclosing the string in delimiters is a syntax error because it is lexed as two strings.

I'm uncertain what you mean by item names. Using variables in item names in action and trigger lists falls under the case below. If you have an example of something I've overlooked, please provide it.

I don't think there's anything I can do about %SOLVED_JOURNAL% and the like. It would require a different parser and using variables in the syntactical backbone of the D structure introduces dicey problems.

It produces d/tra pairs for any kind of OUTER_SPRINTs used for triggers or transactions (with error messages, but they have no influence), like %ERASEJOURNALENTRY_xx%, Class(Player1,MAGE%_ALL%), ActionOverride("Ragefast",%STARTDIALOGNOSET%([PC])), %ISGABBERPLAYER1%, CreateCreature("c#lcba02",[3452.3736]%FACE_9%)

As you say, using variables in trigger and action lists produces warnings, but no fatal errors. The warnings can possibly be inhibited during traification. I'll have a look.

[tuldor88]

Hi, I have a small suggestion.
Now if we will use automatic traification then weidu assigns to every utterance sequential number @ whether there are more same utterance or not. For example - if we have such a file:

Code: [Select]

IF ~NumTimesTalkedTo(0)~ THEN BEGIN 1
SAY ~Hi!~
++~Hi~ + 2
++~Go Away!~ EXIT
END

IF ~~ THEN BEGIN 2
SAY ~It's late, I have to go, bye bye!~
IF ~~ THEN EXIT
END file.tra will look that:

@0 = ~Hi~
@1 = ~Hi~
@2 = ~Go Away!~
@3 = ~It's late, I have to go, bye bye!~

As you can see weidu added to the dialog.tlk two new string while one will by enough.
Of course if we have a small file as in the example we can improve it by hand ... but if the file contains ~1k@ (my biggest file have 3k@) it will be a very 'annoying'.
Will it be feasible to fix it?
(weidu 238)

[Wisp]

WeiDU already performs this optimisation. The reason you aren't seeing it in your example is that one hi has an exclamation mark and the other does not.
This untraified D

Code: [Select]

IF ~NumTimesTalkedTo(0)~ THEN BEGIN 1
SAY ~Hi!~
++~Hi~ + 2
++ ~Hi!~ + 2
++~Go Away!~ EXIT
END

IF ~~ THEN BEGIN 2
SAY ~It's late, I have to go, bye bye!~
IF ~~ THEN EXIT
END
produces this traified D

Code: [Select]

IF ~NumTimesTalkedTo(0)~ THEN BEGIN 1
SAY @0
++@1 + 2
++ @0 + 2
++@2 EXIT
END

IF ~~ THEN BEGIN 2
SAY @3
IF ~~ THEN EXIT
END
and this TRA content

Code: [Select]

@0    = ~Hi!~
@1    = ~Hi~
@2    = ~Go Away!~
@3    = ~It's late, I have to go, bye bye!~


[jastey]

tuldor88: What Wisp said: If the text is 100% the same, there will be only one tra-line be produced and re-used. If you find "similar" lines after traification, have a very close look, especially concerning punctuation, because there will be differences.

Variables can be used in dlg references like so

Code: [Select]

EXTERN ~%tutu_var%aldeth~
Not enclosing the string in delimiters is a syntax error because it is lexed as two strings.

Very cool, thank you. If I traify next time, I'll look out for what I meant with "in item names". (I don't mind error messages, as long as the d/tra pair is created.)