Jax64 on 10/6/2019 at 04:07
This is an issue with the family texture palette being properly applied. A few FMs implement new texture families, but neglect to also supply the palette in the form of the FULL.PCX file, causing the texture to not look as it should, often resulting in this “deep-fried” appearance.
However, this issue also plagues the original game if we are talking about Thief 2, specifically the cave texture family in which no family palette is present. The texture that you have pictured above does indeed seem to be a member of the cave family. This issue has already been addressed in the latest unreleased T2Fix beta and will become available in version 1.26b.
Until then, dropping (
https://drive.google.com/open?id=1sr4Q7IN8NzLTwNnm-RBx181bz7ljhY20) this directory in your USERMODS folder (or other high-priority mod folder if you are not using T2Fix) will fix the issue until the new version is made available.
Durandall on 10/6/2019 at 13:53
That does indeed fix the texture in the example.
Still, why does the texture look fine initially and then incorrect on loading a save?
Jax64 on 10/6/2019 at 18:16
In this particular case, this is a result of the fan mission failing to import the cave texture family properly. When the mission is initially loaded, the palette used is lifted from the texture itself, which looks correct. However, because the family was not imported properly when the mission was built and no proper family palette is available, the palette (in the form of FULL.PCX) cannot be located when a savegame is loaded, causing the texture to appear this way.
Yandros on 10/6/2019 at 19:28
In short: Cause Dark is funny like that.
Durandall on 12/6/2019 at 03:17
_
Jax64 on 12/6/2019 at 08:02
Quote Posted by Durandall
It's too late here to do much testing, but does this help the problem for anyone?
Also, did it blow up your PC? Trash your thief install? :)
linkWhile this may
seem to eliminate the issue, it does not actually address the underlying problem, which is, in fact, an intended behavior rather than something that needs to be fixed. What you have effectively done (by editing a single byte of the game executable, it seems) is force the game to disable the use of the family palette entirely. This behavior is identical to that of the previously-existing configuration variable, "disable_32bit_fampal", which can already be enabled by simply adding this string to the cam_ext.cfg file located in the game's installation directory. However, because no family palette is being used with this enabled, some textures will not look as they were intended to, particularly in the case of any fan mission that uses Thief 1 resources. The only reason you were seeing this issue was because the game could not locate the family palette, which is not a shortcoming of the game itself, but rather the assets it is attempting to load. This issue is best fixed by simply supplying a family palette where it is required.
Because of this, I would highly recommend you to use the fix I posted earlier, at least until the next T2Fix version is released. If you must use this option, however, it is much more preferable to utilize the "disable_32bit_fampal" configuration variable rather than editing the executable.
bassoferrol on 12/6/2019 at 12:46
Convert the textures in cave folder to png format.
Durandall on 12/6/2019 at 14:00
Quote Posted by Jax64
While this may
seem to eliminate the issue, it does not actually address the underlying problem, which is, in fact, an intended behavior rather than something that needs to be fixed. What you have effectively done (by editing a single byte of the game executable, it seems) is force the game to disable the use of the family palette entirely. This behavior is identical to that of the previously-existing configuration variable, "disable_32bit_fampal", which can already be enabled by simply adding this string to the cam_ext.cfg file located in the game's installation directory. However, because no family palette is being used with this enabled, some textures will not look as they were intended to, particularly in the case of any fan mission that uses Thief 1 resources. The only reason you were seeing this issue was because the game could not locate the family palette, which is not a shortcoming of the game itself, but rather the assets it is attempting to load. This issue is best fixed by simply supplying a family palette where it is required.
Because of this, I would highly recommend you to use the fix I posted earlier, at least until the next T2Fix version is released. If you must use this option, however, it is much more preferable to utilize the "disable_32bit_fampal" configuration variable rather than editing the executable.
Thanks Jax64 for the technicals.
Something seemed odd. Newdark diverged from the original source here.
It seemed to provided a means of bypassing a palette load that was only called during a reload of assets.
Seemed like the perfect place to tinker. Now I see the convenient bypass was a config var. Probably should have just looked at that...
I do have your fix installed, but it does not account for FMs missing the full pal.
Still, it seems strange that the issue on crops up on reload.
One way or another, it feels like there is a bug in here.
Whether the images missing the full pal should always appear corrupt or never.
It's certainly not a feature that it changes on loading a save.
