warpPedIntoVehicle causing C++ runtime assertion failure

[Dark-Dragon]

Describe the bug

Some obscure, mostly trailer-like vehicles that can technically have a driver currently misbehave when you attempt to warp someone inside on a passenger seat using warpPedIntoVehicle, causing network trouble for the player at best and a Microsoft Visual C++ Runtime assertion failure on the server at worst (see below).

Example Vehicle IDs: 610, 611, and a couple more

Steps to reproduce

run veh = createVehicle(611,0,0,3) plyr = getRandomPlayer() warpPedIntoVehicle(plyr,veh,0) -- works as intended, contrary to...

run veh = createVehicle(611,0,0,3) plyr = getRandomPlayer() warpPedIntoVehicle(plyr,veh,1) -- warpPedIntoVehicle will falsely return true but warp the player on top of the vehicle instead, causing network trouble after a while

run veh = createVehicle(611,0,0,3) plyr = getRandomPlayer() warpPedIntoVehicle(plyr,veh,10) -- to cause the assertion failure

Version

MTA:SA Server v1.5.9-release-21554 (Windows 10, 64 bit)

Additional context

Possibly related: #2907 getVehicleMaxPassengers returns 'false' for those instead of the expected 0

Relevant log output

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Assertion failed!

Program: ... Andreas 1.5\server\mods\deathmatch\deathmatch.dll
File: C:\BuildAgent\work\675e5b8e8f135823...\SharedU....Misc.h
Line: 1571

Expression: uiIndex < SIZE

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)
---------------------------
Abbrechen   Wiederholen   Ignorieren   
---------------------------

Security Policy

• I have read and understood the Security Policy and this issue is not security related.

[sacr1ficez]

I don't think it's related to certain vehicle models. I remember having network trouble when calling warpPedIntoVehicle right after vehicle creation, if you delay warp (by setTimer) - it should be fine, hacky - but working temporary fix.

[Dark-Dragon]

I don't think it's related to certain vehicle models. I remember having network trouble when calling warpPedIntoVehicle right after vehicle creation, if you delay warp (by setTimer) - it should be fine, hacky - but working temporary fix.

Most likely an entirely separate issue, it doesn't appear to matter when I use warpPedIntoVehicle to reproduce the same buggy behavior with these vehicles every time.

[lopezloo]

You also can't warp clientside ped to clientside trailer (ex. 611) at any seat (not even the driver one). Maybe should be reported as seperate issue though.

crun veh = createVehicle(611, 0, 0, 3)

crun ped = createPed(17, 0, 0, 4)

crun warpPedIntoVehicle(ped, veh, 0)

Command results: false [boolean]

Maybe this is the actual correct behaviour and possibility to warp players to trailers driver seats is not. But it works for players though. It makes me wonder if it would be possible to actually add possiblity to warp to passenger seats too in trailers (related issue: #851).

That assertion failure happens because the passed seat number is higher than the max vehicle seat count:

mtasa-blue/Server/mods/deathmatch/logic/CVehicle.h

Line 370 in eedbdc5

SFixedArray<CPed*, MAX_VEHICLE_SEATS> m_pOccupants;

[Dark-Dragon]

Maybe this is the actual correct behaviour and possibility to warp players to trailers driver seats is not.

Well the engine seems to allow it, and while I can't think of very many use-cases, I think it shouldn't be removed. Seems like the few issues they're having right now are reasonably easy to sort out.

It might be worth noting that admin2 lists these trailer vehicles and will warp the player inside when Give Vehicle is used, so that's at least one case where having this can help. It's also not out of question that some scripts use these vehicle IDs to replace the model with their own, is it? Also even the title screen shows it as if it were a feature as of now: