Improvement to Interjection Component

[SimDing0]

Okay, I think it might be possible, given that duplicating triggers won't do any harm. I can't figure out how to explain it though. I tried writing something from memory which is certainly completely wrong syntax-wise, but does anybody else get it?

 

REPLACE_TEXTUALLY ~OR(\([0-9]*\))\(.*\)IsValidForPartyDialog("anybody")\(.*\)\(OR*\)~ ~OR(\1)\2InParty("anybody")\3OR(\1)\2InMyArea("anybody")\3\4~

[the bigg]

REPLACE_TEXTUALLY ~OR(\([0-9]*\))\(.*\)IsValidForPartyDialog("anybody")\(.*\)\(OR*\)~ ~OR(\1)\2InParty("anybody")\3OR(\1)\2InMyArea("anybody")\3\4~

 

I doubt it could work: it would get stuff like

 

IF
OR(2)
aaa
bbb
THEN
 RESPONSE #100
    ccc
END

IF 
 IsValidForPartyDialogue(me)
THEN
 RESPONSE #100
   ddd
END

I prefer not to think what disasters would that generate.

 

The perfect way would be to parse and edit the file manually (READ_BYTE etc.). Of course, it's no small challenge

[SimDing0]

So we need to check for either THEN if patching scripts or a tilde if patching dialogs.

[CamDawg]

Huh, I think you're on to something. Though it would leave some very ugly triggers around, this should also work for !IVFPD.

 

REPLACE_TEXTUALLY ~OR(\([0-9]+\))\(.*\)I[sf]ValidForPartyDialog\(ue\)?(\(.+\))\(.*\)~ ~OR(\1)\2InParty(\4)\5OR(\1)\2InMyArea(\4)\5~
REPLACE_TEXTUALLY ~\(!\)?I[sf]ValidForPartyDialog\(ue\)?(\(.+\))~ ~\1InParty(\3) \1InMyArea(\3)~

 

The first one would only replace IVFPD in triggers with OR blocks, and the second would grab anything else, so we'd only have the messy triggers for OR block replacements.

 

But, ugh. The first OR(x) IVFPD IVFPD ... IVFPD dialogue block it hits is going to be ugly, as it'll result in 2^x OR blocks as a result.

[SimDing0]

I think that's probably just how it has to work though. Also, brainstorming time-- are there any points where it's gonna break? !IsValid should be fine, I think, but...

 

PS. Previously considered unsolvable by the community.

[CamDawg]

Dialogues are not a problem--WeiDU decompiles the triggers on a single line, and since . does not match newline characters, we're fine.

 

Scripts remain an issue without \n support, as WeiDU decompiles them with line breaks. With \n support, it's just a matter of throwing in [^THEN] so we don't span multiple script blocks.

[SimDing0]

Oh, poo, yeh... "." doesn't match newlines. I think we need newline support somehow, no matter what Weimer thinks. Can we strongarm DevSin or somebody into doing it?

 

Although it seems IsValid doesn't even appear in scripts.

[devSin]

"." doesn't match newlines

With PCRE, you can define (?s) to make it match newlines. Hands from all the people that think this would work in WeiDU. You could also create recursive patterns, which might be able to help automate this.

 

Can we strongarm DevSin

Not a chance in Hell.

 

If I thought I could do it, I would (if only to demonstrate that \n support won't make this any easier), but I know nothing about OCaml (nor am I inclined to learn it; I can tinker with the code that already exists, but it still looks like gibberish to me). I could whip up a PATCH_FAIL or something (), but integrating perl-compatible or enhancing the current grep support is beyond my abilities. Sorry.

 

What you're trying to do is very difficult to automate. You'd need to find a pattern that will descend through the list of triggers in an OR() block, find the IsValidForPartyDialogue() trigger, and somehow manipulate it. While it's conceivable that you could use WeiDU patch actions to automate this (it would technically be possible to find the OR(), forcably extract the number of triggers, iterate through each of them, and generate a suitable replacement), it would not be simple, and I don't see how support for \n would improve this (you would have to create some repeating pattern, as \n will match a newline once, and only once (and there's rarely more than one newline in a row)). So you'd still need to do .+\n.+\n.+\n (and so on), which may or may not be better than simply doing ~OR(\d)

\w+

\w+

\w+ ...~

 

WeiDU decompiles dialogues with each trigger and action separated by a newline (I believe it outputs LF newlines), and compiles the triggers and actions separated by DOS newlines (CR/LF; it doesn't matter what whitespace you use to separate dialogue actions and triggers, just as long as there is a whitespace (unless you're coding for Icewind Dale)). This may work differently for the DECOMPILE_DIALOGUE_TO_D action, though.

 

IsValidForPartyDialogue() is never used in scripts, and very rarely used as a top-level trigger in dialogue states. I'd say automate the simply replacement (find the trigger, replace with InParty() InMyArea() !StateCheck(1) (unconscious creatures can't dialogue)), and then identify problem dialogues and manually change them.

 

Also, keep in mind that the common pattern modifiers should be greedy by default (although I doubt even this works in WeiDU). Meaning that your pattern could likely find the first OR() trigger, the last IsValidForPartyDialogue() trigger, and return everything in-between. Full regexp support (again, either perl-compatible or GNU) would likely change the behavior, and you'd possibly run into a lot more problems with patterns like these.

[the bigg]

Dialogues are not a problem--WeiDU decompiles the triggers on a single line, and since . does not match newline characters, we're fine.

<{POST_SNAPBACK}>

False. Try it out for yourself:

 

 

BACKUP. AUTHOR, BEGIN ...

COPY_EXISTING ~bnalia.dlg~ ~bnalia.d~

DECOMPILE_DLG_TO_D

 

will result in:

IF ~InParty("Mazzy")
See("Mazzy")
AreaType(CITY)
!StateCheck("Mazzy",STATE_SLEEPING)
Global("BNalia1","LOCALS",0)~ THEN BEGIN 0
 SAY #24578
 IF ~~ THEN DO ~SetGlobal("BNalia1","LOCALS",1)~ EXTERN ~BMAZZY~ 3
END

where the newline (in winxp environment) is 0x0d0a (and not 0x0a as DevSin says).

[SimDing0]

What you're trying to do is very difficult to automate. You'd need to find a pattern that will descend through the list of triggers in an OR() block, find the IsValidForPartyDialogue() trigger, and somehow manipulate it.

I don't see why finding the number of triggers in an OR block and then descending through them is necessary. The idea I was suggesting was basically to duplicate EVERY trigger as many times as we have new triggers to add, with each duplication containing a different trigger in place of IsValid. Messy, but with something that could match an undefined number of newlines, I don't see that it'd cause difficulties.

[devSin]

and not 0x0a as DevSin says

Suggested, not declared. "I believe it outputs LF newlines," not "It outputs LF newlines."

 

EDIT: And indeed, it does output Unix linefeeds on Mac OS X.

~SetGlobal("SculptorPlot","GLOBAL",4)
TakePartyItem("MISC5K")
SetGlobal("GaveStuff","LOCALS",1)
~
in hex:
7E2150617274794861734974656D28224D495343354B22290A2150617274794861734974656D28224D495343365322290A47
6C6F62616C2822476176655374756666222C224C4F43414C53222C30290A7E

Not a carriage return to be found.

 

The idea I was suggesting was basically to duplicate EVERY trigger as many times as we have new triggers to add, with each duplication containing a different trigger in place of IsValid.

I'm sure I had a reason for the previous post, but damned if I can puzzle my way through it now.

 

For now, I'd suggest attempting to fake it (in your pattern, do something like the following):

REPLACE_TEXTUALLY ~OR(\([0-9]+\))
\(.*
?\)*I[sf]ValidForPartyDialog\(ue\)?(\(.+\))
\(\(.*
?\)*\)~

Or something. I honestly doubt this would work, but you can do limited searches for \n by sticking an actual linebreak in the pattern. (This pattern is a quick hack of the previous, and would probably need to be altered to do something sensible.)

[SimDing0]

Yeh, hmm. Or, if that fails, would it be possible to have the TP2 replace newlines with a unique pattern at byte-level, run the regexp, then switch back to newlines?

[the bigg]

Actually, after checking with xvi32, I got pure 0x0a too in windows. However, in Context it declared it was a DOS 0x0d0a file (it says that in tools/convert text to... submenu). This makes it easier to emulate the \n support.

(yeah, my fault for not checking bla bla