Bugzilla – Bug 3749
Two functions to retrieve a function name given its id
Last modified: 2013-06-19 08:19:29 PDT
I would like to propose two functions parallels to funcidx() and get_func_id(): (to retrieve a function name given his id).
Why?
I wanted them for the particular purpose of creating two plugins. One's purpose would be to provide a menu to create menus stored with sql. So the user creating one would select to which function a menu entry would link. Like to creating a menu called Games where entry Tetris would point to plugin tetris.amxx function menuTetris(id). So a user could have a list of functions from each plugin. Other's purpose would be to call functions from the console. So it would make me able to store all the functions names in a data structure so i would know the valid functions to call from the beginning. But, to make the second one, that function wouldn't be enough because i want it also to be able to call natives (writting "is_user_bot(1)" in the console as an example), so i'm working on making a module for it.
(In reply to comment #2) > So a user could have a list of functions from each plugin This is not really the right idea, plugins should register handlers that get called when you trigger some event. This is much better than poking randomly at a plugin's function list. Anyway, you don't need the request in comment #0 to do this. > Other's purpose would be to call functions from the console Ideas like this have been proposed before. It's too difficult and probably not worth implementing. There is no type information associated with functions or natives. There is no way to verify that a function is receiving the right input types or even the right amount of input. This is problematic because you could call this function: > f(str[], len) With something completely invalid, like: > f() This would probably crash at best. Another example is variadic functions, or functions with by-reference input. Describing these on the console is verbose and ultimately a waste of time. And it's not optional. You must get the calling signature correct. > so i'm working on making a module for it A module can only see natives that exist inside a plugin. If a native isn't used anywhere the module has no access to it (unless I'm forgetting something in the annals of the module API). But there's an additional problem: A module isn't a plugin. The module can't call any natives without a plugin to do it from. You need some sort of "shell" plugin that can be used as a scratch area for the module. ... The moral of this story? I would abandon this idea. It's been proposed before and the hurdles are too great. If you're trying to make it easy to get access to certain functions, just hardcode them. If you're trying to make some sort of debugger, it needs to be part of the Core. If you're trying to get scriptability from the console, you need to invoke a compiler or something that constructs an AMX structure. If you're doing this to learn about the (backwards and archaic) underpinnings of AMX Mod X, go ahead ;) But you will find it quite difficult for few rewards.
My thought is to provide a command like: call "cs_set_user_money(1,5000)" I thought about this: " This is problematic because you could call this function: > f(str[], len) With something completely invalid, like: > f()" And i was hoping that that kind of use would lead the command to abort but not the plugin to crash. And i would leave that to its user. The way of parsing that i thought was with '' is a string, with only digits is a number. If a & is prepended its value in the end is to be outputted (i already did that part with regular expressions). To pass the data from the plugin to module i thought of tree cellarrays. One would store the type of data: enum ArgType { Cell, CellReturn, MultiCell, MultiCellReturn } Other would store numbers, the last would store strings. Then i would call a native on the module that would receive that 3 cellarray handlers, convert their data to a new (cell *params) and call the associated function. About: "A module can only see natives that exist inside a plugin" I thought that i could trace what happens to amxmodx_Natives[] , and use that information to call the natives. Anyway, i will try to see what i can make since i'm enjoying "messing" with the amxmodx code.
(In reply to comment #4) > but not the plugin to crash Unavoidable ;) > And i would leave that to its user. That's fine, though it requires the user knows the calling convention. > I thought that i could trace what happens to amxmodx_Natives That only contains a portion of the natives, they're actually spread about. The central list might be in *module.* somewhere.
Ok. Really sorry for bothering. Just this last thing: "This is not really the right idea, plugins should register handlers that get called when you trigger some event. ... Anyway, you don't need the request in comment #0 to do this. But to do that ("plugins should register handlers...") wouldn't i had to change every plugin's source? About that part, what i thought was: At plugin_cfg search for every pluginID and for every functionID associated to it and store the data in two celltrie's to access them by a function name (to retrieve the pluginID and the functionID associated). I would assume that the function to be called would be function(ID) and i would call it with callfunc_begin... I already did that functions that i requested in the amxmodx files (it's just copy and paste code) but i didn't know that "you don't need the request in comment #0 to do this." I assumed that to do that it would be used the function amx_GetPublic( so i searched for it in the source but didn't find uses of it to reach that.
So, the question is: how to do that?
> But to do that ("plugins should register handlers...") wouldn't i had to change every plugin's source? Yes. I don't understand how this would work otherwise. It's a really bad idea to poke at plugin internals blindly. I find it hard to believe that most plugins will have an identical, state-generic public function for exactly what yo want. http://www.amxmodx.org/funcwiki.php?search=callfunc&go=search
Ok. Thanks. I understand what you mean.
But, anyway, callfunc wouldn't be enough because i want the user to select the functions, so i have to have their names first.
Of course... what else would you have? Numerical identifiers are internal implementation details. If you're looking for some sort of function iterator, that's a possibility - though I don't personally like the idea at all, because the use cases are bad.
For what i've seen, the "functions that show menus"'s headers are function(id) or function(id, level, cid). So i would assume the second since its ok for the first. But, i understand what you mean. It's ugly, inefficient, unworthy, unnecessary. I told you "callfunc wouldn't be enough because ..." because you told me: "Anyway, you don't need the request in comment #0 to do this." "http://www.amxmodx.org/funcwiki.php?search=callfunc&go=search" Anyway, sorry for take you this time, you certainly have plenty of better things to do.