Lundar Posted June 19, 2017 Share Posted June 19, 2017 Hello, could someone please check the following mods: Ruad Rolles Konolan Tweaks (at least for the rod of Refuge) That are some simple yet special merchants. They -should- be compatible; they only add some items well and one area for the Konolan mod... But I am no modder, perhaps someone has tested them ? Greetings Lundar Quote Link to comment
Roxanne Posted June 19, 2017 Share Posted June 19, 2017 Hello, could someone please check the following mods: Ruad Rolles Konolan Tweaks (at least for the rod of Refuge) That are some simple yet special merchants. They -should- be compatible; they only add some items well and one area for the Konolan mod... But I am no modder, perhaps someone has tested them ? Greetings Lundar Technically they should be compatible, the issue are the item descriptions and bams that will not follow EE standards. So the original modder needs to invest some work, this is not done by simple conversion tool. Anyway, if you can live with the cosmetic issues, you could try them. There should be little risk that they bug your game. Quote Link to comment
Sam. Posted June 19, 2017 Share Posted June 19, 2017 What's the issue with the BAMs? If it's just the description images being 1 frame instead of 4, I can probably batch convert those fairly handily. If it's that the description BAMs won't match the darker SoD theme, that's harder. EE BAMs have gone through several iterations of various changes over the years. Is there a discrepancy between the old and newest item BAMs? Quote Link to comment
Roxanne Posted June 19, 2017 Share Posted June 19, 2017 What's the issue with the BAMs? If it's just the description images being 1 frame instead of 4, I can probably batch convert those fairly handily. If it's that the description BAMs won't match the darker SoD theme, that's harder. EE BAMs have gone through several iterations of various changes over the years. Is there a discrepancy between the old and newest item BAMs? I am no expert for bams honestly, just an observer here. Maybe due to those changes you mentioned sometimes they are not displayed or odd or oddset for mod made items. It probably depends on how the author once made them. This may oe may not be something in the above mentioned mods, I do not know them myself. Itt was just a reminder that of you try them in EE they may work or have minor issues but nothing that should hinder you from trying. Quote Link to comment
Sam. Posted June 19, 2017 Share Posted June 19, 2017 What's the issue with the BAMs? If it's just the description images being 1 frame instead of 4, I can probably batch convert those fairly handily. If it's that the description BAMs won't match the darker SoD theme, that's harder. EE BAMs have gone through several iterations of various changes over the years. Is there a discrepancy between the old and newest item BAMs? I am no expert for bams honestly, just an observer here. Maybe due to those changes you mentioned sometimes they are not displayed or odd or oddset for mod made items. It probably depends on how the author once made them. This may oe may not be something in the above mentioned mods, I do not know them myself. Itt was just a reminder that of you try them in EE they may work or have minor issues but nothing that should hinder you from trying. If you (or anyone else for that matter) run across vanilla or mod-added BAMs that don't display correctly or don't match current EE standards, please bring them to my attention: I would like to investigate them further. Structural errors, incorrect dimensions or offsets, wrong orientation (e.g. weapon item icons oriented in the wrong direction), item icon shadows in the wrong direction: these types of thing are generally easy for me to fix. Anything requiring actual artistic talent or voodoo magic with Photoshop... not so much Quote Link to comment
Gwendolyne Posted June 21, 2017 Share Posted June 21, 2017 (edited) If I can help, I was so upset to create hundreds of specific bams for BG2:EE that I wrote the following small workaround to avoid my inventory bams which display different frame 0 and frame 1 (I mean different images, not 32x32 and 64x64 versions of the same picture) not to work in BG:EE inventory screens. I know this coding is not perfect and might be improved but it works. DEFINE_PATCH_FUNCTION ~GW_CONVERT_INVENTORY_BAM_TO_EE~ BEGIN // Read bam. // --------- READ_ASCII 0x0 sg (4) // Signature READ_ASCII 0x0 sn (3) // Short signature // Decompressed if needed. // ----------------------- PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN READ_LONG 0x8 dl // Uncompressed data length DECOMPRESS_REPLACE_FILE 0xc (SOURCE_SIZE - 0xc) dl END ELSE BEGIN dl = SOURCE_SIZE // Uncompressed data length END // Add frame 0 as second frame in the first sequence. // -------------------------------------------------- PATCH_IF (~%sn%~ STRING_EQUAL_CASE ~BAM~ = 1) BEGIN READ_SBYTE 0x0a cc // Count of cycles PATCH_IF (cc = 2) BEGIN // only 2 cycles = inventory bam (ground and description have 1 or 4 frames). READ_SHORT 0x08 fc // Frame count READ_LONG 0x0c fn // Frame entry offset READ_LONG 0x14 lu // Offset (from start of file) to frame lookup table READ_SHORT (fn + (fc * 0xc)) c_fnb0 // Count of frame indices in 1st cycle WRITE_SHORT (fn + (fc * 0xc)) (c_fnb0 + 1) // Adds one frame in 1st cycle END END // Recompressed if needed. // ----------------------- PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN COMPRESS_REPLACE_FILE 0 dl 9 INSERT_BYTES 0x0 0xc WRITE_ASCII 0x0 ~BAMCV1 ~ WRITE_LONG 0x8 dl END END // of DEFINE_PATCH_FUNCTION Then in the tp2 : ACTION_IF (GW_EE) BEGIN ACTION_BASH_FOR ~%MOD_FOLDER%/Bam/~ ~^.+\.bam$~ BEGIN COPY ~%BASH_FOR_FILESPEC%~ ~override~ LPF ~GW_CONVERT_INVENTORY_BAM_TO_EE~ END BUT_ONLY END END Edited June 21, 2017 by Gwendolyne Quote Link to comment
Sam. Posted June 21, 2017 Share Posted June 21, 2017 @Gwendolyne Well this is downright cool. Can I implement this in BAM Batcher? You will be credited of course Quote Link to comment
Gwendolyne Posted June 21, 2017 Share Posted June 21, 2017 If I didn't want to share it, I would not have posted it. Of course, you can use it and even modify it. You have most probably recognized blocks of code borrowed from Bam Batcher. Quote Link to comment
Sam. Posted June 26, 2017 Share Posted June 26, 2017 I know this coding is not perfect and might be improved but it works. I have studied your code and found the following: // Count of Cycles is not signed, so should use BYTE not SBYTE Code does not take into consideration that: 0th cycle may already have more than 1 frame (was already processed). 1st cycle may be blank (no frames), thus has no frames to add to 0th cycle. The “Large” frame may arbitrarily be Frame_0 or Frame_1. Same goes for the “Small” frame. This must be taken into consideration. The Frame Lookup Table may store the frames as {0,1} or as {1,0}, thus simply adding 1 to the frame count of the 0th cycle may produce unexpected results. My current working version is: DEFINE_PATCH_FUNCTION ~gw_convert_inventory_bam_to_ee~ BEGIN // Read bam. // --------- READ_ASCII 0x0 sg (4) // Signature READ_ASCII 0x0 sn (3) // Short signature // Decompressed if needed. // ----------------------- PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN READ_LONG 0x8 dl // Uncompressed data length DECOMPRESS_REPLACE_FILE 0xc (SOURCE_SIZE - 0xc) dl END ELSE BEGIN dl = SOURCE_SIZE // Uncompressed data length END // Add "small" frame as second frame in the first sequence. // -------------------------------------------------- PATCH_IF (~%sn%~ STRING_EQUAL_CASE ~BAM~ = 1) BEGIN READ_BYTE 0x0a cc // Count of cycles READ_SHORT 0x08 fc // Frame count READ_LONG 0x0c fn // Frame entry offset READ_LONG 0x14 lu // Offset (from start of file) to frame lookup table READ_SHORT (fn + (fc * 0xc)) c_fcc0 // Count of frame indices in 0th cycle PATCH_IF (cc = 2) AND (c_fcc0 = 1) BEGIN // only 2 cycles = inventory bam (ground and description have 1 or 4 frames). only 1 frame in 0th cycle = not already processed READ_SHORT (fn + (fc * 0xc) + 0x2) c_fic0 // Index into frame lookup table of first frame index in 0th cycle READ_SHORT (fn + (fc * 0xc) + 0x4) c_fcc1 // Count of frame indices in 1st cycle READ_SHORT (fn + (fc * 0xc) + 0x6) c_fic1 // Index into frame lookup table of first frame index in 1st cycle PATCH_IF (c_fcc1>=1) BEGIN // 1st cycle mush have at least 1 frame in order to add a frame to 0th cycle READ_BYTE (lu + c_fic0) FLT_0 // Get frame used by cycle 0 READ_BYTE (lu + c_fic1) FLT_1 // Get frame used by cycle 1 WRITE_SHORT (fn + (fc * 0xc)) 2 // Sets 0th cycle to have 2 frames WRITE_SHORT (fn + (fc * 0xc) + 0x2) 0 // Sets 0th cycle to start at FLT index 0 WRITE_BYTE (lu) FLT_0 // Sets 0th FLT entry to the frame used by cycle 0 WRITE_BYTE (lu + 1) FLT_1 // Sets 1st FLT entry to the frame used by cycle 1 END END END // Recompressed if needed. // ----------------------- PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN COMPRESS_REPLACE_FILE 0 dl 9 INSERT_BYTES 0x0 0xc WRITE_ASCII 0x0 ~BAMCV1 ~ WRITE_LONG 0x8 dl END END // of DEFINE_PATCH_FUNCTION There may still be edge-cases that aren't handled properly, but this modification adds some robustness to your code. However, this code will always copy a modified version of the file to the destination directory (whether or not the actual BAM V1 contents were changed) simply because WeiDU uncompressed and recompressed the BAMC file using a slightly different ZLIB implementation than whatever was used to compress the original. I don't like this in the context of BAM Batcher (nor in the context of processing arbitrary in-game BAMs to re-expose the small item icons), but don't know how to avoid it. Any ideas? Quote Link to comment
Gwendolyne Posted June 30, 2017 Share Posted June 30, 2017 (edited) Good job! I wrote this code to fit my needs (I always use the same template to create my inventory bams : large frame in frame 0 and small one in frame 1). That's the reason why I did not bother to check every case (even if I you noticed I began write the READ_LONG 0x14 lu line, but did not go further). Sorry for the compression process, but it is far out of my skills. I just used a copy paste from Bam Batcher code. Edited June 30, 2017 by Gwendolyne Quote Link to comment
Sam. Posted June 30, 2017 Share Posted June 30, 2017 Good job! I wrote this code to fit my needs (I always use the same template to create my inventory bams : large frame in frame 0 and small one in frame 1). That's the reason why I did not bother to check every case (even if I you noticed I began to when I wrote the READ_LONG 0x14 lu line, but did not go further). Sorry for the compression rocess, but it is far out of my skills. I just used a copy paste from Bam Batcher code. With some suggestions I was able to figure out the compression bit. Current version of the updated code can be found here. I apologize for straying a bit OT, Lundar. Quote Link to comment
junislee Posted March 25, 2019 Share Posted March 25, 2019 On 6/19/2017 at 1:53 PM, Lundar said: Hello, could someone please check the following mods: Ruad Rolles Konolan Tweaks (at least for the rod of Refuge) That are some simple yet special merchants. They -should- be compatible; they only add some items well and one area for the Konolan mod... But I am no modder, perhaps someone has tested them ? Greetings Lundar Hey guy, could you tell me how to convert Ruad and Rolles to EE edition??.... I really like these items mod. Thank you very very much! Quote Link to comment
junislee Posted March 26, 2019 Share Posted March 26, 2019 9 hours ago, Gwendolyne said: Have a look here. Waooo....that's great!! Thx ! Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.