Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: jastey
« on: August 19, 2015, 11:12:08 AM »

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.)
Posted by: Wisp
« on: August 17, 2015, 08:37:04 AM »

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!~
Posted by: tuldor88
« on: August 17, 2015, 07:02:04 AM »

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:
Quote
@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)
Posted by: Wisp
« on: August 16, 2015, 06:23:18 AM »

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.

Quote
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.
Posted by: Wisp
« on: May 06, 2015, 04:34:18 PM »

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.
Posted by: jastey
« on: May 06, 2015, 02:27:43 PM »

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.
Posted by: The Imp
« on: May 06, 2015, 03:45:01 AM »

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. :P 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.
Posted by: jastey
« on: May 03, 2015, 09:35:21 AM »

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.)
Posted by: jastey
« on: May 25, 2014, 12:38:34 PM »

Thank you!
Posted by: Wisp
« on: May 24, 2014, 04:46:49 PM »

Using weidu v236 the traifying of strings for male and female versions doubles the string number in the .d file.
Okay, fixed. Due to the extra work of ensuring a correct traification of varied input, --traify now also runs a bit slower (it's perhaps only be noticeable on very big files).
Posted by: jastey
« on: March 24, 2014, 05:12:43 PM »

Or maybe I am an idiot and the traify works although weidu gives all sorts of error messages. It just traified a neat .d/.tra pair after giving all sorts of parsing errors. I am confused.

EDIT: It didn't traify because of one OUTER_SPRINT variable (%tutu_var% in connection with a dlg name), whereas other OUTER_SPRINTS ("stand alone" like %IsGabberPlayer1% used as trigger) didn't lead to a stop. I guess it can be explained by the error tolerance of weidu ("do not stop because of non-identified trigger", for example?)
Posted by: jastey
« on: March 15, 2014, 10:09:21 AM »

I manage with replacing and re-replacing the OUTER_SPRINTs, but if you comeup with something, this would be great.
Posted by: Wisp
« on: March 09, 2014, 04:18:05 AM »

Having the D parser evaluate TP2 variables will not fly, sorry. I'll try to think of something, but I explicitly make no promises about whether something will materialise.
Posted by: jastey
« on: March 08, 2014, 03:38:18 PM »

Oh, cool! I installed the mod, replaced the % signs with "__" in the .d for traifying, and now traifying worked without complains.

Supercool! I can manage the replacing and back-replacing. So this seems to be working.

jastey - happy!
Posted by: jastey
« on: March 08, 2014, 02:48:33 PM »

There has to be a solution to the problem of "traifying a mod that is coded using the "Crossing the great Divide" approach aka OUTER_SPRINT variables". Please! PLEEEASE!

If I try to traify something like
Quote
EXTEND_BOTTOM %tutu_var%SCAR 14
+ ~!Alignment(Player1,19)
!Alignment(Player1,35)
!Alignment(Player1,51)
ReputationGT(Player1,11)~ + ~First, I would like to talk to you some more, Scar.~ + talking_battle
END
weidu chokes at the OUTER_SPRINT variable if I try to traify it. OK, it looks like syntax error, I can understand, so I replaced all "%" with "_PERCENTAGESIGN_". Leading to weidu still choking, at the use of "CD_STATE_NOTVALID" (not in the example) - why? This is not a syntax error, so weidu shouldn't care for traifying purpose. And next it complains that there exists no "_PERCENTAGESIGN_tutu_var_PERCENTAGESIGN_SCAR" dlg in the game. Why? It shouldn't care!
State is, it is impossible to traify a mod that uses OUTER_SPRINT variables, currently.

Would it be possible to let the traify process either use the libs of the mod I want to traify, or let it ignore dlg names and things the mod introduces if they are not (yet) installed?

I do not know how to solve this, without a lot of handwork. (I am talking about a mod with 35 components, btw.)

jastey - sad.  :'(