New bug in version 0.5.11 - Work around found

[Maximum]

Good work on Version 11, its very stable; I've been working with it on/off for the entire day and haven't had it crash yet.

But there seems to be a problem and its a weird one.

I've been converting TA Spring content over to TA3D with no problems UNTIL I decided to remodel a chassis for a unit. Upon texturing it and firing up the game I noticed that there was a single garbled texture over that entire part.

So I loaded up the starting unit and rotated a single texture, saved it and compiled a new HPI. Everything was fine, unit looks fine.

Next test I did was to change a single texture on that starting unit, now suddenly everything attached to that 'part' is wrapped in a single garbled texture.

Thinking 3dobuilder was maybe screwed I reinstalled 2.10, but get the same thing. I decided at this point to load up an older version of 3dobuilder and see if that affected things, 2.02.... Nope still loads with the part being wrapped in a garbled texture after changing one of the 3D Faces of the part.

Now the odd thing is, I've made some custom units from scratch for version 10 that load fine, I've also made some 3D map features that load fine.

So at this point I'm stuck and can't really do much more and I'm not too sure why its all of a sudden doing this.

Only thing I can think of is that theres some kind of change in the unit part loading process for the models or something since version 10.

Edit: I run an nVidia card with the latest drivers, nothing else is messed up just the above.

[zuzuf]

the 3DO loader merge all textures used on an object into a single one to speed up rendering but it creates UV coordinates that match respective textures so this shouldn't be visible unless there is a bug in the corresponding code. But things work that way since ... 0.0.2 or something like this ? one of the first versions to support 3DO format.

Can you send me the model that is showing that bug ?

[Maximum]

Update:

I decided to try to find if maybe it was an issue with the texture cache option. I never have it enabled in TA3D but perhaps its on by default now?

Reason I ask is because I changed the 1 texture again, renamed the unit to "NAME2" than set that as the commander in the gamedata.tdf file (so it spawns right off the bat) low and behold the units textures are fine.

Now taking that "NAME2"s model and changing one texture on a single face, saving than reloading the game causes that part to be wrapped in a garbled texture just like the origional unit was if 1 was changed.


I've been able to repeat this with any unit even loading up the core commander and changing one texture on it in the origional Totala.hpi files.


I'm wondering if updating the units texture on a part (even 1 panel) gives TA3D an error when it loads the unit causing the entire part to be out of whack.

Turning texture cache on or off doesn't seem to change loadtimes for my project and both yield the same results.

[zuzuf]

hm, interesting, texture cache may be the problem indeed since it cannot detect when the texture has changed it still put the old one which doesn't match the unit texture.

It's even worse now since there are 2 levels of texture cache:
_compressed texture cache (the first texture cache implemented in TA3D), can be deactivated
_raw texture cache (used to speed up loading), cannot be deactivated since it doesn't rely on any OpenGL extension/capability

it would be better to find a way to check if something has changed before loading cached data, for now you'll have to clear the cache each time you change one of this texture, it's in ~/.ta3d/cache on Linux, on windows it depends if you're using Door's binary (ta3d/cache) or ours (doc & settings/app data/ta3d/cache or something like that, next package will behave like Door's binary).

[Maximum]

Now that I know where it's saving this information I can just clear it manually. For some reason I never thought to just look at the command prompt debug window and just look up the directory where things were being stored.

"C:\Documents and Settings\ **LOGIN NAME** \Local Settings\Application Data\ta3d\cache\"


Its really nice to see the maps I made years ago in Bryce show up in real 3D and with the correct height coordinates to boot. Anyway, thanks for the texture cache work around.

[zuzuf]

Thanks for reporting this

[Balthazar]

"C:\Documents and Settings\ **LOGIN NAME** \Local Settings\Application Data\ta3d\cache\"

Maybe \ta3d\cache\ is better way to store data?

[Maximum]

That would be handier, or just an option to refresh the models built into the executable.

Since unless you're working on custom content there is never a need to refresh the model cache files.

[Balthazar]

Well, there are screenshots are stored... And it`s not very nice to search for them each time