Broken Human Peds for Specific Models and Other Ambient Ped Outfits Not Syncing

RedM Discussion RedM OneSync Reports
1

Client

Using canary? Yes, but N/A currently
Build: 1491 (I believe this was introduced in a later 1436 patch though)

Server

Operating system: Windows
Artifact version: 5848 and 6478
Edit: NOT OneSync Specific - happens with base networking

Incident

Summary:
Certain human ped models seem to be breaking sync between world grid owner and all other clients, both impacting all other ambient human ped outfits and those broken models are synced to other clients as mp_male with the default outfit.

Expected behavior:
Synced human ped models/outfits

Actual behavior:
Specific _y_ human ped models break by switching to mp_male with a default outfit on clients that don’t own the world grid / ped. Also, all ambient human ped outfits do not sync between world grid owner client and other clients in scope when one of those broken peds exist in scope. Those two things seem to certainly be connected, as when in other areas that don’t have a broken ped model in scope, the human ped outfits sync fine - it seems to only occur once these broken peds are in scope. Though it does seem to persist after that point until restarting the client.

Steps to reproduce:
Go to Annesburg or St. Denis with two-three players (-cl2 is fine). Whichever player arrived first should be the world grid owner, so the second player should start to see broken peds that are mp_male with the default outfit. The second player also will see different outfits for all ambient human peds compared to the world grid owner. If a third player comes into scope, they’ll see the same as the second player: broken human NPCs with mp_male model and the same outfits on ambient human peds, different from the world grid owner. If a non-owning client player grapples with a broken ped or takes ownership in some way, the ped will then be broken as mp_male to the previously owning player.

This specific location in St. Denis has one of the broken models (a_m_y_nbxstreetkids_01): 2736.90,-1365.59,46.37

Alternatively you can also just spawn the ped models and replicate it in the same way.

Here are the known broken models:
a_m_y_asbminer_01
a_m_y_asbminer_02
a_m_y_asbminer_03
a_m_y_asbminer_04
a_m_y_nbxstreetkids_01
a_m_y_nbxstreetkids_slums_02
a_m_y_unicorpse_01

Here’s an example of owning client vs non-owning (notice the non-matching outfits on the background ambient peds as well):

RedM_b1491_GTAProcess_hJFSjyvD4d
RedM_b1491_GTAProcess_hJFSjyvD4d1187×869 230 KB

RedM_cl2_b1491_GTAProcess_AJYWMEoIsx
RedM_cl2_b1491_GTAProcess_AJYWMEoIsx1166×758 91.3 KB

2

Actually, upon further review, this is happening without OneSync entirely… My apologies. I’m going to check if it’s occurring in RDO, but it is certainly happening with OneSync off with exactly the same behavior.

1 Like
3

Can confirm, this is a common occurrence in Saint Dennis.

4

It doesn’t occur in RDO, so this is an issue just in RedM, but even without OneSync. Something changed in a later 1436 build from R* that seemed to break it.

I can either close this or it can be moved to regular bug reports.

5

Interesting finding. Wonder why this can happen on RedM in non-1s mode but not in RDO. You can keep this topic in OneSync category if you want. Would be good to know for sure if this actually doesn’t happen on 1311/1355. Might be a broken patch in this case.

1 Like
6

Sounds good. I’ll test each build later today and confirm the status.

7

Can confirm that this does not occur in 1311 or 1355. Only 1436 and 1491. I recall it also not occurring with the initial 1436 release, but a mid-to-late patch prior to 1491 last Fall. I believe the second to last patch in 1436, but it’s been a while. I should’ve done due diligence and reported it back then :slight_smile:

8

Apparently in 1436.31 there was an additional function that was meant to block some certain ped models from syncing between players (mp_male was a used as a fallback model), no idea how this list ended up having “casual” ped models among “bad” models that was abused before. However we don’t want to restrict anything, so nuking the whole list. Going to be fixed soon.

UPD:

bool __fastcall tunablesIsPedModelBlocked(uint32_t modelHash)
{
  CTunables *tunablesMgr; // rbx
  unsigned int tunableHash; // eax

  tunablesMgr = atSingleton<CTunables>::sm_Instance;
  tunableHash = TunableHash(0xE3AFC5BD, 0x7CEC5CDA);
  return (unsigned __int8)CTunables::TryAccess(tunablesMgr, tunableHash, 1)
      && (modelHash == 0x8486093                // re_rally_males_01
       || modelHash == 0xBB6D5452               // re_rallydispute_males_01
       || modelHash == 0x39C84A35               // re_rallysetup_males_01
       || modelHash == 0x8E76B9B9               // a_m_y_asbminer_01
       || modelHash == 0x5C0454CD               // a_m_y_asbminer_02
       || modelHash == 0x14FD46C4               // a_m_y_asbminer_03
       || modelHash == 0x30407D4A               // a_m_y_asbminer_04
       || modelHash == 0xFC40064                // a_m_y_nbxstreetkids_01
       || modelHash == 0xACA57303               // a_m_y_nbxstreetkids_slums_01
       || modelHash == 0xCA57B2C4               // a_m_y_sdstreetkids_slums_02
       || modelHash == 0x75CC2B66               // a_m_y_unicorpse_01
       || modelHash == 0x111A98CA               // s_m_y_newspaperboy_01
       || modelHash == 0x84F58DCD);             // s_m_y_racrailworker_01
}

// ...

  if ( tunablesIsPedModelBlocked(*(_DWORD *)(a1 + 8)) )
  {
    *(_BYTE *)(a1 + 30) = 1;
    *(_DWORD *)(a1 + 8) = 0xF5C1611E;           // mp_male
  }
2 Likes
9

Can confirm this is resolved in Canary now. Thanks! :cowboy_hat_face: