Increase streaming memory

[Xenius97]

Is your feature request related to a problem? Please describe.

MTA currently have maximum 256mb streaming memory, that's not enough if you want to use new features as well. (Like: #3065)
If you load eg. an img which is around 200-250mb map will be blinking if streaming memory is on full, so new IMG feature is useless now.

Describe the solution you'd like

Something like engineSetStreamingMemory( [megabytes] 256-768 )
768mb should be enough for all servers, which have eg. large model pack (like mentioned in #3065)

I've tested with this, and have no issues (original discussion: #2264):

Describe alternatives you've considered

No response

Additional context

No response

Security Policy

• I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.

[Dutchman101]

If you load eg. an img which is around 200-250mb map will be blinking if streaming memory is on full, so new IMG feature is useless now.

I think you got the wrong perspective.. both with the new engineLoadIMG as the classic engineLoadDFF / engineLoadTXD functions, you are doing just that: load custom assets into the game. If you chose to load more, or more & more unoptimized, heavy, assets when you began using engineLoadIMG, then you may encounter the effect you're describing. Even though on MTA there are tons of unoptimized servers, which are to an extent playable with 256MB of streaming mem. My point is, if these servers were to use the same mods, in the same amounts, but switch from classic functions to IMG, the outcome should be the same. If it's not, then we may be talking about a different issue, that the performance of IMG functions is worse than classic ones, but its PR #1677 states the opposite: "This feature will save client RAM memory" and until you show otherwise i think that would be subjective, produced by the sentiment that you currently have after encountering streaming mem issues while you're working on your models and using the new IMG features for it.

It's important to keep these aspects apart from eachother, and evaluate individually. Some server owners may be triggered by the new IMG features, and inclined to redo their mods, of which a step may be loading more, or different (more heavy/unoptimized) mods, with the unintended side-effect of causing issues with streaming mem and memory-stability. Then they may feel like it's directly a result of using IMG features, but nah. Unless of course, you can demonstrate the truth is the contrary of the "This feature will save client RAM memory" statement, then we can split this matter into 1) investigating why that is, reviewing the new IMG functions regarding it, and as i see it's what you are interested in, we can give re-introducing the streaming memory limit increase, another look (To help, i just made some comments on it @ PR 2323#comment-9

I've tested with this, and have no issues (original discussion: #2264)

During your own tests, you're overlooking what we know (original reasons for revert of that streaming memory increase). For background on that please refer to the comment link above, as well.

[Meine1]

My point is, if these servers were to use the same mods, in the same amounts, but switch from classic functions to IMG, the outcome should be the same. If it's not, then we may be talking about a different issue, that the performance of IMG functions is worse than classic ones, but its PR #1677 states the opposite: "This feature will save client RAM memory"

I tested loading the exact same mods via the new IMG functions and the classic loading functions and indeed, the memory performance using the new IMG functions is much worse than the classic functions when the streaming memory limit is reached. The PR's statement is not wrong, when you start a resource with mods loaded via IMG functions the client's RAM memory is extremely low at first, but the more custom assets you encounter in the game the memory usage keeps increasing until the map blinking bug happens, with the classic functions that never happened.

[patrikjuvonen]

cc @TheNormalnij

[Xenius97]

memory is extremely low at first, but the more custom assets you encounter in the game the memory usage keeps increasing until the map blinking bug happens, with the classic functions that never happened.

When you using img, GTA will stream assets dinamically, much better than classic method cause classic method loads everything into memory even it isn't needed, so client memory could fill in a second when you using larger modpack / vehicles.

GTA:SA automatically clearing assets which doesn't needed (like when car model streams out), classic method will keep in memory.

GTA:SA streaming could break map too, if you're using too much assets. The best solution is combining these 2 methods, eg. load cars with .img, and load object models with classic method.

[Meine1]

When you using img, GTA will stream assets dinamically, much better than classic method cause classic method loads everything into memory even it isn't needed, so client memory could fill in a second when you using larger modpack / vehicles.

The IMG loading functions work really well for loading large modpacks, the problem is when the streaming memory is filled then the game map disappears and sometimes even serious input lag, rendering the whole point useless. It's a shame because the way it dynamically streams custom assets and frees up memory when not close to them already would make them far superior to the classic functions.

[Pirulax]

Seems like everyone has forgot about the comments I made on the original PR, so here's the link.
tldr: MTA uses a model cacher, that was made with the default model sizes in mind [so 140 kb/vehicle model, etc], but. The way it works is it keeps vehicles, peds, etc in memory [to reduce pop-in], but it's more like a bandaid to the shit streamer GTA has [that was designed with CDs in mind, not HDDs, thus the performance is garbage on HDDs, and SSDs alike, because of how the streamer tries to load nearby models together]]
The fix would be to:

• a. Disable the cacher
• b. Rewrite the cacher to take into account the model size [from CStreamingInfo]
• c. Rewrite the streamer to be more HDD/SSD friendly - This is IMO the best solution, as it would solve the pop-in issue altogether, and we could remove the cacher altogether [or, at least the ped+veh part, because it seems like the cacher is also there to prevent some crashes?]