When the cursor is moved over a slope (like the one in the image) the function (event) "is_work_allowed_here(pl, tool_id, pos)" is triggered without clicking.
The routine that computes the possible end point of a potential tunnel is calling is_work_allowed_here all the time.
Is that a problem here?
Quote from: Dwachs on October 20, 2022, 06:23:07 AMThe routine that computes the possible end point of a potential tunnel is calling is_work_allowed_here all the time.
I thought this was a bug.
Quote from: Dwachs on October 20, 2022, 06:23:07 AMIs that a problem here?
I just have to make some specific changes to compensate for this. :P
Quote from: Dwachs on October 20, 2022, 06:23:07 AMThe routine that computes the possible end point of a potential tunnel is calling is_work_allowed_here all the time.
Unfortunately these checks are giving me problems with other tools. :-[
Is there a way to identify them so they don't interfere?.
It would be great if the tool indicates when it's a real build action and a simple check on the map.
Differentiating between these two actions with drag tools (two clicks) would be very helpful.
Couldn't you simply ignore the calls for the tunnel tool?
What kind of problem do you want to solve with the `is_work_allowed_here` function? Maybe it can be solved in a more simple way.
Quote from: Dwachs on November 16, 2022, 01:54:44 PMCouldn't you simply ignore the calls for the tunnel tool?
This affects all build/remove way tools.
Quote from: Dwachs on November 16, 2022, 01:54:44 PMWhat kind of problem do you want to solve with the `is_work_allowed_here` function? Maybe it can be solved in a more simple way.
For example, in some cases the cursor (the hint that appears when you hold down the mouse button and drag the mouse) gets stuck on underground constructions.
I can't determine with certainty if a track was removed because the tool triggers "is_work_allowed_here function()" but it doesn't give me certainty that the remove action has been performed. Just moving the cursor over the track does this to trigger "is_work_allowed_here function()", but without removing anything because the click was not released.
I also cannot determine with certainty how many times a tool is clicked.
In conclusion, I think that differentiating between "a click to trigger tool" and a "check tool" could be very useful and would help me simplify things in the script. ;)
I do not know, what is happening in the video, I cannot reproduce it.
Quote from: Dwachs on November 16, 2022, 05:57:32 PMI do not know, what is happening in the video, I cannot reproduce it.
Here is a test script:script_test.zip
Still, I do not understand, what is the error here. What would you expect to happen? and what happens instead?
Quote from: Dwachs on November 16, 2022, 06:42:56 PMStill, I do not understand, what is the error here. What would you expect to happen? and what happens instead?
Captura desde 2022-11-16 14-10-36.png
The preview track should go away when you release the click, but it doesn't when the condition is not met.
This is not a bug (or at least not a big bug), but it would be great to improve this, for example if I had a way to know when the click is released, then I can enforce the condition right then and so the cursor should disappear. ;)
In r10810 these preview images should be removed when moving the cursor into a forbidden region.
Quote from: Dwachs on November 17, 2022, 06:42:57 PMIn r10810 these preview images should be removed when moving the cursor into a forbidden region.
Thanks .
How about we use "two_click_tool_t::is_first_click()" to determine the state of the click?
Quote from: Dwachs on November 17, 2022, 06:42:57 PMIn r10810 these preview images should be removed when moving the cursor into a forbidden region.
There is a problem, "is_work_allowed_here()" gets stuck in a loop after building the tunnel. :o
The bug is dead - long live the bug! :) Will see what I can do.
Quote from: Dwachs on November 18, 2022, 06:29:29 AMThe bug is dead - long live the bug! :) Will see what I can do.
;D
Edit
Yes, it confused me since apparently with underground mode you don't need to click to activate "is_work_allowed_here()".
I'd like to implement this so I can better determine when it's "click and drag" on a tool.
0001-Add-click-second.patch
Quote from: Yona-TYT on November 18, 2022, 07:00:45 PMI'd like to implement this so I can better determine when it's "click and drag" on a tool.
0001-Add-click-second.patch
I've done some testing with this and it's definitely what I'm looking for to better identify the tools in use.
Is there something wrong with the code?. ???
I add this inverter so that the result is consistent, so it will be "true" only at the moment of dragging, which is what I need. :P
bool is_first_click()
{
two_click_tool_t *active_tool = dynamic_cast<two_click_tool_t*>(welt->get_tool(welt->get_active_player_nr()));
return active_tool? !active_tool->is_first_click() : false;
}
I think it would be better to provide this value as an additional parameter to is_tool_allowed. Not sure how to solve this in a backward compatible way.
Quote from: Dwachs on November 20, 2022, 10:26:43 AMI think it would be better to provide this value as an additional parameter to is_tool_allowed. Not sure how to solve this in a backward compatible way.
I guess the name of the parameter should be "is_drag" ;)
Quote from: Dwachs on November 20, 2022, 10:26:43 AMNot sure how to solve this in a backward compatible way.
Well I think some method is needed to determine the number of parameters in the "is_work_allowed_here(pl, tool_id, pos)" function in scenario.nut (is there any way to do this ?), then depending on the result the function will be executed.
We must make a "NULL" value mean that the parameter will be ignored.
if (what_scenario == SCRIPTED) {
static plainstring msg;
const char *err = script->call_function(script_vm_t::FORCE, "is_work_allowed_here", msg, (uint8)(player ? player->get_player_nr() : PLAYER_UNOWNED), tool_id, pos, parameters > 4 ? NULL : is_drag );
return err == NULL ? msg.c_str() : NULL;
}
return NULL;
What is the motivation for distinguishing these calls? Are you really interested in handling all these calls to is_work_allowed_here? Or do you want to achieve something else and listening to the calls to is_work_allowed_here is the only way?
Quote from: Dwachs on November 21, 2022, 07:11:37 AMWhat is the motivation for distinguishing these calls? Are you really interested in handling all these calls to is_work_allowed_here? Or do you want to achieve something else and listening to the calls to is_work_allowed_here is the only way?
It was just something that occurred to me to maintain backwards compatibility but unfortunately it is something that escapes my understanding. :-[
I think it is more feasible to modify one by one the pakset scripts that use "is_work_allowed_here" to include an additional parameter and thus avoid those code tricks.
The only scenarios that use this (if we talk about the ones included in paksets) we only have the ones from pak128 .
This is off topic... but:
It would be great to have a page where you can manage the scenarios again, so we would only have to modify the existing ones there.
https://scenarios.simutrans.com died a long time ago. :-[
This seems to be fixed now, as it was most likely the same bug as in your other post.
Quote from: Dwachs on December 03, 2022, 01:21:02 PMThis seems to be fixed now, as it was most likely the same bug as in your other post.
Well I think that now we can bury this bug hahaha. ;D