[Script API] Get current tool in class tool_x

[Yona-TYT]

[Script API] Get current tool in class tool_x

This patch fixes all (or most) of the limitations I have in the tutorial:  ADD-class-tool_x-and-get-current-tool.patch.

This gives me the possibility to "get system type", "is ctrl pressed", "is drag tool" among other interesting functions.

Code Select Expand

tool = debug.get_tool()
tool.get_id()
tool.is_ctrl()
tool.is_shift()
tool.get_waytype()
tool.get_system_type()
tool.is_drag()
tool.get_start_pos()
I've tested it and everything seems to work fine, please consider implementing this.


Changing the subject a bit, about "is_work_allowed_here(pl, tool_id, pos)", I think that the "tool_id" parameter should be replaced instead by a class tool_id that includes all the functions of this patch. Even though this breaks script compatibility old, the benefit of this is greater in my humble opinion.

[Dwachs]

Changing the subject a bit, about "is_work_allowed_here(pl, tool_id, pos)", I think that the "tool_id" parameter should be replaced instead by a class tool_id that includes all the functions of this patch. Even though this breaks script compatibility old, the benefit of this is greater in my humble opinion.

If the goal of patch is to work around missing information to is_work_allowed_here calls, then it might be better to modify is_work_allowed_here to give more information. Compatibility issues can be taken care of.

Or are you more interested in calls after the tool did the work. I.e., user clicked, and this object was build there etc. So that the tutorial can react to results of the players actions.

I do not want to implement a patch that queries the current tool's state. When the script uses the information might be already invalid.

[Yona-TYT]

I would actually prefer to call from "is_work_allowed_here", but in that case we would have to replace the "tool_id" parameter and instead create a class tool_x to pass all the tool information.

[Yona-TYT]

If the goal of patch is to work around missing information to is_work_allowed_here calls, then it might be better to modify is_work_allowed_here to give more information. Compatibility issues can be taken care of.

I was doing some experiments to try to send a parameter in "is_work_allowed_here", but it's a bit difficult.

To start with, "tool_t" is already assigned to the "command_x" class, also when I send the parameter and try to access it to process the functions then simutrans fails/breaks.

I was able to get around the bug simply by accessing a class called "tool_x" and processing the functions just like in the previous patch, but I don't think this is the right way to go, as I would be accessing the tool with something like this:

Code Select Expand

tool_t* dynamic_cast<tool_t*>(welt->get_tool(welt->get_active_player_nr()));
The ideal would be to access the tool sent by the parameter:

Code Select Expand

tool_t* tool = param<tool_t*>::get(vm, 1);
But all my attempts made simutrans fail.


I really need to implement this in the tutorial, as it will help me solve several problems at once.
but I don't quite understand how the class process works in the API, nor why it fails if I try to access "tool_t" when the parameter is sent... therefore I'm stuck I'm afraid. :(

[Dwachs]

I thought about this problem as well. It is not as easy as it sounds. is_work_allowed is called at different places in the code. And for some calls there is no proper tool available at the scope of the call (i.e. the drag events for build-tunnel tools).

[Yona-TYT]

I did a little experiment sending a fake class to create the class "tool_x" and then passing it as a parameter in "is_work_allowed_here", everything seems to work fine: 0001-ADD-class-tool_x-to-is_work_allowed_here-as-a-parame.patch