Suddenly afflicted by a spike in crashes on b3258, after November 2nd, 2024. Users will connect to the server, play for 1-2 hours with no issue, then continuously crash over and over.
Clearing their local cache will fix this temporarily.
We suspect this might be related to maps/streaming, but we haven’t changed map files since the 28th of October. We’re unsure why there’s a massive surge of crashes. Occasionally users will crash right on selecting their character until they clear their local cache.
Anecdotally, this seems to occur quickly on 10778. I am unable to replicate this myself, but my players are able to. I don’t know if this is related to the SLOD2 issue or the solution for it, but seems to affect users who are actively moving around the map.
But whatever is causing this, some script on your server, is likely a cause.
Additionally, you have a TON of broken .ybn that need to be fixed. These loading in real time like that and being fixed on load causes overhead which will crash clients. The broken .ydr and .ybn poly edge references does in fact cause crashes and need to be fixed by the source mapper.
It could also be that now its more sensitive to it on latest artifacts. But regardless they need to be fixed. Figure out whatever this zone thing is too.
[ 1194172] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 398528)^7
[ 1194172] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 709891)^7
[ 1194172] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 469128)^7
[ 1194172] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 588633)^7
[ 1194172] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 586964)^7
[ 1194172] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 954931)^7
[ 1196187] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 286014)^7
[ 1196187] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 627016)^7
[ 1196187] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 314823)^7
[ 1196187] [b3258_GTAProce] MainThrd/ ^3Warning: attempted to remove a zone that does not exist (id: 563201)^7
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 7 edge reference is invalid. It leads to vertex 65267, when there are only 4390 vertices.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset ch2_07d_0.ybn.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 215 edge reference is invalid. It leads to vertex 65528, when there are only 4208 vertices.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset ch2_07d_0.ybn.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 2 edge reference is invalid. It leads to vertex 65271, when there are only 4877 vertices.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset ch2_07d_0.ybn.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 3 edge reference is invalid. It leads to vertex 63794, when there are only 4678 vertices.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset ch2_07d_0.ybn.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196453] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 3 edge reference is invalid. It leads to vertex 2667, when there are only 2317 vertices.
[ 1196469] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset ch2_07d_0.ybn.
[ 1196469] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196469] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 0 edge reference is invalid. It leads to vertex 294, when there are only 132 vertices.
[ 1196469] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset ch2_07d_0.ybn.
[ 1196469] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[ 1196469] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 11 edge reference is invalid. It leads to vertex 65531, when there are only 95 vertices.
[ 1204125] [b3258_DumpServ] 20432/ Process crash captured. Crash dialog content:
[ 1204125] [b3258_DumpServ] 20432/ GTA5_b3258.exe!sub_140777E18 (0x5d)
[ 1204125] [b3258_DumpServ] 20432/ An error at GTA5_b3258.exe!sub_140777E18 (0x5d) caused FiveM to stop working. A crash report is being uploaded to the FiveM developers.
Doing some testing, it seems there is some kind of memory leak or at least streamed streaming memory is not being properly cleaned up.
The way you can do this is to just teleport and/or no clip around the map extremely quickly, this will lead to ResourceCache usage to build up, and never be cleared. Reconnecting to the server will result in either the resourcecache being totally full or nearly full, and will go over the limit once the player is loading assets.
Clearing the client cache will temporarily fix this, but eventually, after moving around enough, it will cause these crashes again.
To add to this, my experience with ResourceCache usage is that it will constantly expand so it can take on more assets, while never properly clearing itself out. This will lead to texture loss and crashes, as the client will eventually run out of room for the cache or the cache will grow too large for the game to properly handle. It has been that way for me since I started playing FiveM.
I have also noticed an uptick of people mentioning crashes after one of the more recent server artifacts came out. This is, in true CFX fashion, almost always blamed on the client without an actual explanation as to how it is the client’s fault. It’s hard to believe that numerous people have all started having consistent crashing after moving to the new server artifacts, but those artifacts don’t play some sort of role in the crashing. I haven’t, and won’t, update my server artifacts until this issue is resolved or definitively proven to not be caused by the newer server artifacts, as it seems to exacerbate an already bad and overlooked issue in how FiveM manages streaming resources and cache cleanup. Unless something has changed, restarting the server should be enough to reset the ResourceCache. Obviously, this isn’t an ideal way to deal with a problem that is only getting worse.
Ideally, assets exclusive to Paleto Bay should not be loaded in while you’re in Los Santos, and vice versa, unless we’re talking about a skyscraper or something similar. Furthermore, after the asset is no longer nearby or in use, it should be removed from the cache until it is in use again (this would probably have some sort of performance tradeoff). Some of that will come down to how creators optimize their assets, as I have had maps in Paleto Bay be immediately in cache as soon as I join my server, regardless of where I was on the map, which is unnecessary.
You are basically just describing how the game already works.
The grcore/ResourceCache usage in the streaming memory viewer indicates the amount of video memory being used. It will basically always show as full, because it unloads the least recently used textures on demand.
Yeah, this was made before the current archtype testing you set up for us to try, so I was looking for any indications of why this crashed.
ATM there does seem to be an overall increase in crashes, which I think is tied to a number of things related to mapping, but for us specifically it was that double archtypes issue.
With the dual archtypes, did you manually go through your YTYP and remove vanilla (unedited files) that were added to the YTYP by dumb mappers. Or did you just remove any duplicate named .ydr or .ytyp from the server?
