Client Crashes when attempting to fix Poly Edge Refences on .ydr or .ybn [ Physics validation failed ]

[Legacy-TacticalGamingInteractive]

What happened?

[    366829] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset tuco_paleto_sheriff_ext.ydr.
[    366829] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[    366829] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 40 edge reference is invalid. It leads to vertex 111, when there are only 108 vertices.
[    366829] [b3258_GTAProce] ResourcePlacementThr/ Physics validation failed for asset tuco_paleto_sheriff_ext.ydr.
[    366829] [b3258_GTAProce] ResourcePlacementThr/ This asset is **INVALID**, but we've fixed it for this load. Please fix the exporter used to export it.
[    366829] [b3258_GTAProce] ResourcePlacementThr/ Details: Poly 84 edge reference is invalid. It leads to vertex 59868, when there are only 15947 vertices.
[    379891] [b3258_DumpServ]                 8468/ Process crash captured. Crash dialog content:
[    379891] [b3258_DumpServ]                 8468/ GTA5_b3258.exe!sub_140C5E6DC (0x2b)
[    379891] [b3258_DumpServ]                 8468/ An error at GTA5_b3258.exe!sub_140C5E6DC (0x2b) caused FiveM to stop working. A crash report is being uploaded to the FiveM developers.
[    379891] [b3258_DumpServ]                 8468/ 
[    379891] [b3258_DumpServ]                 8468/ Legacy crash hash: massachusetts-snake-juliet
[    379891] [b3258_DumpServ]                 8468/ Stack trace:
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140C5E6DC (0x2b)
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140C5E86C (0xb6)
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140C7CF2C (0x31c)
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140C63640 (0xab)
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140C4B520 (0x4f5)
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140F19F44 (0xa4)
[    379891] [b3258_DumpServ]                 8468/   GTA5_b3258.exe!sub_140F19344 (0xa1)
[    379891] [b3258_DumpServ]                 8468/ 
[    382704] [b3258_DumpServ]                 8468/ Crash report service returned si-94b461a352a547ada74370f97f0cc646

• Does anyone know if the function that fixes these on load has been altered in any way or perhaps requires an update since the latest game build?

• Is it possible to make it more efficient/cause less crashing some way?

This problem with crashing due to this function has been occurring for weeks - pretty much ever since we updated to the latest game build.

In previous builds, this was not that big of an issue, and did not seem to cause any crashing. However on the latest game build this causes client crashes 90% of the time.

This crash due to the fixing on load will occur more often when there are many models that require being fixed on load nearby. Such as when there are many .ydr or .ybn in the area due to multiple MLO's etc. For example the popular large mod known as Roxwood is chalked full of these errors as well as many other maps out there and can lead to crashes 90% of the time when combined with other MLO's in the area needing to be fixed in real time.

Map Dev workaround:

There is a tool to fix the Poly Edge References ( @smallo92 [ https://github.com/92-Smallo/Ymap-Ybn-Mover ] ) for the models and collisions... however.... the issue is further compounded because many mappers are unaware of this issue in the first place - or even how to fix it, even with that tool being given to them they are still impossible to deal with about it. Some are unresponsive for months, if at all regarding fixing their models.

• .ybn files can be fixed by server owners without the original map designer needed

• .ydr files can be fixed so long as they are NOT encrypted, otherwise the tool cannot read them! This is where the biggest issue comes into play - relying on mappers to fix original source .ydr. Which is next to impossible to get responses from most after they've taken your money.

Every client on our server has been experiencing it so its not a matter of specs on the client side either. Nor is it related to player counts or any other issues. Its a very specific crash every time.

For fun, here are a few mappers that seem to not care and some screenshots there of the issue also occurring with their models. Yay!

Here are some more instances:

Expected result

Function to fix poly edge references on load to not cause crashing on client.

Reproduction steps

1. Load many .ydr and .ybn with broken poly edge references (most things exported by GIMS or Sollumz honestly end up like this)
2. Drive around or no clip around the MLO's that load these files and wait.
3. Problem happens more often the more models there are in an area.

Importancy

Crash

Area(s)

FiveM, FXServer

Specific version(s)

FiveM - tx: v7.2.2 | fx: b9875 | gta build 3258

Additional information

Might be related.

Note: Some of these shots of the crash logs are from other players not just me.

[tugamars]

+1 confirmed issue

[eotsbrooks]

Can confirm this is an issue.

[Mytic2330]

This is the same thing isn't it?

The problem was resolved when we removed most custom props from emote menu, but it still occasionaly appears.

[ook3D]

i would suggest rather using smallos tool to fix the warning messages, try importing then exporting it with sollumz (blender addon)

[Legacy-TacticalGamingInteractive]

i would suggest rather using smallos tool to fix the warning messages, try importing then exporting it with sollumz (blender addon)

Smallos tool works fine and it is the only solution we have right now to fix these problems.

Unless youre saying that sollumz can read encrypted files lol

[ook3D]

i would suggest rather using smallos tool to fix the warning messages, try importing then exporting it with sollumz (blender addon)

Smallos tool works fine and it is the only solution we have right now to fix these problems.

Unless youre saying that sollumz can read encrypted files lol

oh, i must have missed that, i thought i read the files were not encrypted

[Mytic2330]

So fixing encripted files is impossible without getting them open source from the creator?
What about if the game didn't fix polys? Would it work better?

[ook3D]

So fixing encripted files is impossible without getting them open source from the creator? What about if the game didn't fix polys? Would it work better?

ideally, you shouldnt need to fix anything to be honest, i would let the creator know and have them fix it

[Legacy-TacticalGamingInteractive]

i would suggest rather using smallos tool to fix the warning messages, try importing then exporting it with sollumz (blender addon)

Smallos tool works fine and it is the only solution we have right now to fix these problems.

Unless youre saying that sollumz can read encrypted files lol

oh, i must have missed that, i thought i read the files were not encrypted

Its too bad that it cant fix them, because with this latest crashing due to the in game real time client fix attempt the game makes, its making it a really serious problem. A good 75% of maps we buy, from big mapprers too, have these issues.

[Mytic2330]

Another topic,
is it possible that this crash is present in earlier game builds too?

[Legacy-TacticalGamingInteractive]

Another topic,
is it possible that this crash is present in earlier game builds too?

Dont know. We didnt experience it nearly as much on previous gamebuild. Then again maybe It didnt have massachusetts-snake-juliet in it if so.

[Mytic2330]

I wonder if it is possible, as we got a lot of crashes like "RAGE error: ERR_MEM_MULTIALLOC_FREE" and when analyzing crash dumps it was the same as the dump above, with matching citizenfx log. So fixing models is possibly the root cause of crashes?

[Legacy-TacticalGamingInteractive]

So fixing encripted files is impossible without getting them open source from the creator? What about if the game didn't fix polys? Would it work better?

ideally, you shouldnt need to fix anything to be honest, i would let the creator know and have them fix it

yeah but thats the problem lol. They don't. Or have gone completely inactive. Thus why this issue was created. Because without them fixing it we are all stuck with broken models. This, as stated in the OP, didn't cause that much of a big deal before but now it does.

[Legacy-TacticalGamingInteractive]

I wonder if it is possible, as we got a lot of crashes like "RAGE error: ERR_MEM_MULTIALLOC_FREE" and when analyzing crash dumps it was the same as the dump above, with matching citizenfx log. So fixing models is possibly the root cause of crashes?

Might be if the memory is maxed out due to the overhead of fixing the loading files perhaps?

[d22tny]

Stopping the resource from starting if it has physics validation failures or oversized assets would be a good addition. It would teach all the mappers how to actually work in optimal conditions. Most of the mappers have no idea about optimization and how the engine does work, so a change like that, stopping the resources from starting on any optimization error seems like a good change to me. It would not affect the quality, just having to export the right way and assign textures into ytds < 16.0 MiB of physical memory.

[Legacy-TacticalGamingInteractive]

Stopping the resource from starting if it has physics validation failures or oversized assets would be a good addition. It would teach all the mappers how to actually work in optimal conditions. Most of the mappers have no idea about optimization and how the engine does work, so a change like that, stopping the resources from starting on any optimization error seems like a good change to me. It would not affect the quality, just having to export the right way and assign textures into ytds < 16.0 MiB of physical memory.

While its a bit of a digression on the topic, lol, Its not even a bad idea. Would force them to actually put quality and care a little bit about the people who they are taking money from, and what their needs are. Besides just throwing out some crap product be it a map or a script. We've wasted thousands on scripts/maps from devs who refused to refund or fix anything or even let us fix it for them. Many of them don't even have test servers or any beta testing at all and these are also some of the most well known mappers and script devs you would think would actually test things. But its painfully obvious that they don't. Anyone can hit F8 and see client error logs alone and that should be enough for someone to stop and say to themselves hey maybe I should fix that - before even releasing. Oh what a world it would be. But there is no accountability so they do whatever they want. Anyways.

[d22tny]

I have a ticket opened with every creator that has problematic maps on my server. No-one helped. No1. told me to wait because they are busy releasing something, passed a week, no response. No. 2 never answered. No. 3 has some guys in staff telling me that both oversized assets and with poly edge reference errors on them have no major impact on the game.. This change really needs to be made.

[d22tny]

After some thinking only oversized assets can be stopped from starting, cuz only them are checked on startup, physics validation is done in runtime. Still, a very good addition only for the oversized assets.

[Legacy-TacticalGamingInteractive]

I have a ticket opened with every creator that has problematic maps on my server. No-one helped. No1. told me to wait because they are busy releasing something, passed a week, no response. No. 2 never answered. No. 3 has some guys in staff telling me that both oversized assets and with poly edge reference errors on them have no major impact on the game.. This change really needs to be made.

Yea its ridiculous

[Sirelle]

I'm dealing with the same issue. I had to remove most of my MLOs because the creators don't seem to care when I explain the problem to them. Their response is usually something like, "I've had a server with 1,000 players, and no crashes have ever happened," which is incredibly frustrating.

[iridium-cfx]

You should absolutely fix the errors, but just because that was the last thing in the crash log, it doesn't mean that caused the crash.

Looking through the crash logs in the screenshots, none of them immediately look related to physics stuff.