LMS

What happens with the code above? The pickups certainly do work, I have used them with money bags before. Will see if I can find that code later.

You could try combining it with _HAS_ENTITY_BEEN_DAMAGED_BY_WEAPON and _CLEAR_PED_LAST_WEAPON_DAMAGE. If you set the third parameter of _HAS_ENTITY_BEEN_DAMAGED_BY_WEAPON it will do a weapon type check instead of looking for one specific weapon (second parameter). So you do not have to do that many calls to figure it out.

You should be able to get player money via C02DABFA3B98176 and set it via BC3422DC91667621.

Can you show me your ped class? Isn't that just a glorified uint32 so you cannot really store anything on it and would need a dictionary lookup anyway? In general, dictionary lookup are incredibly fast and you can do many lookups per native call in terms of performance.

It sounds really strange and I have never seen it happen, but I will keep an eye open. Do let me know if you find a way to reproduce it.

I am honestly not sure what would cause this. Have you tried logging their health during the arrest? Maybe that gives you a clue about what is going on and how to double check.

I would assume in most cases you just check the animation time and then do something based on that. It might also involve synchronized scenes as objects can play animations.

They are all just opened using DOOR_SYSTEM_SET_DOOR_STATE.

Not all doors can be opened unfortunately. RDRFR should have all the openable ones in terms of jail doors, are you just looking for those or for some other doors?

I don't personally use it (we use string hooks to achieve the same), but iirc it returns a char pointer in a special managed game memory that can be fed to game functions like you do above.

The type Prompt is just a wrapper around a handle, so int as a type is totally fine. It is the same for peds, you can have your type Ped, but ultimately it is just a wrapper around a handle (uint).

Odd, perhaps something else messes up the return value or the way it is passed. But that is definitely the function to use.

Casting it to string probably corrupts the return value of _CREATE_VAR_STRING as it is not a .NET string. Try using long or ulong as the return value instead.

We use a mixed approach in RDRFR. We get the group id as just Lambda has shown you, but also set the desk's group to be the active ambient prompt group if the player is close via 0x315C81D760609108 / _UIPROMPT_SET_AMBIENT_GROUP_THIS_FRAME. This is also where we feed the key (not the actual string!) to our custom name.

You are doing everything correctly, but the model change is detected by a game script and reverted. I think it is medium_update, but not entirely sure. A common way to solve this is to set the global that holds the model the player is supposed to have to your new model, so that the game does not detect any change. Below you can find an example from Alexander Blade's trainer. Please note that the global is outdated, however, and I doubt it works on the current version. You would find a more up to date script with the current version of look through the decompiled medium_update source yourself to locate the new global address. DWORD model = GAMEPLAY::GET_HASH_KEY(const_cast<char *>(m_model.c_str())); if (STREAMING::IS_MODEL_IN_CDIMAGE(model) && STREAMING::IS_MODEL_VALID(model)) { UINT64 *ptr1 = getGlobalPtr(0x28) + 0x27; UINT64 *ptr2 = getGlobalPtr(((DWORD)7 << 18) | 0x1890C) + 2; UINT64 bcp1 = *ptr1; UINT64 bcp2 = *ptr2; *ptr1 = *ptr2 = model; WaitAndDraw(1000); Ped playerPed = PLAYER::PLAYER_PED_ID(); PED::SET_PED_VISIBLE(playerPed, TRUE); if (ENTITY::GET_ENTITY_MODEL(playerPed) != model) { *ptr1 = bcp1; *ptr2 = bcp2; } }

Expanding the native game support to support more horses is quite tough I think, so your best bet might be to save your horse outfits with Pimp My Horse and then spawn the different horses in, when you want them. It is a bit hacky, but for now probably the best way.

I think that would be rather tough as it is probably deeply wired into the core game code. It might be easier to draw your own crosshair on screen instead (if that is useful for your case).

You could hook game functions that resolve text to translations and then feed your own text, yes. But I think the OpenIV team is working on language editing support, so perhaps just wait for that.

We had considered making a ScriptHook earlier this year when the game was supposed to launch, but the plans were abandoned with the multiple delays due to time constraints on our end during release time. I also personally have to say I only played it for like 30 minutes since it kept crashing, so I am not too interested in it.

I have unfortunately no idea what it might do, sorry.