Can't extend a script

[temnix]

I don't get why this doesn't do anything:

COPY_EXISTING_REGEXP GLOB ~.*\.BCS~ ~override~

PATCH_IF ((~%SOURCE_RES%~ STRING_CONTAINS_REGEXP ~ACT0~) == 0) | ((~%SOURCE_RES%~ STRING_CONTAINS_REGEXP ~CTALARM~) == 0) THEN BEGIN

INNER_ACTION BEGIN

EXTEND_TOP ~%SOURCE_FILE%~ ~Privet Property/SCRIPT_#.BAF~ EVALUATE_BUFFER

END

END
BUT_ONLY

"SCRIPT_#.BAF" is there, and the compiler does attempt to attach its contents to the files, but nothing ends up added. Any ideas?

[kjeron]

Your code worked fine (after providing a BAF file).  You may need to check over the content of your SCRIPT_#.BAF.

Edited June 25, 2021 by kjeron

[Angel]

With the INNER_ACTION, you are patching the same file you are already copying.  The WeiDU readme contains an explicit warning not to do this, as the results are undefined.

"Note that an INNER_ACTION should never modify a file that is being modified by the current action. For example, never put APPEND  foo.2da  inside of COPY_EXISTING  foo.2da . More formally, if the inner action and the outer action both modify the same file, the results are undefined."

The proper way to do this is to use DECOMPILE_AND_PATCH and INSERT_FILE.

[temnix]

You can ignore that warning. I patch inside all the time, there are no problems unless you script yourself into an infinite loop. @kjeron, if there were problems with SCRIPT_#, the compilation would stop at midpoint, but the installer announces success, only nothing changes. But there is no mystery, here is what I'm trying to put on top of those scripts:

IF

Heard([ANYONE],4325)

THEN

RESPONSE #1

DestroySelf()

END

[Angel]

The warning is there for a very good reason, and pretending you know better than the actual author of WeiDU how it works is pretty foolish.  Even if it works on your setup (and you started this thread because it does not, right?) it may not for someone else whose setup is slightly different from yours.

But if you want to continue writing broken code against the advice of those who have been at this far longer than you have, be my guest.

[temnix]

Piss off, Angel. I've done this hundreds of times, and nothing happens. Some chickshit coward wrote that warning, which may apply to particular cases, and you're kowtowing to it. If you have nothing to contribute, stay out of my thread.

[subtledoctor]

This is insane. How do you know he hasn’t identified your error if you don’t test to establish it one way or the other? Try:

COPY_EXISTING_REGEXP
  PATCH_IF (STRING_CONTAINS_REGEXP)
    SPRINT $list(“%SOURCE_FILE%”)”1”
  END
BUT_ONLY

ACTION_PHP_EACH list AS file => num BEGIN
  EXTEND_TOP “%file%” yadda
END

Should work as well as your code, and it excludes the (potential!) INNER_ACTION issue as a possible source of your problem. What do you have to lose?

Edited June 27, 2021 by subtledoctor

[Angel]

Said "chickenshit coward" would be Weimer, you know, the coder who originally wrote WeiDU (Weimer Dialog Utility, for your information), and probably knows a lot better how things work than you do.

But please, do continue to show your poor attitude to the world, see how much coding help you'll be getting in the future.  I'll just be here munching my popcorn and watch you self-destruct.

Edited June 27, 2021 by Angel

[temnix]

4 hours ago, subtledoctor said:

This is insane. How do you know he hasn’t identified your error if you don’t test to establish it one way or the other? Try:

 

COPY_EXISTING_REGEXP
	PATCH_IF (STRING_CONTAINS_REGEXP)
	SPRINT $list(“SOURCE_FILE”)”1”
	END
	BUT_ONLY
	ACTION_PHP_EACH list AS file => num BEGIN
	EXTEND_TOP “%file%” yadda
	END

 

Should work as well as your code, and what do you have to lose?

I'll test this, of course, but there should be no problem with the code as I wrote it.

[jastey]

1 hour ago, temnix said:

there should be no problem with the code as I wrote it

You mean, except the ones you are experiencing.

[Ardanis]

PATCH_IF ((~%SOURCE_RES%~ STRING_CONTAINS_REGEXP ~ACT0~) == 0) | ((~%SOURCE_RES%~ STRING_CONTAINS_REGEXP ~CTALARM~) == 0) THEN BEGIN

Not sure if it's the issue, but you seem to be using | (aka BOR) operator, which should be used for things like matching bits in a value, instead of || (aka OR), which is the "one or the other" kind. I fell into the same trap long ago, thinking they were the same.

Also, as others mentioned, just because you never had issues using INNER_ACTION on the current file, doesn't mean they don't exist - much like I myself kept using BOR because it worked so far, but then one day it didn't and I had to find out I was doing it wrong all the time.

PS Probably not the issue, since your values are either 0 or 1 anyway. Still, something to keep in mind for future reference.

Edited June 28, 2021 by Ardanis

[temnix]

jastey hasn't been useful, but to you I will reply. The principal issue is whether writing to the file currently being written must invalidate the operation. It must not. As I said, I have done this many times. Is this a case when that limitation applies? Maybe, but there could be another explanation. I haven't posted all of the code for this extension. Below I also try, out of economy, to do a DECOMPILE_AND_PATCH operation with REPLACE_TEXTUALLY for those scripts. The replacement succeeds, but maybe this throws off the EXTEND_TOP above somehow. I don't have the time to test it right now, but I will check later.

[kjeron]

If you made any change to the file during the COPY then that version is going to overwrite the version that receives the APPEND/EXTEND.

COPY_EXISTING file override	// current state of file is read into memory
	DO y	// "y" is performed upon that copy (doesn't matter if "DO y" is before and/or after the INNER_ACTION block)
	INNER_ACTION	BEGIN
		APPEND file ~test~	// copies the current state of the file (not the current COPY) to override with ~test~ appended
	END
BUT_ONLY
// if "DO y" made any changes to the file (or if the "BUT_ONLY" is removed), then it is copied to the override with those changes, effectively negating the APPEND action.
// if "DO y" made no changes to the file, then the APPEND version remains in override.

 

Edited June 28, 2021 by kjeron

[Guest morpheus562]

Angering people attempting to help your ineptitude over a mod no one will actually use: job completed.

[temnix]

Okay, I was right. The problem was with my attempt to REPLACE_TEXTUALLY in the same operation as EXTEND_TOP. As soon as I removed that, the code began to be added normally. Thanks to those who offered advice. And all you little people can rejoice: that warning is proven not to apply. You can go and write to the files currently being written, saving time and with one less worry. But, of course, you like worrying, and it's not like you are making anything anyway.