couldn't you just implicit convert functions to refs using ref and deref

couldn't you just implicit convert functions to refs using ref and deref

i think i couldn't understand well what you mean
but if you mean why those are table
its because it doesn't cause confusion when passing a function as an argument in triggerEvent and other functions and you can check in other resources that where does this function come from

No news about this PR? I can't imagine a cases for what need store functions in elementData, but for exports it very useful. 🤔

This reminds me of #3551

I consider this feature as excessive and the implementation as dangerous.

i need time to refactor this PR

I'm opposed to this. There's no good reason for this to exist, it can be dangerous AND it can cause easy memory leaks.

I think that’s a good idea.
With more complex resources, it would often be useful to send something like a callback instead of having to trigger, for example.

(削除) Is it safe? (削除ここまで)
(削除) Yes and no — it depends on how it’s used. We can’t halt project development because of fear or poor script management by the community. We should, however, provide them with tools to manage such a feature, like sending functions.
It is indeed dangerous in the sense that if a potential cheater finds a trigger that accepts a function as an argument and, worse, executes it without checking, they could run arbitrary code on the server. But does that immediately disqualify this PR? Absolutely not. (削除ここまで)

(削除) It’s ultimately the scripters’ responsibility to secure their server. We can help them, but we can’t do it for them. (削除ここまで)

(削除) Imo, the ability to send functions via a trigger or export should have a toggle in mtaserver.conf - but only for the client-to-server direction.
Meaning: the server can always send functions to the client, but the reverse is only possible if the option is enabled in mtaserver.conf. If disabled, the server ignores the function and shows an appropriate warning as it does now. (削除ここまで)

As for element data, I’m not sure if it has any real use here, but if the server ignores a value that’s a function during synchronization (since a cheater could force this even with the 4th sync argument set to true), then that’s fine.

It is indeed dangerous in the sense that if a potential cheater finds a trigger that accepts a function as an argument and, worse, executes it without checking, they could run arbitrary code on the server.

but only for the client-to-server direction.
Meaning: the server can always send functions to the client, but the reverse is only possible if the option is enabled in mtaserver.conf. If disabled, the server ignores the function and shows an appropriate warning as it does now.

I think you really misunderstand this PR. How would a client send a function's reference to the server or vice versa? That's not how it works. This is to send functions between resources on the same script side with either local events or exports.

It is indeed dangerous in the sense that if a potential cheater finds a trigger that accepts a function as an argument and, worse, executes it without checking, they could run arbitrary code on the server.
but only for the client-to-server direction.
Meaning: the server can always send functions to the client, but the reverse is only possible if the option is enabled in mtaserver.conf. If disabled, the server ignores the function and shows an appropriate warning as it does now.

I think you really misunderstand this PR. How would a client send a function's reference to the server or vice versa? That's not how it works. This is to send functions between resources on the same script side with either local events or exports.

I don’t know why I kept thinking it was about sending a function between sides, something like a string and reading it through loadstring, lol. Maybe it’s just after work and the effect of being sleep-deprived.

But still... I think a properly refined solution is acceptable. Currently, cheaters can execute any code on the client side, so I don’t think sending a function from resource X to resource Y would create any huge threat here. On the client side, nothing is and never will be truly secure. A cheater can do whatever they want, so sending their own function to some resource doesn’t really give them any additional capability to cause harm.

But still... I think a properly refined solution is acceptable. Currently, cheaters can execute any code on the client side, so I don’t think sending a function from resource X to resource Y would create any huge threat here. On the client side, nothing is and never will be truly secure. A cheater can do whatever they want, so sending their own function to some resource doesn’t really give them any additional capability to cause harm.

I don't think megadreams meant the "dangerous" part as in cheaters. More like easy memory leaks, segfaults, etc. But I think if you are careful enough, it can be implemented in a safe way