83 replies to this topic

[Creepin]

Thanks a lot Sam., the update is much appreciated.

[Gwendolyne]

Hi, Sam.

 

Nice update.

 

Many years go, I wrote a French translation for BAM batcher. Are you interested? If yes, I could dig up my old DDs, look for it and update it to this new version.

[Sam.]

Hi, Sam.

 

Nice update.

 

Many years go, I wrote a French translation for BAM batcher. Are you interested? If yes, I could dig up my old DDs, look for it and update it to this new version.

Sure .  I'm not particularly experienced with this sort of thing, so if you see anything I've messed up or that could be improved, please speak up.

 

Here's the English TRA for comparison:

setup.tra

[Gwendolyne]

Thanks. But the longest part will be the readme, even If I have already translated the previous technical section.

 

Do you want that I add the Languages selection to the tp2 and traify it?

[Sam.]

Thanks. But the longest part will be the readme, even If I have already translated the previous technical section.

Wow, that's more ambition than I expected, but I am pleasantly surprised .

 

Do you want that I add the Languages selection to the tp2 and traify it?

The TP2 has already been traified, it (the TRA linked to above) just needs to be translated, added to the bambatch/translations folder, and another LANGUAGE line added to the TP2 (unless I'm missing something?). Once the Readme has been translated, the README line in the TP2 can be updated using the %LANGUAGE% variable also.  You are welcome to do this and make a pull request with Git if you want.

[Gwendolyne]

The readme is done and is proofread by new French modders : if they understand the technical parts, my job will be OK.

I am an old bear and did not learn how to use github (despite I signed in and open an account many years ago). So I will PM you the files.

I added the readme line : to make it work, you will have to rename your English readme file to bambatch-readme-english.html. Another tip is to move all the readme files into their respectives folders.

With these changes in the tp2 file, you must modify the line numbers noticed in the readme : line 10 becomes line 16 (component 1) and line #127 becomes line #133 (FAQ : Can I get that in-game background look like the icons below?).

Last, I noticed two glitches in your setup :

1. If I well understood your coding, line 284 (my updated tp2 file) or 280 (v2.2.1), @11 = ~Bitmap %bs% is not 8-bit or is compressed - check the file.~ should be @11 = ~Bitmap %bf%s is not 8-bit or is compressed - check the file.~

2. in the Fix spell BAM coordinates and Fix description BAM coordinates components, you use the same reference string (@23 = ~%SOURCE_FILE% has %fc% frames (spell BAMs need 1) - check source file.~). I think you might add a new one for component 7 (@nn = ~%SOURCE_FILE% has %fc% frames (description BAMs need 1) - check source file.~)
 

Edited by Gwendolyne, 16 May 2017 - 06:10 PM.

[Sam.]

Lastly, I noticed two glitches in your setup :

1. If I well understood your coding, line 284 (my updated tp2 file) or 280 (v2.2.1), @11 = ~Bitmap %bs% is not 8-bit or is compressed - check the file.~ should be @11 = ~Bitmap ¿%s is not 8-bit or is compressed - check the file.~

2. in the Fix spell BAM coordinates and Fix description BAM coordinates components, you use the same reference string (@23 = ~%SOURCE_FILE% has ü% frames (spell BAMs need 1) - check source file.~). I think you mifgt add a new one for component 7 (@nn = ~%SOURCE_FILE% has ü% frames (description BAMs need 1) - check source file.~)

Fixed in local repo, thanks!

 

Another tip is to move all the readme files into their respective folders.

Done on local repo.

 

So I will PM you the files.
[...]
With these changes in the tp2 file, you must modify the line numbers noticed in the readme : line 10 becomes line 16 (component 1) and line #127 becomes line #133 (FAQ : Can I get that in-game background look like the icons below?).

Awaiting PM

[Sam.]

Readme [English] [French]
 
Version 2.2.2: 18 May 2017

• Add French translation

Version 2.2.1: 15 May 2017

• Traify setup-bambatch.tp2

Download from GitHub

[Creepin]

Here's an visual demonstration

I've spent a good part of today trying to figure out why Mazzy looks nothing like CIFF1INV.BAM until I finally realised to check CIFF1INV.PLT

Sadly, NI doesn't tell me what are X/Y offsets of PLT paperdoll, is there any way I could check it?

Edited by Creepin, 21 May 2017 - 01:20 PM.

[Sam.]

Here's an visual demonstration

I've spent a good part of today trying to figure out why Mazzy looks nothing like CIFF1INV.BAM until I finally realised to check CIFF1INV.PLT

Sadly, NI doesn't tell me what are X/Y offsets of PLT paperdoll, is there any way I could check it?

A quick look indicated that PLTs don't have offsets:  every one has a width of 128 pixels and a height of 160 pixels.  IIRC, 1PP forces the game to use the BAM paperdolls by adding a zero-byte file to the override folder that has the same name as the PLT file you do NOT want to use.  Basically overwriting the PLT file with a blank file forces the engine to skip it and use the corresponding BAM instead.  I recommend this since working with BAMs is generally much easier than working with PLTs, largely due to the availability of tools involved.

[Fiann of the Silver Hand]

A bit of an aside here, but if a bam for this is functionally the same as plt, why did Bioware invent this file type?

[Sam.]

A bit of an aside here, but if a bam for this is functionally the same as plt, why did Bioware invent this file type?

If Bardez's postulations about the PLT file format are correct (and I believe they are), the PLT file format has a built-in layer of obfuscation that allow them to reference something like 65,281 different colors, compared to the 256 color limitation of the BAM format.

[Fiann of the Silver Hand]

Thanks.  I wonder how much of a difference that made back on my 800x600 CRT back in '98.

[Sam.]

Readme [English] [French]

Version 2.3: 30 June 2017

• Added "Convert inventory BAMs to EE" component (special thanks to Gwendolyne)
• Update Readme
• Update WeiDU

Download from GitHub

[Sam.]

Readme [English] [French]

Version 2.4: 22 October 2017

• Modify "Convert BMPs to inventory BAMs" to no longer require identical palettes in small and large frames
• Modify "Convert BAMs to BMPs" to properly handle multiple BAMs
• Added 'Fix BAMWorkshop colors' component
• Fix 'Convert BMPs to description BAMs' to properly handle multiple images at a time
• Update Readme

Download from GitHub

[Miloch]

Modify "Convert BMPs to inventory BAMs" to no longer require identical palettes in small and large frames

What black magic is this? He's a witch! Burn him!

[K4thos]

Regarding the "Convert inventory BAMs to EE" component - if I understand correctly icons converted to EE style are not supported by the old engine. If that is the case then I'd like to request an option to completely remove unused small icon and cycle to make the file smaller and due to wrong icon showing up in Near Infinity with the current code. I can't think about any benefits at all in keeping the unused data.

Edited by K4thos, 18 May 2019 - 01:05 AM.

[Sam.]

Regarding the "Convert inventory BAMs to EE" component - if I understand correctly icons converted to EE style are not supported by the old engine. If that is the case then I'd like to request an option to completely remove unused small icon and cycle to make the file smaller and due to wrong icon showing up in Near Infinity with the current code. I can't think about any benefits at all in keeping the unused data.

This component adds the small frame as a second frame to the sequence that has the large frame.  The result is the classic Infinity Engine style of item icons that display the small frame when the item is in the inventory and the large frame when you pick it up.  My tests show this is true (identical behavior with the modified BAM) in vanilla (tested in ToB) and EE games.  If you are experiencing different behavior, please provide me a specific example I can use to reproduce.  Furthermore, IIRC this code does not add a single byte to the the pre-Zlib compressed BAM (Zlib compliant compression is context specific, so it's theoretically possible the modified BAM doesn't compress quite as well, but I doubt the difference could be more than a byte or so).  If you want to perform this modification using PS BAM, you can achieve even better compression and the filesize will shrink compared to the original.

 

Since the modified BAM works as intended in both the vanilla and EE games, and since the modified file is no larger than the unmodified version, I see no reason to depreciate or modify this component.  If you want to keep the EE style item icons (only the large frame is displayed), then you can certainly drop the small frame.  If there is an interest in this capability, I can add the functionality to PS BAM.

 

Note that "Convert inventory BAMs to EE" does NOT convert to BAM V2 files (which is not backwards compatible with vanilla games).

[K4thos]

Since the modified BAM works as intended in both the vanilla and EE games, and since the modified file is no larger than the unmodified version, I see no reason to depreciate or modify this component.  If you want to keep the EE style item icons (only the large frame is displayed), then you can certainly drop the small frame.  If there is an interest in this capability, I can add the functionality to PS BAM.

understandable, if the outcome icon works correctly on both engines (I assumed otherwise without checking). Thanks for answer.

[Salk]

Hello!

 

I have unpacked a description BAM which is made of 4 frames. How can I repack it into a description BAM? Convert BMPs to description BAMs creates four different files rather than putting them together like Convert BMPs to inventory BAMs does using xxxxxxl.bmp and xxxxxxs.bmp as source.

 

Thanks!

Edited by Salk, 18 May 2021 - 08:05 AM.