T3FM's size. - TTLG Forums

242 on 21/10/2005 at 17:45

Potter, if I understood you correctly, I don't think it's a good idea.
Every time someone will add new texture to the pack everybody else will have to download it - no flexibility at all. Every author should decide for himself which textures he/she wants to include in the IBT and compile it him/herself.
End user shouldn't be involved in this, or in downloading and installation of any additional packs except the FM archive.

potterr on 21/10/2005 at 18:03

242, not quite what I meant, I was aiming more as a large texture pack of say 300 textures that people can use in thier FMs. Any additional ones (not in the pack) can still be added in to the ibt on release, where as ones known in the standard pack will be on peoples PCs. Kind of like an unofficial upgrade to T3. This would reduce file size down a lot but still give great flexibility to authors. The thing that I see as a problem is that as we find out things about the editor it is likely there will be new custom objects coming out, new AI models, static meshes, conversations, etc. This in turn will also bump up the file sizes so if its possible to start with a minimal package size to begin with then these additions shouldn't cause too much overhead. Plus if you have a bigger set of textures to begin with there is greater scope for people to make their FMs (kind of like a the upgrades that were done for dromed).

If new textures become common after the texture pack is released then there is every possibility to expand that to a second pack. GL can be programmed to pick up texture pack flags and not allow someone to play if they don't have the texture pack installed, etc.
The only downfall would be that the texture pack needs to be available all the time to download.

Anyway it was just a thought for one possibility to reduce file size.

Bardic on 21/10/2005 at 18:32

I just had a thought, and I guess Shadowspawn would be the one to know this.

He's hoping to create a process where the Mission creator strips the texture data out of the FM ibt file (At least OM textures and Garrett's stuff as mentioned above), and then on the user side a GarrettLoader plugin will take all the OM texture .dds files and convert them and put them back into the ibt. Which means the end user will have to download a zip with the OM textures once.

Can we eliminate the end user needing to download the OM texture pack by creating a program that will strip them out from the original missions? The end user already has them on their computer with the Thief3 install.

Ziemanskye on 21/10/2005 at 19:55

Uh, I think the idea here was to have a one-shot texture pack of all the official textures.

These then get stripped from the ibt files for FMs - because the game can look for them in the PCTextures/DynamicallyLoaded folder.

The same is true, on different paths, for Garrett and the NPCs and the animations, but I think the main thing is to get the textures out.

(custom?) Smeshes and custom textures remain in the ibt files.
That was the idea I think - the original texture pack is never extended, and smeshes keep their physics properties and reskins for the mission through being safely inside the reduced ibt files.

We don't need to recompile the ibt files afterward - it'll take a little longer to load (in game), but the file sizes are down and the game can still find the "missing" stuff.

I might be wrong about that plan. I remember having an argument with someone about the process around here a while ago, and I think this was the compromise I stopped replying to the thread at.

Bardic on 21/10/2005 at 21:27

I think Shadowspawn can already strip them out, he is just hoping he can find a way to add them in clinet side also. And of course he can take any time he needs, It's just cool that things are progressing.

Everyone could live with the performance hit of loading from the dynamically loaded folder, for most people it may not be a big deal. Iit can be done, that's cool too.

Shadowspawn on 22/10/2005 at 02:10

I think the idea method would be to strip out all large items from the IBT which are "standard" Thief 3 textures, smeshes, AI, etc. Shipping this "compressed" IBT would be alot easier, it will be much smaller.

On the client side, a small program run at installation time would go out and get all the things needed to re-inflate the IBT to full size, with all the pre-cooked data. This might take some time, but it should only need to be run once.

After we get this worked out, we could include specific "search paths" which would say, for example, "Unable to find Texture blahblah_n.dds, last found in \Special High Quality Texture Pack\wood\old". This could inform the player that he really needs the "Special High Quality Texture Pack" installed if he wants to play this FM. This could eliminate the need to constantly distribute stuff, players could find out what they need during installation, go get the stuff if they want it, and then re-install the FM. It's possible we could even tell them all the missing items (in a file or something) and they could go pick and choose the items they need (for slow connections / limited space users), provide our content providers want their stuff allowed to be broken up.

Just some thoughts. First step is to get the IBT compiler finished.

Crispy on 22/10/2005 at 07:25

Well, everyone already has most of the core data; it's in the OMs. Why not have the client-side program look for resources in the OMs? It could be distributed with a list of resources that are in the OMs, and where to find them. (For example, "the texture GENwall512.dds can be found in Auldale.ibt at location blahblah...". This list would be generated automatically, of course.) Then it can take that resource and stick it straight into the new IBT.

The beauty of this system is that you don't need to convert from, say, DDS to IBT and vice-versa. It's already *in* the IBT's internal format! You just copy out the chunk and stick it into the new file.

Advantages:
- No format conversion is necessary. Therefore we gain both speed (copying data is faster than converting it) and simplicity (none of the OM stuff has to be run through conversion routines).
- Nobody has to download any of the data that's already in the OMs. Dial-up users rejoice!

Disadvantages:
- This doesn't account for any resources that were distributed with the editor but weren't actually used in OMs, or custom resources. These will still have to be downloaded. However, this is an issue that will have to be dealt with regardless.
- This does introduce additional complexity, and requires writing more code. Perhaps this should be left until after the issue of resource packs etc. has been dealt with; then OM stuff can be distributed as a downloadable resource pack to start with. Once that's all up and working, then this can be added in.
- ???

OrbWeaver on 22/10/2005 at 09:53

Quote Posted by Shadowspawn

Do you actually need to add the standard content back into the mission IBT files? Will the game not automatically load them from the kernel IBTs if they are not found?

Ziemanskye on 22/10/2005 at 10:38

It can certainly load it from */DynamicallyLoaded folders.

The only reason(s) to put it back in are if the stripping process breaks the ibt file somehow, or if people really want the level to load that bit quicker (for some people it doesn't seem to make much difference - for me it seems to add about a minute onto the loading times).

potterr on 22/10/2005 at 10:51

Quote Posted by Ziemanskye

...or if people really want the level to load that bit quicker (for some people it doesn't seem to make much difference - for me it seems to add about a minute onto the loading times).

I suppose it may be something we have to live with if we want smaller zip files and continued available downloads.