100 replies to this topic

[horred the plague]

This gets more baffling. Today w/ bp scripts my brand new PC was attacked, but an imported bg2 pc was not. I toggled the scripts back and forth---on a brand new pc w/ vanilla scripts firebeard walked right out of the area w/o attacking or talking. In a second game like this he was just randomly walking around the area.

 

 

Unfortunately you're right. I tested it specifically. All of a sudden, literally after 12 years and w/ dozens of other modders using this,

 

IF

    True()

THEN

        RESPONSE #100

END

 

suddenly no longer works on BG2. It works fine on BGEE, I put the exact same scripts in and assigned them to firebeard. I removed ToB-ex, it's not the culprit.

 

 

and

 

 

IF

    True()

THEN

    RESPONSE #100

        NoAction()   

END

 

still prevents the subsequent scripts from firing.

 

 

I don't know why, I can't help caring but I totally give up--totally frustrated. Absolutely blown away, that a key function can work perfectly for many many many years and suddenly not, when nobody changed a damn thing.

 

THE BOTTOM LINE:

 

With this not working, BP will NOT work on BG2. So, after 12 years and 1000's of happy players, BP NO LONGER CAN SUPPORT THIS ANCIENT $%&*ING GAME. My advice: Buy BGEE and BG2EE and throw your crusty decade-old disc's in the garbage.

 

My support for BG2:ToB officially ends today. I can't fight back, when I'm boxing at shadows. When Spellhold has a BG2EE category, I'll move this mod out of the BG2 section and into that one. Sorry to all my fans....I'm at a loss for words, if I leave out the swear words.

[Cahir]

Sorry for interrupting this thrilling this discussion, but does it all mean, that BP 181 works flawlessly with BG(2)EE?

 

Cause ye know, I've already thrown away my dusty old vanilla BG(2) discs some time ago

[horred the plague]

Sorry for interrupting this thrilling this discussion, but does it all mean, that BP 181 works flawlessly with BG(2)EE?

 

Cause ye know, I've already thrown away my dusty old vanilla BG(2) discs some time ago

 

Well, I can't say "flawlessly" w/ a straight face...but this bug definitely does not happen there. I just hotwired BP onto BGEE, and tested the same situation. Firebeard acted as intended--no unusual behavior whatsoever. Not even the infamous fire shield bug.

 

 

The plot thickens. I tried the ultimate shutoff on ToB, and still it cast through it:

 

IF
    True()
THEN
    RESPONSE #100
END

 

I'm talking with what remains of my scripting colleagues about this, and they are equally as baffled. BP is not the only mod using this trick, so the potential for chaos is widespread. We all know this used to work! I've tested Win98/XP compatibility modes, I tried a clean BGMAIN after uninstalling tob-ex.

 

Nothing is working. If we can figure out what's causing it, I can support ToB again. I didn't pull support lightly, nor willingly. There's no script workaround that can help this problem--zero.  Still trying to solve it.

Edited by horred the plague, 25 February 2014 - 11:32 AM.

[pro5]

Um, are you sure you're not overreacting on this, Horred?

When I tested the behavior of the empty execution blocks earlier (after you clarified that they should stop current script but move on to the next one in script stack), I confirmed that they are in fact working as you describe. Just not in the first AI round, when they fall through. I'll do more testing in the next few days to be sure, but if this is correct - it's hardly an insurmountable problem, OnCreation() triggers should help.

Also, I have to ask, is it possible it always worked like this and the "fire shield" and other buffs firing (which you admitted happened), for instance, was caused by it? After all, Firebeard is only casting offensive spells first because he doesn't have buffs like Ghost Armor memorized, otherwise the script would prioritize them...

Edited by pro5, 25 February 2014 - 11:44 AM.

[horred the plague]

Success! It's a cludgy workaround, but it's worked in 3 tests in a row:

 

 

IF
    OR(2)
        !Allegiance(Myself,EVILCUTOFF)
        !Detect([GOODCUTOFF])
    Global("TOB_SUXX","LOCALS",0)
THEN
    RESPONSE #100
        SetGlobal("TOB_SUXX","LOCALS",1)
END

IF
    OR(2)
        !Allegiance(Myself,EVILCUTOFF)
        !Detect([GOODCUTOFF])
    Global("TOB_SUXX","LOCALS",1)
THEN
    RESPONSE #100
END

 

This adds a 1-second delay to the scripts, but at least in firebeard's case he's a non-combatant so it won't affect a battle.

 

Now, what remains is devising some weidu code to change this in all the scripts, but only in a ToB install. That, you're going to have to wait for, when I can ration the time out. I can write IE scripts from memory, but not weidu scripts--need much document perusal. So until then BP is closed for ToB, but works fine on BG2EE.

 

Phew...at least it can live on. Other scriptors who used this function: BEWARE!!

 

We eliminated all but one theory: the new GoG.com installation broke this function. The original vanilla scripts never use it, so maybe they totally overlooked its usefulness when recompiling the engine.

 

 

My other assertion still remains: Scrap this old game and play EE instead! Not only does this function work, it's a way better engine, way better for modding on, has very active dev support and is getting better & better all the time.

Edited by horred the plague, 25 February 2014 - 12:05 PM.

[pro5]

We eliminated all but one theory: the new GoG.com installation broke this function. The original vanilla scripts never use it, so maybe they totally overlooked its usefulness when recompiling the engine.

I'm pretty sure my ToB copy is not GoG, it's a backup I created ages ago from some ancient CD version.

For your WeiDU code, this should do the trick

<<<<<<<< ...\p5-inlined\src.baf
IF
  OR(2)
	!Allegiance(Myself,EVILCUTOFF)
	!Detect([GOODCUTOFF])
THEN
  RESPONSE #100
END
>>>>>>>>

<<<<<<<< ...\p5-inlined\dest.baf
IF
    OR(2)
        !Allegiance(Myself,EVILCUTOFF)
        !Detect([GOODCUTOFF])
    Global("TOB_SUXX","LOCALS",0)
THEN
    RESPONSE #100
        SetGlobal("TOB_SUXX","LOCALS",1)
END

IF
    OR(2)
        !Allegiance(Myself,EVILCUTOFF)
        !Detect([GOODCUTOFF])
    Global("TOB_SUXX","LOCALS",1)
THEN
    RESPONSE #100
END
>>>>>>>>

SILENT
COPY_EXISTING_REGEXP GLOB ~BP.*\.bcs~ ~override~
	R_B_B ~...\p5-inlined\src.baf~ ~...\p5-inlined\dest.baf~
BUT_ONLY
VERBOSE

This won't catch other shutoff blocks, obviously, so you might need to repeat this for every one of them.

[horred the plague]

We eliminated all but one theory: the new GoG.com installation broke this function. The original vanilla scripts never use it, so maybe they totally overlooked its usefulness when recompiling the engine.

I'm pretty sure my ToB copy is not GoG, it's a backup I created ages ago from some ancient CD version.

For your WeiDU code, this should do the trick

<<<<<<<< ...\p5-inlined\src.baf
IF
  OR(2)
	!Allegiance(Myself,EVILCUTOFF)
	!Detect([GOODCUTOFF])
THEN
  RESPONSE #100
END
>>>>>>>>

<<<<<<<< ...\p5-inlined\dest.baf
IF
    OR(2)
        !Allegiance(Myself,EVILCUTOFF)
        !Detect([GOODCUTOFF])
    Global("TOB_SUXX","LOCALS",0)
THEN
    RESPONSE #100
        SetGlobal("TOB_SUXX","LOCALS",1)
END

IF
    OR(2)
        !Allegiance(Myself,EVILCUTOFF)
        !Detect([GOODCUTOFF])
    Global("TOB_SUXX","LOCALS",1)
THEN
    RESPONSE #100
END
>>>>>>>>

SILENT
COPY_EXISTING_REGEXP GLOB ~BP.*\.bcs~ ~override~
	R_B_B ~...\p5-inlined\src.baf~ ~...\p5-inlined\dest.baf~
BUT_ONLY
VERBOSE

This won't catch other shutoff blocks, obviously, so you might need to repeat this for every one of them.

 

Well aware of that, which is why there's no quick fix available. This will take a lot of time; there's over 300 scripts in the mod to dissect. This is time I don't have currently, nor in the forseeable near future. Nor, at present, even the inclination--I didn't break this and I no longer even play ToB. Thus, I have to pull support for ToB--at the very least, for a GoG version. Use at your own risk, fair warning issued.

 

I can't prove nor disprove that GoG claim, only going on first hand experience over the years. My last BGT run was on my original disc install, and it worked fine. It works fine on the EE engines (both games) right this minute. This GoG install does not work fine, as we've both noted.

 

However, @pro5 I greatly appreciate your diligence in reporting, your support and your code offer. When I do find time, I'll base the work off of it (and naturally, pass along the credits).

Edited by horred the plague, 25 February 2014 - 12:44 PM.

[horred the plague]

And further we go down the rabbit hole...

 

I tried all sorts of stuff, and narrowed it down to 1 line. A very simple script confirmed my results.

 

Remove the Continue() from the following block:

 

IF
    Global("NOBREACH","LOCALS",0)
    !HaveSpell(WIZARD_BREACH)
    !HaveSpell(WIZARD_SPELL_STRIKE)
    !HaveSpell(WIZARD_PIERCE_SHIELD)
    !HaveSpell(WIZARD_RUBY_RAY_OF_REVERSAL)
    !HaveSpell(WIZARD_WARDING_WHIP)
    !HaveSpell(WIZARD_PIERCE_MAGIC)
    !HaveSpell(WIZARD_SECRET_WORD)
    !HaveSpell(WIZARD_SPELL_THRUST)
THEN
    RESPONSE #100
        SetGlobal("NOBREACH","LOCALS",1)
        Continue()
END

 

And that global stagger proposed in the prior thread is no longer needed. It's something to do w/ Continue(), and it doesn't affect EE games. Nor, did it affect the original disc installs. Continue() is causing it to ignore that shutoff, and just plough right over it.

 

This should be a lot easier to address than the other work-around, thankfully. Stopping for today; I'll get something together in the next few days.

[pro5]

Now that you mention it... all we had to do was look in the IESDP under Continue().

Use of continue in a script block will cause the parser to treater subsequent empty response blocks as though they contained a Continue() command - this parsing can be stopped by including a NoAction() in the empty response block.

Good to know EE fixes that.
 

However, @pro5 I greatly appreciate your diligence in reporting, your support and your code offer.

No problem, glad it all worked out in the end.

[Quiet]

There was a problem with the installation of the component "Kensai Ryu's Improved Crypt King":

ERROR: error compiling [bp/baf/new_bad/bpundead.baf]: Sys_error("bp/baf/new_bad/bpundead.baf: No such file or directory")

Solution: in file bp/lib/bp_encounters.tph line 1927:

COMPILE ~bp/baf/new_bad/bpundead.baf~

need change to:

COMPILE ~bp/baf/new_baf/undead/bpundead.baf~

[rainagel]

Hi, guys.

I got an error installing the Ritual component from BP1.81 - 4672 with BWI.bat.

The .bat reported [BP/Ritual/tAR3000.baf] parse error at line 7 column 16-54

After opening that .baf I found this:

ActionOverride(Player1,LeaveAreaLUAPanic("sola0002","",[677.502],NW))

ActionOverride(Player1,LeaveAreaLUA("sola0002","",[677.502],NW))

ActionOverride(Player2,LeaveAreaLUA("sola0002","",[677.502],NW))

ActionOverride(Player3,LeaveAreaLUA("sola0002","",[677.502],NW))

ActionOverride(Player4,LeaveAreaLUA("sola0002","",[677.502],NW))

ActionOverride(Player5,LeaveAreaLUA("sola0002","",[677.502],NW))

ActionOverride(Player6,LeaveAreaLUA("sola0002","",[677.502],NW))

which I believe should be

ActionOverride(Player1,LeaveAreaLUAPanic("sola0002","",[677.502],2))

ActionOverride(Player1,LeaveAreaLUA("sola0002","",[677.502],2))

ActionOverride(Player2,LeaveAreaLUA("sola0002","",[677.502],2))

ActionOverride(Player3,LeaveAreaLUA("sola0002","",[677.502],2))

ActionOverride(Player4,LeaveAreaLUA("sola0002","",[677.502],2))

ActionOverride(Player5,LeaveAreaLUA("sola0002","",[677.502],2))

ActionOverride(Player6,LeaveAreaLUA("sola0002","",[677.502],2))

[horred the plague]

I've seen this one before in other components, and this comes right from Tactics. (Only thing we did to Tactics was fix bugs, like this one, and make it install smoother). BGEE/BG2EE will parse this no problem, and some versions of BG2 also will parse it.

 

 dir.ids   111bytes   357 downloads

 

Here's the dir.ids file from the bg2ee game attached. This should make the installer work. w/o it "should" parse to zero, which is also fine. Facing isn't even used in BG beyond screen effect.

[hook71]

Bug that might be BP-related reported here: http://forum.baldurs...eld-on-level-up

 

Looks like Big Picture overwrites MFIST7.ITM/MFIST8.ITM with two-handed versions in BGII:EE.

[Elve]

Now that you mention it... all we had to do was look in the IESDP under Continue().

Use of continue in a script block will cause the parser to treater subsequent empty response blocks as though they contained a Continue() command - this parsing can be stopped by including a NoAction() in the empty response block.

Good to know EE fixes that.
 

However, @pro5 I greatly appreciate your diligence in reporting, your support and your code offer.

No problem, glad it all worked out in the end.

 

So, what would be the "right" fix for this problem? Adding NoAction() to all those empty blocks?

[micbaldur]

Component "Kensai Ryu's Brown Dragon" has cre typo at BP/BrownDragon/bAR1900.BAF.

 

It has KRDRGBRN and it probably should be BPDRGBRN. More info here.

 

There is also problem at Sahuagin City with Ettin because BP creates Mage Construct (CONST01.CRE) with same script name SAHOTY01. More info here.

 

Lollorian has fixed these in BWP Fixpack.

[agb1]

@horred - we are trying to identify stable components of BP that can be used with or instead of SCS components in BGT games.

 

Observations so far can be found here, mixed with other mod issues:

 

http://www.shsforums...ritized-bg1-bg2

 

I see above that you've withdrawn support for the old engine, but your comments would still be appreciated if you have any insight on the issues we are seeing.

 

Thanks!

[agb1]

BP's Improved Watcher's Keep component (#1750) modifies creatures to use items (DAGG25 and DAGG26 at least, maybe others) that are only installed by BP's Add magic Bags and Throwing Daggers to Stores component (#35).

[The Imp]

Extract this archive to your game directory to fix that ... the report of the file being broken is incorrect.

 

But then again:

Installing [Big Picture, core component (required for most subcomponents)] [v181-b4610]

According to this, that's the WRONG version, use the ...11

Edited by The Imp, 25 March 2016 - 04:10 AM.