Allow allocating new ID's on server

[TheNormalnij]

API

int model = allocateModel( string type, ... config )

This function will allocate new modelID from the end of modelIInfo array( from 20000 to 0 )
Will return false if modelIInfo array is full

bool success = allocateModelAt( int modelID, string type, ... config )

This function will provide manual ID control.

bool success = freeModelAt( int modelID )

Will destroy all objects used by this ID and deallocate modelID

How to it will works

When resource with new ID's will be started, server will send packed with new registered ID's. If client has conflicts with serverside ID, client should reconnect to this server.
When client try connect to the server. It should get packed with all new allocated ID's before game and resources started and allocate new ID's

[Pirulax]

I don't think we should use numeric IDs on the server. How about names instead, like:

bool success = allocateModel(string name,  string type, ... config )

We'd add support for passing in model names(of server allocated IDs) to existing functions. Maybe even add support to client-sided engineRequestModel as well? Eg.:

bool success = engineRequestModel(string name, ....)

In the case of a name clash:

• Client tried to allocate a server id: fail so we prevent desyncs
• Server tried to allocate a client id: server succeeds

Why?

• No ID clashes possible, because we're aren't returning ID's, so no need to kick anyone unless they're out of free IDs
• In the future if the client's free ID limit gets increased the server will be limited to around 5000 unique IDs
• Future proofing
• numeric model ID's are kinda unpredictable. How would one write a system which allows only certain vehicle models to do something without sending packets back and forth with the server? Managing client-side tables (sent from the server) is still a pain in the ass that would need to be maintained (by the scripter)

[TheNormalnij]

• No ID clashes possible, because we're aren't returning ID's, so no need to kick anyone unless they're out of free IDs

Model names clashes possible

• Server tried to allocate a client id: server succeeds

Server will silently break something at client, bad idea, i think

• In the future if the client's free ID limit gets increased the server will be limited to around 5000 unique IDs

Impossible, because server owner manages his own resources

• Future proofing

But you need replace all current API and sync system for new system. This is too big refactor. My solution is simple.

• numeric model ID's are kinda unpredictable

It's GTA SA design

[Pirulax]

It's GTA SA design

GTA wasn't designed to have a whole Lua API.

This is too big refactor. My solution is simple.

Indeed it's simpler, but also worse.
I dont care if the refactor is "too big" (which it really isn't, because we just need to add support for string modelid, and change the sync logic for peds/vehicles (and whatever types can be allocated)).
As for the bitstream part (aka syncing part):

• We hash the ID with a hash function that has little to no collisions, but is fast as well.
• Send that fixed size hash instead of a model ID (with a bit indicating whenever we've sent a regular modelid or a hash)
• This wont cause any backwards compatibility issues(even tho it breaks the backwards compatibility), as for proper syncing this function require minclient to be the same as when it is introduced

Model names clashes possible

Idk wdym here. They're as stated, yes.
But, keep in mind I want to make this future proof, so if once we add unlimited models we'll wont break backwards compat.
Also, adding this function, and then deprecating it would be a nightmare.

[Pirulax]

• Server tried to allocate a client id: server succeeds

Server will silently break something at client, bad idea, i think

Yes, but hacked clients could return true always, thus making the server unable to allocate an ID.
Perhaps add a client-side debug script telling that "id %s overwritten by the server".

[Pirulax]

So, what do you think?
I'd like to start working on this.

[AlexTMjugador]

I agree that it would be nice that the Lua API for this uses names instead of numeric IDs, to avoid numeric ID clashes between uncooperative resources and making sure that the same model has the same ID in both the client and the server. Of course, at the end of the day the model string should still be converted to a numeric ID that will be used in the GTA: SA modelInfo array; for this, a collision-free hashing method would need to be developed, which can be as simple as using a normal hash function but making sure that no hash is used twice (by using open addressing techniques, treating the hashed model IDs as if they were buckets in a hash table). The biggest drawback I can see is that using ID strings feels a bit strange, because people already are used to numeric IDs because of the client-sided functions, but with proper documentation, education and widespread usage this should not be a problem.

Maybe even add support to client-sided engineRequestModel as well?

I'd support this, as it would make the client-side and server-side functions more similar. IIRC, GTA: SA model IDs already have names somewhere we can use (or at least someone assigned such names in the map editor), so it should be possible to deprecate numeric IDs entirely for every function that uses numeric model IDs, like engineReplaceModel.

I also fancy the collision resolution method that @Pirulax pointed out for client and server requested IDs. I agree that the server should have priority over the client.

[Pirulax]

Thanks for your feedback!
Now that I think about it, since we'd break net compatibility anyways*, we might as well think about a good way to sync these ID's.
My idea would be to only sync the model name once (when allocated / client joins the server), and assign an ID to it, and later just have a bit prefix indicating whenever the ID is server allocated or native.
This way hash collisions wouldn't be an issue.

* AFAIK its fine to not be net compatible. (As 1.6 is not planned to be anyways)

[TheNormalnij]

it should be possible to deprecate numeric IDs entirely for every function that uses numeric model IDs,

Numeric ID's are ultrafast because it direct access to model info. You can still use engineGetModelIDFromName if you want use model names only. I wouldn't make current API slower. Sometimes i need to use few functions for 6000 models and with strings it's be slow. Using hashes will make client network little slower also.
I don't want to desync getElementModel function between client and server.
Now engineGetModelIDFromName use hardcoded names, we need to use modelInfo array for this stuff. So i think that function engineGetModelNameFromID is useless so we can sync only char eModleType + int ID + int nameHash.

So we can use:

-- Server
int model = allocateModel( string type, string name, ...config )
bool success = allocateModelAt( int modelID, string type, string name, ...config )

-- Client
local model = engineGetModelFromName( "model_name" )

Perhaps add a client-side debug script telling that "id %s overwritten by the server".

We can solve collisions by deallocating client-side models or reallocating them. But i think that it's rare situation . It's can happens if scripter will reach ID limit.

I still think that replacing whole net system to using hashes is fun but useless idea.

I would like other MTA members to take part in the discussion.

[Pirulax]

Numeric ID's are ultrafast because it direct access to model info.

A Lua API call probably takes more time than us resolving the model name -> id conversion :D
(A hashtable lookup is around 400-500 ns, you can trust me that a Lua call is way more than that).
Also, keep in mind I woudn't be using the model info array for resolving the model names. I'd copy all id, name pairs into the hash table, and thats it (since model ID's and names are static).

We can solve collisions by deallocating client-side models or reallocating them. But i think that it's rare situation . It's can happens if scripter will reach ID limit.

What guarantees that free IDs are the same on all clients?

Using hashes will make client network little slower also.

The sync wouldn't get any slower, we only need a bit to indicate whenever the model is a native, or server allocated one.
(When a model is allocated, the server would send out a request packet in model name, server id format, and when you sync the model id, you'd use the server id, and a 1 bit prefix to indicate that it's a server ID.

[TheNormalnij]

What guarantees that free IDs are the same on all clients?

We don't need sync clientside allocated id via engineRequestModel.

You can implement same functionality via Lua API now. Just use setElementData for model name and onClientElementStremedIn to sync custom model.

If you want to use only model names for current Lua API, you can do somethings like this:

eModel = { 
   __index = function( self, key )
       return engineGetModelIDFromName( key )
   end;
}

setmetatable( eModel, eModel )

localPlayer:setModel( eModel.truth )

I think mostly server owners don't want to see dynamic changes in ID's on server. For example, car showroom is very common script on servers. With my system server owner only need call allocateModelAt( 19999, ... ) and add info for model 19999 to car config. This script will good work with database without additional changes. With your system server owner need rewrite DB code, config code, creating code... And this is for almost all scripts that use current static ID's. It's painful for scripters.

So, I think we can provide your string model ID API via additional resource for those users who need it.

[Pirulax]

Internal numeric IDs are fragile.
You havent answered my question regarding "do all clients have the same free ids?"
Right now, with your solution the process would look like this:

• Send packet to clients requesting an ID
• ????? Clients might send back different IDs??
• Which ID do we return?
  Or you wan't to have another giant hardcoded table somewhere that has free IDs in it?

Also, as stated above, if in the future we decide to change something, and it'd require us to remove some ID's or something the scripts would break. With a naming abstraction layer i'd work perfectly.

[TheNormalnij]

You havent answered my question regarding "do all clients have the same free ids?"

MTA doesn't support custom GTA SA IPL and IDE mods, so yes, all clients have same free id's at joining.

• Send packet to clients requesting an ID
• ????? Clients might send back different IDs??

Client should use server ID anyway and client don't need send something back

• Or you wan't to have another giant hardcoded table somewhere that has free IDs in it?

MTA server uses table for valid objects we need update and use it. Anyway we need model manager at server to save some specific config for new models( vehicle friendly names, seats count, handling, some args for objects ).

remove some ID's

I tested all free id's, we don't need remove something.

something the scripts would break

Can you provide any potential scenario? And yes, you want break it now.

[Disinterpreter]

I think allocateModelAt and freeModelAt looks legit for https://github.com/multitheftauto/amx because SAMP had non-default objects, I guess we would make analogs and merging them IDs