grodrigues Posted February 5, 2011 Share Posted February 5, 2011 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
Jarno Mikkola Posted February 5, 2011 Share Posted February 5, 2011 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
grodrigues Posted February 5, 2011 Author Share Posted February 5, 2011 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
Jarno Mikkola Posted February 5, 2011 Share Posted February 5, 2011 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
grodrigues Posted February 5, 2011 Author Share Posted February 5, 2011 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
Mike1072 Posted February 6, 2011 Share Posted February 6, 2011 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
Jarno Mikkola Posted February 6, 2011 Share Posted February 6, 2011 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
Mike1072 Posted February 6, 2011 Share Posted February 6, 2011 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
Jarno Mikkola Posted February 6, 2011 Share Posted February 6, 2011 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
Miloch Posted February 23, 2011 Share Posted February 23, 2011 Will fix the arrow thing and add another C/R (longbow only) option. Since I put it there, I suppose I should tidy it up. So uh, no other bugs in this mod? Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.