26 replies to this topic

[Miloch]

This patch requires that the modified rings are created at the beginning of the mod

Ok, but the ring cloning is only necessary if someone picks the Skeleton Warrior component, no? And then, it only needs one version of the ring depending on which choice the user makes, right?

Though there are some creatures in the Distinctive Undead component that might need one or the other too...

[Turambar]

This patch requires that the modified rings are created at the beginning of the mod

Ok, but the ring cloning is only necessary if someone picks the Skeleton Warrior component, no? And then, it only needs one version of the ring depending on which choice the user makes, right?

Though there are some creatures in the Distinctive Undead component that might need one or the other too...

I think that the distinctive undead only need the non-glowing ring99 (all those who get the barrow wight animation need a check), whereas only one of the three possibilities for the skeleton warriors would need the glowing ring95.

The only animation which must receive the glow effect is the skeleton, and it's only used in that IA component, so it could be just put there, that's right.

[Turambar]

I've found how to pass the glow color to the add_item_eqeffect function.

These should be the two pieces, the former to be put in the main component, the latter in the skeleton warriors component (if you chose the skeleton animation):

ACTION_IF FILE_EXISTS_IN_GAME ring99.itm AND NOT FILE_EXISTS_IN_GAME ringn99.itm THEN BEGIN
	COPY_EXISTING ~ring99.itm~ ~override/ringn99.itm~
	PATCH_IF (%SOURCE_SIZE% > 0x71) THEN BEGIN // file size sanity check (filters out 0 byte files i.e. ALLOW_MISSING)
		SET opcode_to_delete = "8"
		LAUNCH_PATCH_MACRO ~DELETE_ITEM_EQEFFECT~ //remove glow
	END
END

ACTION_IF FILE_EXISTS_IN_GAME ring95.itm AND NOT FILE_EXISTS_IN_GAME ringg95.itm THEN BEGIN
	COPY_EXISTING ~ring95.itm~ ~override/ringg95.itm~ //glowing version of the ring
	PATCH_IF (%SOURCE_SIZE% > 0x71) BEGIN // file size sanity check (filters out 0 byte files i.e. ALLOW_MISSING)
		LAUNCH_PATCH_FUNCTION ADD_ITEM_EQEFFECT //makes it glow
			 INT_VAR opcode = 8 // set colorglow solid
				 target = 1 //self
				 timing = 2 // while equipped
				 parameter1 = 0xc800	//green/blue/red/2 empty
				 parameter2 = 2 // Major Color
				 probability1 = 100 // probability1: 100%
		END
	END
END

[Miloch]

Thought you already coded it with ADD_ITEM_EQEFFECT. Though like I said, using it as a FUNCTION is better than a MACRO because you don't need to intialise all the zero values with the function.

[Turambar]

Thought you already coded it with ADD_ITEM_EQEFFECT. Though like I said, using it as a FUNCTION is better than a MACRO because you don't need to intialise all the zero values with the function.

I didn't change it there because it needed one parameter only.

I've tried to re-write the patch as well; the variables ringn99need and ringg95need , if set, could maybe be used to only patch the rings if needed.

sz = SOURCE_SIZE	//begin glowcheck
		PATCH_IF ("%sz%" > "0x2d3") BEGIN
			PATCH_IF SHORT_AT 0x28 = 0x6403 BEGIN  //skeleton
				SET glow=1
			END ELSE BEGIN
				SET glow=0
			END
			READ_LONG 0x2bc itemsoffset
			READ_LONG 0x2b8 itemslot
			READ_LONG 0x2c0 items
       		READ_SHORT (%itemslot% + 0x08) ring  //left ring
			SET hasitem = 0
			FOR (i = 0; i < 21; i += 20) BEGIN
    			PATCH_IF NOT (%ring% = 65535) BEGIN //has any ring there
					SET lring = %itemsoffset% + 20*%ring%
       				READ_ASCII %lring% rname
    				PATCH_IF NOT ("%rname%" STRING_CONTAINS_REGEXP ~ring[g-n]?9~) BEGIN //immunity ring
       					PATCH_IF hasitem BEGIN
							REMOVE_CRE_ITEM RING95    //remove duplicated rings
							REMOVE_CRE_ITEM RING99    //remove duplicated rings
							REMOVE_CRE_ITEM RINGG95    //remove duplicated rings
							REMOVE_CRE_ITEM RINGN99    //remove duplicated rings
        				END									//now, he doesn't have any more, but remembers the old one
   						PATCH_IF glow BEGIN
   							PATCH_IF ("%rname%" STRING_CONTAINS_REGEXP ~ring[g-n]?99~) BEGIN	//ring95
   								WRITE_ASCII %lring% ~RINGG95~ #7 //change ring with glowing bg2 version
   								SET ringg95need = 3				//need modded ring
   							END ELSE BEGIN
   								WRITE_ASCII %lring% ~RING99~ #7 //change ring with glowing bg1 version
   							END
   						END ELSE BEGIN			//noglow
   							PATCH_IF ("%rname%" STRING_CONTAINS_REGEXP ~ring[g-n]?99~) BEGIN	//ring95, contains is true if not contains
   								WRITE_ASCII %lring% ~RING95~ #7 //change ring with unglowing bg2 version
   							END ELSE BEGIN
   								WRITE_ASCII %lring% ~RINGN99~ #7 //change ring with unglowing bg1 version
    								SET ringn99need = 3				//need modded ring
  							END
						END
						SET hasitem = 1
					END //immring
					READ_SHORT ("%itemslot%" + 0x0a) "ring"  //right ring
				END //have ring
			END //for
		END //sz>0

[Miloch]

So does that code replace your earlier code or is it additional?

Stuff like this:

WRITE_ASCII %lring% ~RING99~ #7

Will likely mess up the .cre file, because you're writing 6 characters to an 8-character offset (and calling it 7 characters). Should probably just use #8 after all those WRITE_ASCIIs. Have you tested it?

[Turambar]

So does that code replace your earlier code or is it additional?

It replaces it: the previous code was actuallly quite long and the remove_cre_item was misused.

Stuff like this:

WRITE_ASCII %lring% ~RING99~ #7

Will likely mess up the .cre file, because you're writing 6 characters to an 8-character offset (and calling it 7 characters). Should probably just use #8 after all those WRITE_ASCIIs. Have you tested it?

Yes, I have; I've written a fix for Icharyd to remove his glowing and his ghast class.

I actually put #7 because I expect this to be only used where there's already ring95, ring99, or a modded version of those, so the 8th ASCII should already be NULL, and is not touched by this mod. Anyway, we could use #8 just to be sure.

Edited by Turambar, 08 September 2010 - 12:19 AM.