Default parameter for script-tools

[Yona-TYT]

I'm planning to create some script tools that will be used in an online game, but there's no way to identify from the scenario which script tool is being used.

For example:

Code Select Expand

function is_work_allowed_here(pl, tool_id, name, pos, tool)
{
local is_rect = false
foreach(key, value in sender){
if(key == "rect"){
is_rect = true
}
}

if(name == "script_confirm" && is_rect){
forbid_tools_range(sender.rect)
sender.rect = null
return "The rules have been applied correctly."
}

return null
}
0001-Add-default-parameter-for-script-tools.patch

[Yona-TYT]

Maybe instead of "name" use the "icon" parameter that already exists?.

[prissi]

Actually, does this matter? The actions of the tool would be still forbidden or allowed based on the rules, or not? Only script tools, that do not affect the game state could not be stopped.

[Yona-TYT]

Actually, does this matter? The actions of the tool would be still forbidden or allowed based on the rules, or not? Only script tools, that do not affect the game state could not be stopped.

In fact, this is not to be used with the rules, it is to be used in the function is_work_allowed_here, where it is very useful.

[prissi]

Why? If a certain tool is forbidden, why you need to forbid a certain script?

Also, what is the meaning of "if player==NULL returns default_param that was used to create the tool" Any tool has its unique default_parameter inhereted from class tool_t, which should not be changed later.

I am sorry, but I still did not understand what you want achieve here.

[Yona-TYT]

Why? If a certain tool is forbidden, why you need to forbid a certain script?

You see, when there is more than one script tool there is no method that allows us to differentiate one from the other, the default parameter seems perfect to me to know specifically which tool is doing the clicking.

Also, what is the meaning of "if player==NULL returns default_param that was used to create the tool"

Oh no, that was my mistake, please ignore that comment. 

Any tool has its unique default_parameter inhereted from class tool_t, which should not be changed later.

But in the case of script tools it is never getting it, not even when the name parameter is specified to the menu bar icon pak file.

[prissi]

Well, the title can be easily added to the default parameter. But all these entries are translated, i.e. they change with each language.

I have added the folder name as default_parameter in r11448.

[Yona-TYT]

Well, the title can be easily added to the default parameter. But all these entries are translated, i.e. they change with each language.

I have added the folder name as default_parameter in r11448.

Excellent thanks!.

[Yona-TYT]

I have added the folder name as default_parameter in r11448.

Sorry, I hadn't tried this, and it seems that it's not returning the default parameter.

Code Select Expand

function is_work_allowed_here(pl, tool_id, name, pos, tool)
{

    return name
}

Does the tool have a menu for it to work?.

Edit.
It's strange, in some cases it shows the name, others it shows nothing, and in others it shows buffer dirt.

[prissi]

The default parameter was not static and thus the memory could have been overwritten at this point. Fixed in r11460.

[Yona-TYT]

I think there is a similar bug in message options.

[prissi]

Should not happen, but for safety, I initialised that array with zero. I fixed Englsiche and German on the translator, maybe you can fix spanisch. The last three entries are missing, these are the public chat, company char and private messages.

[Andarix]

Should not happen, but for safety, I initialised that array with zero. I fixed Englsiche and German on the translator, maybe you can fix spanisch. The last three entries are missing, these are the public chat, company char and private messages.

mmh, r11467

[prissi]

Yes, stupid error, must be outside the loop. r11469 should fix this.