[Script API] Simple data sender from script tool to scenario

[Yona-TYT]

There is currently no way to communicate with scenarios from a script tool.

0001-ADD-Simple-data-sender-from-script-tool-to-scenario.patch

[prissi]

Please give a reason for inclusion for any patch like an example of usage.

[Yona-TYT]

Please give a reason for inclusion for any patch like an example of usage.

Sorry, I didn't have time to make a good test example yesterday.

An interesting example is to be able to mark rectangles and send the information to be processed from the scenario.

I want to make use of this functionality in an online game. The rules are not going to be applied instantly, they must first be reviewed by the server administrator, therefore the data must be saved until the administrator decides whether to approve the request or not.

I also want to combine this with "https://forum.simutrans.com/index.php/topic,23257.0.html", so that the requests are managed from the chat window, then from there they will be approved or not.

crate_tool_rect.zip

Edit.
This is all a work in progress, for a scenario I'm planning, but I need to work around some limitations that are currently in the API.

Edit.
By the way, I also need a default param for the scripts tools: 
https://forum.simutrans.com/index.php/topic,23274.msg208860/topicseen.html#msg208860

[Yona-TYT]

I have updated the patch and fixed some bugs.
0001-ADD-Simple-data-sender-from-script-tool-to-scenario-.patch

I attach a script and test tools.
First use the script_mark_rect tool and then script_confirm_rect:
script-and-tools.zip

[prissi]

I am no expert on the squirrel implementation, but in the simtool-script.cc, you init the vm and then, ten lines deeper, init it again. Would that not void whatever data was in the first virtual machine? Also, it looks like you called send before init. Furthermore, scenario can be NULL. I see no provisions for that in the patch. Also, is every tool named "my_tool"?

Looking at the squirrel documentation, there is the command sq_move, which can move any object on the stack between virtual machines. That seemed more versatile than just sending strings.

If not using sq_move, maybe it would make more sense to have a dedicated tool for sending strings to players (if scripted) or scenarios, which returns error messages if the destination is unavailable. That would be at least easier for me to debug.

[Yona-TYT]

I am no expert on the squirrel implementation, but in the simtool-script.cc, you init the vm and then, ten lines deeper, init it again. Would that not void whatever data was in the first virtual machine?

I think that is a specific configuration that is activated with the parameter:

Code Select Expand

restart=1 I have not used that parameter in my tests.

Also, it looks like you called send before init.

Before calling sender, it is checked that "init_vm(player)" is true.

Furthermore, scenario can be NULL. I see no provisions for that in the patch.

I have not received errors, even testing in a game without a scenario, I will check that anyway.

Also, is every tool named "my_tool"?

There should be two slots, one for two-click tools and another for one-click, I should check that.

Looking at the squirrel documentation, there is the command sq_move, which can move any object on the stack between virtual machines. That seemed more versatile than just sending strings.

A while ago @dwachs suggested that you could send simple data to communicate between the tools and the scenario, so I thought of doing it this way. But if you think it's better to send the objects that way then maybe I can try it in the future.

If not using sq_move, maybe it would make more sense to have a dedicated tool for sending strings to players (if scripted) or scenarios, which returns error messages if the destination is unavailable. That would be at least easier for me to debug.

I still don't know very well how to create a dedicated tool for simutrans, so it's a bit difficult for me at the moment, I'll think a bit about it.

[prissi]

I think you are good with squirrel and I am good with the rest, so I think we should be come at a good solution together. On the weekend, I may look again at sq_move. Becasue, in principle, then one could be able to communicate also between players and tools.

[Yona-TYT]

Looking at the squirrel documentation, there is the command sq_move, which can move any object on the stack between virtual machines. That seemed more versatile than just sending strings.

I've been experimenting with "sq_move", but I haven't found an alternative mechanism to send data other than compiling text strings using "sq_compilebuffer" and ensuring that the text sent is of type table (this is already done from tool_base.nut).

This is what I have so far.

Code Select Expand

HSQUIRRELVM vm = script->get_vm();
sq_pushroottable(vm); // root
SQInteger max = sq_gettop(tool_vm);
sq_move(vm, tool_vm, max);

plainstring str = script_api::param<plainstring>::get(vm, 2);
return script->eval_string(str);

[prissi]

I see, you want to send the data over the network. Then indeed you have to keep to simple datatypes. sq_move can only work without decoding the stack object, i.e. local on the same computer. Then if Simutrans has to add as a broker, then an internal tool seems the proper way to send messages.

But is it really possible to run custom scripts in a server game? I thought this was forbidden.

[Yona-TYT]

But again, the script tools will not work online. It will crash whenever tried to init the local vm. At least in my tests.

If I recall correctly, the script tools were planned to work online, I guess that's a bug?.

I see, you want to send the data over the network. Then indeed you have to keep to simple datatypes.

maybe that's why @dwachs wanted to do it like that.

[prissi]

I have never bothered much with the skript tools. Ok, I checked, scripts are running but executed extremely slow since any action must be sent to the server.

In case of a scenario, building becomes almost impossible as every tile is queried to the server. As it stands now, this is unusable.

[Yona-TYT]

In case of a scenario, building becomes almost impossible as every tile is queried to the server. As it stands now, this is unusable.

Wow, that's disheartening, I guess it must be very difficult, if not impossible to fix that.

[prissi]

Well, one could leave it with only testing start and end tile for way building.

Or another parameter for is_work_allowed_here, that only tests the rules but not calls the scenario script for the internal tests of tiles for way building.

[Yona-TYT]

I could also save the coordinates in a text label from the script tool, it shouldn't be that slow, should it?

The only drawback is that there is no easy way to lock the text label so it won't be renamed by the player, I tried to make a rule for "TOOL_RENAME", but I hit a dead end with the default param, (I had created a thread, but deleted it (here)).

[prissi]

Looking more closely at the code I found that for any two_click tool, is_tool_allowed and is_work_allowed_here is never sent to the server and only the local rules are checked. Hence, when developing an online scenario, then please be aware that the only way to allow or forbid actions is via the rules. Hence, there are no local scripts executed. Each player would need a script tool to execute to contact the server.

Under these circumstances, I am not sure that your idea can work at all.

Please give the whole setting you are thinking about, what the local player shoudl have and what the server should have. What the local scripts should achieve and so on.

[Yona-TYT]

Please give the whole setting you are thinking about, what the local player shoudl have and what the server should have. What the local scripts should achieve and so on.

I made some modifications to the previous tool, its use is basically the same.

Load the scenario, use the script_mark_rect and later use script_confirm_rect.


scenario-and-tools.zip

[prissi]

Please, for what purpose you want to select the rect?

And how should it work in a real game? A network user has to download a tool? I am still very confused what you want to achieve.

[Yona-TYT]

Please, for what purpose you want to select the rect?

And how should it work in a real game? A network user has to download a tool? I am still very confused what you want to achieve.

Players must download the script tools, the idea is to share them.

It is not yet complete, but the idea is that this tool will mark an area within a city, which will only be accessed by a specific player.

I did a test with a local server, but is_work_allowed_here() does not respond to the one-click script tools.

[Yona-TYT]

There also seems to be a bug in the script tools with the popup messages, it seems that the buffer is not cleared correctly, so the previous popup message continues to appear, but without affecting the execution of the tool.

[prissi]

As mentioned before, the scenario is_tool_allowed and is_work_allowed_here are not querying the scenario script over the network, only the rules are checked. It has been deliberately designed that way. Otherwise, the clients would wait a second after every mouseclick or mousemove with most tools.

These functions are only for local scenarios.

About the popup: Maybe this is the same as with your test scripts. THe test script (under test/... ) finish after an error, but your script seem to restart and restart, and one has to minimise the error window two or three times.

[Yona-TYT]

the scenario is_tool_allowed and is_work_allowed_here are not querying the scenario script over the network,

Some tools do this, for example I can check for a click when using "tool_remover", but I can't use it to confirm things.

I would like to use the new "pipette" tool for this, but that is also ignored by is_tool_allowed and is_work_allowed_here :( .

[prissi]

At the beginning of a scenario is the check for network. In case of network, only the rules are used but the scenario is not queired.

And all tools are queried, but obviously the list of tools needs an update.