Pocket Plane Group

Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: jastey on July 06, 2007, 09:26:50 AM

Title: traify-ing question
Post by: jastey on July 06, 2007, 09:26:50 AM
I added more lines to a .tp2 that was already in .tra-version. If I traify it now, the remaining (newly added) lines will be listed starting at "@0". The resulting tp2 has two states @0 now, of course, etc. (WeiDU v. 199)

It would be nice if the traifying procedure would recognise the tra-version and start counting from the highest number. Would this be possible?
Title: Re: traify-ing question
Post by: the bigg on July 06, 2007, 09:34:07 AM
Code: [Select]
weidu --traify something.d --traify# (X+1) --out foowhere X is the highest @reference file in the older .tra file.

I will look into automating the process.
Title: Re: traify-ing question
Post by: jastey on July 06, 2007, 09:37:56 AM
What you posted is already available? Jastey, RTFM. :(

Automating would be cool of course.
Title: Re: traify-ing question
Post by: cmorgan on July 06, 2007, 10:28:36 AM
If it is just a few lines, I even like to add them manually - no sense re -traifying if you just need to add 5 or 6 things on. The TRA entry numbers do not have to be in any order at all, as proven by my hashing around on The BG1 NPC Project...
Title: Re: traify-ing question
Post by: Kulyok on July 06, 2007, 10:52:13 AM
I usually do it bigg's way(without foo folder - just dump it into dlg one), and, yes, so far it worked perfectly with Xan.

By the way, while we're talking about automating stuff here - we'll probably need to traify RE files just before the release - is there a mass traify command for the whole folder(meaning WeiDU/BiggDU will look entire RE folder, with all its subdirs, and traifies all .d files it finds, somehow)?
Title: Re: traify-ing question
Post by: cmorgan on July 06, 2007, 11:30:18 AM
Searchiong - yes there is - i just need to find it. the bigg posted it for Domi and again for me when we attempted to deal with The BG1 NPC project. I'll be right back with the link/code.

Quote
Just use the mass-converter for all the files using the batch code algorythm:

FOR %A IN (mymod\d\*.d) DO WeiDU --traify %A --out mymod\tra\%~nxA

 it will automatically create multiple TRAs; just make sure that there are no files with the same names in the different folders, because trhey will all go in the same TRA folder.

There is more - for some reason I can't remember I needed to add a % to make it %%A, or something - the bigg helped with that, too. I am searching the archives...


there.

In Fiile BG1NPCTRAIFY.BAT
[bat]
FOR %%A IN (BG1NPC\Phase1\DLG\*.D) DO WeiDU --traify %%A --out BG1NPC\TEMP\%%~nxA
FOR %%A IN (BG1NPC\Phase2\*.D) DO WeiDU --traify %%A --out BG1NPC\TEMP\%%~nxA
FOR %%A IN (BG1NPC\Phase3\*.D) DO WeiDU --traify %%A --out BG1NPC\TEMP\%%~nxA
[/bat]

I think the %% was for Win98. You may have to ajust for WinXP to use just the one %.

Title: Re: traify-ing question
Post by: Kulyok on July 06, 2007, 11:41:42 AM
Oh. That's surely scary for me, but that's also surely useful. I'll try this one, thank you very much. Not yet, though.
Title: Re: traify-ing question
Post by: the bigg on July 06, 2007, 12:32:21 PM
the %% vs. % is for...


















wait for it...
































SPOILER
































Windows requires a double %% in *.bat files, and a single % when doing so from the Dos Prompt. Talk about consistent design.
(and yes, I should shut up since we have some similar in congruences in WeiDU, and some are my fault. That's what happen when programs grow non-destructively according to user requests, rather than according to a plan)
Title: Re: traify-ing question
Post by: jastey on July 10, 2007, 04:21:37 PM
Code: [Select]
weidu --traify something.d --traify# (X+1) --out foo

If I do that WeiDU has suddenly a problem with "AddJournalEntry" (WeiDU version 199, BG1 + TotSC), although first traifying, installation of the mod and playing in game made no problems.

The error message is:

unable to resolve Translation string @63
WARNING: cannot varify action ~AddJournalEntry(@63)
ActionOverride("C#Q05002",EscapeArea()) ActionOverride("C#Q05003",EscapeArea())
ActionOverride("C#Q05004",EscapeArea()) ActionOverride("C#Q05005",EscapeArea())~
: Parsing.Parse_error

(Is there a more efficient way to get the text out of the command window than copy by typing?)
Title: Re: traify-ing question
Post by: the bigg on July 14, 2007, 05:17:53 AM
If I do that WeiDU has suddenly a problem with "AddJournalEntry" (WeiDU version 199, BG1 + TotSC), although first traifying, installation of the mod and playing in game made no problems.

The error message is:

unable to resolve Translation string @63
WARNING: cannot varify action ~AddJournalEntry(@63)
ActionOverride("C#Q05002",EscapeArea()) ActionOverride("C#Q05003",EscapeArea())
ActionOverride("C#Q05004",EscapeArea()) ActionOverride("C#Q05005",EscapeArea())~
: Parsing.Parse_error
Some stupidity with action strings. Will check this out.

Quote
(Is there a more efficient way to get the text out of the command window than copy by typing?)
In the standard windows prompt, you can activate select and copy via some menu or some other.
Title: Re: traify-ing question
Post by: jastey on August 05, 2007, 07:11:19 AM
Was there a possibility to combine a .d-.tra-combo to a hard-coded .d again? I checked the readme but couldn't find anything. There was a thread about it somewhere, but I don't recall what came out of it in the end. (I would have a use for it.)
Title: Re: traify-ing question
Post by: berelinde on August 05, 2007, 10:17:54 AM
unable to resolve Translation string @63
WARNING: cannot varify action ~AddJournalEntry(@63)
Could it be looking for the AddJournalEntry(@63,QUEST)?
Title: Re: traify-ing question
Post by: jastey on August 22, 2007, 01:36:58 AM
I didn't see your reply.
Now that you say it, it could be that. Thing is, that installation and playing of the mod worked fine (and the journal entry was set).
Title: Re: traify-ing question
Post by: cmorgan on August 22, 2007, 08:58:10 AM
weidu --untraify-d MyMod.d --untraify-tra MyModTra.tra

(I think that is all you need)

I would move them to the game directory and rename them so you have the originals as backup.

On WinXP, anyways, you then need to go and look at the resulting .d in a good txt editor. Due to diferences in newline behavior (I think), there may be little "boxes" at the end of lines. Use the text editor mass replace 'box" to a blank space to delete them all.

This results in a hardcoded .d that will be able to install perfectly and can be re-traified when you are through.
Title: Re: traify-ing question
Post by: Kulyok on August 26, 2007, 03:50:49 AM
Quote
FOR %%A IN (BG1NPC\Phase1\DLG\*.D) DO WeiDU --traify %%A --out BG1NPC\TEMP\%%~nxA

- I am happy to say that this stuff worked for RE, but only for one directory - I had to dump all .d files into one directory to have them traified, and then I had to manually copy them back where they belonged.

Perhaps it is possible to search inside subfolders(two or three layers, or more), as well?
Title: Re: traify-ing question
Post by: the bigg on August 26, 2007, 06:55:12 AM
There's an ugly workaround to do that. Generally, it is easier to install CygWIN (http://www.cygwin.com) and use `find' for that purpose.

Code: [Select]
#!/bin/bash

for dfile in `find re -iname '*.d'`; do
  trafile=re/languages/english/`basename ${dfile%.d}.tra`
  weidu --traify $dmasterfile --out tmp
  mv tmp.d $dfile
  mv tmp.tra $trafile
done

EDIT: I didn't respect your folder structure, so YMMV.
Title: Re: traify-ing question
Post by: Kulyok on August 26, 2007, 07:47:28 AM
But that's cool! Please, please, post this thing as a tutorial - it should be extremely useful for big projects.
Title: Re: traify-ing question
Post by: the bigg on August 26, 2007, 09:25:37 AM
I would, but the really difficult part is to teach people enough Unix to be able to cd to their work directory, set it up as a script file (along with automatic build making), etc.

Which I don't have the patience to do correctly  :(
Title: Re: traify-ing question
Post by: cmorgan on August 26, 2007, 11:08:11 AM
I am not confident enough in my skills to do these as a mass destructive operation, so I simply expanded my .bat file with the bigg's original code like this:

[bat]
FOR %%A IN (MyMod\Component1\DLG\*.D) DO WeiDU --traify %%A --out TEMP\Component1\DLG\%%~nxA
FOR %%A IN (MyMod\Component2\DLG\*.D) DO WeiDU --traify %%A --out TEMP\Component2\DLG\%%~nxA
FOR %%A IN (MyMod\Component3\DLG\*.D) DO WeiDU --traify %%A --out TEMP\Component3\DLG\%%~nxA
FOR %%A IN (MyMod\Component4\DLG\*.D) DO WeiDU --traify %%A --out TEMP\Component4\DLG\%%~nxA
[/bat]

and then manually moved the .tra files and swapped in the new subdirectories under TEMP to replace the old directories under MyMod. I guess I could also have done something with copying and moving within the .bat, too, but frankly I prefer to keep changes separate until I have manually inspected them to make sure I didn't mess something up! Especially as I don't know what happens when WieDu is working with a file and you try to write a new file with the same name in the same place...
Title: Re: traify-ing question
Post by: cmorgan on August 30, 2007, 01:10:46 PM
EDIT\ never mind. Found the typo. Only took an hour or so...
Title: Re: traify-ing question
Post by: jastey on September 29, 2007, 01:28:52 PM
weidu --untraify-d MyMod.d --untraify-tra MyModTra.tra
This doesn't really work for me.
First thing: all non-common letters (ä, ö, ü, ß) are not transferred, although this might be a problem of the tra-file.
Second: If I edit the new created .d, and make it small / open another window in front / close it (but not necessarily), meaning: don't look at it for a moment, the formatting is completely lost. I think the line breaks are missing, although at first glance, i.e. as long as I don't edit the file, the formatting is visually there.
This looks like this:

Quote
BEGIN ~DKGUENJ~IF ~True()~ THEN BEGIN HalloGuen1  SAY ~*GROAAARRRRRRR*~  IF ~~ THEN REPLY ~Folge mir und greife keine Feinde an!~ DO ~SetGlobal("DKBewegungGuen","GLOBAL",0) SetGlobal("DKAngriffGuenMagier","GLOBAL",0)~ EXIT  IF ~~ THEN REPLY ~Greife ohne Rcksicht auf Verluste jeden Gegner an!~ DO ~SetGlobal("DKBewegungGuen","GLOBAL",1) SetGlobal("DKAngriffGuenMagier","GLOBAL",0)~ EXIT  IF ~~ THEN REPLY ~Greife nur die Zauberkundigen an, treuer Schatten!~ DO ~SetGlobal("DKAngriffGuenMagier","GLOBAL",1) SetGlobal("DKBewegungGuen","GLOBAL",0)~ EXIT  IF ~~ THEN REPLY ~Ich habe keine besonderen Befehle!~ DO ~MoveToObject("DKDrizzt")~ EXIT   ENDAPPEND ~C6Harp~
:'(

EDIT: I copy and pasted the text into an empty file, and upon saving the new file it sais there is formatting in "Unicode" which will be lost. If this by any chance is comething WeiDU could take care of I would be very happy. It's my usual editor and I normally don't have these problems, also for traifying there never were any problems of this kind.
Title: Re: traify-ing question
Post by: the bigg on September 29, 2007, 02:48:19 PM
There about ten different standards for encoding non English characters, and at least three for coding new lines. WeiDU is very dumb at this and is based on copying the stream of bytes (for special characters) and Unix line breaks. Notepad is a very stupid program and can't handle either Unix line breaks or Unicode. Wordpad, the other standard Windows text editor, should be better at handling different formats.

As much as I dislike being an asshole to people I don't think are idiots, saying "Notepad doesn't work" is pretty much like saying "My LVL1 Beastmaster can't solo against Ascension on Insane" - it's better to use better tools than accommodate WeiDU to stupid ones.
Title: Re: traify-ing question
Post by: jastey on September 29, 2007, 04:08:27 PM
That sounds right, but as I said, I had never problems of that kind before. Worse: If I use Wordpad, there are hidden characters WeiDU chokes on.
Title: Re: traify-ing question
Post by: cmorgan on September 29, 2007, 04:16:46 PM
Jastey, try Crimson Editor or ConTEXT (I have a version of ConTEXT mirrored on the BG1 alpha/beta site.) I think you will be very happy - and if you get the Crimson Editor one, I think you will really like the highlighters. If you have troubles, just PM me.
Title: Re: traify-ing question
Post by: Kulyok on September 29, 2007, 04:28:42 PM
Quote
Second: If I edit the new created .d, and make it small / open another window in front / close it (but not necessarily), meaning: don't look at it for a moment, the formatting is completely lost. I think the line breaks are missing, although at first glance, i.e. as long as I don't edit the file, the formatting is visually there.

When I had this problem, I have manually copy-pasted all Romantic Encounrers files in Word, then copy-pasted and saved them again, with line breaks. Maybe some sort of script could've been easier, but I wanted to make them workable - so whoever maintains RE(currently me, that is) has easier time implementing typo reports.
Title: Re: traify-ing question
Post by: the bigg on September 29, 2007, 04:57:41 PM
Well, anyway, for both traify and untraify WeiDU is doing a lot of 'dumb' global search and replace, without changing between different encodings (there's no such thing in standard OCaml). As such, there's no (easily codeable) way to ensure that an UTF-16 .tra and a US-ASCII .d can cooperate without punching each other out. You should manually make sure to save both your .d and your .tra in the same encoding (likely UTF-8).
Title: Re: traify-ing question
Post by: jastey on September 29, 2007, 05:07:07 PM
cmorgan: I might try Crimson Editor, but I tried and hated ConTEXT.

Kulyok: I try to avoid Word, whenever possible, because every file I ever touched with Word is cursed and lets WeiDU die.
Title: Re: traify-ing question
Post by: Kulyok on September 29, 2007, 05:12:32 PM
It really shouldn't - in English and in Russian, at least. It might have to do with German coding - then probably folks at the German modding forums you moderate know the answer.
Title: Re: traify-ing question
Post by: jastey on September 29, 2007, 05:29:30 PM
The answer is simple: I use the word editor (maybe it's notepad, I don't know, it's called "Editor"), and it works fine in all times except the untraifying.

One time a .d or .baf is saved with Word leads to a load of hidden rubbish WeiDU chokes on.
Title: Re: traify-ing question
Post by: Kulyok on September 29, 2007, 05:38:36 PM
No, no, you really shouldn't save .d or .baf in Word. Work in .rtf or .doc, and then save it as .txt file, or better yet - copy/paste the ready text into Notepad, save it, edit the filename, and you're all set.
Title: Re: traify-ing question
Post by: jastey on September 30, 2007, 02:46:38 AM
If you save it with Notepad I dont see a reason to work in Word first. Sorry to sound ignorant, it's just that I don't need it and Notepad (?) worked fine, except here.
Title: Re: traify-ing question
Post by: the bigg on September 30, 2007, 07:02:18 AM
Can you email me your (not --untraify'ed) .d and the .tra that give you this behavior? Zip them up to minimize the chances of the email system messing formats things up.
Title: Re: traify-ing question
Post by: jastey on September 30, 2007, 07:47:48 AM
Emailed. (This time with the attachment the first time). Thank you!
Title: Re: traify-ing question
Post by: the bigg on September 30, 2007, 08:06:03 AM
It looks like the two files are in a different encoding: the .d uses UTF-8 (as stated by the starting ef bb bf signature), whereas the .tra is ASCII (no signature). As a result, when they merge special characters are lost due to the different encoding. I cannot get the "break formatting" problem, though. Further, WeiDU cannot work with the .d (because of the unknown signature).

Since OCaml doesn't understand Unicode, your best bet is to save your files as ANSI (in Notepad, select ANSI encoding in the Save As... window).
Title: Re: traify-ing question
Post by: jastey on September 30, 2007, 08:18:23 AM
Are you saying my original .d is the problem? I have to admit, since I am recoding atm, that I didn't try to compile it yet.
EDIT: Now I saw what you mean. Not that I know what it means, but I'll save it as ANSI and that should solve the problem. Thank you!
Title: Re: traify-ing question
Post by: the bigg on September 30, 2007, 08:23:56 AM
Not that I know what it means
Me neither, if that can reassure you  :)
Title: Re: traify-ing question
Post by: jastey on September 30, 2007, 08:35:00 AM
Don't spoil the "coding ninja"-impression I have from you, OK?

Now the transition of the letters goes fine, but the format loss still happens as soon as I edit the untraified D. This doesn't happen with the original .d, so I am kind of confused. You say you can't reproduce it, ..any suggestions? Bullet in my head?
Title: Re: traify-ing question
Post by: the bigg on September 30, 2007, 08:42:17 AM
...give the full .tra, rather than only a line from it  :) ?
Title: Re: traify-ing question
Post by: jastey on September 30, 2007, 08:51:32 AM
It took me a whole minute to undestand what you mean. Ahem. I will send the correct .tra in a minute... (What is this, me and (not) sending files to you...)
Title: Re: traify-ing question
Post by: the bigg on September 30, 2007, 09:10:21 AM
For some reason, WeiDU is breaking your files by adding by adding an extraneous 0d character in front of 0a (resulting in 0d0d0a). Notepad destroys the formatting on that, unless you're using 'automatic line breaks', in which case it doesn't display problems (mine had `automatic line breaks' selected, as a matter of fact).

EDIT: 0d0d0a appearing when --untraify is a dumb bug in WeiDU (fixed for V202). However, saving as ANSI is still needed, unfortunately.
Title: Re: traify-ing question
Post by: jastey on September 30, 2007, 11:48:29 AM
EDIT: 0d0d0a appearing when --untraify is a dumb bug in WeiDU (fixed for V202).
Cool! Thank you very much.
Now that my attention was drawn to the existence of different txt formats, this format error won't happen to me again.
Title: Re: traify-ing question
Post by: jastey on May 24, 2008, 03:47:36 AM
I noticed a new issue. For cross-coding BG1 and Tutu/BGT, I defined an OUTER_SPRINT ~CLERIC_ALL~ which reads for BG1 "CLERIC" and for the BGII engine "CLERIC_ALL".

If I use this trigger in a dialogue, it looks like this:

+ ~Class(Player1,%CLERIC_ALL%) Alignment(Player1,19)~ + ~I believe in Helm, like you do, Ajantis.~ DO ~SetGlobal("C#AjantisPCTalk","GLOBAL",9)~ + helm_26

But after runing traify, the result was the following, which isn't quite what I wanted:

+ ~Class(Player1,@149) Alignment(Player1,19)~ + @150 DO ~SetGlobal("C#AjantisPCTalk","GLOBAL",9)~ + helm_26

with @149 being ~CLERIC_ALL~.


The same behaviour I noticed when traifying the tp2:

My code

OUTER_SPRINT ~ajantisportrait~ ~placeholder_value~
OUTER_WHILE (!(IS_AN_INT ~ajantisportrait~) OR (~ajantisportrait~ > 0x14) OR (~ajantisportrait~ < 0x1)) BEGIN
PRINT @17
  ACTION_READLN ~ajantisportrait~
END

was traifyed into ( @268 being ~placeholder_value~)

OUTER_SPRINT ~ajantisportrait~ @268
OUTER_WHILE (!(IS_AN_INT ~ajantisportrait~) OR (~ajantisportrait~ > 0x14) OR (~ajantisportrait~ < 0x1)) BEGIN
PRINT @17
  ACTION_READLN ~ajantisportrait~
END

Which, in principle, might work, until confused translators change it into something else.
Title: Re: traify-ing question
Post by: the bigg on May 24, 2008, 04:46:39 AM
Sorry, %strings% in BAF files (wether they're in BAF files or inlined in D ones) are always treated as tlk-level strings (I can't know if they're variables or not when I run --traify). Removing the %%s before traifying and re-adding them after is a good (but cumbersome) bet.

In tp2, (OUTER_)TEXT_SPRINT FTW. Pure (OUTER_)SPRINT can take tra referenes (I.E. OUTER_SPRINT myVar @1 works - that's the way Weimer coded it, and I'm not going to change it).
Title: Re: traify-ing question
Post by: jastey on May 25, 2008, 01:20:07 PM
I have a deja-vu feeling about this dicussion..

Would there be any other way of solving this problem? Like it is now, I have a huge potential of introducing coding errors, either by making them by hand while substituting the %..% with something else to smart out WeiDU, or WeiDU does it with the ones I forgot. Plus, cross-platform coing just became a lot, lot less attractive. (And I am not CamDawg, who prefers coding in tra-form.)

Any chance to find a coding structure that functions for the EVALUATE_BUFFER while *not* being recognised as potential strings? Like.. %%..%%? Or &%..%&, or §§"$&$$..&%%§?
Please?
Title: Re: traify-ing question
Post by: the bigg on May 25, 2008, 02:30:26 PM
I can rewrite the BAF grammar so that it knows if it's searching for a TLK string, a BAF string, an IDS string, or an Object (it currently decides this in a second pass, and I'm not even entirely sure you can write a similar grammar without having to list the contents of all Action.IDS and Trigger.IDS in the grammar).

I can decide out of my ass that $variableName$ will be substituted just like if it was %variableName% but will not be considered a Local String Entry, but unfortunately $$ has already a meaning in the regexp as well as in the tp2 grammar (meaning I'm going to break complex regexp constructs), so I'll also have to pick an otherwise not meaningful character / construction (and the ASCII set is running rather thin). This also runs the (minor) risk of breaking mods by people who decide that it's cool to have A` as a modding prefix.

Neither is very likely, unfortunately. You can try using stuff like

+ ~Class(Player1,___PERCENT___CLERIC_ALL___PERCENT___) Alignment(Player1,19)~ blah blah

in your D file, and compile with

COMPILE ~path/to/d/file.d~
  REPLACE_TEXTUALLY ~___PERCENT___~ ~%~
  EVALUATE_BUFFER

I have to use similar workarounds in a number of places, if that's a comfort  :)
Title: Re: traify-ing question
Post by: Nythrun on May 25, 2008, 07:09:30 PM
You may want to use
Code: [Select]
!Class(Player1,1)
!Class(Player1,2)
!Class(Player1,4)
!Class(Player1,5)
!Class(Player1,6)
!Class(Player1,7)
!Class(Player1,9)
!Class(Player1,10)
!Class(Player1,11)
!Class(Player1,12)
!Class(Player1,13)
!Class(Player1,16)
!Class(Player1,19)
!Class(Player1,20)

instead, as that'll act the same in both the BGII and BG engines.

Obviously, it's no panacea.
Title: Re: traify-ing question
Post by: jastey on May 25, 2008, 11:13:49 PM
That means the work-around is your solution? Well, I have seen worse things than that, at least it would be working. Thanks!

Nythrun: Aren't these the single-class checks only? How would I include check for the _ALLs in BGII?
Title: Re: traify-ing question
Post by: Nythrun on May 26, 2008, 12:45:38 AM
Code: [Select]
+ ~!Class(Player1,1)
!Class(Player1,2)
!Class(Player1,4)
!Class(Player1,5)
!Class(Player1,6)
!Class(Player1,7)
!Class(Player1,9)
!Class(Player1,10)
!Class(Player1,11)
!Class(Player1,12)
!Class(Player1,13)
!Class(Player1,16)
!Class(Player1,19)
!Class(Player1,20)
Alignment(Player1,19)~
+ ~I believe in Helm, like you do, Ajantis.~ DO ~SetGlobal("C#AjantisPCTalk","GLOBAL",9)~ + helm_26
so you wouldn't have to evaluate anything here - the code would be the same on either engine.
Title: Re: traify-ing question
Post by: the bigg on May 26, 2008, 12:53:41 PM
In the latest beta (which should be already up, do you want the link to experiment?):
Code: [Select]
+ ~Class(Player1,$CLERIC_ALL$) Alignment(Player1,19)~ + ~I believe in Helm, like you do, Ajantis.~ DO ~SetGlobal("C#AjantisPCTalk","GLOBAL",9)~ + helm_26
Code: [Select]
OUTER_SPRINT CLERIC_ALL CLERIC_ALL
COMPILE myfile.d
EVALUATE_BUFFER_SPECIAL ~$~
Title: Re: traify-ing question
Post by: jastey on May 27, 2008, 01:46:32 PM
In the latest beta
:-*
I don't say no to the link, but I have no time to experiment, and no new mod for traifying. Still, very cool!

Nythrun: In this case what you propose would mean the same, that is true. But the next reply option has the trigger ~!Class(Player1,%CLERIC_ALL%)~, and I don't even want to start thinking about substituting that one. Plus, I am using the OUTER_SPRINT thing for other engine differences, too, like EraseJournalEntry() and SOLVED_JOURNAL vs. JOURNAL etc.
Title: Re: traify-ing question
Post by: the bigg on May 27, 2008, 05:19:24 PM
Sorry, do you need the link or not? I'm slow sometimes  :(
Title: Re: traify-ing question
Post by: jastey* on May 28, 2008, 03:58:16 AM
Yes, but don't expect any reports because by the time I'll start using it, it might be officially available.
Title: Re: traify-ing question
Post by: the bigg on May 28, 2008, 04:11:07 AM
Actually, I'm going to release it either today or tomorrow. I'll make it a point to send you the link next time this happens though  :)
Title: Re: traify-ing question
Post by: jastey on August 01, 2008, 06:10:48 PM
I guess there is nothing I can do if the tryifying doesn't work because of OUTER_SPRINT syntax like %SOLVED_JOURNAL% that I use for bgqe. Traifying stops with syntax error warning, but also it now deleted the whole content of my .d file, and left me with an empty .d and (also empty) .tra file. (I am working with a copy, so I didn't chose a new name for the trayfied version, but still.)
Title: Re: traify-ing question
Post by: the bigg on August 02, 2008, 02:56:44 PM
Sorry, can't help you there I'm afraid  :(
Title: Re: traify-ing question
Post by: jastey on August 02, 2008, 02:59:06 PM
Yes, I meant to start the sentence with "I guess there is nothing you can do...", actually.
I'll try to remember it next time, so I don't have to delete and re-edit the crossengine syntax.
Title: Re: traify-ing question
Post by: jastey on January 16, 2013, 03:43:51 PM
because I didn't remember, or it is the same file I left laying around for some time: Same problem again. traify chokes on the cross-platform OUTER_SPRINT difinitions in the %...%. Any way this could be included into the traify progress, now?
Title: Re: traify-ing question
Post by: Miloch on January 20, 2013, 08:50:41 PM
Not sure if this is the solution, but you might try OUTER_TEXT_SPRINT instead of OUTER_SPRINT. Also, you can generally leave out %...% when defining variables - you only need them when doing variable substitution.
Title: Re: traify-ing question
Post by: jastey on January 26, 2013, 06:15:35 AM
OUTER_TEXT_SPRINT has the same problems with tarify if weidu doesn't know what the variables stand vor. Your second command I don't understand: If I use (undefined) variables in a .d weidu will choke, regardless of whether I put them in % or not.

What I meant was that something along the lines of

I_C_T %tutu_var%bg1dlg 4
SAY ~bla~
IF ~~ THEN %SOLVED_JOURNAL% ~bla~ EXIT
END

cannot be traified using weidu, as it will give error messages, plus it leaves an empty .d / .tra combo.

Question to the weidu maintainer8s): Would it be possible to combine traify with the OUTER_SPRINT definitions? Like, including them into the process, so weidu knows what to do with them while traifying?
Title: Re: traify-ing question
Post by: Wisp on January 26, 2013, 12:59:02 PM
Question to the weidu maintainer8s): Would it be possible to combine traify with the OUTER_SPRINT definitions? Like, including them into the process, so weidu knows what to do with them while traifying?
I don't think so. traify does its own little thing, with no knowledge of mods and other such things.
Can you solve your problem by installing the mod and calling --trans on the DLG?
Title: Re: traify-ing question
Post by: jastey on January 26, 2013, 02:37:09 PM
Quote
--trans   Emit coupled D and TRA files when decompiling a DLG.

Hm, the problem is it has to be a dlg, as it seems. This could work for a mod-npc's dlg, as long as there are no NPC interjections etc. My .d are usually a summation of new mod-npc-dlgs and APPEND (E_B) to existing game dlgs with dialogues between them etc.

But keep them coming, I wasn't aware --trans existed! I should study the weidu readme again carefully. Last time I did that was, well, some time ago.
Title: Re: traify-ing question
Post by: Miloch on January 27, 2013, 01:08:10 PM
Which causes the error, %tutu_var%bg1dlg or %SOLVED_JOURNAL% or both? Pretty sure I've used such syntax without issue in both cases. I am assuming you double-checked your variables are actually defined.
Title: Re: traify-ing question
Post by: jastey* on January 28, 2013, 03:11:32 AM
Milcoh: If I use weidu to --traify my .d, the OUTER_SPRINT variables are not defined, obviously. Or am I missing something?

Installing the mod goes fine. Traifying doesn't. Are you saying that e.g. %tutu_var% is known by weidu and doesn't lead to an error message upon --traify?

If yes, I didn't come that far. weidu gave some obscure error message (helpful like: syntax error near text: end of error message) when I tried traifying my .d, so I didn't identify which %-% OUTER_SPRINTs make problems.
Title: Re: traify-ing question
Post by: jastey* on January 28, 2013, 03:13:39 AM
Sorry for the spelling error. :(
Title: Re: traify-ing question
Post by: Miloch on January 28, 2013, 01:45:09 PM
Oh, I see. I forget how I did it but try traifying it with your variables already substituted and then mass replace them with the variables after it's traified.
Title: Re: traify-ing question
Post by: jastey on January 28, 2013, 03:23:41 PM
Yes, I did something like that. It's still some pre- and postparation work I'd rather spare.
Title: Re: traify-ing question
Post by: jastey on February 15, 2014, 09:38:19 AM
Using weidu v236 the traifying of strings for male and female versions doubles the string number in the .d file. Meaning:

IF ~~ THEN statenumber
SAY ~line for male PC~ ~line for female PC~
IF ~~ THEN EXIT
END

gets traified to

IF ~~ THEN statenumber
SAY @0 @0
IF ~~ THEN EXIT
END

With @0   = ~line for male PC~ ~line for female PC~

Giving an error message upon install because of the doubled line number in the .d file.
Title: Re: traify-ing question
Post by: Wisp on February 23, 2014, 04:29:12 AM
Will fix.
Title: Re: traify-ing question
Post by: jastey on February 23, 2014, 04:49:04 PM
Thank you!
Title: Re: traify-ing question
Post 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.  :'(
Title: Re: traify-ing question
Post 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!
Title: Re: traify-ing question
Post 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.
Title: Re: traify-ing question
Post 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.
Title: Re: traify-ing question
Post 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?)
Title: Re: traify-ing question
Post 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).
Title: Re: traify-ing question
Post by: jastey on May 25, 2014, 12:38:34 PM
Thank you!
Title: Re: traify-ing question
Post 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.)
Title: Re: traify-ing question
Post 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 (http://gibberlings3.net/iesdp/scripting/actions/bg2actions.htm#7) 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.
Title: Re: traify-ing question
Post 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.
Title: Re: traify-ing question
Post 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.
Title: Re: traify-ing question
Post 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.
Title: Re: traify-ing question
Post 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)
Title: Re: traify-ing question
Post 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!~
Title: Re: traify-ing question
Post 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.)