Mtasa-blue: engineReplaceModel kicks the player out of the vehicle

[PlatinMTA]

Describe the bug
If you use engineReplaceModel() to model ID while you are on a vehicle with the same model ID, you will be warped out the vehicle.

To reproduce
Get inside a Perennial (404)

Run this resource

--clientside
function onStart()
        local txd,dff
    txd = engineLoadTXD("vehiculos/fiatuno.txd", 404) 
    engineImportTXD(txd, 404)
    dff = engineLoadDFF("vehiculos/fiatuno.dff", 404)
    engineReplaceModel(dff, 404)
end
addEventHandler("onClientResourceStart", resourceRoot, onStart)

Expected behaviour
The vehicle shouldn't kick you out

Version
Clientside: Windows 10 - v1.5.7-release-20462
Serverside: Windows 10 - v1.5.7-release-20462

Additional context
This also happens when using engineRestoreModel()

l33t

[botder]

It's worth mentioning this long-standing bug might already count as feature and fixing it _could_ break existing scripts.

[Lpsd]

In that case would it be possible to have a flag/option somewhere for this (defaulting to original behaviour)?

Not sure where that would be set though.

[PlatinMTA]

In that case would it be possible to have a flag/option somewhere for this (defaulting to original behaviour)?

Not sure where that would be set though.

The api could be changed to be something like this i think:

engineReplaceModel(dff, int model, [warp ped out of vehicle = true])

[Lpsd]

In that case would it be possible to have a flag/option somewhere for this (defaulting to original behaviour)?
Not sure where that would be set though.

The api could be changed to be something like this i think:

engineReplaceModel(dff, int model, [warp ped out of vehicle = true])

I’m not sure about that, it seems kind of weird and messy (since engineReplaceModel doesn’t only deal with vehicles) - plus if a similar issue arises in future that requires backwards-compatibility breaking fixes to be implemented, we can’t just keep adding parameters, it’s ugly!

It probably calls for a separate issue to be opened, but maybe there needs to be some kind of flag system for each bugfix which would break backwards compatibility entirely (and doesn’t seem fit for simply adding an extra parameter).

[qaisjp]

A server using this as a roundabout way to call removePedFromVehicle seems very odd to me.

I think at the very least we should not break scripts that attempt to workaround this issue by putting the ped back inside the vehicle.

Speaking of which, does this happen to all peds, or only players?

Also, is there anything else odd that happens when you replace models -- such as attached elements becoming unattached?

[PlatinMTA]

A server using this as a roundabout way to call removePedFromVehicle seems very odd to me.

I think at the very least we should not break scripts that attempt to workaround this issue by putting the ped back inside the vehicle.

Speaking of which, does this happen to all peds, or only players?

Also, is there anything else odd that happens when you replace models -- such as attached elements becoming unattached?

It seems that it only happens to players, peds aren't affected by it. Elements aren't deattacched, even if the element is a player. Tested on serverside and clientside.

It really appears to be a player issue only.

I’m not sure about that, it seems kind of weird and messy (since engineReplaceModel doesn’t only deal with vehicles)

We already have functions that do this kind of thing (setElementRotation comes to mind). I don't know, which alternative we have if we want it to be backwards compatible?

[saml1er]

It really appears to be a player issue only.

@PlatinMTA You're right. It's only related to players.

The api could be changed to be something like this i think:
engineReplaceModel(dff, int model, [warp ped out of vehicle = true])

Yeah, we can either do this or add a new property function for backwards compatibility. It will work like setGlitchEnabled but for client-side.