No we don’t use that script. Just bob74. We had another script loading some ipls too. But I turned off all of these when testing. Its one of the first things I did to make sure no scripts were causing it for us.
Eh Does that script even work to fix Rockstar Editor mode crashing in FiveM? Doesn’t seem worth it even if it does if its causing those issues for you.
I use it for optimization purposes. I assume since the interiors and everything attached to that ymap aren’t loaded in, that’s less strain on player’s with under performing pc’s.
I’m sure this has absolutely nothing to do with the problem.
Yep, especially since the repos and maps provided here don’t include this map loader resource nor resources being started using the parent folder [folder]
Nice to see Maploader being mentioned here.
As someone who’s dealing with mapping very often, I see the biggest, potential issues here.
A) ymap conflicts, destroying the original parental structure
B) unoptimized maps
C) too many maps in one place, overloading the memory, causing more detailed LODs not to load in
Now, from my experience of building a new city, you can have LODs, optimized drawing distance and occlusion to boost fps, BUT if you have simply too many information loaded in about objects in the nearest vicinity (ytyps), this can result in memory not loading anything else in. Just because your GPU doesn’t visualize it doesn’t mean it’s not bloating the memory. This is very poorly and theoretically explained, but it’s something I noticed recently.
The “easiest” solution would be to lower drawing distance, but for entire ymap. Leaving more breathing room for the client. Presuming you have no ymap conflicts.
From the repro above (which happened to include the incredibly broken kambi_canyon2 ytyp). After noclipping around the map for a minute and dumping g_archetypeHash:
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 0
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 1
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 2
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 3
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 5
After another two minutes:
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 0
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 1
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 2
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 3
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 4
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 5
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 6
MainThrd/ apa_mp_h_acc_plant_tall_01: Hash = 0x553C4A55, Data = 328147757, Offset = 8
After four hours with a variety of add-on content (some broken), it seems plausible that something consistent with the other reported archetype issue is happening.
It seems (testing required) that due to broken extents (?), the constructor/destructor flow is not exhibiting the stack-like behaviour that the current workaround expects (see pointer-equality logic around 0x1415F7726/1604 or 0x14163BA0E/2802).
Can you explain how do you do this "g_archetypeHash’ dump?
I’d like to check it out as well to see which maps are potentially ‘breaking’ as well besides westons_mansion (the one with kambi_canyon2.ytyp) that I have already removed.
… uhh, does that mean that people’s content here:
making this some sort of chaos soup of archetype hell?
for what it’s worth, i’ve still not had the opportunity to look into this myself
I can certainly say that some of these mappers are careless. They have LOD distances across the entire world. I’ve been going through every map on my server one at a time and reducing things and editing things trying to fix this issue from happening and noticed it a lot. As well as issues with the wrong flags like models looking for LOD in parent map whilst being set to ORPHANHD because they actually have no LOD’s but whoever set the flags put the wrong thing. This is both in ytyp and ymaps themselves. If that matters I’m not so sure but some of these mappers are very well known in the community and when you look at their work its sloppy and rushed. In addition to many poly edge references being broken on their YDR and YBNs. Though I dont think that has any relation. Just a point of note.
does anyone notice when this issue starts happening in their server, camera orientation can affect it?
Weird spot for that to happen. What add on maps nearby?
only Gabz prison and an interior for madrazo’s ranch are near by, but I noticed this is kind of consistent. Also, lod issues seem to have stopped now (on beta version) but I’m getting a washington-monkey-double crash report … seems to happen before any LOD issues arise.
We already messed around with those settings on our end and it made no difference in the areas that it was happening. This seems like something else thats causing the same symptom. Could have more than one cause.
Well, I just opened up a few of Gabz maps and looked at the mess of LOD’s, FLAGS, PARENT INDEX values, LOD DEPTH LEVELS, LOD DISTANCES and had a stroke.
Turn off the Gabz stuff and see if its still happening.
Legacymaps, since you seem rather educated, How would one approach the flags determine what appropriate and what isnt?
@ItsOnlyWaifu well in Codewalker the definition for the values are mostly there. If there is no LOD for a prop then don’t have the LOD in parent ymap value selected.
For example here are some common ones I’ve seen. A lot of mappers don’t check the flags or care.
1572905 (lod) > 1572897
1572904 (lod) > 1572896
1572872 (lod) > 1572864
1572873 (lod) > 1572865
157921 (lod) > 1572913
On another note…
Something I wanted to mention is that it looks like Codewalker defaults to an LOD Distance of 1200 and hdtexturedist of 1000 for MLO shells etc inside of a YTYP. This could be a problem. Thats ridiculously far for an MLO? I’ve manually been editing some of them in OpenIV instead as if you try to save it in CW it won’t take. Additionally coming across some of these mappers with 10000-30000 lod dist on their props lol smh.
@LegacysMaps Thanks the information buddy, much love will start tweaking some the mlo’s I have a lot of them on maploader now etc
Do you have a list of MLOs where you found this issues? Maybe we should list them here to remove or fix them one by one. I know there a lot of mappers out there that won’t fix anything. Let’s hope that there will never be escrow on ymap or ytyp files.
Sorry I don’t have a list but I suggest going through your existing maps and what you can do easier is open each .ymap and .ytyp thats in those folders.
loddist and see if you have any INSANELY large ones in the results. Put them down to something more realistic like 200 or something like that (if its an exterior building or a large item you want viewable from far away with no LOD then try maybe 400-500 thats plenty in most cases).childloddist and make sure its set to 0 if the prop doesn’t have any children (numchildren value) 8. Check the lodlevel and make sure it says ORPHANHD at the end if it doesn’t have any LOD attached (you will know because parentindex should/will be -1).Hot Tip: Be careful of ymaps that have just one entity in them such as milo ones. Sometimes if you resave those and try to adjust their LOD distance it can cause render issues. Best to avoid those and just deal with the ymaps that use props and not interiors.
Disclaimer: This is not a sure way to fix the issues mentioned in this thread as the causes of SLOD LOD issue we are all mentioning its yet to be determined!
However it certainly can help optimize your server a bit for your players not having to render so much stuff so far away and should be done the very least with the LOD Distances that are insanely large. I have found maps by literally every major mapper and most small mappers that were all like that. I’m going to go ahead and assume a lot of them don’t care or they don’t have test servers or never had the issue brought up before. As I know whenever I’d have to get support from 99% of mappers in FiveM I get just attitude back lol so it wouldn’t suprise me if they would scoff at the very notion of something being wrong in one of their maps. Including broken polyedge references in their locked props ffs. But I digress.
If you really want to get crazy with performance gains you can set up custom Occlusion on some of your maps especially if they are ones that don’t use an MLO that is if you know how in Codewalker. But most mappers don’t bother doing that. Unfortunately.
This whole SLod/Lod issue seem to be on going, Can’t seem to get away from it, everything on maploader performance wise things are amazing, But slod issue is never ending and happens very randomly, extended texture budgeting seems to be putting a badge on it etc