[factory] EoB engines' structure investigation

[MagerValp]

JackAsser, got anything nice to show for us at Datastorm?

[JackAsser]

Sorry, missed that you posted here.

[Marcuz]

I wanted to ask if somebody ever extracted graphics from AESOP using games: Eye of the Beholder III and Dungeo Hack...
I wanted to have a look at a bitmap image of the chargen pics from these games.

[DK2]

You can use the XWE (eXtendable Wad Editor), despite the name - it's a tool for modify DOOM WAD files - it can open and show data from Eye of Beholder 1,2,3 and Dungeon Hack.
Download it from OoCities (the mirror of the old defunct GeoCities).
However, if you want open non-Doom files, just cancel the first dialog asking the Doom MainWAD file then load the .RES file from the menu.

[Marcuz]

Thank you DK2, I've just tryed it, sadly it doesn't let me choose an external palette, while the pre-installed one regarding EoB 3 appears to be wrong

[DK2]

Just find the palette in the list, the choose from palette menu "use current", so the program will use the current palette to display the images.
You can also export palette so you can choose from the list.
Unfortunately, if you check some palette, they are incomplete (only 16 colors or similar); that's because they need to be merged with the main pal, but the program cannot do that.
You can use an hex editor to quickly copy the values (3 byte each color) or you can manually modify the main pal entering the RGB value of the various colors...

I'll attach some palettes I've made for EoB3. Just put them into Palettes subfolder so you can choose from the menu.

[Marcuz]

I'll try in a bit, thank you a lot!

[Marcuz]

Mmm, they seem to not be the right colors for the files from the "chargen" directory in EoB 3: that idiotic character pics file has its own format so that the pics are stacked or indexed instead to be all on the same image file, but that's not the point.

[edit]
The problem is with its palette, which has its .COL suffix and it is 768 bytes long like .PAL and .ACT files and work with XVE if simply renamed with the .ACT suffix, and the colors are right, just really dark, I think way darker than half brighted.

Anyway the part of the problem of the character indexing is solved, thanks DK2!

Originally Posted by JackAsser

According to the wiki an item contains the following:

struct FileItem
{
   unsigned char nameUnidentified;
   unsigned char nameIdentified;
   unsigned char flags;
   unsigned char picture;
   unsigned char type;
   unsigned char subpos;
   unsigned short levelPosition;
   unsigned short next;
   unsigned short prev;
   unsigned char level;
   unsigned char value;
} __attribute__((__packed__));

I have a few question about this structure.

* What is the meaning of all the flags? The wiki only states a few.
* How does type relate to strings? Is there an actual relation at all, it feels the wiki is borked.
* What is the next and previous pointers used for, I understand they point to other items, but why?
* What is value used for, and is it static per item och can the value actually change during game time?

Hello! I'm Alessandro and I recently tried eotb hex editing about ITEM.DAT and ITEMTYPE.DAT (my bros break me up for add new items! )
I undestand the structs of 2 files, in particular for itemtype:

struct ItemType {
    unsigned short invbits;    // At which position in inventory it is allowed to be put. See INVENTORY_USAGE_* above.
    short int handbits;        // In which hand it can be used
    char acadd;                // Adds to armor class
    unsigned char profallowed; // Allowed for this profession. See CLASS_USAGE_* above.
    unsigned char handallowed; // Allowed for this hand
 
    /* Damage versus small */
    Dice damageVsSmall;
 
    /* Damage versus big */
    Dice damageVsBig;
 
    char unknown1; // Always 0 in EotB 1
    char unknown2; // Always 0 in EotB 2
    char unknown3;
};

I don't know what is 2nd two-bytes (short int handbits) because don't regard the hands by my tests.
Moreover I noticed that second-last byte (char unknown2) regards the events on game, but only for the lower part of the octet (0000 xxxx), so for example 01 is equal to 81 -> 0000 0001 & 1000 0001 and it's used for weapons hit event.
I would like what about higher part of octect...
05 is to activate mage spells window event, 06 for cleric spell, etc.

P.S. I would like even more about flags byte for ITEM.DAT:
80: 1000 0000 -> magic
40: 0100 0000 -> identified
20: 0010 0000 -> no remove on hands (to cursed objects in eob2?)
10: 0001 0000 -> ?
08: 0000 1000 -> drains hp when weapon hits enemies
04: 0000 0100 -> ?
02: 0000 0010 -> ?
01: 0000 0001 -> ?
e.g. C8 could be a magic identified weapon with drain effect.

[Marcuz]

Hello Alessandro, I don't know anything code, but if you actually do add more items to the game, I offer to make custom graphics for them

[Vairn]

I though the handbits did say whether the items worked in both hands, or one hand, or specific hands. Might have to look again.

Thank you for replies.

@Marcuz: my bros is working to the graphics too, but I think that he usually takes from other games and adjust the size & format. Can you create new sword icons or portraits?

@Vairn: I think that they are a bit mask like the bit mask for inventory (first two-bytes), but the only thing that I noticed is that sometimes is specular with unsigned short invbits, sometimes the bit 80 (1000 0000) is removed, maybe both masks are related by AND logic operation somewhere?
The only thing that regulate hands usage is unsigned char handallowed, that you can specify:

• 00 (both hands without restrictions)
• 01 (only right hand, but you can use left hand for shield or small weapons/items)
• 02 (only right hand, but both hands use this weapon, so no other item can be used on left hand)

I attached an .xls to recap eob1 itemtype infos.

[Conundrum]

Folks, I'm not sure if this is the appropriate thread to say this, but in case you haven't missed it, Scummvm now runs the PC version of EOB1&2. After talking to the devs, support for the Amiga version is planned, but it will likely take a bit, due to not many people being currently involved in Kyra engine development part of the project. Perhaps some of you would be interested in lending a hand, given that it's a preservation effort, after all?

[Vairn]

hmm interesting.
Thats pretty cool, there does seem to be some code there which involves amiga data files, but that may just be for legend of kyrandia, since it is part of the same scummvm engine.

[Sleeper Grey]

Hello,
This thread looks like a (lost) treasure trove for people loving Eye of the Beholder.
And changing it, yes.

Might anyone be interested to use the knowledge in this thread for a special task.
EoB-III portraits!

Bad changes in these (compared with EoB I-II portraits) were noted by many.
Yet none cared to fix it.

On page 14 here
http://eab.abime.net/showthread.php?...e=14&styleid=4

there is a great description of EoB-III graphic format. XWE decodes it too.

Also there is "Bmpdepack" code for decoding EoB-III graphic on the defunct Eob.Wikispaces.com/Tools page.

But nothing allows to ~encode~ things in this format. (The palettes for EoB3 are still around.)

How hard it can be if the format is known, here:

https://web.archive.org/web/20070114...s.com/eob3.bmp

"The format is still very simple."(c) JackAsser

I have no problem getting old 31x32 portraits from EoB-1 .cps file as .bmp's but no way to convert them into EoB-3 format.

It's really a pity since some portraits in EoB-3 were spoiled quite seriously.

Any help here?


P.S.
The ultimate patch would be adding custom portraits instead of 'standard' ones as in Baldur's Gate. ~__~

[iliak]

It's time to dig up this post again

I just created a repository containing python code to read game assets.

[CFou!]

Originally Posted by iliak

It's time to dig up this post again

I just created a repository containing python code to read game assets.