Time  Nick       Message
00:00 rubenwardy I don't know, as long as I've been a core developer at least
00:01 rubenwardy there was an object:get_*_id() method
00:03 sfan5      hm
00:04 sfan5      well here's my suggestion: if its position is static, consider get_objects_in_radius
00:04 sfan5      otherwise keep the objectref around and use undocumented ways to test if it's still valid
00:04 sfan5      this works if you need to keep track until its unloaded
00:04 rubenwardy gmmm
00:05 rubenwardy from user: "I am trying to get an arrow to pass through multiple objects and punch each of them once. Problem is, it is punching them multiple times and treating esch punch as a different object, therefore not passing through as many as I want. So I need a good way to check if I have already punched that object and skip it if I have."
00:05 sfan5      if you need to know even if the same object is un- and reloaded add some identifying property to the luaentity and do a for _, ent in pairs(core.luaentities) do and find the right one
00:05 rubenwardy iterating over all lua entities is kinda terrible
00:05 sfan5      no better than get_objects_in_radius :^)
00:06 rubenwardy get_objects_in_radius is at least valid in API terms
00:06 sfan5      minetest.luaentities is also documented
00:06 rubenwardy we can fix the implementation in a future release, and get performance improvements without changes to mods
00:06 sfan5      which surprised me, it's an implemention detail you'd usually keep hidden
00:07 rubenwardy yeah
00:07 sfan5      well ok
00:07 CBugDCoder For my usecase I don't need to worry about unloading objects, and the objects I am trying to keep track of will not be static.
00:07 rubenwardy oh look
00:07 rubenwardy in which case, storing the objectrefs and comparing by reference is probably fine
00:08 CBugDCoder ok thanks :D
00:08 rubenwardy also - I'm not sure if there ever was such a deprecated method, I can't find it anywhere
00:08 sfan5      objectrefs do not implement a comparison operation but since only one ref exists per object that'll still work
00:09 rubenwardy I guess that could be seen as undefined behaviour
00:10 sfan5      why
00:10 rubenwardy objectrefs being comparible isn't documented
00:10 sfan5      no of course not but you can always compare userdata objects in lua
00:10 rubenwardy also, issue: #5012
00:10 ShadowBot  https://github.com/minetest/minetest/issues/5012 -- Modding API: Make Active Object ID directly accessible from ObjectRef
00:11 rubenwardy yeah, userdate comparison is defined but it's undefined as to whether it will be the same userdata always for an object
00:11 sfan5      it's an implementation detail sure
00:12 sfan5      but there currently only ever is a single ref for a single object
00:12 sfan5      anyway I don't think the id should be exposed, instead objects should have an uuid that stays the same even when its un- or reloaded
00:12 rubenwardy wait, are IDs variable between loads?
00:13 sfan5      yes?
00:13 sfan5      whichever object gets loaded first gets id 0 (or 1?) and so on
00:14 sfan5      it's really just for the engine to internally keep track, so exposing it anywhere is not a good idea
00:14 rubenwardy yeah, an id should be globally unique between runs
00:15 rubenwardy *an id exposed to lua
00:15 sfan5      agreed
00:15 CBugDCoder sfan5, They are already exposed via the minetest.luaentities and minetest.objectrefs tables
00:16 sfan5      sure
00:16 rubenwardy anyway, basically - it'll work for the foreseable future, and any future reimplementation is likely to implement an __equals operator anyway, so == on objectrefs is pretty safe
00:16 sfan5      but that stuff is barely documented
00:16 sfan5      someone could implement an __equals right now for extra safety
00:25 rubenwardy wait a second
00:25 rubenwardy * `get_entity_name()` (**Deprecated**: Will be removed in a future version)
00:25 rubenwardy I was thinking about this method
00:27 sfan5      I don't get why that is deprecated
00:27 sfan5      sure you can replace with :get_luaentity().name
00:27 sfan5      but why??
00:29 rubenwardy :get_luaentity().name also isn't good
00:29 rubenwardy object:get_entity_name() is much cleaner than accessing a special key on a table
00:30 rubenwardy also, have fun debugging when a modder does    `self.name = "My Mob's Name"`
00:31 Lone_Wolf  Hmmm, what are we talking about rn?
00:31 Lone_Wolf  I personally prefer object:get_entity_name()
00:31 rubenwardy entity and object stuff
00:31 Lone_Wolf  self.name feels wrong every time I use it