Sounds like an interesting and intriguing concept, I wish you success in bringing it to life.

 

Advice on a couple things which stood out to me:

 

All the same it can be sold to a noble collector in Athkatla but the real story begins if it is kept and worn.....

 

This sounds like it would be easy for a player to skip the quest altogether (perhaps unknowingly) by selling the item. I'd consider adding a plot line to lead the player back towards the amulet after selling it, so the quest can still be started in another way. For example, maybe after a few days the party catches a rumour of the noble collector dying under mysterious circumstances and is called upon to investigate (or maybe they're even suspects in his death now). Or the noble's behavior changes because he's affected by the artifact, and one of his close friends/family comes to the party with questions or plea for aid.

 

 

and if you refuse his attempts to 'save' you which involves him joining the party and trying to destroy the amulet without killing you

 

I'd recommend not making the extra companion mandatory for completing a quest arc. With the amount of NPC mods out there now, those party slots are very precious and by requiring one of them you risk losing a significant part of the audience who'd prefer to have their own NPC party selection. Perhaps the paladin offers to help, and then if the player accepts he also offers to join the group. If this second offer is refused, he can still try to help (perhaps staying at one of the inns, if multiple interactions with him are planned) without joining the party.

 

You should ask Miloch who is working on the next version of I.A. As far as I know, it will include the remplacement of the animation codes in a way that should solve the subject of this topic. But ask him to be sure.

Oh, I'm counting on Miloch to eventually notice I invaded his forum and started hacking his mod. I know he's one busy half-orc these days. But if you're saying he's been working on the same problem already, maybe I should wait for his input before wasting more time on this.

As far as I know, the source code was never released. I just forcefully decompiled it, but it may not have recreated the syntax to 100% of original (see the"Tidy Error"s). It's a start anyway.

Thanks, this could come very useful later if the converted patch ever gets finalized.

Why not use various punctuation symbols like these instead?

 }  (ascii code 0x7D)
 `  (ascii code 0x27)
 ,  (ascii code 0x2C)
 &  (ascii code 0x26)
 ~  (ascii code 0x7E)
 {  (ascii code 0x7B)
 $  (ascii code 0x24)
 =  (ascii code 0x3D)
 +  (ascii code 0x2B)

They are valid filename symbols (in Windows at least, no idea about Mac or Linux), and they are NOT widely used in mods, despite what IA devdoc file says. Not to mention this mod will only ever use them for BAM and (very few) 2DA resources, reducing the chances for any potential conflict further. All these symbols exist with same ascii codes in Japan windows codepage 932 and russian 1251 (I think those were the ones who had problems with IA originally?).

The current solution to force a user to CHCP and reboot every time IA (or any mod using IA) needs to be (re)installed seems, frankly, horrible to me.

You still have to extract the files using the English code page while doing so... as that's where the thing goes boom. ... so it would be better to reupload the files.

Hmm. This should only be possible if the file extraction program was non-Unicode. Which would be strange, to say the least, in this day and age.

But suppose that's exactly what happens and non-Unicode software is used, when you say "goes boom" do you mean that the files extract with incorrect filenames (i.e. for instance Жaag11.bam instead of Æaag11.bam on code page 1251), or that they fail to extract at all? Because in the first case, the renamer utility actually should still work - it should rename both Æaag11.bam and Жaag11.bam into }aag11.bam, I accounted for that possibility.

I could try, although exe patching is out of my usual area of expertise. But the devdoc file has some notes on offsets in the executable, and my initial attempts to decipher them have not been completely unsuccessful.

I've tinkered with 'µ' and 'Æ' refs and replaced them with '~' and '}'. The result appears to work, at least the animations show up. If a few people could check this and confirm it doesn't crash and burn on their end before I attempt the other slots, that'd be great.

Usage:
- unpack and install the test component
- start a new game or load existing save, shouldn't matter
- CLUAConsole:CreateCreature("P5Tst") - Should look like a Bovine Axe Thing. Drawn location will not match foot circle - this particular animation is not centered properly.
- CLUAConsole:CreateCreature("P5Tst2") - Should look like a Nabassu.
- CLUAConsole:CreateCreature("P5Tst3") - Should look like a Chimera.

- CLUAConsole:CreateCreature("P5Tst") - Should look like a Bovine Axe Thing. Drawn location will not match foot circle - this particular animation is not centered properly.
 

 
Strange. It should have been fixed a few months ago : http://www.shsforums...-thing-axe-bug/
 
 
 

I might have the old version archive, before it was updated (these files have been gathering dust on my hdd for a while).

Meanwhile, I think I got another ref slot to work. CHARACTER BGII WQM which used to be referenced by "¢_¢_" has been switched to "+_+_". Tested on MOINESSE_NINJA_MALE_HUMAN animation (¢A¢B --> +A+B).

I was wondering about the ia_reference_picker program that comes packaged with IA. Was its source code ever publicly shared anywhere, or was it only Erephine who had it? If I manage to get this .exe patch fully switched (that's a big IF for now), the app ideally should be updated to accept lists with new symbol references as input, as well as hand out ready-to-use slot ids when claiming new slots. Otherwise, the process of claiming a new slot could become complicated...

OK, a quick follow-up on this while we're waiting for Miloch.
 
It seems that the Reference Picker program actually does not need any updates whatsoever - all it does is read the contents of the anims.list file from the same folder, and looks for the first open slot of appropriate type in that list when claiming a new animation slot. I swapped all slot prefixes in that file with new symbols, and it worked like a charm after that. This is very good news, 'cause I was worried someone (read: me) would have to rewrite it from scratch to make this work. I'm attaching the modified .list file and the .txt with latest reference list converted to new symbols in case someone wants to try this.
 
Locally, all ref slots have been converted to use new symbols. No significant problems so far. The only thing I haven't figured out yet are several dragon slots - they appear to be using a few non-conventional characters that are not used anywhere else in the .exe patch plus I'm yet to locate their offsets in the executable:

0x122c    XDRµ    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x122d    XDRР   EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x122e    XDRÞ    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x122f    XDRØ    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x1230    XDRÑ    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x1231    XDRÆ    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x1232    XDR    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x1233    XDRß    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted
0x1234    XDRÇ    EMPTY                                 HUGE   D Do  DRAGONS (XDR) unpaletted

Fortunately, there are 35 more dragon slots free to use apart from these, but still.
 
The next step will be thorough testing of all slots listed in anims.list to make sure I didn't miss any old symbol references, and didn't replace something I shouldn't have.
 
Current table of symbol swaps in reference names: 

 OLD:          NEW:
µ = 0xb5  ->    0x7e = ~
Æ = 0xc6  ->    0x7d = }
¢ = 0xa2   ->    0x2b = +
£ = 0xa3   ->    0x7b = {
¥ = 0xa5   ->    0x2c = ,
Ð = 0xd0   ->    0x26 = &
Þ = 0xde   ->    0x27 = '
Ø = 0xd8   ->    0x3d = =

If anyone has objections about the chosen replacements now's the time to speak out, before I start full testing of the changes.

The IwD young white dragon uses one of BGI MONSTER LONG 4 PART slots, not one of the dragon slots.

I'm not sure what you're asking is even possible - all "color-cloned" animations in the vanilla game which use different palettes for the same set of BAMs still occupy different slots for each variation. For example, each type of spider takes 1 entry in ANIMATE.IDS, even though they all use the same animation with different bmp palette:

0x7A00 SPIDER_GIANT
0x7A01 SPIDER_HUGE
0x7A02 SPIDER_PHASE
0x7A03 SPIDER_SWORD
0x7A04 SPIDER_WRAITH

It's the same for vanilla dragons (except black and silver).

The "paletted" bit in the slots descriptions refers to them using character colors (major/minor/hair/metal/etc colors in the CRE file), not to them being able to swap BMP palettes in some way while only taking 1 animation entry slot. At least that's my understanding so far.

I've modified Erephine's file renaming utility to automatically mass-rename files from the old scheme to new one (¢A¢E1A1.BAM --> +A+E1A1.BAM, etc.).
 
This means hopefully there will be no need to reupload those GB-sized content archives or worry about files previously installed by mods like Aurora's Shoes, it's enough to add a couple lines like this:
 

AT_NOW ~infinityanimations\batch\renamer.exe "infinityanimations\content\"~ 
AT_NOW ~infinityanimations\batch\renamer.exe "override\"~

 
to the TP2.

I was referring to the adult version. The green ring should be the same as the normal dragons.

There's an adult version? The file you linked only has the young dragon, and there's no adult listed in current reference list... Yes, the foot circle used by the young animation is the same size (HUGE) as the XDR slots. The BGI MONSTER LONG 4 PART slot refspapce is split into 2 parts, entries in 0x1001 to 0x10ff range have LARGE foot circle, and 0x1101 through 0x11ff have HUGE foot circle size. The young white dragon uses the first entry (0x1101) in the second range.

Gwendolyne can just replace the palette on the creature file by the same means that ... no I actually don't know what it means... as Gwendolyne has done this, but... apparently there's problem !?!

So Gwendolyne just needs to append the animate.ids and name the files correctly... or ?

From that thread, looks like what he did was repalette a group of bam files using several different bmp palette files. Thus, he now has several sets of dragon and tarrasque BAMs, each of different "coloring". Each of them will require its own separate animation slot (entry in ANIMATE.IDS) to show up in the game, and will be treated as a standalone animation by the engine (the engine has no idea they are in any way similar, it just draws the contents of the BAM files as indicated by the animation id field in the CRE files). There's no problem, unless occupying 15-20 out of 44 available XDR slots for basically the same 2 recolored animations can be called such.

Argh !!!

I will need to use new dragons slots (5 Tarasques and maybe more than a dozen new dragons if I can deal with their palettes).

So what do you mean : are the "35 more dragon slots free to use" vanilla ones (inluded in IE) or the number of free slots available in I.A. ?

As far as I can see, there are a total of 44 dragon (XDR) slots in anims.list, from entry 0x1209 to 0x1234. None of them are officially taken yet, all are free to use, judging by the latest ref list posted in this forum. Sounds like you will be taking a good chunk of them, Gwendolyne. Are you sure you need all the different paletted types?

The second (under human) is wyvern_white_big, not a dragon.

It should show up on the tooltip if you hover your mouse over the picture in the readme for a bit.

ADD_JOURNAL was introduced in WeiDU v232, and you're trying to install with 231:

[./setup-arath] WeiDU version 23108

 

I don't know where/how BG Mac mod installer gets the OS X version of WeiDU it uses, but you need to make sure it uses latest version (v236) instead, see link in my previous post in this thread.

I don't own a Mac, so I can't give verified instructions. But I see Kaeloree included sox in the package and TP2 uses HANDLE_AUDIO to process audio, so in theory this should install on a Mac with a proper OS X version of WeiDU binary.

 

Try this:

1. Download OS X version of latest WeiDU from weidu.org.

2. Extract the WeiDU binary from the downloaded archive (it's in the "bin" subfolder), put it into your main BG2EE game folder (it should be the one containing the CHITIN.KEY file) and rename it into "setup-arath".

3. Download the .command file attached in a zip archive to this post and unpack it into the same folder. Double-click it to (hopefully) start the installation.

 

I'd like to know if this works too - I've recently added similar install instructions on Mac OS X and Linux to the readme of a mod I'm working on, but without having a Mac I can't verify they are actually correct.

Updated original post with current version, readme and download link.

 

Big thank you to Miloch for maintaining the mod and (apparently) fixing my mistakes. My apologies for this.

My opinion is that BGT should import those mandatory BG2 NPCs (Jaheira, Minsc, Imoen, Viconia and Edwin) to BG2 side even if they are not in party during transition.

Then you'll get a level 1-2 Jaheira in BG2 if you kicked her out for good in BGT after reaching Nashkel, for example.

What i meant that if BGT imports Jaheira despite her NOT being in party you don't get that BG2 cre-file in GAM-file at save file. Then you get automatically get right cre-file when Jaheira comes back.

This might be a BGT bug then, caused by how MoveGlobalObject works. I'll do some tests on this later, but sounds like it's picking up the first script name it finds in GAM (which is the BGT version of Jaheira), instead of using the last one added with MakeGlobal() in AR0602 script.

Or it could be that the MakeGlobal() in your case failed to fire for some reason. There's no SetInterrupt(FALSE) preceding it, so it's possible Jaheira was interrupted by another script action without performing MakeGlobal().

Added French, thanks.

 

 

Since you mentioned that the mod will become BGEE compatible, I assume it will also target BGT/Tutu

Correct, there will be one install package for all 3 platforms.

 

 

 

I don't know if you anticipated the need to have a different character encoding for BGEE

Yes I'm aware of that. I'm prepared to handle the conversions, but having ready-to-use utf8 file for bgee is a great help, thank you.

 

Looking for translations for 17 new lines in BGEE-compatible Drizzt Saga version in French, Italian, Polish and Spanish languages.

 

- 4 lines are component names for WEIDU.LOG (try to use only latin symbols for these)

- 4 lines are setup feedback lines (try to use only latin symbols for these)

- 9 lines are dialog and journal entries for a new Delayed Start component (can use any national symbols here)

 

The short TRA file for translation with comments is attached to this post. Please attach the translated version of the same file, rather than simply posting translated text in a response post (I'd rather not worry about losing any special characters while copy-pasting and saving).

v3 has been released, but this topic is still actual - Italian, Polish and Spanish translations in v3 are either incomplete (SETUP.TRA lines are in english), or imperfect (I didn't want to remove language options because of just a few new dialog lines, so I substituded Google-Translated text for those).

Thank you, will add in next future version, whenever that comes (unless serious bugs are reported that need immediate attention it'll probably be after all other translations come in).

Those quoted lines I pretty much took as is from v2 released by erebusant and Badgert. They looked a bit strange but I figured they were just imitating archaic english (I'm not a native english speaker myself).

Gender-specific lines are ok, you don't need anything else to make them work as WeiDU should understand this just fine:

@10  = ~Aha, <CHARNAME>! Znow sie spotykamy. Wkrotce wyruszam do Doliny Lodowego Wichru. Pragnalbym, abys towarzyszyl mi podczas tej jakze niebezpiecznej wyprawy.~ // MALE
       ~Aha, <CHARNAME>! Znow sie spotykamy. Wkrotce wyruszam do Doliny Lodowego Wichru. Pragnalbym, abys towarzyszyla mi podczas tej jakze niebezpiecznej wyprawy.~ // FEMALE

using the second line for female CHARNAME (as long as DIALOGF.TLK is present and used).

(And erm, yeah, if you are doing advanced BAM manipulation for stuff like animations, drop me a PM... might be able to hook you up...)

Done.   Been away from BG and IE games and modding, but the stir EE raised has brought me back home, at least for now.

Tinkered with it a bit more today, I think this should do it:

 

 

//! Convert BAMs to BMPs /////////////////////////////////////////////////////
BEGIN ~Convert BAMs to BMPs~
SUBCOMPONENT ~BAM Batcher~
NO_LOG_RECORD

//COPY_EXISTING_REGEXP GLOB ~mspi.+\.bam~ ~bambatch/bam~
COPY - ~bambatch/bam~ ~bambatch/bam~
  READ_ASCII 0x0 sg (4) //Signature
  PATCH_IF (~%sg%~ STRING_EQUAL_CASE ~BAMC~ = 1) BEGIN
    READ_LONG 0x8 dl //Uncompressed data length
    DECOMPRESS_REPLACE_FILE 0xc (SOURCE_SIZE - 0xc) dl
    sz = dl
  END ELSE BEGIN
    sz = SOURCE_SIZE
  END
  SPRINT bn ~%SOURCE_RES%~
  PATCH_PRINT ~Converting %SOURCE_FILE% to bitmaps ...~
  READ_SHORT 0x8 fc //Frame count
  READ_LONG 0x10 pf //Palette offset
  READ_ASCII pf pt (1024)
  READ_ASCII (pf + 3) nl (1) //Null
  READ_LONG 0xc fn //Frame entry offset
  FOR (f1 = 0; f1 < fc; f1 += 1) BEGIN //Frame loop
    SET BadFrameSkip = 0
    SPRINT xl ~~ //End of line
    READ_SHORT (f1 * 0xc + fn) fw //Frame width
    df = (fw / 4) * 4
    PATCH_IF df < fw BEGIN
      lz = df + 4 //Line size
      df = lz - fw //Byte difference
      FOR (g1 = 0; g1 < df; g1 += 1) BEGIN
        SPRINT xl ~%xl%%nl%~
      END
    END ELSE BEGIN
      lz = fw
      df = 0
    END
    READ_SHORT (f1 * 0xc + fn + 2) fh //Frame height
    READ_LONG (f1 * 0xc + fn + 8) fd //Frame data offset   
    cp = NOT ((fd & 0b10000000000000000000000000000000) >> 31) //Compression
    fd = (fd & 0b01111111111111111111111111111111)    
    PATCH_IF cp = 0 BEGIN
      ds = (fw * fh) //Data size     
      PATCH_IF (%ds% > 1) BEGIN     
          PATCH_PRINT ~Converting frame %f1% (uncompressed): reading datasize %ds% from offset %fd% ...~
        READ_ASCII fd fm (ds)       
      END  // PATCH_IF (%ds% > 1)
      ELSE BEGIN
        SET BadFrameSkip = 1
      END     
    END ELSE BEGIN
      PATCH_IF f1 < (fc - 1) BEGIN
        READ_LONG ((f1 + 1) * 0xc + fn + 8) nf //Next frame data offset
        nf = (nf & 0b01111111111111111111111111111111)
        ds = (nf - fd)
      END ELSE BEGIN
        ds = (sz - fd)
      END     
      PATCH_IF (%ds% > 1) BEGIN     
          PATCH_PRINT ~Converting frame %f1% (compressed): reading datasize %ds% from offset %fd% ...~
          tx = 0 //Transparency index cleared
          SPRINT fm ~~ //Clear frame data
          cc = 0 //Column count
          FOR (f2 = 0; f2 < ds; f2 += 1) BEGIN //Crawl through frame data
            PATCH_IF tx = 0 BEGIN //If transparency set to 0 (1st byte or non-transparent reached)
              READ_BYTE (fd + f2) bt //1st byte hex value
              READ_ASCII (fd + f2) bx (1) //1st byte ASCII value
              PATCH_IF (bt = 0) AND (f2 < (ds - 1)) BEGIN //If byte is transparent and not last pixel
                READ_BYTE (fd + f2 + 1) bv //Next byte
                FOR (f3 = 0; f3 < (bv + 1); f3 += 1) BEGIN //Augment transparent pixels
                  SPRINT fm ~%fm%%bx%~ //Add byte ASCII value
                  cc += 1 //Column counter
                  PATCH_IF (cc = fw) AND (df > 0) BEGIN //If column is frame width and there's a difference
                    SPRINT fm ~%fm%%xl%~ //Pad line with extra BMP nulls
                    cc = 0 //Reset column counter
                  END
                END
                tx = 1 //Transparency set
              END ELSE BEGIN //If not transparent or last pixel
                SPRINT fm ~%fm%%bx%~ //Add byte ASCII value
                cc += 1 //Increase column counter
                PATCH_IF (cc = fw) AND (df > 0) BEGIN //If column is frame width and there's a difference
                  SPRINT fm ~%fm%%xl%~ //Pad line with extra BMP nulls
                  cc = 0 //Reset column counter
                END
              END
            END ELSE BEGIN //If transparency is not 0
              tx = 0 //Set to 0
            END
          END         
      END  // PATCH_IF (%ds% > 1)
      ELSE BEGIN
          SET BadFrameSkip = 1
      END     
    END  // ELSE (PATCH_IF cp = 0)

    PATCH_IF %BadFrameSkip% = 0 BEGIN   
        SPRINT fk ~~
        INNER_PATCH ~%fm%~ BEGIN
          FOR (g2 = fh; g2 > 0; g2 -= 1) BEGIN //Reverse rows for BMP
            PATCH_IF cp = 0 BEGIN //If compressed
              READ_ASCII ((g2 - 1) * fw) fl (fw) //Read frame width
              SPRINT fk ~%fk%%fl%%xl%~ //Pad with extra nulls
            END ELSE BEGIN
              READ_ASCII ((g2 - 1) * lz) fl (lz) //Read padded line width
              SPRINT fk ~%fk%%fl%~
            END
          END
        END
        fz = (0x436 + (lz * fh))
        INNER_ACTION BEGIN
          COPY ~bambatch/header.bmp~ ~bambatch/bmp/%bn%%f1%.bmp~
            WRITE_LONG 0x2 fz //File size
            WRITE_LONG 0x12 fw //Width
            WRITE_LONG 0x16 fh //Height
            WRITE_LONG 0x22 (lz * fh) //Image size
            WRITE_ASCIIE 0x36 ~%pt%~ //Color table
            READ_LONG 0x36 p0
            PATCH_IF p0 = 0x9797 BEGIN
              WRITE_LONG 0x36 0xff00 //Fix cyan transparency to green
            END
            //Uncomment line below to write a brown background (similar to in-game look)
            //WRITE_LONG 0x36 0x352e21
            READ_LONG 0x3a p1
            PATCH_IF p1 = 0xff6597 BEGIN
              WRITE_LONG 0x3a 0x080808 //Fix pink shadow to dark grey
            END
            INSERT_BYTES 0x436 (lz * fh)
            WRITE_ASCIIE 0x436 ~%fk%~ //Raster data
          BUT_ONLY
        END       
    END  //  PATCH_IF %BadFrameSkip% = 0
    ELSE BEGIN
        PATCH_PRINT ~Skipping frame %f1% - invalid frame size.~
    END
    
  END  // FOR
BUT_ONLY

 

Basically, just added skipping any frame with frame size 1 x 1 or less - those "pixel" frames are really useless for editing, and if anyone needs to reinsert them later into modified animation bams it should be easy to just clone any one of them with weidu.  Rakshasa animation, as it happens, contains tons of those, so this greatly speeds up conversion process too. The loop index variable still goes up for skipped frames, so for example if out of 100 frames 14-65 were skipped, you'll get *0.bmp through *13.bmp and *66.bmp through *100.bmp in the output folder.

 

Hey Miloch. I'm hitting an error when trying to convert standard rakshasa animations (MRAK*.BAM) to bmp. It successfully converts first 14 frames but on the 15th this happens:

 

Converting frame 15 (compressed): reading datasize -21067 from offset 23429 ...
ERROR: illegal 44-byte read from offset 3080 of 0-byte file INNER_PATCH "%fm%"
ERROR: [MRAKG1.BAM] -> [bambatch/bam/MRAKG1.BAM] Patching Failed (COPY) (Failure("INNER_PATCH \"%fm%\": read out of bounds"))
Stopping installation because of error.

 

Looks like the patching goes on even if the calculated frame size was invalid.

I think you need to PM Kaeloree for a forum here.

Sounds interesting, I'll be watching your progress.

I hope you reconsider this part though:
The current plan is to not even release the mod for playing at all if there is no voice-acting present

I for one actually prefer not to have any voicing in mods I use - it's difficult to match the performance and quality of vanilla characters in modding projects and nearly always it stands out as something that does not belong in the game.