Re-add dynamic ped ID allocating

[qaisjp]

This feature was removed before the release of 1.5.6 due to lack of testing. It might land in 1.5.7.

This reverts commit 242684e.

[Einheit-101]

is 1.5.6 so close?

[qaisjp]

@Einheit-101 yes

[Einheit-101]

That is good, no one is joining my server because i am running a late nightly version and players report me as soon as they click "ok" to install the update, mta will always download the same, old version because "update build type" is not set to nightly. I think i will make a bug report about this behaviour.

[qaisjp]

Yes, please do! All issues filed are appreciated. 🙂

[CrosRoad95]

You could compile mta with this feature, and make post with download of this version.
few people know how properly compile mta.

[qaisjp]

good idea

[Brian9221]

Hello, I've tested this feature with nightly rc-14053 and it seems to work pretty well. Though I have one big concern about this new feature: is it all client-sided?

I've tried to set my element model server-side with one of the custom models that this resource returned but setElementModel function only returned false as the model wasn't existing for the server. This might be a huge limitation as scripts would need to handle stream-in and data changes to enable those custom ped models if done clientside, thing that would be easier if we could allocate custom models ID from server, saving client from triggering multiple functions each time something is changed or streamed-in.

Am I missing an update for MTA server that I should have downloaded or the feature is like this, as in all client-sided?

[qaisjp]

Good point @Brian9221.

We haven't actually considered that problem, and the lack of sufficient testing of this feature is why we reverted this.

Future merges of feature/dynamic-ped-allocating should consider a fix or solution to this problem.

[Addlibs]

I'd say dynamic allocation is already a more advanced level and it should be tailored to advanced users, those who will sync it on their own in their own way for their own purposes. Server-side allocation will collide with client-side allocations so it's one or the other and I prefer the client side, which would also work better for multi-gamemode servers where each client might want to use allocated IDs for different purposes rather than being uniform throughout the whole server across all clients.

For instance, one of my scripts using this simply mapped model names to IDs, then the player's model can be stored as an element data and the clients individually allocate IDs and set the player's model on their end to the custom skin. This kind of sync is pretty basic and I can imagine even novice scripters would be able to get their head around this.

[Brian9221]

I guess it would up to server’s developers to decide whether or not do something clientsided or serversided.

Even now setting a skin is both clientside and serverside, including the possibility to cause desync or exploits due to mismatch of skins. Your point is good and obviously anyone with basic skills can script a good ped allocation clientside, yet again why you need to set an element data synced to everyone, then handle it on every client overloading CPU etc. when you want an unified ID for everyone that could be allocated in server and save you time and resources? Once again who manages the server would decide to do it client or server side. I’m not saying to delete this commit but at least provide a double system for users.

[ArranTuna]

Most servers will not be wanting different model ID's assigned to different things at the same time and not being able to do setElementModel(ped, newID) on the server side will cause a lot of confusion and annoyance for scripters.

[dretax]

This commit seems to be working well, but as stated I also recommend implementing a server side solution.

[dretax]

Any news on this?

[Neproify]

I think the best solution for this would be to leave this as-it-is, and just create resource for amateur programmers that they can use to synchronize models(probably add it to mtasa-resources?). There are a lot of servers that would like to synchronize it their own way. However, it still needs to replace models on client-side so i don't see any improvements using the server-side way.

[dretax]

Sync is one thing It really doesn't matter, but I honestly like It more If It's done in C rather than an interpreted lua. As long as It is able to make almost unlimited skins go for It though.

[CrosRoad95]

I agree with you of both, if you want sync ped, use original id's, if you wanna do other things, like place ped in outpost only for decoration reason, you can do this via new id's.

However, using custom id's serverside could be added in future

[dretax]

Indeed. It's really not a big deal to trigger a client side event. Server side can wait, but It is recommended to have it later.

[dretax]

@qaisjp please land this in the next update.

[qaisjp]

How will server-sync work if engineRequestModel is non-deterministic? (when multiple resources are in play)

[dretax]

You should make it script definable.

[qaisjp]

You should make it script definable.

Not really sure what you mean here...

[dretax]

Same here now, i am kinda lost with ur statement xD

[dretax]

Any news on this?

[dretax]

Does this mean that this is now in the latest update?

[ecastro98]

Does this mean that this is now in the latest update?

Yes. Since release 20147.
https://wiki.multitheftauto.com/wiki/EngineRequestModel
https://wiki.multitheftauto.com/wiki/EngineFreeModel

[PlatinMTA]

Does this mean that this is now in the latest update?

Yes, I'm using right now on my server at works just fine

[prnxdev]

How this can be used?

[PlatinMTA]

How this can be used?

Here you have a test resource: https://github.com/multitheftauto/mtasa-blue/files/1109966/testresource.tar.gz

Check the wiki: https://wiki.multitheftauto.com/wiki/EngineRequestModel
https://wiki.multitheftauto.com/wiki/EngineFreeModel