CamDawg Posted April 23, 2007 Share Posted April 23, 2007 Please don't post any logical paradoxes, lest my head explode. Quote Link to comment
cmorgan Posted April 23, 2007 Share Posted April 23, 2007 Starfleet to the Rescue! Quick, CamDawg, listen carefully .... "I always tell the Truth. But I AM LYING!" Quote Link to comment
plainab Posted April 24, 2007 Share Posted April 24, 2007 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..... Quote Link to comment
Miloch Posted April 25, 2007 Share Posted April 25, 2007 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. Quote Link to comment
Guest barnabus79 Posted May 26, 2007 Share Posted May 26, 2007 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. Quote Link to comment
Guest Guest Posted May 26, 2007 Share Posted May 26, 2007 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! Quote Link to comment
plainab Posted May 27, 2007 Share Posted May 27, 2007 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... Quote Link to comment
Miloch Posted June 8, 2007 Share Posted June 8, 2007 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 . Quote Link to comment
plainab Posted June 9, 2007 Share Posted June 9, 2007 (edited) 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 June 10, 2007 by plainab Quote Link to comment
Miloch Posted June 9, 2007 Share Posted June 9, 2007 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). Quote Link to comment
jastey Posted August 25, 2007 Share Posted August 25, 2007 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()~ Quote Link to comment
plainab Posted August 29, 2007 Share Posted August 29, 2007 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 Quote Link to comment
jastey Posted August 29, 2007 Share Posted August 29, 2007 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. Quote Link to comment
plainab Posted September 4, 2007 Share Posted September 4, 2007 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.... Quote Link to comment
jastey Posted September 4, 2007 Share Posted September 4, 2007 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? Quote Link to comment
Recommended Posts
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.