I did a bit more of a search and slowly added back all my resources in my Development server. I’ve found that after I add in [RELEASE] v2: Fix holes and customize the map (bob74_ipl) Rockstar Editor failed to load. Works fine on the normal game build everyone uses but breaks on the Tuner DLC build
1 Like
Just one quick follow up: do you have custom assets loaded on this server before/after you enable bob74_ipl?
I think I have one of these issues isolated. However, it is on a server with more modified assets than what has changed for the next iteration of GTA V. I do not want to spend too much time trying to minify this if it’s something unrelated.
I stopped every map resource and started it after the Cayo improvements was started. Had no other map resources on and it had the crashing problems with rockstar editor.
This is my current hunch:
Both bob74_ipl and CayoImprovements are scripts that greedily request each IPL (REQUEST_IPL) on initiation. They never remove (REMOVE_IPL) them or request them only when required.
When a recording is initiated (or during additional CPacketIPL creations) all #map’s are copied to a temporary (CReplayInterfaceObject) buffer. In 2372.0 this corresponds to:
uint32_t size; // 0x141F93930 (+0x18) or (+0x41C)
uint32_t hashes[256]; // 0x141F93930 (+0x1C) or (+0x420)
// sub_1404C41B0 is the routine
On 2372, with this repro, the number of loaded #map’s will be much higher than 256 (>280). The 1604 equivalent address would be 0x141C267F0 with the number of loaded #map’s not exceeding 170.
The ERR_MEM_MULTIALLOC_FREE, and other residual issues, I presume come from the fact that there is no bounds-checking when memcpy’ing to that buffer. Hence it clobbering subsequent addresses: some of which go through the rage allocator and it thinking the memory has already been de-allocated.
While I do consider this to be a scripting issue, I suppose I could figure out how to add some user feedback/warnings into this.
(Apologies for edits, I’ve been over debugging this issue for an hour now.)
1 Like
Given this is something that changes per release, would it rather make sense to somehow relocate or otherwise resize this fixed-size array, assuming it’s not used in too many weird places?
From an initial inspection, this would require a non-trivial amount of work as increasing those “buffer” sizes would have to be mirrored when processing those replay packets (e.g., 0x140137A44 and 0x1400A1419 in 1604 retail).
Given this is a patch specifically to battle against peoples misuse of loading IPLs when generating replays. Anything more than a message that tells users (more eloquently) to fix their shit just seems like a misuse of time.
1 Like
Nearly every server does this. It’s impossible to get the entire ecosystem to move on this.
1 Like
Interesting 
I’ve taken this into consideration and updated CayoImprovements.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.