Jump to content

Arrows for Cleric + Ranger


grodrigues

Recommended Posts

With the latest Level 1 NPC (vers. 1.5 + 1.6 hotfix) if you allow Cleric + Ranger to wield Long swords and long bows in the proficiency component, the usability of these are set correctly but not the usability of arrows. And bows without arrows are not much use.

 

It should be of no use to the WeiDU ninjas prowling this forum, but anyway, I have coded for myself the following fix.

 

// Fixing Level 1 NPCs oversight.

BACKUP ~cr_arrows\backup~
AUTHOR ~G. Rodrigues~
VERSION ~v0.1~

BEGIN ~Fix Level 1 NPCs oversight: make arrows usable by Cleric + Rangers.~

PRINT ~Fixing arrows.~
COPY_EXISTING_REGEXP ~arow.*\.itm~ ~override~
PATCH_IF (%SOURCE_SIZE% > 0x71) BEGIN
	READ_BYTE 0x1c TYPE
	READ_LONG 0x1e USABILITY
	// Only if the type is arrow.
	PATCH_IF (%TYPE% = 5) BEGIN
		WRITE_LONG 0x1e (%USABILITY% BAND 0b01000000010011001101001111000000)
	END
END
BUT_ONLY_IF_IT_CHANGES

PRINT ~Fixing quivers.~
COPY_EXISTING_REGEXP ~quiver.*\.itm~ ~override~
PATCH_IF (%SOURCE_SIZE% > 0x71) BEGIN
	READ_BYTE 0x1c TYPE
	READ_LONG 0x1e USABILITY
	// Only if the type is arrow.
	PATCH_IF (%TYPE% = 5) BEGIN
		WRITE_LONG 0x1e (%USABILITY% BAND 0b01000000010011001101001111000000)
	END
END
BUT_ONLY_IF_IT_CHANGES

// Item upgrade compatibility.
ACTION_IF FILE_EXISTS_IN_GAME ~c2quiv01.itm~ BEGIN
PRINT ~Fixing Item Upgrade quiver.~
COPY_EXISTING ~c2quiv01.itm~ ~override~
	PATCH_IF (%SOURCE_SIZE% > 0x71) BEGIN
		READ_BYTE 0x1c TYPE
		READ_LONG 0x1e USABILITY
		// Only if the type is arrow.
		PATCH_IF (%TYPE% = 5) BEGIN
			WRITE_LONG 0x1e (%USABILITY% BAND 0b01000000010011001101001111000000)
		END
		// Correct proficiency.
		READ_BYTE 0x31 PROFICIENCY
		PATCH_IF (%PROFICIENCY% != 0x02) BEGIN
			WRITE_LONG 0x31 0x02
		END
	END
	BUT_ONLY_IF_IT_CHANGES
END

 

Btw, I have the following request: is it possible to add a fourth option to Cleric + Ranger to add only longbow proficiencies?

 

Regards,

G. Rodrigues

 

Edit: fix comment in code.

Link to comment
COPY_EXISTING_REGEXP ~arow.*\.itm~ ~override~
The arow... items are not every arrow in the game, at least in a moded game, so why not just use ...
BEGIN ~Ranger Cleric Bow Fix~

COPY_EXISTING_REGEXP GLOB ~.*\.itm~ ~override~
READ_SHORT 0x1c type
PATCH_IF type = 5 OR type = 15 THEN BEGIN
READ_BYTE 0x1f unus
WRITE_BYTE 0x1f (unus BAND 11111011)
END
BUT_ONLY

The type can also be ~0x0005~ or ~0x000f~ ... this was copied from elsewhere...

Link to comment
COPY_EXISTING_REGEXP ~arow.*\.itm~ ~override~
The arow... items are not every arrow in the game, at least in a moded game, so why not just use ...

 

<snip>

 

Yeah you probably are right. I am a WeiDU newbie and felt a bit nervous about looping over all .itm files

 

aside note: and for someone like me who has most of his programming needs covered by Python, WeiDU, though a fine piece of software, feels like trying to dig the earth with your bare hands.

 

About type 0x000f, according to IESDP it corresponds to Hammers and thus already useable by Cleric + Rangers, so there is no need to add a check for it. Please correct me, if I am wrong.

 

Regards.

G. Rodrigues

Link to comment

Well, to me the WeiDU.tp2 is the first and only actual code language... so try there. ???

Well, there was a bit of CNC coding, but it's totally somewhat unrelated........

 

About type 0x000f, according to IESDP it corresponds to Hammers and thus already useable by Cleric + Rangers, so there is no need to add a check for it. Please correct me, if I am wrong.
You are talking about the 0x0015 which is not same as 15, as the "...= 0x0015" is a hexadecimal number(1*16+5) indicator, while the bow is "...= 15" is regular number, so 1*10+5 or 0x000f, like said.

Here's the item types as of reference.

Link to comment
About type 0x000f, according to IESDP it corresponds to Hammers and thus already useable by Cleric + Rangers, so there is no need to add a check for it. Please correct me, if I am wrong.
You are talking about the 0x0015 which is not same as 15, as the "...= 0x0015" is a hexadecimal number(1*16+5) indicator, while the bow is "...= 15" is regular number, so 1*10+5 or 0x000f, like said.

Here's the item types as of reference.

 

Of course, stupid me.

 

But as I said in my first post, Level 1 NPC already fixes usability of bows for Cleric + Ranger, so that is why I have not included them -- but yes, if I wanted to be thorough I probably should include it as well.

 

Regards,

G. Rodrigues

Link to comment

It's a good idea to patch all files if you can devise a good filter to ensure you don't change anything you shouldn't. For example, if you make all arrows and bows usable by cleric/rangers, you may unintentionally give them access to NPC-specific or class-specific items that they really shouldn't be able to use. You can prevent this by first checking that an item is usable by rangers before giving cleric/rangers access to it.

 

Also, a quick comment on this code in your first post:

WRITE_LONG 0x1e (%USABILITY% BAND 0b01000000010011001101001111000000)

This is going a little overboard if you just intend to make the items usable by cleric/rangers. With binary operations like BAND and BOR, you have the power to modify just the bits that you need to change. Jarno gives a good example of changing only the bit that affects cleric/rangers, once you correct for the typo (11111011 is not the same as 0b11111011).

 

WRITE_BYTE 0x1f (unus BAND 0b11111011)

Link to comment
once you correct for the typo (11111011 is not the same as 0b11111011).
I believe that in this case it is not a typo, cause I have used the above code... see the WeiDU as it reads the "READ_BYTE 0x1f unus" can assume that the byte is processed as binary... of course it is smarter to make sure with the 0b...
Link to comment
once you correct for the typo (11111011 is not the same as 0b11111011).
I believe that in this case it is not a typo, cause I have used the above code... see the WeiDU as it reads the "READ_BYTE 0x1f unus" can assume that the byte is processed as binary... of course it is smarter to make sure with the 0b...

Okay, it's not a typo - it's an error.

 

11111011 is a base 10 number - the kind everyone's familiar with - and WeiDU does not magically treat it as a base 2 number just because you want it to. WeiDU gives you a special ability to specify a number in base 2 format, using the 0b prefix.

 

0b11111011 represents the base 10 number 251. You could use WRITE_BYTE 0x1f (unus BAND 251) in place of WRITE_BYTE 0x1f (unus BAND 0b11111011) and they would have the same effect. Using WRITE_BYTE 0x1f (unus BAND 11111011) would have a completely different effect. (Though if your code was using one of the following values instead, you'd be prevented from realizing your mistake: 0, 1, 10000, 10001, 1000000, 1000001, 1010000, 1010001, 10000000, 10000001, 10010000, 10010001, 11000000, 11000001, 11010000, 11010001.)

Link to comment
Okay, it's not a typo - it's an error.
Yep, as the 10 based number "11111011" is actually just "99" as a byte, with is 0b01100011... which allows the bows and arrows to be usable by Fighter/Mage/Cleric, Fighter/Druid, Fighter, and Ranger/Clerics... ???
Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...