SCSII installation warnings

[Leomar]

During the installation of SCSII v8 we've got these warnings:

 

WARNING: cannot find block matching [scsII\help\scripts\uhogre_old.baf]
WARNING: cannot find block matching [scsII\help\scripts\uhogre_old.baf]
WARNING: cannot find block matching [scsII/help/scripts/gpmage_asc.baf]
WARNING: cannot find block matching [scsII/help/scripts/gphealer_asc.baf]

The warnings of uhogre_old.baf was reported here a long time ago:

http://forums.gibberlings3.net/index.php?s...ost&p=94329

 

The warnings of gpmage_asc.baf and gphealer_asc.baf was reported here last year:

http://forums.gibberlings3.net/index.php?s...st&p=127711

 

Greetings Leomar

[jon-eli]

I'm pretty sure the warning about UHOGRE_OLD.baf is because of a conflict between the Better Calls For Help component of SCSII and the Miscellaneous Enhancements component of QuestPack. Better Calls For Help installs with warnings because it uses the ever-flaky REPLACE_BCS_BLOCK, which fails in this case, since QuestPack completely revises UHOGRE.bcs... causing a mismatch with UHOGRE_OLD.baf. Locally, I've chosen to simply remove SCSII's reference, as all it does is blank the file on the assumption that it's an extraneous call-for-help script. I can't remember which file it's in, and for some reason I deleted the diff, which was helpful of me. (Edit: The file in question is HELP.tph; apparently I can't even read my own handwriting.)

 

I've had similar issues with the GP*.baf scripts, if memory serves (Edit: Not the *_ASC.baf ones, though. And this, too, was because of Better Calls For Help); but I think it turned out to be more complicated than the business with UHOGRE, and I know for a fact that I never bothered to fix it... which means I must've gotten a headache trying to rework a REPLACE_BCS_BLOCK into a REPLACE_TEXTUALLY (read: non-trivial).

 

I'd try to offer more details, but I don't have BG2 installed at the moment. I'm basically just cribbing from my collection of notes (the acurracy of which I don't necessarily vouch for). But these problems are bound to pop up from time to time, in various incarnations, because REPLACE_BCS_BLOCK wasn't designed to cope with the possibility of even minor changes to the original script blocks; a case-in-point is Virtue, which is almost impossible to get to install without warnings (on a large install-base, that is), since it uses REPLACE_BCS_BLOCK extensively, and insists on being installed at the very top of the mod stack. The issues with SCSII can be somewhat mitigated by installing it early-ish, and with a peppering of compatibility code, but in the end that may not even be worth the effort.

 

The warnings are non-fatal, and generally harmless.

[DavidW]

They're harmless: it's SCSII trying to replace some blocks that other mods have already changed. Don't worry about them, they don't cause any problems.

[jon-eli]

I'd question the idea that warnings don't represent latent errors... but I guess that would be too picky.

 

/edit

Well alright, that was unhelpfully terse.

 

REPLACE_BCS_BLOCK implicitly, and pretty much by definition, makes assumptions about the state of the resources upon which it operates, and is therefore prone to break things whenever mods are combined in a non-trivial fashion, which is the rule and not the exception these days (cf. just about every WeiDU.log posted all year). It's only usefulness is its inherent simplicity, and by extension, ease-of-cognition (and by extension, ease-of-debugging). It perhaps also raises a bar against conceptual clashes. But apart from that, it's fairly well an ixnay on the ompatibilitycay.

[DavidW]

I'd question the idea that warnings don't represent latent errors... but I guess that would be too picky.

These warnings don't represent latent errors.

 

And if you have suggestions for what to use other than REPLACE_BCS_BLOCK, I'd be interested to hear them. (It is structurally difficult to patch BCS files, much more so than DLG files.) But in any case, "making assumptions about resources" isn't avoidable in scripting.

[DavidW]

It's only usefulness is its inherent simplicity, and by extension, ease-of-cognition (and by extension, ease-of-debugging).

 

Actually, just following this up further: this implies that you think there's a more complex, but more useful and compatibility-friendly, way of doing the kind of thing one uses REPLACE_BCS_BLOCK to do. What are you thinking of?

[cmorgan]

The only maximum-compatabiliy friendly way that I have seen scrounging through mods is extensive use of

 

REPLACE_TEXTUALLY EXACT_MATCH

 

on single line sections. (And as jon-eli indicated, doing that in any large scale fashion is a tall order, if not improbable - it won't throw errors if it doesn't find what it is trying to match and replace, so you have a cleaner DEBUG, but represents a lot of effort for potentially no gain). Unfortunately, it has the same problem - you can't reliably detect (that I can see) blocks which have been modified. You can replace single line entries, no problem, but more than that and you run the risk of the patch failing because

 

IF

Global("Chapter","GLOBAL",2)

IfValidForPartyDialog("jaheira")

 

has used

 

C_B_T_B R_T E_M ~Global("Chapter","GLOBAL",2)~ ~Global("Chapter","GLOBAL",2) Global("c-aranQuest","GLOBAL",0)~

 

resulting in

 

IF

Global("Chapter","GLOBAL",2)

Global("c-aranQuest","GLOBAL",0)

IfValidForPartyDialog("jaheira")

 

I think Ascension64 gets out of this by distributing different "fixes" by reading what is installed before BGT and responding with tailored blocks, but that becomes self-defeating on larger installs. He can live with that because BGT is a "floor" - it expects only two or three specific mods might be present, and then it becomes the new baseline hat everything else is to build off. SCS/SCSII is like Tweaks, and needs a last-or-close-to-last in order.

 

[slightly OT but tangentally related]

I'm still looking for a good way of reading a 2da file to find all dream script references, parsing the relevant .bcs references, and reliably suppressing multiple dreamtalks from firing on rest by adding bg1npc-style RealSetGlobalTimer() and GlobalTimerExpired() to relevant IF and THEN RESPONSE ### , and have not been successful in finding a reliable method of just that simple a manipulation. So if there is a better way of parsing the contents of .bcs files and making decidsions about that stuff on the fly exists, please heklp me out - I thought perhaps SSL could be the ticket to it, and was going to bug DavidW about it this summer, but it sounds like even SSL is forced back onto using REPLACE_BCS_BLOCK.

[jon-eli]

You've probably realized by now that I'm a very annoying person, merely by nature. In part that's due to how perversely scatterbrained I am, and I don't suggest that it's any great failing when someone fails to comprehend what the heck I'm talking about... sometimes I'm not even sure myself. I'll try to be coherent, but no promises...

 

These warnings don't represent latent errors.

Your original statement was fairly generic, and seemed to be a broad assertion that REPLACE_BCS_BLOCK is benign.

 

And if you have suggestions for what to use other than REPLACE_BCS_BLOCK, I'd be interested to hear them. (It is structurally difficult to patch BCS files, much more so than DLG files.)

I've been forced to rewrite large chunks of Virtue to use REPLACE_TEXTUALLY instead of R_B_B, because this is a recurring and frequent problem with that mod, for the reason I mentioned earlier. Admittedly, it's not a perfect alternative, and I'm inclined to believe it wouldn't work on any system apart from my own (since I'm stupid and my crystal ball is broken); but that's a matter yet to be proved. It's a total headache to get right... and probably can never be gotten right to any satisfactory extent. But the choice is ultimately between content being outright skipped at install-time, or there being an effort toward coexistence.

 

On the one hand, there can sometimes be found an invariant in the BCS block you're looking to patch, which allows insertion of additional triggers into that particular block without too much risk of the R_T infecting unintended blocks. Alternatively, a simple EXTEND_TOP can work well in conjunction with an R_T designed to rid the script of any actions that would interfere with your prepended block(s). I suppose Shout() numbers are a different issue, but I'm feeling the chances of a clash are fairly slim.

 

I hope you can forgive me for speaking so abstractly, but my BG2 install got dusted a few days ago, along with many of my diffs (and I forget things about as quickly as I learn them).

 

But in any case, "making assumptions about resources" isn't avoidable in scripting.

At the risk of sounding vaguely polemical, I think generalizations do more harm than good. Statements about the impossibility of what-have-you, are often in lieu of experiment and imagination. I'm reminded for whatever reason of a story told by Richard Stallman (in the vein of those told by Richard Feynman): Upon being given two pairs of chopsticks whilst dining alone, he immediately wondered if one could successfully use four chopsticks to eat his meal. He couldn't, of course, but he'd deigned to find out.

 

BTW, I only just noticed what cmorgan wrote, so I'll digest that post and then figure out where I stand.

[Jarno Mikkola]

I'm reminded for whatever reason of a story told by Richard Stallman (in the vein of those told by Richard Feynman): Upon being given two pairs of chopsticks whilst dining alone, he immediately wondered if one could successfully use four chopsticks to eat his meal. He couldn't, of course, but he'd deigned to find out.

Ouh, well I could have. It's easy, you just tie the sticks to your four fingers and eat as if you would use your fingers, well kinda.

The lack of imagination is a void you better avoid.

[Mike1072]

[slightly OT but tangentally related]

I'm still looking for a good way of reading a 2da file to find all dream script references, parsing the relevant .bcs references, and reliably suppressing multiple dreamtalks from firing on rest by adding bg1npc-style RealSetGlobalTimer() and GlobalTimerExpired() to relevant IF and THEN RESPONSE ### , and have not been successful in finding a reliable method of just that simple a manipulation. So if there is a better way of parsing the contents of .bcs files and making decidsions about that stuff on the fly exists, please heklp me out - I thought perhaps SSL could be the ticket to it, and was going to bug DavidW about it this summer, but it sounds like even SSL is forced back onto using REPLACE_BCS_BLOCK.

If you could define the problem a little more specifically (perhaps in another thread), I think this could likely be solved. You'd probably want to use regular expressions to read this information you want to make decisions about and then some REPLACE_TEXTUALLYs.

[cmorgan]

[sounds good - thanks - I'll get a post up in modding help thsi evening, with what I am talking about detailed out ]

[jon-eli]

[...] extensive use of REPLACE_TEXTUALLY EXACT_MATCH on single line sections. (And as jon-eli indicated, doing that in any large scale fashion is a tall order, if not improbable - it won't throw errors if it doesn't find what it is trying to match and replace, so you have a cleaner DEBUG, but represents a lot of effort for potentially no gain).

This.

 

Unfortunately, it has the same problem - you can't reliably detect (that I can see) blocks which have been modified.

I guess the unhelpful answer is: they've been modified if R_B_B fails.

 

This is difficult to word properly, but switching from R_B_B to R_T isn't meant to allow the detection of modified blocks, but is supposed to allow the patch to proceed despite changes to the blocks. R_B_B will simply refuse to do anything if the blocks don't match down to each hair. R_T will make changes and additions, even harmfully, as long the syntax provides it an excuse to do so. In the case of Better Calls For Help, all we are looking to do is override any other call-for-help material (please correct me if I'm wrong); it doesn't necessarily follow that any other (overlapping) material must be wiped from the script. I'm suggesting that anything that can be expressed as a simple substitution (a clustered addition to a trigger-block, for example) be recast to fit that form, and that anything else should be recast as an EXTEND_TOP, with any potentially-interfering material (from other mods) clobbered by an R_T. Worst-case scenario is that Better Calls For Help would fail to work properly, which is what happens already.

 

Ouh, well I could have. It's easy, you just tie the sticks to your four fingers and eat as if you would use your fingers, well kinda.

Naturally I retold the story COMPLETELY WRONG. It's surely been years since I read it, but I'm not old enough to be losing my mind. Sigh. It's a great read, anyway, if you're into that sort of thing: http://www.stallman.org/articles/on-hacking.html

[DavidW]

You've probably realized by now that I'm a very annoying person, merely by nature. In part that's due to how perversely scatterbrained I am, and I don't suggest that it's any great failing when someone fails to comprehend what the heck I'm talking about... sometimes I'm not even sure myself. I'll try to be coherent, but no promises...

 

These warnings don't represent latent errors.

Your original statement was fairly generic, and seemed to be a broad assertion that REPLACE_BCS_BLOCK is benign.

It may have seemed that, but it wasn't in fact that. Life's too short to debate whether the fault lies with my description or your interpretation.

 

And if you have suggestions for what to use other than REPLACE_BCS_BLOCK, I'd be interested to hear them. (It is structurally difficult to patch BCS files, much more so than DLG files.)

I've been forced to rewrite large chunks of Virtue to use REPLACE_TEXTUALLY instead of R_B_B, because this is a recurring and frequent problem with that mod, for the reason I mentioned earlier. Admittedly, it's not a perfect alternative, and I'm inclined to believe it wouldn't work on any system apart from my own (since I'm stupid and my crystal ball is broken); but that's a matter yet to be proved. It's a total headache to get right... and probably can never be gotten right to any satisfactory extent. But the choice is ultimately between content being outright skipped at install-time, or there being an effort toward coexistence.

I'm unpersuaded that what I wanted to do in this case could have been acheived via REPLACE_TEXTUALLY. If I thought it could be, I'd have used it. (I use it extensively elsewhere in the same mod). Feel free to produce code if you disagree.

 

But in any case, "making assumptions about resources" isn't avoidable in scripting.

At the risk of sounding vaguely polemical, I think generalizations do more harm than good.

At the risk of sounding vaguely polemical, this is a generalization.

[DavidW]

Unfortunately, it has the same problem - you can't reliably detect (that I can see) blocks which have been modified.

I guess the unhelpful answer is: they've been modified if R_B_B fails.

 

This is difficult to word properly, but switching from R_B_B to R_T isn't meant to allow the detection of modified blocks, but is supposed to allow the patch to proceed despite changes to the blocks. R_B_B will simply refuse to do anything if the blocks don't match down to each hair. R_T will make changes and additions, even harmfully, as long the syntax provides it an excuse to do so.

I'm inclined to think that in this context, "refusing to do anything" is better than "doing changes and additions, even harmfully".

 

In the case of Better Calls For Help, all we are looking to do is override any other call-for-help material (please correct me if I'm wrong); it doesn't necessarily follow that any other (overlapping) material must be wiped from the script. I'm suggesting that anything that can be expressed as a simple substitution (a clustered addition to a trigger-block, for example) be recast to fit that form, and that anything else should be recast as an EXTEND_TOP, with any potentially-interfering material (from other mods) clobbered by an R_T. Worst-case scenario is that Better Calls For Help would fail to work properly, which is what happens already.

I say again: my interpretation of the particular situation here was that I wanted to make the substitution if, and only if, I was correct in my inference as to what I was substituting. Give me actual code that works better, and I'll take it seriously.

[Steve]

As far as I can see, the only problem here is that WeiDU complains about it. Without its warning message, this problem joins the thousand of other silent semantic errors in BG. And everybody lives happily ever after.