This bug in the code/executable is why the player blips are stuck together in 2-Player mode

[KaizoM]

 

(I hope this is the right place to post this. If a moderator thinks it belongs somewhere else, feel free to move it!)

Have you noticed that the player blips are stuck at CJ's position? If you've noticed this, you might have ignored it, thinking it was a design decision or something.

No, it has nothing to do with the unused multiple protagonists feature, it's not because it was a lazy decision or a rushed move by the developers. It's a BUG, and a really silly one at that.

CRadar::DrawBlips()

The function responsible for drawing the blips is located in CRadar::DrawBlips (0x588050)

 

This image shows part of the code. Don't panic, I'll try to explain it: The FindPlayerPed function can receive either a 0 or 1, which correspond to player 1 or player 2, respectively. When this function is called without parameters, it looks up the active protagonist (but that's a whole other story). The same goes for FindPlayerVehicle, it can receive the player index and...a boolean? Notice that this boolean value passed to FindPlayerVehicle is always set to 0.

 

Alright, Kaizo, but I see in the image that it's not receiving a 0 or a 1, but a 'push esi.' What does that mean? To keep it simple, 'push esi' is just a way of temporarily saving something while you keep doing other things. Initially, that 'esi' is set to 0, which is the player 1 index. Later, the code asks, 'Does player two exist?' And if player two exists, it goes back to the same functions, but now that 'push esi' is sending a value of 1, for the player 2 index.

 

 

Alright, it makes sense, right? A small loop that first gets information about player 1 and then about player 2. Let's look at the next image. 

 

 

In this next image, we basically see the same thing; FindPlayerPed is still using the 'push esi' and FindPlayerVehicle does the same but with the boolean value set to 0.

Wait... and what about that FindPlayerCentreOfWorld_NoInteriorShift function at the end, what's it receiving?

 

 

It's receiving a value in edx, which is a CPU register we don't care about right now, and a hardcoded 0. THIS IS NOT A BOOLEAN VALUE — IT'S A HARDCODED 0 THAT TELLS THE FUNCTION TO USE PLAYER 1'S INDEX. THAT'S WHY PLAYER 2'S LOCATION IS BEING SET TO PLAYER 1'S POSITION.

 

If we change that push 0 to push esi, then we'll be passing the correct player index based on the loop — so on the second pass, it will FINALLY draw the blip at player 2's position.

 

Is it completely fixed?
Not yet. When the protagonist gets into a vehicle, for some strange reason, the bug shows up again. To fix this, inside the FindPlayerCentreOfWorld function there's a memory address at 0x56E2AD with the instruction je gta_sa.56E2FB. You have to change that je to a jmp and that's it — problem solved.

Why am I explaining it so dryly this time? Because I'm honestly not sure why this solves the issue. I found this out months ago and don't even remember how I came to that conclusion. But hey, with those two changes — replacing the push 0 with push esi, and switching that je to jmp— the player blips are finally and completely separated.

 

 

Conclusion
This bug wasn’t a design choice or a side effect of unused features—it's a simple mistake in the code. With just two small changes, the player blips are finally placed correctly for both players in 2-Player mode. It's a dumb bug, but now it's fixed.

I guess a developer, while copy-pasting the FindPlayerVehicle function, didn't notice that FindPlayerCentreOfWorld was supposed to receive the player index—not the boolean value 0.

Edited May 7 by KaizoM

[ZeroRaxo]

On that note, heres a very small script I compiled with the fix (The code is shamelessly stolen from his Real Multiple Protagonists mod), since as far as I know the fix has only been implemented in said mod.

2P Blips Fix.cs

 

 

P.S.  Dear Kaizo, please teach me how to mess around with memory, thats one part that I still have absolutely no clue on.

While you're at it, teach me how to be a good modder too lol, most of my mod projects hit a roadblock immediately because I lack the proper skills to finalise them.

Regards, Raxo.