Coran and the Wyverns problem

[Guest top1terra1girl]

I'm havin a problem with the wyvern quest. For some reason Kelddath Ormlyr won't take the heads after i kill the wyverns and after 16 days Coran leaves . if anyone has an idea of how to fix it or even a way to stop coran from leavin i will be so greatfull for them to tell me. I really wanna see the romance .

[Daulmakan]

Bring up the console and use this code:

 

CLUAConsole:SetGlobal("SPRITE_IS_DEADX#CoranWyvern","GLOBAL",1)

[Guest top1terra1girl]

Thank you it worked

[Miloch]

Assuming you actually killed the wyvern, is this a mod bug or an engine glitch?

[cmorgan]

I think it is a problem with UB and BG1NPC with the repairs Ascension64 and I worked out - I will recheck his notes and the UB posts...

 

 

...and here is Ascension64's comment:

http://forums.pocketplane.net/index.php/to....html#msg319247

 

Checking the project code now:

 

  /* Create Coran's Wyverns */
 COPY_EXISTING ~%tutu_var%WYVERN.CRE~ ~override/X#CORWYV.CRE~
WRITE_ASCII 0x280 ~X#CoranWyvern~ #32
 BUT_ONLY_IF_IT_CHANGES

 /* put them in the Cave */
 COPY_EXISTING ~%CloakwoodWyverns_WyvernCave%.ARE~ ~override~
READ_LONG 0x54 actors_off
READ_SHORT 0x58 actors_num
FOR (i = 0; i < %actors_num%; i += 1) BEGIN
  READ_ASCII (%actors_off% + %i% * 0x110 + 0x80) actor_resref
	PATCH_IF !(%actor_resref% STRING_COMPARE_CASE "WYVERN") BEGIN
	WRITE_ASCII (%actors_off% + %i% * 0x110 + 0x80) X#CORWYV (8)
  END
END
 BUT_ONLY_IF_IT_CHANGES

/* Changing Coran's old leaving timer */
 COPY_EXISTING ~%CORAN_BCS%.bcs~ ~override~
DECOMPILE_BCS_TO_BAF
  REPLACE_TEXTUALLY CASE_INSENSITIVE
~GlobalTimerExpired("Coran","GLOBAL")~ ~False()~
 COMPILE_BAF_TO_BCS
 BUT_ONLY_IF_IT_CHANGES

 

err... hmmm. I susupect that he is referring to

 

PATCH_IF !(%actor_resref% STRING_COMPARE_CASE "WYVERN") BEGIN

 

that might need to incorporate the _wyvern resref. Checking (again) - I tested this with a code snippet and might not have gotten it moved over. I'll check with Ascension64, too.

 

Something else is failing, too, though - bg1npc falses out the trigger calling on Coran to leave. Perhaps we left out the related dialog? looking...

 

hmmm again. Here's the code.

/* Coran and his Wyverns */
/*wyverns fix */
REPLACE_TRIGGER_TEXT %CORAN_JOINED% ~[dD][eE][aA][dD](\"[wW][yY][vV][eE][rR][nN]\")~ ~Dead("X#CoranWyvern")~

/* Replacing Globals in Coran's Wyvern Misadventure */
REPLACE_STATE_TRIGGER %CORAN_JOINED% 6 ~Global("X#CoranWyvernWarning1","GLOBAL",1)~
REPLACE_TRANS_ACTION %CORAN_JOINED% BEGIN 6 END BEGIN END ~SetGlobal("CoranWyvern","GLOBAL",1)~ ~SetGlobal("X#CoranWyvernWarning1","GLOBAL",2)~

REPLACE_STATE_TRIGGER %CORAN_JOINED% 5 ~Global("X#CoranWyvernWarning2","GLOBAL",1)~
REPLACE_TRANS_ACTION %CORAN_JOINED% BEGIN 5 END BEGIN END ~SetGlobal("CoranWyvern","GLOBAL",2)~ ~SetGlobal("X#CoranWyvernWarning2","GLOBAL",2)~

[Daulmakan]

I'm not sure UB is the problem. I have it installed (without the Coran and the Wyverns component), and just experienced the same thing. Furthermore, Coran only recognised the wyvern being dead and commented on it immediately after the code was set, same thing with Keldath accepting the head. Maybe the wyvern in question doesn't have/isn't setting the variable properly?

[Miloch]

PATCH_IF !(%actor_resref% STRING_COMPARE_CASE "WYVERN") BEGIN

 

that might need to incorporate the _wyvern resref.

Could well be, from the looks of it. Wondering why clone the existing CRE and patch the area for a new reference though... can't you just patch the existing CRE?

[cmorgan]

Well, Ascension64 is even more concerned about preserving existing resources for other modders than I am

 

Patching the existing base resource means everyone else inherits the changes (or blows them away). So this way, the resource is cloned, changed, and patched into the area as a new resource.

 

Confirming, using Tiamon's last posted build of NI in his PPG forum thread + clean vanilla latest version of Macready's EasyTutu_ToB,

 

FW4501.ARE has 5 actors, 3 = baby wyvern and 2 = wyvern.

 

Actor "wyvern" has a name of "wyvern" and a .cre reference of _WYVERN.CRE

 

_WYVERN.CRE = dv wyvern

 

But that does not make sense to me. I must not be understanding something.

 

I thought this code was reading the entry in the area file, which is Wyvern, which I thought was the dv... if that is the case, then it should be picking it up and changing it. Hold on...

 

 

er... ok, out of time for today. Will try rechecking an install tomorrow.

[Wisp]

PATCH_IF !(%actor_resref% STRING_COMPARE_CASE "WYVERN") BEGIN

 

that might need to incorporate the _wyvern resref. Checking (again) - I tested this with a code snippet and might not have gotten it moved over. I'll check with Ascension64, too.

Aside from the %tutu_var%, the %actor_resref% for the STRING_COMPARE needs to be quoted and the syntax for the WRITE_ASCII needs a slight correction. Like so:

 

READ_ASCII (%actors_off% + %i% * 0x110 + 0x80) actor_resref
  PATCH_IF !("%actor_resref%" STRING_COMPARE_CASE "%tutu_var%WYVERN") BEGIN
	WRITE_ASCII (%actors_off% + %i% * 0x110 + 0x80) X#CORWYV #8
  END

[Miloch]

Well, Ascension64 is even more concerned about preserving existing resources for other modders than I am

Well, it's the polite thing to do .

Patching the existing base resource means everyone else inherits the changes (or blows them away). So this way, the resource is cloned, changed, and patched into the area as a new resource.

It'd only be an issue if someone else changed the DV, which I think is unlikely (in fact, it should have an existing DV which would work just as well for BG1 NPC's purpose). SCS, for example, gives the wyvern a new script (probably to make it "smarter") but I don't know if it accounts for a cloned wyvern. It might, knowing SCS, but not sure that goes for other mods that might want to, say, patch an item onto the wyvern or whatever.

[cmorgan]

Cool - but I still need to doublecheck -

 

The NI read of the entry in the area file says the actor is called "Wyvern". It is only after clicking on it that the resource _WYVERN.CRE opens...

 

is this

 

READ_ASCII (%actors_off% + %i% * 0x110 + 0x80) actor_resref

 

picking up the dv, or the .cre? Which one of these is linked in the area file here?

 

I do see that the IESDP shows

 

0x0080 = 8 (resref) = CRE file. What i am not sure about is what happens when we have

 

0x0000 32 (char array) Name = Wyvern

 

but we have

 

0x0080 = 8 (resref) = CRE = X#CORWYV

 

and a DV of X#CoranWyvern

[Mike1072]

is this

 

READ_ASCII (%actors_off% + %i% * 0x110 + 0x80) actor_resref

 

picking up the dv, or the .cre? Which one of these is linked in the area file here?

This is reading the .cre name, as your quote from the IESDP shows at offset 0x80 in an actor block of an area. The DV is not listed within areas at all.

 

The reason why the variable is not being updated when the wyvern is killed is because this code is failing to replace the existing wyvern with the one with the custom DV when installed on Tutu.

 

0x0000 32 (char array) Name = Wyvern

This is just a description of the actor within the area. I don't think it affects much at all.

[cmorgan]

Repaired, matching Wisp's syntax -

  /* Create Coran's Wyverns */
 COPY_EXISTING ~%tutu_var%WYVERN.CRE~ ~override/X#CORWYV.CRE~
WRITE_ASCII 0x280 ~X#CoranWyvern~ #32
 BUT_ONLY_IF_IT_CHANGES

 /* put them in the Cave */
 COPY_EXISTING ~%CloakwoodWyverns_WyvernCave%.ARE~ ~override~
READ_LONG 0x54 actors_off
READ_SHORT 0x58 actors_num
FOR (i = 0; i < %actors_num%; i += 1) BEGIN
  READ_ASCII (%actors_off% + %i% * 0x110 + 0x80) actor_resref
  PATCH_IF !("%actor_resref%" STRING_COMPARE_CASE "%tutu_var%WYVERN") BEGIN
	WRITE_ASCII (%actors_off% + %i% * 0x110 + 0x80) X#CORWYV #8
  END
END
 BUT_ONLY_IF_IT_CHANGES

09.17.2009 v18

 

docs

<li> <a href="http://forums.gibberlings3.net/index.php?s=&showtopic=18104&view=findpost&p=156884"> Wisp's repairs to Coran's Wyverns Address </a></li>

[cmorgan]

Tested - fixed! Will test on BGT.

[ussnorway]

Tested - fixed! Will test on BGT.

Sorry but it is still around guys. I just got this bug again, with my easytutu game.