Mtasa-blue: setElementModel doesn't work on serverside with dynamic ped ID

[Xenius97]

Describe the bug
setElementModel doesn't work on serverside with dynamic ped ID

To reproduce
Client: engineRequestModel("ped")
Server: setElementModel()

Screenshots
https://puu.sh/Eh2r8/aa76893d85.jpg

Version
v1.5.7-release-20164

[qaisjp]

this is not fixable, you need to use triggerClientEvent and set the model client side

[sbx320]

This makes me wonder if we should reserve some IDs to support server based ID allocation later. In most cases everyone just wants to use a new ped for everyone on the server anyway. Could also do similar stuff with engineReplaceModel etc.

[qaisjp]

This makes me wonder if we should reserve some IDs to support server based ID allocation later. In most cases everyone just wants to use a new ped for everyone on the server anyway. Could also do similar stuff with engineReplaceModel etc.

i thought a little about this and thought we could maybe utilise negative numbers? i don't know if model numbers are signed or unsigned. idea being that negatives are used server-side and are mapped locally to whatever is free (but it gets a little complicated when you use getters)

we can still reserve them "live" but we might run into race conditions that way (this is tricky)

[PlatinMTA]

Isn't it possible to simply make the server know about what model you use even if it's model isn't serversided? The 236 IDs are not being used anyway.

What I mean is to make the server know that player.skin (or w/e) is, for example, 398 and trigger that change on all the clients? If the model isn't allocated on the clientside just simply show CJ's skin (now that I think about it, that would mean that all the 236 IDs should be allocated even if the client doesn't really use them, is that really a big problem?).

I'm probably missing something here, but idk.

Either way, making the sync between models from serverside and clientside isn't that complicated, with an elementdata you can work it out.

[qaisjp]

The custom model numbers returned by engineRequestModel are not transferable to other clients.

So if you sent a custom model number from a client to a server (so that you can later use setElementModel serverside), it would only be _guaranteed_ to work for that client, not other clients.

For other clients, that custom model number might correspond to a different texture, a different element type (vehicle, weapon, object), or even simply not exist.

Since model numbers are allocated sequentially, you can still _try_ to guess what the model number would be, but again, consistent model numbers across clients cannot be guaranteed, and will only lead to eventual disappointment!

We can probably make it so that using setElementModel server-side with the custom model numbers will still send the setElementModel request to each client, but with the caveats described above, it would be pointless.

Some steps forward here would be to:

• improve documentation for engineRequestModel to make it _very clear_ that you really should not transfer this model number to other clients
• release an official resource to help handle this allocation for you

Implementing an official resource would also help us find the best way to implement server based ID allocation later.

[PlatinMTA]

Mmmh, I see. I have a question tho, after disconnecting from a server, MTA deallocates all the IDs? If it does not then I suppose every server could, when a user enters, deallocate all the IDs using a table and the function engineFreeModel()

[qaisjp]

Yeah MTA deallocates all the IDs (or at least it should)