Action Compilation Issue

[LCA-EET]

I noticed a strange bug when compiling a D file. Specifically, the DO actions are not correctly captured in the .dlg after the .d is compiled. Here is the action that isn't compiling correctly: //{ D File (XALDGD) IF ~~ THEN DO ~ SetGlobal("XA_LD_MetMorrisInAthkatla","GLOBAL", 1) ~ GOTO XA_LD_IntroAthkatla //}

The result of compiling that action is shown below: //{ DLG decompiled to D, through Weidu. I verified with NearInfinity that this is what is in the .dlg, as well. IF ~~ THEN DO ~) SetGlobal("XA_LD_MetMorrisInAthkatla","GLOBAL",1~ GOTO 5 END //}

Notice in the above how the right parenthesis is the wrong place. When I test in game, the variable is not being set to 1, because of the missing parenthesis after the 1. If I modify the D file to set a dummy variable after setting the variable I'm actually interested in, it corrects the issue. See below: //{ D File IF ~~ THEN DO ~ SetGlobal("XA_LD_MetMorrisInAthkatla","GLOBAL", 1) SetGlobal("XA_LD_WeirdBugFix", "GLOBAL", 1) ~ GOTO XA_LD_IntroAthkatla //}

//{ DLG decompiled to D, through Weidu IF ~~ THEN DO ~) SetGlobal("XA_LD_MetMorrisInAthkatla","GLOBAL",1) <--- This variable is now set correctly in game SetGlobal("XA_LD_WeirdBugFix","GLOBAL",1~ GOTO 5 <--- The set to the dummy variable is now missing the parenthisis END //}

I've never seen anything like this before. I'm using the 64-bit version of Weidu for Windows (24900) to perform the compilation. What's more interesting is that I have another D file in the same project, with the exact same code, and it compiles correctly. Both D files are compiled using COMPILE EVALUATE_BUFFER ~[path_to_folder]~ //{ XALDGD2.D IF ~~ THEN DO ~ SetGlobal("XA_LD_MetMorrisInAthkatla", "GLOBAL", 1) ~ GOTO XA_LD_IntroAthkatla //}

//{ DLG decompiled to D, through Weidu IF ~~ THEN DO ~SetGlobal("XA_LD_MetMorrisInAthkatla","GLOBAL",1) ~ GOTO 5 //}

Any ideas on what the issue may be? I'll keep troubleshooting and update this issue if I find a solution. compilation_issue.zip

[LCA-EET]

The problem had to do with a call to REPLACE_TEXTUALLY on the .dlg, without decompiling it first.