Jump to content

BG1 Fixpack ?


Guest plainab

Recommended Posts

Starfleet to the Rescue! Quick, CamDawg, listen carefully .... "I always tell the Truth. But I AM LYING!"

Do you say that while standing? If so, then it is truly a mind blower.

 

Else you're just lying down somewhere..... :)

Link to comment

Eh... well that actually makes sense as a paradox, perhaps even a witty one. But as to this:

The Dawg has no sense of humour. It's one of those unfortunate side-effects of being a robot.
I don't see the paradox - not that it was intended as one necessarily. Unless you interpret Dawg = dog, in which case there *are* robot dogs, so I really don't get the paradox, if there was supposed to be one. But I am rather dim, being a half-orc and all.
Link to comment
Guest barnabus79

Well, since this seems to be the place to post about bugs / fixes for BG - I got hit with a bug involving yeslick that doesn't seem to have been addressed anywhere (though I can't be certain about this - alas, I only learned about all these various fix packs AFTER being hit by this bug... and thus I'm now far enough into the game I'm not sure I want to try installing any of the various fixpacks out there...)

 

Basically, if you at one point had (or still have) Yeslick in your

party, but don't finish the Cloakwood Mines in time, if Yeslick ever

sees you before you finish he will approach you and continuously ask

to join... but even if you do add him, he immediately drops, and continues spamming you. (Assuming that your reputation is good enough that he's

"happy," and doesn't storm off when he leaves.)

 

I know I'm not the only one who's experienced this:

 

http://www.gamebanshee.com/forums/baldurs-...-bug-57842.html

http://forums.bioware.com/viewtopic.html?t...22&forum=19

 

After looking at the scripts, I think the reason lies in YESLIJ.DLG.

For some reason, the state where he gets mad and leaves has been

disabled - it's trigger condition is set to false. I changed it so

that it triggers if he's already warned you he was getting impatient,

and the timer started when he does so has expired:

 

GlobalTimerExpired("Yeslick","GLOBAL")

Global("MineFlood","GLOBAL",1)

 

Another potential problem might be that in the YESLICK.BCS file, there

is no check that yeslick is in the party before he initiates the

dialogue, as there is with most characters who leave the party after a

certain time if you haven't done something; ie, his condition is

 

IF

GlobalTimerExpired("Yeslick","GLOBAL")

Global("FLOODED","GLOBAL",0)

THEN

RESPONSE #100

Dialogue([PC])

END

 

while most timer-dependent NPCs have an 'InParty(Myself)" check as

well (ie, micsc, khalid/jaheira, coran, etc... though, oddly, not

Kagain.. maybe dwarves just don't give a damn if they're in your party

or not!)

 

(Also - note the ever-so-distinguishable-and-not-at-all-easy-to-get-mixed-up variable names "FLOODED" and "MineFlood" that bioware chose to use... yay!)

 

I'm not sure whether the InParty check should be included, however,

since if it is, it leads to the rather strange situation where you can

ask him to join, and he seems perfectly happy to do so... until, of

course, he actually DOES join, at which point he tells you off for

taking too long, and storms off. From a game-world believability

standpoint, it makes more sense that he would come up to the PC and

tell him off for taking too long, and then scoot, even if he wasn't in

the party.

 

Of course, I personally don't like having potential party members

disappear from the game forever simply because I happened to get near

them, so for my own game I went ahead and changed YESLICK.BCS, and

continuity issues be damned. I tested it with the standard

YESLICK.BCS, though, and it seems to work fine.

Link to comment
Guest Guest

Hmm... ok, actually, on further consideration, I think you DO need the InParty(Myself) check as well, since, now that I think about it, he also spams you with join requests when his first timer expires (the one where he simply warns you that you're moving a mite slow). I'd forgotten about this once since, at least in this case, if you simply accept him he'll stop spamming you, so it wasn't the show stopping bug that you get when his second timer expires.

 

Unfortunately - this means I'm not sure how best to address the potential continuity issues. Perhaps add a timer / "MineFlood" check in YESLIP.DLG as well, that then jumps to the appropriate state within YESLIJ.DLG?

 

Of course... I believe by simply adding in the InParty(Myself) check to YESLICK.BCS, and the appropriate trigger checks to YESLIJ.DLG, you now make Yeslick behave exactly the same as most other quit-on-timer NPCs (Coran, Minsc, etc)... which means that I think these other NPCs also potentially have this game continuity issue.

 

I'll have to check that later today though... don't have time at the moment.

 

Ugh... you know, when I first ran into this bug, I thought it should be so easy to fix... but then I had to learn exactly how the DLG system worked... which meant I needed to learn all about the scripting system... and now I'm wondering if I need to apply some sort of uniform fix to half the NPCs in the game. Why the hell couldn't I have just slapped the InParty check on, and be done with it?

 

Cuuuurse you Infinity Engine.... currrse youuu!

Link to comment

Regarding the Yeslick issue in the two posts prior...

 

Thank you for bringing this to our attention. We have in fact been aware of this issue and a fix has been developed, at least in theory if not in practice. I will look into it once again and make sure that all aspects of the fix are properly coded.

 

IF you have a save prior to first time you entered the cloakwood mine level where Yeslick can be found and you would like to test the proposed fix, let us know. With Miloch's help I'm sure we can figure out a way to get you what you would need...

Link to comment

I believe we have a working fix for the Yeslick issue. This seems to crop up frequently on various forums (like here), perhaps as often as the Lothander/Marek bug for which we also have a fix. And when I say "we" I really mean "plainab" who has done the majority (if not all) of the work.

 

We have tons more open issues to sort out for the BG1 Fixpack. But what I'm proposing is to make this Yeslick fix, and maybe a few others that crop up a lot, available as a mini-mod, or a pre-alpha, or whatever you want to call it. And I'll package it and host it on my server in the absence of CamDawg or a real admin to make it "official" (which it isn't in any case, as yet). However, all bug reports and support issues will go directly to plainab :(.

Link to comment
However, all bug reports and support issues will go directly to plainab :(.
Yes, if you have a real bug or issue let me know. Otherwise, if you just want to complain for no reason send those coments to Miloch. That's something even a Half-Orc can handle. ;)

 

 

Seriously though, do let me know of any issues that you may have when trying out these fixes. Thank you.

 

 

EDIT: Okay, okay... Put that axe down! I'll go an fix it...

Edited by plainab
Link to comment
Otherwise, if you just want to complain for no reason send those coments to Miloch. That's something even a Half-Ogre can handle. ;)
Half-orc - get it right :(.

 

I guess I should point out that there isn't, as yet, any Fixpack to download here. I was just offering to package what we have and put it out there if there's any immediate need for the fixes mentioned. But it not, we'll just keep clicking away at it (and by "we," I mean plainab again).

Link to comment

Maybe you already squashed this bug:

 

in IMOENP.dlg, Imoen's leaving dialogue, in state 2, the action reads

 

~JoinParty() SetGlobal("KickedOut","LOCALS",0)~

 

In this order, the setting of the variable does not get performed, at least not in BG1Tutu, independent of LOCALS or GLOBAL variable, leading to Imoen giving her "left and return" dialogue upon kickout after the second kick out.

 

Instead, it should read

 

~SetGlobal("KickedOut","LOCALS",0) JoinParty()~

Link to comment
Maybe you already squashed this bug:

 

in IMOENP.dlg, Imoen's leaving dialogue, in state 2, the action reads

 

~JoinParty() SetGlobal("KickedOut","LOCALS",0)~

 

In this order, the setting of the variable does not get performed, at least not in BG1Tutu, independent of LOCALS or GLOBAL variable, leading to Imoen giving her "left and return" dialogue upon kickout after the second kick out.

 

Instead, it should read

 

~SetGlobal("KickedOut","LOCALS",0) JoinParty()~

Will look into it.

Thanks

Link to comment

We found more:

 

JAHEIP - actions need to be changed

 

IF ~~ THEN BEGIN 7 // from: 1.0
 SAY #96028 /* ~So soll es denn sein. Gorion hat Euch unterrichtet, so gut er konnte, und offenbar ist einiges von seinem Wissen an Euch haften geblieben.~ */
 IF ~~ THEN DO ~JoinParty()
SetGlobal("KickedOut","LOCALS",0)
~ EXIT
END

 

QUAYLP - setting of Global("KickedOut","LOCALS",0) is missing

 

IF ~~ THEN BEGIN 2 // from: 0.1
 SAY #96194 /* ~Natürlich! Ihr wäret ein vollkommener Schwachkopf, wenn Ihr nicht so denken würdet. Dann mal los!~ */
 IF ~~ THEN DO ~JoinParty()
~ EXIT
END

 

BG1NPC solves this by replacing "JoinParty()" with "ActionOverride("npcx",JoinParty())" in JAHEIP and IMOENP. At least that was the last status I know of.

Link to comment

Maybe you already squashed this bug:

 

in IMOENP.dlg, Imoen's leaving dialogue, in state 2, the action reads

 

~JoinParty() SetGlobal("KickedOut","LOCALS",0)~

 

In this order, the setting of the variable does not get performed, at least not in BG1Tutu, independent of LOCALS or GLOBAL variable, leading to Imoen giving her "left and return" dialogue upon kickout after the second kick out.

 

Instead, it should read

 

~SetGlobal("KickedOut","LOCALS",0) JoinParty()~

Will look into it.

Thanks

I looked into it. I must say that it is apparently a tutu or modded tutu issue. There is no global set anywhere within the imoenp.dlg file. For your reference, I looked at the unmoddifed original non-totsc file.

In looking at my heavily moddified easytutu file I did notice such a global variable, but I've got a ton of mods installed and am unsure if any modifiy the imoenp.dlg file.

BG1NPC solves this by replacing "JoinParty()" with "ActionOverride("npcx",JoinParty())" in JAHEIP and IMOENP. At least that was the last status I know of.

I have bg1npc internal beta installed and there were still the simple JoinParty() commands within the imoenp.dlg file (which I looked up at the first mention of this issue) So, I am unsure of what's going on....

 

If I can determine what's going on, I'll let ya know....

Link to comment

I didn't check vanilla P.dlgs, that is true, my apologies if it doesn't apply there. (I didn't came to my mind there could be differences, but then I have no idea how the Tutu conversion works.)

 

The fix in BG1NPC was introduced not long ago, which internal version were you looking at?

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...