Runtime IMG container

[Xenius97]

Summary

This PR adds runtime image containers through engineLoadIMG folder support.

When engineLoadIMG receives a folder path, the client builds a temporary IMG archive in the resource root directory, then streams models from that generated IMG the same way as a normal archive. This lets resources update individual files instead of forcing players to redownload one large static IMG every time. Runtime archives are created in the resource root with names like runtime-image-<tick>-<pid>.tmp and deleted automatically when resource stops (also cleared when it starts, so if your game crashes for some reason at next time this will do a cleanup)

Motivation

Updating model containers is currently expensive for players.
If one file changes inside a large IMG, clients must download the whole archive again.

With this change, resources can ship model files individually, and the client assembles a runtime IMG locally. This reduces client-side update overhead and saves server bandwidth, because players no longer need to redownload hundreds of MB when only a few files change.

Test plan

Resource:
runtime_img.zip

Everything works same as normal img containers.

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

[lynconsl]

Hi, any news about PR? I'm just waiting

[Xenius97]

Nobody check it, so just wait. Would be cool with 1.7

[qaisjp]

What is the point of img in the first place?

[lynconsl]

What is the point of img in the first place?

To allow some users to employ .img files without having to use multiple .txd/.dff (.col) files, .img organizes the files in a compact and systematic manner

[qaisjp]

Found it -- saves client memory and optimises load time according to: #1677

[qaisjp]

This is a cool idea but I wonder if it'd make sense to instead support some sort of "file patching" system for large files (like bsdiff / bspatch).

This would move the optimisation into file downloading, which could work for all types of large files, rather than changing how the img is loaded client side.

[Xenius97]

Actually, this only creates a temporary IMG archive that SA can load afterward. The files themselves are still downloaded individually, just like in every other case. The end result is that if you modify something, you don’t have to re-download a 600–800 MB archive again, only the single modified file. This also reduces the load on the HTTP server when multiple players are downloading at the same time.

I couldn’t find any other solution, and based on my tests, this was the only viable approach that actually worked.
I didn’t change anything about the original loading process, the only difference is that when it receives a folder path, it creates a temporary archive, mounts it, and uses that instead.