Always use EXTEND_TOP

[Kulyok]

(A long-winded ramble about EXTEND_TOP, EXTEND_BOTTOM, and my experiences with both. You've been warned.)

About three years ago, someone asked at (now inactive) CoM boards: should I use EXTEND_BOTTOM in area scripts, or EXTEND_TOP?  And SConrad, I remember, answered: "Always use EXTEND_TOP."

Why? I wondered then. Many mods use EXTEND_BOTTOM and are happy with it!

But just in case, I decided to follow suit, and coded Xan for BG2 with EXTEND_TOP.  I found out, however, that it had its disadvantages: in order not to interfere with OnCreation() command in some of the area scripts, I had to use Continue() at the end of each of my extended blocks for these areas.

Okay, two years passed, and now, I thought, the danger was clearly past. After all, all NPC mods, starting with Kelsey, happily use EXTEND_BOTTOM, and everything seems all right! That said, I decided to forget about EXTEND_TOP's, and used EXTEND_BOTTOMS for de'Arnise romance and Angelo both.

Everything worked fine, until testers started to report the unability to complete Bodhi quest in Chapter 6, because the characters didn't spawn in Temple District. (Which means no Angelo for ToB, as you imagine). I switched EXTEND_BOTTOM with EXTEND_TOP, and bug reports ceased. (Maybe because people were afraid of me.  You never know.)

Still, I suspected it was a fluke. I was still biased towards EXTEND_TOP, because I knew there were unwise modders who coded their area scripts with

IF
True()
THEN
...
END

(which kills EVERY script block underneath, making EXTEND_BOTTOM useless).

But yesterday I became entirely convinced that EXTEND_TOP is the only way to go.

I've been peacefully testing IWD NPC for chapter 4, but when I entered a certain chamber, neither of the banters started. I checked the scripts, checked the dialogue file. Nothing. I checked the area script: my blocks appended all right.

... two hours later, I found out the cause: one of the blocks in the _vanilla game script_ started with

IF
True()
THEN
...
END

Grrr.

Of course, I spent the next fifteen minutes adding Continue()'s and replacing EXTEND_BOTTOM's with EXTEND_TOP's, and of course, it worked immediately afterwards.

... I think I'll stick with EXTEND_TOP from now on.

[the bigg]

I think that modders using True() like that should be shot in the head have their mods updated against their will.

[Kulyok]

I am not sure which is a crueler punishment. Note how I carefully typed "unwise".

[jastey]

Yes, that is exactly the reason why I am thinking "Thank you for creating I_C_T2, but actually with all the mods adding interjections, modders please stick to I_C_T + passback line".

[Kulyok]

I think I_C_T2's are all right. Sure, Weidu sometimes adds slightly paranoid warnings, but it works as it should, and it's the best way to avoid something without adding new lines and a crash before a cutscene. But EXTEND_BOTTOM after True() is more serious stuff.

[jcompton]

Well, the implications of EXTEND_TOP in scripting (which is what Kulyok's talking about) and EXTEND_TOP in dialogue transitions (which I_C_T2 would speak to) are rather different.

(this is also a good time to mention: WeiNGINE supports explicit, numerical transition weighting!)

[aVENGER]

Everything worked fine, until testers started to report the unability to complete Bodhi quest in Chapter 6, because the characters didn't spawn in Temple District. (Which means no Angelo for ToB, as you imagine). I switched EXTEND_BOTTOM with EXTEND_TOP, and bug reports ceased. (Maybe because people were afraid of me.  You never know.)

There's a nasty bug in AR0800.BCS which can prevent any script blocks that are placed below the bugged block from running. So far, only the G3 BG2 Fixpack corrects this, other fixpacks (i.e. Baldurdash) do not.

I've recently became aware of the full extent of this bug and realized that it can even prevent Bodhi from spawning both in Chapter 2 and in Chapter 6 (which disables my Chosen of Cyric encounter) so I'm mirroring this fix locally in RR with Cam's blessings.

[devSin]

I've recently became aware of the full extent of this bug and realized that it can even prevent Bodhi from spawning both in Chapter 2 and in Chapter 6

In the default game, this is most certainly not the case. Unless I'm completely missing something, the final block only pertains to the Chapter 2 Bodhi.

For the curious, the wayward block belongs in Ar0900 (oops!). Along with code to keep Cyrando from spawning until Irlana and Cadril are active (this shit never ends; I'll be tweaking this crap forfuckingever). Thanks to the almighty that IsActive() actually worked like I expected (allowing me to avoid Time() checks, which I always have to think about and then check and recheck).

[Kulyok]

So that's why it didn't work! Now the Angelo's mystery is revealed.  Thank you.

[aVENGER]

In the default game, this is most certainly not the case. Unless I'm completely missing something, the final block only pertains to the Chapter 2 Bodhi.

I'm at work ATM so I can't check how exactly the Chapter 6 Bodhi spawn is affected but I seem to recall that it could fail as well (possibly due to a mod though). Anyway, what's 100% certain is that any mod which uses EXTEND_BOTTOM on AR0800.BCS will have their script blocks fail if this bug is not fixed.

[berelinde]

aVENGER, thank you for pointing this out. I used EXTEND_BOTTOM on AR0800.bcs for Fading Promises, and have had one bug report by a user who was unable to get Aidan to spawn. It was on a heavily modified game, so I attributed it to the contribution of another mod, but now I know. Since I use the G3 Fixpack myself, I was unable to duplicate the bug.

For the next version, I'll do what you have done, and secure permission to use the fix, and include checks for both the BG2 Fixpack and for RR.

[aVENGER]

For the next version, I'll do what you have done, and secure permission to use the fix, and include checks for both the BG2 Fixpack and for RR.

As far as I can tell, the fix is foolproof i.e. it will harmlessly fail if another mod has already made it, though RR still checks for the G3 Fixpack just in case.

I'm sure devSin can clarify this further if needed.

[Jarno Mikkola]

Could you tell us: With component fixes the problem in the G3 BG2 Fixpack? As we(you) probably wouldn't want every mod combonation have all the fixes in the fix pack, as there are others etc.

[Kulyok]

If you're a modder, just use EXTEND_TOP(with Continue(), if the area script has an OnCreation() block) in your mods; if you are a player, just install BG2 Fixpack before your mods and don't worry about it.

[CamDawg]

But yesterday I became entirely convinced that EXTEND_TOP is the only way to go.

I've been peacefully testing IWD NPC for chapter 4, but when I entered a certain chamber, neither of the banters started. I checked the scripts, checked the dialogue file. Nothing. I checked the area script: my blocks appended all right.

... two hours later, I found out the cause: one of the blocks in the _vanilla game script_ started with

IF
True()
THEN
...
END

Modders should actually check the resources they're modifying. In other news, gravity causes you to fall down, the sky is blue, and 2+2=4.

[Kulyok]

Well, excuse me for believing in humanity aka "IWD programmers weren't morons" in the first place.

[CamDawg]

Well, excuse me for believing in humanity aka "IWD programmers weren't morons" in the first place.

Developers aren't perfect and didn't expect others to mod their games. In other news...

edit: It's ar6010.bcs, yes? This'll be handled in the next IWD Tweaks.

[Kulyok]

It seems that the developers didn't foresee the case of expansions, either: a "Return to Loneliwood" block(and an OnCreation()) block are situated right under the faulty True() block. Granted, they don't make the weather, but it still falls further than "not perfect" category, ending up somewhere between "forgetful", "moronic", "graduated from MSU/Lumumba" and "graduated from Ivy League schools".

And, yes, it's AR6010.

[CamDawg]

It seems that the developers didn't foresee the case of expansions, either: a "Return to Loneliwood" block(and an OnCreation()) block are situated right under the faulty True() block. Granted, they don't make the weather, but it still falls further than "not perfect" category, ending up somewhere between "forgetful", "moronic", "graduated from MSU/Lumumba" and "graduated from Ivy League schools".

You need to spend more time on the Fixpack forums if you think this is somehow unusual or notable. BG2 has this error twice (ar0800, ar0400) and BG at least once (ar0300).

[CamDawg]

Here's your fix, if you want it:

Code: [Select]

ACTION_IF NOT FILE_EXISTS_IN_GAME ~ar9100.are~ THEN BEGIN

  // stop cockblocking the script - no or() without how
  COPY_EXISTING ~ar6010.bcs~ ~override~
    DECOMPILE_BCS_TO_BAF
      REPLACE_TEXTUALLY ~True()~ ~False()~
      APPEND_FILE ~g3daletweaks/baf/ar6010.baf~
    COMPILE_BAF_TO_BCS
    BUT_ONLY_IF_IT_CHANGES

END ELSE BEGIN

  // stop cockblocking the script
  COPY_EXISTING ~ar6010.bcs~ ~override~
    DECOMPILE_BCS_TO_BAF
      REPLACE_TEXTUALLY ~True()~
        ~OR(3) !Global("AR6010_PLAY_SOUND","GLOBAL",0) !Global("PUZZLE_B_DISABLED","GLOBAL",0) !Global("PUZZLE_A_DISABLED","GLOBAL",0)~
    COMPILE_BAF_TO_BCS
    BUT_ONLY_IF_IT_CHANGES

END
ar6010.baf

Code: [Select]

IF
  !Global("AR6010_PLAY_SOUND","GLOBAL",0)
THEN
  RESPONSE #100
    SetGlobal("AR6010_PLAY_SOUND","GLOBAL",0)
END

IF
  !Global("PUZZLE_A_DISABLED","GLOBAL",0)
THEN
  RESPONSE #100
    SetGlobal("PUZZLE_A_DISABLED","GLOBAL",0)
END

IF
  !Global("PUZZLE_B_DISABLED","GLOBAL",0)
THEN
  RESPONSE #100
    SetGlobal("PUZZLE_B_DISABLED","GLOBAL",0)
END

[Kulyok]

Thank you for showing me. I'd gladly use it if it were critical for IWD NPC, but, fortunately, it's not, so I'd rather leave it to IWD Tweaks.

It proves my point, though: my script will still be screwed if I use EXTEND_BOTTOM(as I use !Global("PUZZLE_A_DISABLED","GLOBAL",0) condition, and the new block will set it to 0 at once), but with EXTEND_TOP and Continue() it's fine and dandy.

[Ascension64]

Why not be just black or just white and use the appropriate EXTEND_* as is expedient to the situation? "Always use X, Y, Z, and bikinis" seems to be a rather one-sided, biased way to do modding.

[jcompton]

a rather one-sided, biased way to do modding.

Did somebody say biased modding?

Anyway, the scripting EXTEND_TOP vs. EXTEND_BOTTOM question is easy enough to sum up:

EXTEND_BOTTOM: Anybody from Bioware to Interplay to Sikret can fuck you up.

EXTEND_TOP: It is imperative that you not fuck up.

[Ascension64]

Interesting read, but I don't get the 'criminally biased' part of it. For what it's worth, it appears to be a rather aureate but impartial history of IE modding...and could have been an IM entry.

My take on EXTEND_* is:

EXTEND_BOTTOM (of Lawful alignment): You are at the mercy of the EXTEND_TOP gods, who may one day be benelovent and do not f* up, or on other days be fascist and f* you over and over, and on the lucky days be knotted in their brain and absent-mindedly f* up. Whatever happens, you'll work it out when your forum brims with bug reports of objects not appearing in areas.

EXTEND_TOP (of Neutral or Evil alignment): You can censor any mods that you wish your mod to be incompatible with by deliberately f*ing up. You may snigger when 5 years after your mod is released, someone finds out. You proceed to justify your actions as legacy code from the crappy impotent old days of WeiDU and the prevailing modding maxims of the ancient.

[CamDawg]

Why not be just black or just white and use the appropriate EXTEND_* as is expedient to the situation? "Always use X, Y, Z, and bikinis" seems to be a rather one-sided, biased way to do modding.

I find your ideas intriguing and would like to subscribe to your newsletter.