Open ghost opened 5 years ago
If someone close this issue, then he can also close MTA too :)
add point:
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:
(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
hassynchronize = true
by default. It's very wrong decision, I think. It should befalse
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
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.
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
Optional