Jump to content

Erase Journal entry

Red Carnelian

Recommended Posts

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?

Link to comment

yep - leads to long lists of







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).

Link to comment

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...

Link to comment

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.

Link to comment

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.)

Link to comment

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. )

Link to comment


This topic is now archived and is closed to further replies.

  • Create New...