getPlayerID & getPlayerFromID

[fresholia]

Script writing can be made easier by giving players automatic IDs starting from one.

getPlayerID(Element player) -- return a ID from player
getPlayerFromID(int ID) -- return a player element

and maybe we can use it like this (it can break most backward scripts)

for playerID, player in pairs(getElementsByType("player")) do
--code content
end

[CrosRoad95]

mta already have getElementID, but this function is weird - does not return real id, even "id" sounds like something unique and in numeric type it not a case for this function, mta. i'm not talking about how insanely slow it is. I prefer focus on improvment of already existing getElementID and getElementByID to return real globally unique id ( maybe new function and depretece old one?? )

[fresholia]

Is getElementID giving IDs sequentially?

[CrosRoad95]

no, by default returns empty string until you set some id

[PlatinMTA]

mta already have getElementID, but this function is weird - does not return real id, even "id" sounds like something unique and in numeric type it not a case for this function, mta. i'm not talking about how insanely slow it is. I prefer focus on improvment of already existing getElementID and getElementByID to return real globally unique id ( maybe new function and depretece old one?? )

I think he is thinking of something like SAMP. You can already do this via scripting and it isn't that hard to implement. If you won't be able to manipulate the player ID then I would go against this, otherwise, if it's faster than lua (which will probably be) then it would be a nice addition.

[fresholia]

faster than lua

[Disinterpreter]

mta already have getElementID, but this function is weird - does not return real id, even "id" sounds like something unique and in numeric type it not a case for this function, mta. i'm not talking about how insanely slow it is. I prefer focus on improvment of already existing getElementID and getElementByID to return real globally unique id ( maybe new function and depretece old one?? )

I think he is thinking of something like SAMP. You can already do this via scripting and it isn't that hard to implement. If you won't be able to manipulate the player ID then I would go against this, otherwise, if it's faster than lua (which will probably be) then it would be a nice addition.

https://github.com/multitheftauto/mtasa-resources/discussions/291 I think better to make a resource.

[sbx320]

This seems rather pointless. Why can't you just store the elements themselves? It won't get any faster if you need two C++ function calls either.

mta already have getElementID, but this function is weird - does not return real id, even "id" sounds like something unique and in numeric type it not a case for this function, mta. i'm not talking about how insanely slow it is. I prefer focus on improvment of already existing getElementID and getElementByID to return real globally unique id ( maybe new function and depretece old one?? )

Those ids are more commonly used to reference objects from separately loaded maps.

[jey-banned]

It's actually a pretty good idea but we should go further. I suggest assigning unique identifiers to each newly created element so we can use getElementID as planned. Example:

local obj = Object ( ... )
print ( obj.type ) -- object
print ( obj.id ) -- 123456

local p = Ped ( ... )
print ( p.type ) -- ped
print ( p.id ) -- 123456

We can create ID range to each element type ( GTA & MTA limitations included ) and map it to element's reference. This might have a good impact on data structuring

[Allerek]

It's actually a pretty good idea but we should go further. I suggest assigning unique identifiers to each newly created element so we can use getElementID as planned. Example:

local obj = Object ( ... )
print ( obj.type ) -- object
print ( obj.id ) -- 123456

local p = Ped ( ... )
print ( p.type ) -- ped
print ( p.id ) -- 123456

We can create ID range to each element type ( GTA & MTA limitations included ) and map it to element's reference. This might have a good impact on data structuring

I think we should avoid GTA & MTA limitations by giving sperate ID pool for each element type, whole problem about ID's in GTA series is that we're limited because some further ID's might be taken by other object type which can cause issues, so every element type should have its own ID pool so it would be a lot more clear-looking.

[Pirulax]

We could assign a unique numeric ID to each element. (With the help of a simple counter) But I'm not sure how backwards compatible our change would be. I wouldn't be surprised if people checked if an ID was set by simple comparing the returned value to an empty string. (Eg.: getID() == "")

[Allerek]

We could assign a unique numeric ID to each element. (With the help of a simple counter) But I'm not sure how backwards compatible our change would be. I wouldn't be surprised if people checked if an ID was set by simple comparing the returned value to an empty string. (Eg.: getID() == "")

We can avoid that by giving other name to the function like: getElementIDFromPool (?) where getElementID would stay the same as now, it could be useful for some guys still (for whatever reason)

[ArranTuna]

There is no way this makes script writing easier.