Need Help Changing Textures of Model

[Levis]

So I was experimenting a bit and I noticed models allow for textures to be in subdirectories. This made me think we might be able to safe some space with textures which are copied multiple times in different directories by having the game locate to a higher folder and then only for the specific textures go to the lower folder.
For example at the moment and outside location looks in the folders JUNGLES,NATIVES,HOLLAND,FRANCE,SPAIN or ENGLAND
And a lot of the textures in these folders are the same. Maybe it could be like:

PLACES
|-HOLLAND
|-FRANCE
|-ENGLAND
|-JUNGLES
|-NATIVES

and have most of the files only in the PLACES folder while the specific ones are in the respective folders.
This would also later open up the possebility of making new textures for more wealthy or war-torn towns, and you could actually have the town look burned after it was raided etc.

But with hexediting the model files I could take a filename linke Roof_All.tga and change it to test\All.tga and have rename the Roof_All.tgx file to All.tgx and move it to a subfolder called test, but I couldn't add something to the name. Probably because there is a checksum in the file or a defined lenght for the string block in the model file. Does anyone has information about this and know how to change these things?

 

[Levis]

okay by toying around with a hex editor I know it's not a checksum, I think I found what looks like a chunksize/header in front of the strings (what I expected) and when increasing it with 1 and adding 1 byte to the strings the game does load the model kind off ... it doesn't crash at least.
I think the file starts with a header specifying the lenght of different chunks, so I would need to identify which bytes define which chunk. then you could increase the size of the strings.

 

[Levis]

Update again. I can now make the game load the model right but it doesn't recognise the strings/textures right yet.
Like I suspected the game has a header defining the different chunk sizes.
In byte 08 and 09 the size (and maybe others too but I don't think so) the size of the strings chunk is defined. These bytes are in reversed order, so if it says EC 02 that means the size is 02EC = 748 bytes long.
By adding one byte to the string chunk and increasing this value with 1 I was able to load the game and the model, but the textures aren't recognised.
Now I changed one of the very first textures. in the files. When changing one of the last ones it will load without a problem (except for these last textures), so I guess there are pointers in the file pointing to the names of the textures used. So if I want to add data here I would need to find these pointers and change them to match the new places .

Anyone knows anything about this?

 

[ChezJfrey]

header defining the...size of the strings chunk is defined. .

Correct, a portion of the header defines size in bytes of the entire catalog of string names.

...so I guess there are pointers in the file pointing to the names of the textures used. So if I want to add data here I would need to find these pointers and change them to match the new places .

Also correct. When the strings are read in, the entire size-of-bytes we already discussed, is read into one, continuous character array. When texture portions are read in, the 'name' is actually just an integer, for the index number, that is used to find the starting position in that giant character array as the starting point for the texture path/name (zero based index: zero to size-in-bytes strings, less 1).

So what you are looking to do, would require changing, via hex-edit, the size of bytes to exactly match how you manipulate the strings, and if you move the starting char position of any individual name, you must find that portion of the file that pointed to that spot (a zero-based index for that char array), and change that too.

There is an easier way...I changed the texture lookup feature to backtrack directories, automatically, if a .tx can't be found. So now, simply remove the redundant .tx files from NATIVES,HOLLAND,FRANCE,SPAIN or ENGLAND, put them in JUNGLE and voila! It will continue to backtrack, upon failed find, until the root TEXTURES directory is reached.

Oh, ETA: I had made this change for precisely the same reason; to reuse/reduce redundant textures and reduce file consumption of the game I also wrote my own special utility that will compress all the .tx files, en masse, that I ran against all textures over a certain size (for my own flavor of mod, if they weren't already compressed).

 

[Pieter Boelen]

Cool stuff, @Levis and @ChezJfrey!

Until now, the only thing we could do was to have the Installer EXE copy the identical files to their subfolders.
That does save on download size (which explains how the Build Mod installer can be so "small"), but once installed, it is still as big as ever.

 

[Levis]

Correct, a portion of the header defines size in bytes of the entire catalog of string names.



Also correct. When the strings are read in, the entire size-of-bytes we already discussed, is read into one, continuous character array. When texture portions are read in, the 'name' is actually just an integer, for the index number, that is used to find the starting position in that giant character array as the starting point for the texture path/name (zero based index: zero to size-in-bytes strings, less 1).

So what you are looking to do, would require changing, via hex-edit, the size of bytes to exactly match how you manipulate the strings, and if you move the starting char position of any individual name, you must find that portion of the file that pointed to that spot (a zero-based index for that char array), and change that too.

There is an easier way...I changed the texture lookup feature to backtrack directories, automatically, if a .tx can't be found. So now, simply remove the redundant .tx files from NATIVES,HOLLAND,FRANCE,SPAIN or ENGLAND, put them in JUNGLE and voila! It will continue to backtrack, upon failed find, until the root TEXTURES directory is reached.

Oh, ETA: I had made this change for precisely the same reason; to reuse/reduce redundant textures and reduce file consumption of the game I also wrote my own special utility that will compress all the .tx files, en masse, that I ran against all textures over a certain size (for my own flavor of mod, if they weren't already compressed).

So we just need to wait untill you figured out with @pedrwyth how to get the build mod completly working as intended on the new storm engine and this problem is solved ?
That's good to hear, then I'm not going to look into it further, because figuring out where the textures are in the file would be a tough job unless there was documentation from inez dias or so.

 

[Pieter Boelen]

figuring out where the textures are in the file would be a tough job unless there was documentation from inez dias or so.

As far as I am aware, there isn't.

 

[ChezJfrey]

So we just need to wait untill you figured out with @pedrwyth how to get the build mod completly working as intended on the new storm engine and this problem is solved ?
That's good to hear, then I'm not going to look into it further, because figuring out where the textures are in the file would be a tough job unless there was documentation from inez dias or so.

I suppose so. I will add though, to my knowledge, the thing already works, 95 plus percent. To this point, there seems to be some quibbling over some slight interface changes, that I would say were predictable, some placement issues (like the current gun charge icon in battle interface) that are easily solved by simply changing the X/Y coordinates in the definition. Unless @pedrwyth is holding out on me, saving me from more crushing and debilitating problems, as yet unmentioned?

The texture manipulation you were looking to do seems rather unfeasible, in my opinion, given that if you were to change the strings, at the beginning, every subsequent name has now shifted X number of bytes, and you would have to alter (assuming you were given where the indices for those are in the file structure) the actual texture name value that corresponds to add that number of bytes everything shifted on that 'right' side of the large character array. If you shift another name string, again change all corresponding index values...etc. Keeping track of all that shifting, manually, and trying to edit that via hex-editor, is a daunting prospect, to get correct.

The reasoning behind the change you are looking for is indeed sound, but the process and attention needed to get it correct seems crazy difficult...maybe I'm just soft, LOL

 

[Levis]

I suppose so. I will add though, to my knowledge, the thing already works, 95 plus percent. To this point, there seems to be some quibbling over some slight interface changes, that I would say were predictable, some placement issues (like the current gun charge icon in battle interface) that are easily solved by simply changing the X/Y coordinates in the definition. Unless @pedrwyth is holding out on me, saving me from more crushing and debilitating problems, as yet unmentioned?

The texture manipulation you were looking to do seems rather unfeasible, in my opinion, given that if you were to change the strings, at the beginning, every subsequent name has now shifted X number of bytes, and you would have to alter (assuming you were given where the indices for those are in the file structure) the actual texture name value that corresponds to add that number of bytes everything shifted on that 'right' side of the large character array. If you shift another name string, again change all corresponding index values...etc. Keeping track of all that shifting, manually, and trying to edit that via hex-editor, is a daunting prospect, to get correct.

The reasoning behind the change you are looking for is indeed sound, but the process and attention needed to get it correct seems crazy difficult...maybe I'm just soft, LOL

I'm a programmer too as soon as I knew how to do I would write a script to do it for me.