Weidu: Parse Error with STRING_SET_EVALUATE + Reading .2da without Copying

[Guest]

Hello all,

I am trying to write some mods as a little project and slowly getting the hang of Weidu.  I have some experience with other coding (Python, Matlab) but am struggling a little with the finer points of this program.  I'm hoping with all the experience available here someone might be able to give a few pointers...

Below is a block of code I am working on that uses a FOR loop to:
  -  look through the clastext.2da file
  -  finds Fighter/X multiclasses
  -  grabs the string reference for their descriptions
  -  calls the description from DIALOG.tlk
  -  patches the description
  -  writes the new description back to DIALOG.tlk

QUESTION 1
It is all working right up to the very last line - STRING_SET_EVALUATE.  I have no idea why this command is throwing a GLR parse error.  Using PATCH_PRINT statements to debug I can see that the inputs to STRING_SET_EVALUATE (strref + newdesc) exist and are correct so I am at a loss.  I have tried STRING_SET as well with no luck.

QUESTION 2
It has come up several times in my project where I need to read a .2da file to get string references, etc but not make any changes.  Is there a way to do this without using COPY_EXISTING and creating an extraneous copy?  My workaround has been to copy to the mod's /backup folder instead but just wondering if there is a better way.

Thanks in advance for any help!

/////////////////////////////////////////////////////////////

// Update class descriptions
COPY_EXISTING ~clastext.2da~ ~TestBed/backup~
   COUNT_2DA_ROWS 9 numrows
   FOR (i=0; i<%numrows%; i=i+1) BEGIN
      READ_2DA_ENTRY %i% 0 9 name
      PATCH_IF ("%name%" STRING_MATCHES_REGEXP "FIGHTER_.*" = 0) BEGIN
         READ_2DA_ENTRY %i% 4 9 strref
         GET_STRREF %strref% desc
         INNER_PATCH_SAVE newdesc "%desc%" BEGIN
            REPLACE_TEXTUALLY ". They may Specialize in, but not Master, any weapon they can use." "."
            REPLACE_TEXTUALLY ". This character may Specialize in, but not Master, any weapon they can use." "."
         END
         PATCH_PRINT "%name%"
         PATCH_PRINT "%strref%"
         PATCH_PRINT "%newdesc%"
         STRING_SET_EVALUATE %strref% "%newdesc%"
      END
   END

[Guest]

QUESTION 1 self-answered, solution documented below in case anyone is having the same issue:

I'm gradually working out by trial and error the difference between "actions" and "patches".  It seems like Weidu works in (what I am calling) either "action" mode or "patch" mode, and commands that are from the opposite category will throw an error e.g. PRINT [action] vs PATCH_PRINT [patch].

Trial and error showed that STRING_SET_EVALUATE is an "action", not a patch and Weidu was running in "patch" mode, hence the error.

To fix the above code I added an INNER_ACTION block around the STRING_SET_EVALUATE command and it worked fine.

No solution to QUESTION 2 yet though...

[Mike1072]

For question #2, there are a couple of ways to avoid writing the file when performing a COPY.  If you use BUT_ONLY (short for BUT_ONLY_IF_IT_CHANGES), it will only write to the file if you have made changes to it.  This is very common and people usually place it as the last patch statement in the COPY (e.g. after the END for your FOR loop).

Another way is to add a hyphen after the COPY and before listing the source file.  For example:

Code: [Select]

COPY_EXISTING - ~clastext.2da~ ~TestBed/backup~
This instructs WeiDU to store all changes of the changes in memory but not actually write them to disk.


There are a couple of optimizations I'd recommend for your code, but this is a good start.  If you want to improve on it, I'd recommend looking into:

• READ_2DA_ENTRIES_NOW and READ_2DA_FORMER instead of READ_2DA_ENTRY
• RESOLVE_STR_REF instead of STRING_SET_EVALUATE
• SET_2DA_ENTRY_LATER and SET_2DA_ENTRIES_NOW

If you have other modding questions to dicuss, I'd suggest the Modding Q&A forum at G3, which has more activity these days.

[Guest]

Hey Mike, thanks for the response and the answer to my second question.  I had played a little with BUT_ONLY before but for some reason hadn't had any luck - of course it is working a treat now so must have been doing something wrong before.

Also thanks your suggestions, I can see how they will reduce the load not having to read/write the 2da each iteration.  And thanks for the tip on the G3 forum, I'll post there if I have any more questions.

Much appreciated!