New Limit Adjuster

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. Poor engineReplace* performance #748
• Maximum draw distance—ability 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—ability 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

[obuhhh]

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

[CrosRoad95]

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.

[Einheit-101]

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.

[Einheit-101]

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.

[WADmitry]

• 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).

[WADmitry]

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.

[Dezash]

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.

[WADmitry]

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).

[qaisjp]

@Dezash @WADmitry - see #638