Mtasa-blue: New Limit Adjuster

Created on 15 Apr 2019  路  19Comments  路  Source: multitheftauto/mtasa-blue

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

SA has many limits, and we need to lift them. When you're loading mods, it takes forever to wait. Some servers will cause clients to eat 90% of MTA process RAM and crash eventually. I played modern games, even they don't consume that much RAM. This happens because objects are loaded the moment you call engine functions, and loading is done on the main thread. We should have at least 2 threads for loading mods, and here we are loading on the main one. All of these issues are possible to fix since we have optimized memory pools #480.

Describe the solution you'd like

  • Implement a new streamer for streaming in and out entities as the current one will cause massive lags when you have too many objects and players on screen @ArranTuna
  • Loading DFF, COL, TXD, and IFP on a separate thread when using engine functions, GTA SA loads them on a separate thread using CdStream* functions, but MTA doesn't.
  • Saving RAM by loading an object only when it needs to be streamed. engineReplace* functions will load it immediately, we need to only load it if the object is visible. #748
  • Maximum draw distance鈥攁bility to stream in entire map.
  • Support for multiple low LODs for a single custom object or a GTA map object and set distance for each LOD. Depending on how far the object is from the camera, the low LOD will be rendered instead of the high LOD model, this would save lots of CPU.
  • Removing ID limit鈥攁bility to add new objects without replacing current ones, this includes new vehicles with driving ability.

Optional

  • Increasing map sectors, so mappers can create objects outside of the current -3000 to 3000 range. I think that something like -10000 to 10000 would suffice.
  • Custom collisions for every object. We can make it object based rather than model based.
  • general fix of collision detection, now you can affect fps drop when you're inside bounding box of collision bigger then ~300KB
enhancement

Most helpful comment

If it can be easily fixed, well then we would all appreciate it as many people play MTA because it's all their computer can handle yet MTA gives me worse FPS than GTA V which completely demotivates us to play and many other players have said this too.

I did some testing with current MTA streamer in December when I removed default map objects and streamed in entire Alien City map (550mb). My game froze completely and everything was so much laggy that I couldn't even move my mouse cursor, so I disabled the MTA streamer and wrote a couple of lines of code to force MTA to stream in all custom objects, it surprisingly gave me 25 FPS with zero optimizations even though there were still some performance bottle necks which was giving me bad FPS, and at that very moment I realized that without writing a new streamer, it's simply not possible to have new features without losing performance.

I used to think there was not much that could be done about the low FPS in MTA because I thought it was GTA collision system, but when I realised that a PS-2 could handle the GTA world with it's 299 MHz processor and 32 MB of RAM so we must be playing on PC's 100x more powerful than a PS-2 yet unable to get a stable frame rate something else must be going wrong.

That's right. It's not GTA causing the problems, it's MTA.

To be honest, all other changes to MTA feel pointless to me and probably many other players too because we don't have a stable FPS to enjoy those changes. I think we could get back a lot of players to MTA if the low FPS was improved. Low FPS is the true limit in MTA.

I know, that's why I'm rewriting the streamer, so players can enjoy new features with stable FPS.

All 19 comments

If someone close this issue, then he can also close MTA too :)

add point:

  • ability to load .col and .dff files bigger then 256x256x256 ( make whole map in few files )
  • general fix of collision detection, now you can affect fps drop when you're inside bounding box of collision bigger then ~300KB

support to .obj files too would be nice, no more not working plugins that export invisible collision.

My biggest concern is actually the currently poor performance, but that infinite streaming sounds good

  • ability to load .col and .dff files bigger then 256x256x256 ( make whole map in few files )

make whole map in few files

I wonder how is that going to be helpful.

  • general fix of collision detection, now you can affect fps drop when you're inside bounding box of collision bigger then ~300KB

That would be nice. Do you have any bigger object with collision. I'd like to test it.
>

support to .obj files too would be nice, no more not working plugins that export invisible collision.

Invisible collision? Are you talking about KAM's script for 3ds max?

My biggest concern is actually the currently poor performance

@Einheit-101 can you be more specific about performance? Do you mean gameplay, some Lua functions, streaming in and out of entities, or something else? 馃檪

Arran told me about current MTA streamer that when you have too many objects, vehicles, or peds on screen, it will cause massive lags. I've experienced it personally, and that can be easily fixed.

I talk about terrible performance when there are many Peds streamed in and setElementData. There seems to be another thing wrong but i could not figure out what it is. On my server the performance drops to a very low level when there are many battleships streamed in.

I talk about terrible performance when there are many Peds streamed in and setElementData. There seems to be another thing wrong but i could not figure out what it is. On my server the performance drops to a very low level when there are many battleships streamed in.

I don't think setElementData has anything to do with MTA streamer. It's important to understand that setElementData will synchronize the data with all clients, which is mostly not what you want. Wiki states:

As element data is synced to all clients, it can generate a lot of network traffic and consume server CPU

Using triggerServerEvent or triggerClientEvent without using root as element will save CPU. If you still believe there's a problem, then send me a code snippet, so I can reproduce it.

  • ability to load .col and .dff files bigger then 256x256x256 ( make whole map in few files )
    make whole map in few files

I wonder how is that going to be helpful.

Currently there is a problem with low accuracy. I.e. when we export map's parts from 3ds Max (which are divided to 256脳256 pieces), there may be small gaps between edges of the adjacent pieces (for an example, one corner's vertex may be a little higher than should be). In the case we would just join nearest parts of the map and avoid these gaps.

This actually would be very helpful in _some_ cases (I don't think that loading the whole map as one object (or a few objects) is a good idea).

I don't think setElementData has anything to do with MTA streamer. It's important to understand that setElementData will synchronize the data with all clients, which is mostly not what you want. Wiki states:

Actually I surprised that MTA still has not ability to sync a data using different ways out-of-the-box, like:

  • Sync data between server and only one client (one-side direction, from server to client)
  • Same, but two-side directions, from server to client and from client to server)

(and it should send data only when it has been changed)

-- how much time left before the offer ends
player:setData("time_left", time_left, SYNC_SERV_TO_CLIENT) -- one-side direction, from server to client

And I very surprised that setElementData has synchronize = true by default. It's very wrong decision, I think. It should be false by default.

Actually I surprised that MTA still has not ability to sync a data using different ways out-of-the-box, like:

  • Sync data between server and only one client (one-side direction, from server to client)
  • Same, but two-side directions, from server to client and from client to server)

(and it should send data only when it has been changed)

Everything you described is already achievable by other means. Also, MTA streamer has nothing to do with it so you would be better off creating a separate topic for it.

And I very surprised that setElementData has synchronize = true by default. It's very wrong decision, I think. It should be false by default.

It is true by default because that's how most new scripters would expect it to be.

Everything you described is already achievable by other means

Sure. I didn't write this is not possible. But right now we should always use own implementations for this. I'll file an issue for it.

It is true by default because that's how most new scripters would expect it to be.

Most of them use it "by default" everywhere and then have a lot of problems (lags, low performance). Most part of newbies always uses simplest way (miss optional aruments, don't read documentation, etc). And actually this way of sync (sync between server and all clients in both directions) is needed only in a few cases. Anyway, I don't think it would be changed (because of breaking change).

@Dezash @WADmitry - see #638

just fix shadows
image

Currently there is a problem with low accuracy. I.e. when we export map's parts from 3ds Max (which are divided to 256脳256 pieces), there may be small gaps between edges of the adjacent pieces (for an example, one corner's vertex may be a little higher than should be). In the case we would just join nearest parts of the map and avoid these gaps.

This actually would be very helpful in _some_ cases (I don't think that loading the whole map as one object (or a few objects) is a good idea).

I see. It's probably better to create a new issue. Also, please provide some images and the DFF model itself.

  • Loading DFF, COL, TXD, and IFP on a separate thread when using engine functions, GTA SA loads them on a separate thread using CdStream* functions, but MTA doesn't.
  • Saving RAM by loading an object only when it needs to be streamed. engineReplace* functions will load it immediately, we need to only load it if the object is visible. #748

Would hooking the CdStream* functions to load custom DFF/TXD instead of the original from gta3.img solve both these issues?

Would hooking the CdStream* functions to load custom DFF/TXD instead of the original from gta3.img solve both these issues?

Maybe, I just think that would be unnecessary or even ugly since they are small functions, and they are specifically designed for loading models from gta3.img. We already have our own functions for reading custom mods. We just need a new thread for I/O operations like described here.

There are only 3-4 functions that we need to hook or rewrite completely to make the new limit adjuster a reality. You can check the decompiled code:
CRenderer::SetupMapEntityVisibility
CRenderer::SetupEntityVisibility

@Einheit-101 can you be more specific about performance? Do you mean gameplay, some Lua functions, streaming in and out of entities, or something else? 馃檪

Arran told me about current MTA streamer that when you have too many objects, vehicles, or peds on screen, it will cause massive lags. I've experienced it personally, and that can be easily fixed.

If it can be easily fixed, well then we would all appreciate it as many people play MTA because it's all their computer can handle yet MTA gives me worse FPS than GTA V which completely demotivates us to play and many other players have said this too.

I used to think there was not much that could be done about the low FPS in MTA because I thought it was GTA collision system, but when I realised that a PS-2 could handle the GTA world with it's 299 MHz processor and 32 MB of RAM so we must be playing on PC's 100x more powerful than a PS-2 yet unable to get a stable frame rate something else must be going wrong.

To be honest, all other changes to MTA feel pointless to me and probably many other players too because we don't have a stable FPS to enjoy those changes. I think we could get back a lot of players to MTA if the low FPS was improved. Low FPS is the true limit in MTA.

If it can be easily fixed, well then we would all appreciate it as many people play MTA because it's all their computer can handle yet MTA gives me worse FPS than GTA V which completely demotivates us to play and many other players have said this too.

I did some testing with current MTA streamer in December when I removed default map objects and streamed in entire Alien City map (550mb). My game froze completely and everything was so much laggy that I couldn't even move my mouse cursor, so I disabled the MTA streamer and wrote a couple of lines of code to force MTA to stream in all custom objects, it surprisingly gave me 25 FPS with zero optimizations even though there were still some performance bottle necks which was giving me bad FPS, and at that very moment I realized that without writing a new streamer, it's simply not possible to have new features without losing performance.

I used to think there was not much that could be done about the low FPS in MTA because I thought it was GTA collision system, but when I realised that a PS-2 could handle the GTA world with it's 299 MHz processor and 32 MB of RAM so we must be playing on PC's 100x more powerful than a PS-2 yet unable to get a stable frame rate something else must be going wrong.

That's right. It's not GTA causing the problems, it's MTA.

To be honest, all other changes to MTA feel pointless to me and probably many other players too because we don't have a stable FPS to enjoy those changes. I think we could get back a lot of players to MTA if the low FPS was improved. Low FPS is the true limit in MTA.

I know, that's why I'm rewriting the streamer, so players can enjoy new features with stable FPS.

Can be this issue reopened and assigned to me? I hope #1677 will help me.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CrosRoad95 picture CrosRoad95  路  3Comments

CrosRoad95 picture CrosRoad95  路  3Comments

Cazomino05 picture Cazomino05  路  3Comments

CrosRoad95 picture CrosRoad95  路  4Comments

commanderagu picture commanderagu  路  3Comments