Wondering if anyone has seen/experienced this before and has any clues to what may cause this.
This issue is reproducible on a server with no scripts, just maps. For instance all gabz maps plus a couple other maps and this’ll be reproducible.
If you change which maps you enable, it’ll happen as well. (What I mean is for instance have all gabz maps + 5 random maps, this’ll happen. Then disable those 5, enable another different 5 maps, this’ll happen just as easy.
From testing, I believe it’s related to assets being loaded into VRAM, then unloaded, then when loaded back they just scuff like that.
The way to reproduce this the quickest is to noclip around the map at fast speed and this will happen. Sometimes you have to just stand still for 2 minutes or so until your VRAM clears like it did from the 1st screenshot to the 2nd. Doing that will cause the issue to happen quicker I believe
This issue also aggravates the longer you stay connected, with the more times assets load and unload. For instance, at an early stage, if you encounter the issue like the screenshot above, you go away, then go back and it’ll render normally again. But from that point on everything is pretty much unstable and you’re subject to getting the that issue all over the map (even though there are zones where this is more common. The first one tends to be these mountains on the screenshot above). Noclipping around forcing the de-render of that zone and rendering it again may fix the issue temporarily. Also, it can be “fixed” via the use of 2 natives: SetFocusEntity and SetFocusPosAndVel. You can use SetFocusPosAndVel somewhere else far away in the map and then set focus back on yourself via SetFocusEntity(PlayerPedId()) and it’ll force the normal render of the area around you, fixing the issue. But obviously this isn’t practical, and it’s only temporary as well.
Also has the issue get worse (as your session time increases while you noclip/drive around) it has some affect on performance and it eventually also leads to a crash. This was tested in all game builds.
Do you actually have an actual list of ‘maps’ and so on that this consistently fails with? A statement like ‘all gabz maps and 5 random maps’ is still very much open to interpretation and might not consistently break.
It’s going to be impossible to investigate if not, also I suspect this might still be something being ‘wrong’ with these maps (for example duplicate entries of some sorts somewhere).
I know and I apologise, I mostly wanted to get the issue out there. I’ll try to get a list of maps (preferably no escrowed) this happens with. Also unlucky that of all my bug reports, the one without reproduction steps is the one that gets attention
In that case some acknowledgment, just to know that it has not fallen into oblivion.
Anyway, as requested I’ll send the maps I’ve used to reproduce the issue twice, using different maps. I’ll leave below the links to the reproduction so the issue can quickly be identified and so you can also see the pathing / speed I’m doing in order to “quickly” reproduce this issue. The first attempt took me 14 minutes total, and the 2nd attempt took me 32 minutes total in order to reproduce. This takes “so long” because I’m using a small number of maps in order to make this easy to reproduce. The more maps used, this can be reproduced as fast as 2 minutes. I’ve also tried, in both reproductions, to use maps in different locations and far from the places where the LOD issue are affected first. The only constant between both attempts are gabz maps, however this is also reproducible if used a bunch of other maps and no gabz maps (just mentioning this to perhaps exclude the option that one may think its related to gabz maps then).
First attempt:
ensure cfx-gabz-mapdata #*THIS RESOURCE IS REQUIRED FOR ALL RESOURCES TO WORK. IT MUST BE STARTED FIRST*
#ensure cfx-gabz-scenarios #*THIS RESOURCE IS OPTIONAL, IT REMOVES CONFLICTING PEDS SPAWNS*
ensure cfx-gabz-pdprops #*THIS RESOURCE IS REQUIRED IF YOU USE ANY PD. IT MUST BE START BEFORE PD'S*
ensure cfx-gabz-247 #*THIS RESOURCE IS MANDATORY IF YOU USE [CFX-GABZ-OTTOS]*
ensure cfx-gabz-altruists
ensure cfx-gabz-ammunation
ensure cfx-gabz-arcade
ensure cfx-gabz-atom
ensure cfx-gabz-aztecas
ensure cfx-gabz-bahama
ensure cfx-gabz-ballas
ensure cfx-gabz-barber
ensure cfx-gabz-beanmachine
ensure cfx-gabz-bennys
ensure cfx-gabz-binco
ensure cfx-gabz-bobcat
ensure cfx-gabz-bowling
ensure cfx-gabz-carmeet
ensure cfx-gabz-casino
ensure cfx-gabz-catcafe
ensure cfx-gabz-davispd #*THIS RESOURCE REQUIRES [CFX-GABZ-PDPROPS] TO WORK PROPERLY*
ensure cfx-gabz-diner
ensure cfx-gabz-esbltd
ensure cfx-gabz-families
ensure cfx-gabz-firedept
ensure cfx-gabz-fleeca
ensure cfx-gabz-harmony
ensure cfx-gabz-haters
ensure cfx-gabz-hayes
ensure cfx-gabz-hornys
ensure cfx-gabz-import
ensure cfx-gabz-impound
ensure cfx-gabz-lamesapd #*THIS RESOURCE REQUIRES [CFX-GABZ-PDPROPS] TO WORK PROPERLY*
ensure cfx-gabz-lost
ensure cfx-gabz-lostsc
ensure cfx-gabz-lscustoms
ensure cfx-gabz-marabunta
ensure cfx-gabz-mba
ensure cfx-gabz-mirrorpark1
ensure cfx-gabz-mirrorpark2
ensure cfx-gabz-mrpd
ensure cfx-gabz-ottos
ensure cfx-gabz-pacificbank #*THIS RESOURCE REQUIRES [CFX-GABZ-PDPROPS] TO WORK PROPERLY*
ensure cfx-gabz-paletobank
ensure cfx-gabz-paletocamp
ensure cfx-gabz-paletoliquor
ensure cfx-gabz-paletopd #*THIS RESOURCE REQUIRES [CFX-GABZ-PDPROPS] TO WORK PROPERLY*
ensure cfx-gabz-parkranger
ensure cfx-gabz-pdm
ensure cfx-gabz-pillbox
ensure cfx-gabz-pinkcage
ensure cfx-gabz-pizzeria #*THIS RESOURCE IS MANDATORY IF YOU USE [CFX-GABZ-OTTOS]*
ensure cfx-gabz-ponsonbys
ensure cfx-gabz-prison
ensure cfx-gabz-records
ensure cfx-gabz-sandypd #*THIS RESOURCE REQUIRES [CFX-GABZ-PDPROPS] TO WORK PROPERLY*
ensure cfx-gabz-studio
ensure cfx-gabz-suburban
ensure cfx-gabz-tattoo
ensure cfx-gabz-townhall #*THIS RESOURCE REQUIRES [CFX-GABZ-PDPROPS] TO WORK PROPERLY*
ensure cfx-gabz-triads
ensure cfx-gabz-tuners
ensure cfx-gabz-vagos
ensure cfx-gabz-vbmarket
ensure cfx-gabz-vu
ensure cfx-gabz-weedcamp
ensure cfx-gabz-yachts
ensure designer_penthouse
ensure malibu_mansion
ensure pacific_bluffs
ensure rooftopflat
ensure vineyards
ensure westons_mansion
ensure lfb
Referencing a related report: there are entity definitions referencing (unloaded) archetypes ba_gen_strip_emit (from dump) and bkr_int_02_lamp_no_mod (screenshot) that were causing crashes.
In your dump the archetype name (w/ hash) 0xCEB60B6A is still on the stack: this should hopefully narrow down the resource (unfortunately, I could not find this hash in vanilla GTA files). While conflicting/bad assets is likely the culprit to this. It is interesting to see that specific path fail in the dump.
I’m still getting similar crashes and I’m struggling to find the related archetype name in the dump. Can you explain how you’ve managed to get this value?
I also am having this issue. I am using gabz maps in addition to a plethora of other’s. I originally thought it was an LOD issue with how they render/de-render but it appears to be something consistent across other servers… I’ve also noticed this happens to some people in the same server, but not others.
What graphics cards are being used? I wonder it that has something do with it.
2080 Super
Maybe its like @nta said and its an issue of duplicate entries. I have seen that being mention in several topics but still need to wrap my head around it.
We have been having this issue for months. It happens even in areas of the map that have no custom MLO’s or YMAP’s like near Zancudo. I have checked custom YMAP’s on the server for LOD linkage issues and found none they are all set to ParentIndex -1 as they should be when they don’t have any LOD’s. Or Existing modified SLOD or LOD files were all removed from the server for testing purposes and the problem still remained. I assumed that some mapper had broken the LOD’s when editing some LOD or SLOD vanilla files. But alas, it did not fix said issue.
My next thought was maybe its got something to do with detecting where the ped is in relation to the LOD and SLOD’s. Some kind of issue checking the distance so that it knows when to unload or load the LOD’s as someone moves around. Its almost always SLOD2 SLOD3 that are loading on top of the HD textures. Double loading basically.
The only temporary fix is teleporting far away then teleporting back so that it reloads the textures and models. But its not feasible.
Its also absolutely not a specs issue. Even tried resetting to default settings with Graphics. Hell even tried some other alternatives like changing DirectX version in the settings.
Here are some examples. No mods exist anywhere near here. I also double checked by looking on the entire server for the LOD’s and SLOD’s that are seen here to see if someone else was loading them or conflicting. Even IPL loader scripts.
Very strange.
Given that I’ve been systematically checking all additional maps and have some more knowledge than the average player when it comes to troubleshooting this in detail based on how this game is built and I’m still stumped on it is rather frustrating. It may reach the point where I just start moving SLOD’s underneath the ORPHANHD as a temporary fix lol so even if they do double load they will be underneath the proper texture. But its not a viable option really in the long term and would take a lot of time to do manually.
It is not related to a GPU nor is it just a W10 or W11 thing. (I have not tried on my older W7 PC but I am curious.)
In my case with W10 PC I’ve tried WITH 5700XT as well as a 6900XT, 64GB OF Physical Ram (Corsair Vengeance) and plenty of HD space on a Samsung 980 NVME. But it happens to people with Nvidia just the same even on less powerful PC’s.
We run two servers. One is a fresh test server, we put some maps on it. Then turn them all off in batches until we had only 1-2 running on the test server and it STILL did it. Sometimes it would do it the second you load in. A virtually empty test server without any add on cars, scripts and 99% of its custom maps turned off and yet it still does it.
unfortunately we found and facing the same problem in our server too for the last 2 weeks, and the same results and information that currently we do have are the same as the other people brought up and attached here, regarding this issue,
addition to this thread, this problem occurs when you move to an Add-on mapping on the server, the Add-on mappings will disappear and only a few objects are hanging in the air will remain, And with using of Natives such as SetFocusEntity and SetFocusPosAndVel this issue will be resolved temporary.
If you encounter this issue often try to make them as reproducible as possible and/or attach crash dumps. The more information we can provide the easier it will be to track down the issue
I’m fairly confident it’s related/escalated by the amount of maps, as mentioned previously. I’ve tried this myself but a quick way for you to confirm as well is just update the game build of the server that is working correctly to the same game build as the other and see if the issue starts happening. Probably it won’t. Also won’t be related to ESX build since we run a custom framework and it happens as well, and even without any script at all it’ll happen. I’ve also tried 3 different game builds and it happens in all.
