It is actually possible to iterate though minetest.luaentities and compare the objectRefs directly so step 1 is not strictly necessary, however, this would be a very useful feature.

I don't know if comparing the ObjectRefs directly will work. Lua can only compare pointers, and if both are different, they will not match.

Lua can only compare pointers, and if both are different, they will not match.

You may well be right there, I don't know enough about the inner workings to comment but code like this has worked seemingly reliably for me in the past.

local function get_object_id(object)
	for id, entity in pairs(minetest.luaentities) do
		if entity.object == object then
			return id
		end
	end
end

OK, when experience proved it...
Still not good.

Still not good.

I totally agree, this is a much needed feature for more advanced uses of SAOs that needs to be implemented in a proper way.

few people mentioned it on IRC in the past:

http://irc.minetest.ru/minetest/2015-06-09#i_4283750
http://irc.minetest.ru/minetest/2015-10-23#i_4429635
http://irc.minetest.ru/minetest/2016-06-20#i_4635356
http://irc.minetest.ru/minetest/2016-11-08#i_4739365

I second this request. I'm taking a stab at using Lua entities for ambient sounds, and it would really help to have access to the active object IDs so that I could track when they are loaded and unloaded in the environment, similar to the implementation that orwell96 is suggesting above.

This should be an extremely easy change to the API since server active objects already have a getId( ) method in the parent class. Something like this in l_object.cpp perhaps?

// get_id(self)
int ObjectRef::l_get_id(lua_State *L)
{
        NO_MAP_LOCK_REQUIRED;
        ObjectRef *ref = checkobject(L, 1);
        ServerActiveObject *co = getluaobject(ref);
        if (co == NULL) return 0;
        // Do it
        lua_pushinteger(L, co->getId());
        return 1;
}

Is the object ID allocated when the object is loaded? If so, there's the possibility of IDs being reused which could cause obscure bugs

@rubenwardy little chance to be re-used as it's incremented on each entity and it's a u64
exposing get_id sounds reasonable

Old issue, is this supported by any core devs? I assume yes from the comments but please add the label if you do.

Relevant IRC discussion from yesterday:

http://irc.minetest.net/minetest-dev/2020-02-29

I support this and I think sfan5 does too

I want to check if certain entities are still loaded from a globalstep, by storing their ActiveObjectID in a table and looking if the ObjectRef still resides in minetest.object_refs
little chance to be re-used as it's incremented on each entity and it's a u64

aren't object IDs u16? they currently do get re-used; object_ids are not unique over time, only at any given moment. it's possible that the id points to a different object when you do a check.

or has this become a proposal to increase the size of the id? i notice the title of the issue has changed, though the reasoning for that might have been on IRC...

BTW, a reliable method to check if a stored ObjectRef is still loaded/associated to an SAO is to call object:getyaw(). If it returns nil, it is not.

this works currently, but i thought this was discouraged?

#11050 btw