Merchant Mods

[Lundar]

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

 

 

 

[Roxanne]

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.

[Sam.]

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?

[Roxanne]

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.

[Sam.]

 

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

[Gwendolyne]

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

[Sam.]

@Gwendolyne

Well this is downright cool. Can I implement this in BAM Batcher? You will be credited of course

[Gwendolyne]

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.

[Sam.]

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:

• 0^th cycle may already have more than 1 frame (was already processed).
• 1^st cycle may be blank (no frames), thus has no frames to add to 0^th 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 0^th 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?

[Gwendolyne]

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

[Sam.]

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.

[junislee]

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!

 

 

[Gwendolyne]

Have a look here.

[junislee]

9 hours ago, Gwendolyne said:

Have a look here.

Waooo....that's great!! Thx !