I’m looking for something that does not involve a while true do wait() ... end loop nor any explicit function calls when the object needs to be gced
My usage for this is telling the client to gc its own version of the server sided table or “object” when the that of the server is gced
(aka prevent memory leaks)
Well I believe the metamethod is restricted on Roblox due to security issues.
Typically I would try to avoid relying on GC for custom replication patterns. Instead I would try to explicitly code that myself. In other words, the server should be responsible for explicitly cleaning up data and informing the client to do the same. That will give you more control over everything.
i don’t like that for my scenario because im replicating tables with references to other tables (nested tables) (for a general solution to replication) and tables will be tagged as needing to replicate either if they are explicitly defined or if they are a descendant of a table that was explicitly tagged
so __gc would be ULTRA clean in this scenario, but I could keep track of extra connections and whether or not this was explicitly defined and decrement/increment num connections whenever a root table is supposed to be destroyed… but even calling a function for each root table would be a hassle, not to mention the messiness of this implementation
root = explicitly defined
Unfortunately due to the fact you can completely bypass the Lua sandbox using __gc (thus why it was disabled, used to be a thing), this most likely won’t happen without some underlying changes and even then …
You’re going to have to find another solution tackle this problem.
Are you sure you aren’t overcomplicating this?
ya’
In other words, when the server does something that makes part of your game’s state redundant, what you should really do is send that signal yourself. You know when the server does what, so you should be able to pull that off. There’s no need for a roundabout hacky mechanism like this.
A fancy way of going about it would be to store your client side state in a table with weak keys. I’d then use any value that Roblox replicates as the key. Note that for this to work the only references to the replicated value should be in the client side weak table, and once somewhere on the server. When the server reference is deleted, then it will propagate to the client side, eventually in the client’s time being collected.
That being said, I really like @buildthomas’s reply. When a client needs some information from the server it should get rid of it asap if it can become invalid. If it needs to be there for a period of time, then the server should send updates when needed. Sending updates is easy and clean, not to mention a much better practice.