Erase Journal entry

[Red Carnelian]

I'm trying to set an O_S %ERASEJOURNALENTRY_01% entry from a different dialog file then the one in which the O_S %UNSOLVED_JOURNAL% was set. If charA set the unsolved entry using an entry from its own tra file does this mean I have to include that particular Tra file entry in charB tra file as well?

[Miloch]

AFAIK, yes, unfortunately. There should be examples of this in the last DS edit.

[cmorgan]

yep - leads to long lists of

EraseJournalEntry(@1234)

EraseJournalEntry(@1235)

EraseJournalEntry(@1236)

EraseJournalEntry(@1237)

EraseJournalEntry(@1238)

 

etc., and will not (of course) pick up customized or fixed strings that do not match that are already installed... which is why it is so blasted tough (actually, impossible unless you are the onlymod in the install) to get a comprehensive EraseJournalEntry() behavior. Within your own mod, though, it means "look for all the journal entries in everyone's tra, and replicate", or use a separate .d file to hold all the JOURNAL, UNSOLVED_JOURNAL, SOLVED_JOURNAL, AddJournalEntry(), EraseJournalEntry() lines. (I have never seen anyone do this. It probably isn't worth the .tra savings; it would have to be a huge set to have meaningful reduction).

[Red Carnelian]

I've been doing some testing and found that the UNSOLVED_JOURNAL and SOLVED_JOURNAL entries in BGT are ending up in the quests. Is this right? seems odd to me.

[cmorgan]

Yep. Solved and unsolved are quests, journal is "private journal", I think. There are qualifiers available, if you check the IESDP.

[plainab]

To slightly slide the topic,

 

Why does everyone use different tra files for their dialog?

I'm just using one: Setup.tra

 

When I'm done making a d-file, I use weidu's traify option that lets me specify a number. I set that number to be whatever it would be if rounded to the next highest thousand. When it's done, I just copy and paste into the bottom of my setup.tra. Whola! Strings for everyone in one place. So, if I know that I've used a particular string (as in a journal) I can point to it directly in the next d-file and weidu will just skip it when it does it's traify.

 

Weidu docs say that it starts at 0 unless you specify a number and if you already have some @xxx instead of text strings, you could run into duplicate entries. However, with judicious and careful use you can have all your strings in one place...

[cmorgan]

Chalk it up to many things - for instance, many older mods started before .tra was standard (and some mods still ship hardcoded .d rather than traified). Those options in weiDu are the bigg's stuff, and relatively new.

 

Other reasons might be size of mod - it is easier for big projects to coordinate lots of smaller files with translators, and keep them together using AUTO_TRA.

 

But primarily, I think it is because folks mostly use hardcoded .d to write the basic mod, then traify, so that each file gets its own .tra reference. It is true that it would simplify things by dropping everything into one setup-tra and then

COMPILE ~mymod/myD1.d~ USING ~mymod/myonlytra.tra~

COMPILE ~mymod/myD2.d~ USING ~mymod/myonlytra.tra~

using your method - nothing wrong with it.

 

But most folks just use AUTO_TRA and are done with it as a .d/.tra pair, and don't bother with USING (exept tht they need to remember if there are .tras for .bafs, then they need to specify USING). They expect to revisit and revise the .d file, and are happy enough with that organization. Savings of a few lines of code is not considered worth the effort.

[jastey]

cmorgan: If using the setup.tra, you don't have to specify USING, since missing strings are automatically taken from the setup.tra (in non-MODDER mode).

 

Although having only one tra would make sense installing-wise, and solve the problem with doubled strings, I still prefer having several, for the sake of handling. I don't know what size you are talking about, but my NPC mod has about 24 .d files, with sizes of some over 1000 strings. I would go crazy having all these in one file; plus as cmorgan pointed out, this way it's much easier to coordinate proof-reading and translation help, as several steps can be done parallel.

(And I would have to remember the syntax for traifying from a number greater than 0, which I didn't even know is possible before not too long.)

[cmorgan]

Point taken, Jastey - things will always fall through to setup-mymod.tra. But I troubleshoot with MODDER enabled, and then would get all sorts of extra stuff in the warnings section of debug. (I need to confirm that last with .baf and the bigg, though - even in the latest WeiDU, I seem oly to be able to use translation strings in .baf under COMPILE and COMPILE EVALUATE_BUFFER if I designate a .tra file via USING. )