[API Script] The rules do not work correctly with several tools

[Yona-TYT]

With this list the rules should apply to each tool but this is not happening:

Code Select Expand

too_list <- [
tool_remove_wayobj,
tool_build_way,
tool_remove_way,
tool_remover,
tool_make_stop_public,
tool_build_station,
tool_build_bridge,
tool_build_depot
]

For some reason "tool_remover" is the only one in the list that accepts the rules.

See my test script: test-tool_rect_bug.zip

[prissi]

In "is_work_allowed_here()" in line 51, you return "Action Not Allowed"; Hence the action is blocked as it should be. If this function returns null, the road is built.

[Yona-TYT]

In "is_work_allowed_here()" in line 51, you return "Action Not Allowed"; Hence the action is blocked as it should be. If this function returns null, the road is built.

Yes, but keep in mind that in start() several allow_way_tool_rect rules are being filled that should apply to the entire map, but are only fulfilled for tool_remover.

Edit:
The same goes for forbidden rules:

Code Select Expand

too_list <- [
                tool_remove_wayobj,
                tool_build_way,
                tool_remove_way,
                tool_remover,
                tool_make_stop_public,
                tool_build_station,
                tool_build_bridge,
                tool_build_depot,
           
            ]

function forbid_tools_map()
{
    for(local j=0; j<too_list.len(); j++) {
        rules.forbid_way_tool_rect(player_all, too_list[j], wt_all, "", coord(0, 0), coord(map_siz.x, map_siz.y), "Action Not Allowed")       
    }
}
This should have a rule to forbid each tool, but it seems to only be creating one, specifically for tool_remover.


This other example, since it is a rule to forbid, the return in "is_work_allowed_here()" is null, but the expected result should be that the tool_build_way tool is prohibited.
test-tool_rect_bug2.zip

[prissi]

The script is only asked after all rules have been applied and not already denied the tool use before. Hence, if there is an allow rule but the script forbids it, then it is forbidden.

So if I return null in line 63 and add local pl = player_x(0) in line 109, your test script completes.

[Yona-TYT]

So if I return null in line 63 and add local pl = player_x(0) in line 109, your test script completes.

Ok I understand that with "allow_way_tool_rect" that is the correct behavior.

But I am referring to something strange that is happening that affects both rules (allow_way_tool_rect and forbid_way_tool_rect) when the rules are integerated with a list of tools.

For example these rules are not being applied:

Code Select Expand

too_list <- [
                tool_remove_wayobj,
                tool_build_way,
                tool_remove_way,
                tool_remover,
            ]

function forbid_tools_map()
{
    for(local j=0; j<too_list.len(); j++) {
        rules.forbid_way_tool_rect(player_all, too_list[j], wt_all, "", coord(0, 0), coord(map_siz.x, map_siz.y), "Action Not Allowed")       
    }
}

But the strange thing is that if you remove the "tool_remover" tool then it works fine:

Code Select Expand

too_list <- [
                tool_remove_wayobj,
                tool_build_way,
                tool_remove_way,
            ]

function forbid_tools_map()
{
    for(local j=0; j<too_list.len(); j++) {
        rules.forbid_way_tool_rect(player_all, too_list[j], wt_all, "", coord(0, 0), coord(map_siz.x, map_siz.y), "Action Not Allowed")       
    }
}

This one will give an error (tool_remove is in its list): test_rect_tool_remover.zip
This one should work fine (I have removed tool_remove from the list): test_rect_without_tool_remover.zip 

[Yona-TYT]

The script is only asked after all rules have been applied and not already denied the tool use before. Hence, if there is an allow rule but the script forbids it, then it is forbidden.

So if I return null in line 63 and add local pl = player_x(0) in line 109, your test script completes.

I would honestly prefer the allow rule to be prepended to "is_work_allowed_here()" so if the rule is correct it will return a NULL.

[prissi]

Sorry, what is your request? That if a rule is allowed, do not ask the script?

[Yona-TYT]

Sorry, what is your request? That if a rule is allowed, do not ask the script?

Yes, so I can restrict the whole map with the script (using is_work_allowed_here() for example), but bypassing the allow rules.

But if you don't think it's convenient then that's fine 😉.

Edit.

But I am referring to something strange that is happening that affects both rules (allow_way_tool_rect and forbid_way_tool_rect) when the rules are integerated with a list of tools.

Could you not replicate the bug?.

[prissi]

You can restrict the whole map with a cube rule. That is exactly what they are meant for. It is also faster than asking the script. Because when searching a way, every tile is asked of this is ok. This would be very slow with a script.

[Yona-TYT]

You can restrict the whole map with a cube rule. That is exactly what they are meant for. It is also faster than asking the script. Because when searching a way, every tile is asked of this is ok. This would be very slow with a script.

Yes, that's what I was thinking of doing. 

[Yona-TYT]

It works fine now, even my test scripts work as expected.

By the way, it would be nice to add this to automated tests.

[prissi]

The rules are tested in the automated tests. That is why I update them many times. You can submit better test rules. The menu bar is not tested for instance in the tests. Honestly, scripting is not my strong point.

[Yona-TYT]

For some reason the tool_remove_way and tool_remove_wayobj icons do not disappear with rules.

Code Select Expand

local wt_tool = [
tool_build_way,
tool_build_bridge,
tool_build_tunnel,
tool_build_roadsign,
tool_build_wayobj,
tool_remove_way,
tool_remove_wayobj,
tool_build_station,
tool_build_bridge,
tool_build_depot,
tool_build_transformer,
4129, //id tool_remove_wayobj
4113 //id tool_remove_way
]
local tool = [ tool_remover,
tool_raise_land,
tool_lower_land,
tool_setslope,
tool_restoreslope,
4103, //Show Reservation
tool_remove_way
]

foreach(t in tool){
rules.forbid_tool(pl, t)
}
foreach(t in wt_tool){
foreach(wt in all_waytypes){
rules.forbid_way_tool(pl, t, wt, "")
}
}

[Yona-TYT]

I made a small automated test for you, this one checks the menus better than the previous one.

I tested with r11400 and it passes the test there (I only tested the menus).

test-tool_menu_way.zip

[prissi]

The first script hides. The second does not in r11455

Btw. the wayremove and wayobj remove tools have a default parameter, which is the waytype.

[Yona-TYT]

The first script hides. The second does not in r11455

Btw. the wayremove and wayobj remove tools have a default parameter, which is the waytype.

See here (L198).,           

Code Select Expand

if (f.parameter_hash != 0)It should not also be: f.parameter_hash != forbidden_t::EMPTY_HASH ?
Edit.

The first script hides. The second does not in r11455

I actually made a mistake with the script and I just now realized it.

[Yona-TYT]

Now the ground/climate editing tools don't disappear.


I have modified the above script in the hope that it will work fine this time, this time it will check all the previous tests, including the count of menus without waytypes.

test-tool_menu_all.zip


I've taken the r11400 as a reference again, the counter test works fine there.

In the case of the last night it shows a total of 61, but it should be 59.

[prissi]

It seems to work in r11458. Getting the wildcards finally to work as intended.

[Yona-TYT]

It seems to work in r11458. Getting the wildcards finally to work as intended.

That's great, I'm so glad the script finally works. 

[prissi]

It still complains on a different entry of menu entries, but that is probably because I use a different version of pak64 ...