19 replies to this topic

[Daulmakan]

Bring up the console and use this code:

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

[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]

cmorgan, on Aug 19 2009, 10:00 AM, said:

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]

cmorgan, on Aug 19 2009, 04:00 PM, said:

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]

cmorgan, on Aug 20 2009, 10:33 AM, said:

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

Well, it's the polite thing to do .

Quote

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]

cmorgan, on Aug 21 2009, 04:29 PM, said:

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.

Quote

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]

cmorgan, on Sep 18 2009, 10:16 AM, said:

Tested - fixed! Will test on BGT.

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