Invisible gears in inventory

[tadjer]

Hi epvp , idk why i cant see my gear but i can use it . And thx .

Hi epvp , idk why i cant see my gear but i can use it . And thx

[wallerus]

Using an EP4 game.exe with an EP5 data.saf will cause this, due to the game.exe not being able to properly read the .dds files associated with item icons.

Episode 5; 18.dds

 Spoiler

Episode 4.5; 18.dds

 Spoiler

I'm sure you can see the difference in size, you'll need to update your icon files to suit your game.exe, located in

Data > interface > icon

[tadjer]

Ok ill try ,

[castor4878]

Originally Posted by wallerus

Using an EP4 game.exe with an EP5 data.saf will cause this, due to the game.exe not being able to properly read the .dds files associated with item icons.

You certainly mean using a dds from the Icon folder of an EP5 ... coz using a (whole) EP5 data.saf will crash the client preventing it to display anything.

From my own experience, using last format (1 .dds 128x512px; instead of up to 2 .dds 128x256 px) doesn't prevent any display of icons - the sonov client uses the low level DirectX method to obtain bitmap from DDS file, it so obtain an HBITMAP w/o checking its full height and then map the HBITMAP (whatever it is) to a 4x8 icons for a client 4 (and 4x16 for the last), consequently using a 128x512px DDS file results in final icons containing 2 images (originally defined on 32x64, resampled on 32x32).

"From my own experience" doesn't mean for all possible clients, but only those for which I could do a test.

Another simple possible reason is that you have left the icon field to 0.

Edit:

checking your pict (if ePvP prevents u to use their embedded pict system, make sure your links are visible)

 Spoiler

it appears that indeed icons ARE displayed, and indeed they contain 2 icons resampled as one because you're using wrong DDS file height.
the equiped gears as well as the item in first cell of inventory DO have icons, a double-empty one, likely because icon field was invalid (possibly to high, more likely null).

[wallerus]

Originally Posted by castor4878

You certainly mean using a dds from the Icon folder of an EP5 ... coz using a (whole) EP5 data.saf will crash the client preventing it to display anything.

Yes, sorry. What I meant was when using Ep5 data with an Ep4 game, certain files must be converted to suit the Ep4 format, including the .dds files otherwise you will have errors as we see here.

The problem is 100% he is using .dds files that are 512*128 instead of 256*128. I don't have an Ep4 setup atm to prove it, but I have done the reverse (using 256*128 instead of 512*128).

As you can see the equipped weapon is elongated due to how the game.exe reads it, whereas the unchanged boots (21.dds) are read correctly. This will happen regardless of the (valid) icon value set in the Item.SData.

The game.exe reads the files and divides them by a certain value, an Ep5 game.exe dividing value is twice that of an Ep4 game.exe, this is the root cause of that error. (credits to Nubness for that info)

[castor4878]

Originally Posted by wallerus

Yes, sorry. What I meant [...]

The game.exe reads the files and divides them by a certain value, an Ep5 game.exe dividing value is twice that of an Ep4 game.exe, this is the root cause of that error. (credits to Nubness for that info)

Don't be sorry I pretended not to understand just to add comments to your point.

"The client does divide the bitmap ["whatever it is"!] - by a certain value", it's the key point indeed, and the info is that that certain value has changed in episo 5; the icon files have been changed as a basic consequence.

I will also do a test to highlight it, well apparently I forgot to explain it before Nubness, pity it remains for me to make drawings

Let's work with current european client (patch 290), if we replace the 17.dds file with this one:

which is 256x256, the gears seller shows tops as:


(note that the "new" 17.dds is a TGA of course, but since the 17.tga already exists - it's the former 128x128 file - they had stored the TGA 128x512 as "17.dds" and since DirectX doesn't care about file extension (it actually manages loaded streams) all is fine)