A tool to execute squirrel script

[THLeaderH]

Thanks to a tremendous work by Dwachs and other contributors, simutrans squirrel api has a lot of useful features.

So why don't we use this scripting api for the definition of tools? This is like MOD systems which are commonly seen in major games, such as Minecraft and Cities:Skylines.

The attached patch is a proof-of-concept implementation. In my implementation, init() and work() interfaces are provided and players can implement their own tool function in those interfaces. The nut file is put in pakXXX/tool/<scripting_tool_name>/tool.nut. For example, in my environment, tool.nut is put under pak128/tool/test_tool/ . The script loading window is called with dialog_tool[34].

One thing which scripting enables us is to build a station which consists of multiple kinds of add-ons with a single click. A demo video is available here. The attached nut file is the script used for this demo.

[Dwachs]

This is a very nice idea.

[prissi]

I like this idea too. I just think you are overly optimistic to assume that every too is network save. It is more the other way round, unless the script is on the server I do not see how it could be network save (but then I did not touch the scripting much at all).

Getting an icon (and even an individual tooltip) is not a priory difficult, I think.

This brings me to the actual implementation. I would prefer if the file name to the script is defined as in the menuconf.dat (default_parameter). That way several scripts could be active (as well as icons to be defined). It might even allow for a forth class beyond dialog_tool ... like Script_tool in menuconf.tab.

[Yona-TYT]

Well something I have always wanted is a special tool for scripts that allows you to select rectangles with multiple tiles (As the climate editing tools do), this can be very useful to do something like delete a specific type of object in that selected area.

It seems to me an excellent idea!.

[Dwachs]

This should be save for network modes. The scripting framework handles this already: calls to tools are send to the server, and the script is suspended as long as the tool is not executed. The script will resume after the tool gets executed and it receives the error message (if there is any).

[THLeaderH]

Thank you for your feedback. I have a problem in the implementation. Is it possible for script_vm_t::call_function() to pass non-primitive values to the script? For example, my implementation passes the coordinate as three integers in work() function, but passing single coord3d object is more reasonable than passing three integers.

[prissi]

OK, while technically save for networking, having a script only for oneself could be like a cheat mode, putting someone at advantage.

But I wonder, there are scripts in the tutorial that block certain calls. If they are blocked locally, what would happen, if another player sends them from his client?

[Dwachs]

Is it possible for script_vm_t::call_function() to pass non-primitive values to the script?

Yes. It should be possible (koord3d and also player_t*). Did you try? For instance, scenario_t::is_work_allowed_here passes koord3d directly.

But I wonder, there are scripts in the tutorial that block certain calls. If they are blocked locally, what would happen, if another player sends them from his client?

There are two types of blocks: one that is purely script based. This only works locally. The second also works for network games, but it is more limited. The forbidden calls are caught in the network code. The scenario class has methods like is_work_allowed_here()  to check some conditions.

[THLeaderH]

Yes. It should be possible (koord3d and also player_t*). Did you try? For instance, scenario_t::is_work_allowed_here passes koord3d directly.

I tried and succeeded. That I hadn't able to do this was due to another bug of my implementation. Thank you.

So the interface work() can be defined as

Code Select Expand


string work (player_x player, coord3d pos)


Although AI and scenario interfaces passes the player argument as a number, I think passing player_x object directly is more reasonable.

[THLeaderH]

I attached the updated patch. Now scripted tools can be called from toolbars. Arguments of the functions are passes as coord3d and player_x objects. The script loading window, which is assigned to dialog_tool[34], is also available.

This version supports the following interface for scripted tools. The meaning of arguments and return values are same as those of tool_t's functions.

• bool init (player_x player)
• bool exit (player_x player)
• string work (player_x player, coord3d pos)
• string check_pos (player_x player, coord3d pos)

The move() function is not supported. This is because move_has_effects() needs to be a const function, but squirrel does not seem to be have such a mechanism. Also, move() is not network safe.
There is a plan to support the functions of two_click_tool_t, such as do_work() and mark_tiles().

Please note that simutrans/script/tool_base.nut must be copied into your simutrans executable directory.

You can write description.tab to define additional parameters for the scripted tools, although it is optional. description.tab is placed at the same directory as tool.nut. In other words, description.tab is placed at pakXXX/tool/<tool name> . The definition in description.tab is as follows.

Code Select Expand


title=tool for test
type=one_click
restart=1
menu=my_tools
icon=test_tool


"title" value is used as the tooltip text in a toolbar. "menu" value represents the group of scripted tools and used in menuconf.tab. For example, when you write menuconf.tab like this,

Code Select Expand


toolbar[4][10]=scripts(my_tools)

toolbar[4][10] shows all scripted tools whose "menu" value is my_tools.

"icon" value defines the name of menu icon. The definition is same as that in menuconf.tab.

"restart" and "type" value is not implemented yet. If "restart" is 1, the script virtual machine is disposed every time the tool is exited. Otherwise, the virtual machine is not disposed and state of the tool is preserved. "type" defines the scripted tools is based on tool_t or two_click_tool_t.

KNOWN BUG: When you call a scripted tool from the toolbar, simutrans often crashes. The following log is the backtrace of the crash.

Code Select Expand


* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x5ae75993)
    frame #0: 0x000000010041418c sim`::sq_gettop(v=0x000000005ae7594b) at sqapi.cc:829:13
   826
   827 SQInteger sq_gettop(HSQUIRRELVM v)
   828 {
-> 829 return (v->_top) - v->_stackbase;
   830 }
   831
   832 void sq_settop(HSQUIRRELVM v, SQInteger newtop)
Target 0: (sim) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x5ae75993)
  * frame #0: 0x000000010041418c sim`::sq_gettop(v=0x000000005ae7594b) at sqapi.cc:829:13
    frame #1: 0x00000001003213aa sim`script_vm_t::intern_prepare_call(this=0x000000010a372020, job=0x00007ffeefbfbbc8, ct=QUEUE, function="init") at script.cc:221:95
    frame #2: 0x00000001003d4956 sim`char const* script_vm_t::call_function<bool, player_t*>(this=0x000000010a372020, ct=QUEUE, function="init", ret=0x00007ffeefbfbc2f, arg1=0x0000000125a62f60) at script.h:124:3
    frame #3: 0x00000001003d47fd sim`tool_exec_script_t::call_function(this=0x000000010121a400, func_name="init", player=0x0000000125a62f60) at simtool.cc:6550:16
    frame #4: 0x00000001003d42ca sim`tool_exec_script_t::init(this=0x000000010121a400, p=0x0000000125a62f60) at simtool.cc:6483:10
    frame #5: 0x00000001003f1161 sim`karte_t::local_set_tool(this=0x0000000124a2b200, tool_in=0x000000010121a400, player=0x0000000125a62f60) at simworld.cc:3046:30
    frame #6: 0x00000001003e88d0 sim`karte_t::set_tool(this=0x0000000124a2b200, tool_in=0x000000010121a400, player=0x0000000125a62f60) at simworld.cc:3031:3
    frame #7: 0x00000001001ec7fb sim`tool_selector_t::infowin_event(this=0x0000000125a63960, ev=0x00007ffeefbfc028) at tool_selector.cc:119:12


[prissi]

This looks very good to me. But I have to admid, that I never worked with the sripting part of simutrans. Could you provide files with a testing tool, please?

Also, I do not understand, where you actually define the name for each tool script. Or do they all need to be in a single file?

And, I think the crashing issue needs fixing before going into trunk. If you have a testing file, I could also help also testing it.

[THLeaderH]

I attached the testing files. The test script just prints very simple messages. I use an image of road as the icon of testing tool.

The name of tool is defined by "title" value in description.tab. If it is not defined, the directory name of tool is used instead.

[Yona-TYT]

This looks great, I will wait for it to be included in the trunk to do the tests, regards !.

[Dwachs]

Thanks! I will look into this crash. Why put the script-manager into bauer/ ?  script/ would be a more natural choice.

[THLeaderH]

This is because classes that have fill_menu() functions gather around bauer/ directory. way_builder_t and hausbauer_t are in bauer/, and script_tool_manager_t also has fill_menu() function.

UPDATE: The crash bug was due to not initializing tool_exec_script_t::script to NULL. Initialization solved the problem.

[THLeaderH]

I attached the updated patch. This version includes the support of "restart" value and cursor image support. Although previous version used menu object for the icon image, this version uses a cursor pak object. image[0] of a cursor object is used as the cursor image, and image[1] is used as the icon image.

The patch contains code preparation for two-click tool , although I have not tested it at all. To enable two-click tool mode, you have to add

Code Select Expand


type=two_click

in description.tab. In two-click mode, following interfaces are available.

int is_valid_pos (player_x player, coord3d pos, coord3d start)
string do_work (player_x player, coord3d start, coord3d end)
void mark_tiles (player_x, player, coord3d start, coord3d end)

I will provide a script tool for testing.

[Yona-TYT]

Is it possible to use the selection mode, as seen in the image?. 

[Dwachs]

mark_tiles has to call some c++ routine to put the markers somewhere and assign an image to them. There is nothing in the script interface to support any marking (besides marking tiles).

Why did you delete these in simskin.cc:

Code Select Expand

static special_obj_tpl<skin_desc_t> const fakultative_objekte ?

@Yona: somthing like this should be possible.

[THLeaderH]

I attached the updated patch. Two click tool was supported and some bugs were solved. I attached the code patch file and testing scripts. pak128.zip contains the testing scripts, and test_cursor.zip contains the cursor pak file.
I write down here how to use this patch.

Directory Structure
A scripted tool consists of two files, tool.nut and description.tab. tool.nut is required and description.tab is optional, although it is highly recommended. They are put at pakXXX/tool/<script_name>/ . Attached pak128.zip has this directory structure, where script_names are test_tool and test_two_click.

Please note that script/tool_base.nut at the simutrans executable directory must be placed to make tools work properly. The code patch contains this file tool.

description.tab
The code below is a sample of description.tab.

Code Select Expand


title=tool for test
type=one_click
restart=1
menu=my_script
icon=one_click_test


• title: The title of this scripted tool. It is used as the tooltip text.
• type: It defines the tool type. one_click means one click tool, and two_click means two click tool. The default is one_click.
• restart: restart=1 means the tool always reloads the script when the tool is exited. If restart=0, the tool vm is not disposed and the state of the tool is preserved until simutrans is terminated.
• menu: The key to call this tool in menuconf.tab. The value does not have to be unique across scripted tool definitions.
• icon: It defines the cursor and icon image. For this example, cursor image is image[0] of cursor.one_click_test.pak, and icon image is image[1] of that pak.

How to call the scripted tools
There are two ways to call scripted tools. The first one is using the script loading window, which is assigned to dialog_tool[34]. When the tool is called with this dialog, the script is always reloaded regardless of "restart" value which is defined in description.tab.

The second way is using toolbars. The toolbar definition in menuconf.tab is required. For example, adding

Code Select Expand


toolbar[4][10]=scripts(my_script)

in menuconf.tab shows all scripted tools whose "menu" value is "my_script" at toolbar[4][10]. Please note that "icon" value needs to be properly set to show the designated icon of the scripted tools.

Script interfaces for scripted tools
When "type" value is one_click, the tool is one click mode and following interfaces are available. The meaning of arguments and return values are same as those of the c++ code.

• bool init (player_x player)
• bool exit (player_x player)
• string work (player_x player, coord3d pos)
• string check_pos (player_x player, coord3d pos)

When "type" value is two_click, the tool is two click mode and following interfaces are available. The meaning of arguments and return values are same as those of the c++ code.

• int is_valid_pos (player_x player, coord3d pos, coord3d start)
• string do_work (player_x player, coord3d start, coord3d end)
• void mark_tiles (player_x, player, coord3d start, coord3d end)

These functions are called when the scripted tool is launched, exited, clicked, and so on. Implementing any of these functions is optional.

Known issues

• is_valid_pos() cannot return error messages. It can only return state number.
• Scripted tools cannot be called when simutrans is in network mode. This problem is to be fixed.

@Dwachs
Deleting fakultative_objekte was my mistake and was restored in the attached patch. skinverwaltung_t::register_desc() was slightly modified to support extra cursor pak objects.

[Dwachs]

Thannk you! It should be possible to make this safe for use in network games.

[Yona-TYT]

I would like to make a tool to mark the places to build stops / stations in a city.

Currently I use Script text links from the scenario window, and put the coordinates "start" and "end" manually.

In addition to marking, it would also be a good idea for all stops to be built with just one click, since having the coordinates is very easy to do.

I attach the script.

[Isaac Eiland-Hall]

I wish it showed the coverage area, but still looks nice and useful. But with wishes, being able to move the planned stops (i.e. adjust them after clicking) seems hand as well.

[Yona-TYT]

I wish it showed the coverage area, but still looks nice and useful. But with wishes, being able to move the planned stops (i.e. adjust them after clicking) seems hand as well

I can do something like a menu of options (improvised), so that the player can choose the name or type of stop he wants to place, and if they can be replaced very easily.

[Yona-TYT]

I created menus improvised earlier in the script for the regions. 



Double message sorry. 

[THLeaderH]

@Dwatchs
I am seeing around the script behavior in network mode. In network mode, the script itself seems to be executed only on server, even if it is called from another client. Is it intended?

Also, when I called command_x.set_slope() function in the network mode, I received "Cannot call this tool from within ~ " error.

In the latest version of my patch, init(), work(), and exit() is properly called in server when I call one-click script tool. However, when I call two-click tool, only is_valid_pos() and do_work() is called in server. mark_tiles() should be called in client but it isn't, and that would be a problem.

[Dwachs]

I will look into this. Thanks for your work!

[Yona-TYT]

This is my idea for a script tool:

- Now I use the coordinates of the city limits as "start" and "end" automatically just by selecting a town hall.
- Now you can select the stop for your construction automatically.
What do you think ?. 

I attach the script for the curious hehehe. 
Edit.I forgot, it should also work on any pakset. 

[THLeaderH]

I made a fix and attached the patch. I fixed the call type of script functions. work() and do_work() should be script_vm_t::QUEUE and the rest of tool interfaces are script_vm_t::FORCE.

And I noticed the following phenomena.

• The result of print() function is not shown on the console when simutrans is in network mode and is not a server.
• When I write multiple command_x instructions in a single work() function and simutrans is in network mode, only the first command_x instruction is executed and the rest are suspended, but they are not called anymore.

[Dwachs]

I started working on the patch (the one against r9080).

In the current implementation, the script is not executed on the client but on the server, because is_work_network_safe returns false. Changing this to true would not help too much. There is infrastructure missing to wakeup the script after the command gots executed (for AI players this is done automatically since they have step() called frequently).

Also setting work to QUEUE and other functions to FORCE might not work: The queued script waits for response from server. The forced function might overtake the suspended call, which could lead to strange misbehavior.

Edit: I will move the scripted tools to their own files. Editing simtools.h is a pain, because half of the project is recompiled after a change to this file.
Also the check_pos function is not needed: It is there for regular tools to throw (quickly) an error message to the user before sending it over network and doing more comprehensive checks in work().

Also I would like to get the patch to the state, where the script is only executed on the client (and need only be present there), and only game changing calls are sent over network. (In principle, this works for AI players. They are limited to server because of missing possibility to save and reload their state at clients)

[THLeaderH]

Thank you for working on this. I agree with eliminating check_pos() function and making scripts themselves executed only on the client.

[THLeaderH]

@Dwatchs
Is there any progress in the implementation?

[Dwachs]

Yes, I am working on this. Both kind of tools work with network mode. I wnat to have a function that enables mark_tiles to place real markers.

[Yona-TYT]

Yes, I am working on this. Both kind of tools work with network mode. I wnat to have a function that enables mark_tiles to place real markers.

Very nice  .

[prissi]

THis would be a shame to bot make it into the next release. How is the status of this?

[Yona-TYT]

and why not include the work until now?.

[Dwachs]

Because it is not finished and largely untested?

Here is a current patch. I need to find more time to work on it: tools work over network now. It still needs more testing for two-click tools, of scripted tools loaded by menuconf.tab, there is no sensible way to mark tiles for action in two-click tools.

Home office, home schooling, and video conferences suck out alot of energy to work on free-time projects like this. Please be patient.

[Yona-TYT]

I was thinking, and it occurs to me that it may be an excellent idea to have a "Scenario Tool Windows", so the user would have the possibility to create a tool with options from the graphical interface. 

Edit.
Basically it would be a type of windowed tool, similar to the "Schedule" tool in vehicles / depot.

Something like this improvised interface: 

[Dwachs]

Here is a new version of the patch. It should work with network games.

Unpack the zip file into addons/pak128 . Then add a line

Code Select Expand


dialog_tool[34]=,^D

to menuconf.tab to load tools after pressing control+D. Both tools simply remove stuff. The two-click-tool removes stuff in a rectangle given by two mouse clicks.

[Yona-TYT]

I am very happy to see progress in this. great!. 


Regards!. 

[Isaac Eiland-Hall]

The two-click-tool removes stuff in a rectangle given by two mouse clicks.

Ooh, that's a neat idea!

[THLeaderH]

Thank you for the update! I will look into it in a few days

[THLeaderH]

Today I tested the patch briefly in network games and found a problem. The following script makes three slopes and it works in local games. However, in network games, the only first set_slope(pl, p, 82) function was executed, and the rest of set_slope() functions were not executed.

Code Select Expand


function work(pl, pos)
{
local p = pos
command_x.set_slope(pl, p, 82);
p.y -= 1
command_x.set_slope(pl, p, 4);
p.y -= 1
command_x.set_slope(pl, p, 72);
return null
}


This phenomenon occurs on both a client and the server in network games.

EDIT:
simmenu.cc:L907 should be

Code Select Expand


tstrncpy(buf, c, len+1);

to contain '\0' properly.

Even with this fix, I cannot see the icon of scripted tools at the toolbars designated in menuconf.tab. It seems that icon is properly loaded to the scripted tools, and the menubars are properly filled with the scripted tools. I have not made it clear why the icon of scripted tools are invisible.

[Dwachs]

Thanks for testing! Here is an updated patch.

I could not reproduce your report with network games: It may take some time until the script is properly executed, because each work command is send to server, resend to client, then executed. In the meantime the script is stopped, and it will resume after the work command was executed on the client.

The other problem is fixed. There were multiple problems (menu_arg not properly returned, images initialized in init() instead of constructor, paths were wrong to load addon tools at startup).

[THLeaderH]

I confirmed that the latter problem was fixed. Thank you for the bug fixing!

I found that even print() function output cannot be seen in network games. These phenomena may be only for my environment, so I want to know how it is in others' environment.

[Dwachs]

print messages are only shown if started with '-debug 2' or higher.

[THLeaderH]

I'm looking forward to the date when the Dwatch's patch is incorporated and I can start writing a scripting tool 

[Ranran on indefinite leave]

I'm looking forward to the date when the Dwatch's patch is incorporated and I can start writing a scripting tool

In the meantime, you can make a clarification on the non-working or unfinished code you left on extended.
Their work remains stalled by you not doing it. Because you know the most about it.
when you make a clarification about it we can start processing it.

[freddyhayward]

In the meantime, you can make a clarification on the non-working or unfinished code you left on extended.
Their work remains stalled by you not doing it. Because you know the most about it.
when you make a clarification about it we can start processing it.

the scripting code on extended is currently a nuisance, increases compilation times and causes unexpected errors, and serves no purpose at all. Is our goal to bring it in line with standard? If not, it is best to remove it as soon as possible.

[Dwachs]

This is now submitted in r9187. Sorry for the delay, I definitely needed a break.

[Yona-TYT]

Wow, I'm very happy to see this implemented at last! Greetings! .  :p

[prissi]

Thank you.

[Ranran on indefinite leave]

the scripting code on extended is currently a nuisance, increases compilation times and causes unexpected errors, and serves no purpose at all. Is our goal to bring it in line with standard? If not, it is best to remove it as soon as possible.

I didn't mean that, I just wanted THLeaderH to address the problem he left behind in Extended. e.g. a meaningless button placed by him on the GUI.

[Yona-TYT]

I've been testing and I have two questions:

1 - Is it possible to call a tool from the toolbar menu? In this case I think that for this the creators of pakset should include a new generic icon for the script tools (it would be very nice).

2 - Can you combine a script tool with a scenario script ?, I mean to be able to pass data from the tool to the scenario script, such as the start and end coordinates from "mark_tiles" for example, with this I can solve a problem in the "Split Regions" script to not use toll gates.

[Dwachs]

1) yes, write ``scripts(blub)''. It will put all all scripts with ``menu=blub'' into this toolbar. Cursor images can be specified. See the posts of THLeaderH above.

2) start and end coordinates are sent to the scenario with is_work_allowed etc. I do not understand the problem. Please explain in a new thread.

[THLeaderH]

Thank you very much for the integration and writing the documents

[Yona-TYT]

@Dwachs
It is possible to make tools that need confirmation for the changes to take effect?.
For example, one click to mark objects then another click to confirm that the objects will be deleted.

Would you show us an example of how to do this? .... Greetings! 

[Dwachs]

This is not possible currently. One would need to open a script-defined window for this confirmation...

[Yona-TYT]

This is not possible currently. One would need to open a script-defined window for this confirmation...

I mean to confirm by a second click on the map.

[Dwachs]

Make a two-click tool, that only does something on the second click. But how do you signal to the tool that you do not want it to execute?

[Yona-TYT]

Make a two-click tool, that only does something on the second click. But how do you signal to the tool that you do not want it to execute?

I've already managed to get something, but it doesn't work quite right I'm afraid. 

This tool allows you to delete all stops in a previously selected city. But for some reason, when there are several types of stops, not all of them are removed.

I leave you attached the tool and a savegame.

[Dwachs]

Maybe remove the halt in a loop until it is not there anymore?

[prissi]

Not all stops have buil.get_desc().get_type()==34, older paks and e\xtens etc. will have different type. And if there is a city car, the tool remover will remove the citycar. Is there not a call to remove a entire halt? There is an internal routine for doing this.

[Dwachs]

Not all stops have buil.get_desc().get_type()==34, older paks and e\xtens etc. will have different type.

This should not be the case: those types should be corrected in building-reader.

Yes, might be a good idea to add a routine to remove a stop completely.

[prissi]

A post office will have type 35 while still being a halt, a dock 11, and a flat dock 36. Thus 34 will not catch all halts.

[Yona-TYT]

A post office will have type 35 while still being a halt, a dock 11, and a flat dock 36. Thus 34 will not catch all halts.

Certainly I used this in the tutorial scenario to prevent the player from clicking on a stop of another type even if it is connected to the station to be used. 


Here is a new version:

- Added a loop when removing stops, this ensures that the stop was removed.
- Now it is checked that the stop belongs to the active player when selecting and eliminating.
- Now it is checked that the stop is "wt_road", since this tool only makes sense for buses or mail trucks.

[Yona-TYT]

I am trying to use an icon to make "mark tile", the problem is that there is only "mark_tiles (pl, start, end)" for tools that require drag and drop.

Can you make this work with one-click tools?


As seen in the image, if I use the "two_click" mode I must drag the cursor by at least one tile.

[Dwachs]

I would rather not do this. At the moment, the scripted tools use some auto-cleanup methods do delete those markers, which are not available for one-click tools.

[Andarix]

...

Directory Structure
A scripted tool consists of two files, tool.nut and description.tab. tool.nut is required and description.tab is optional, although it is highly recommended. They are put at pakXXX/tool/<script_name>/ . Attached pak128.zip has this directory structure, where script_names are test_tool and test_two_click.

...

Known issues

• is_valid_pos() cannot return error messages. It can only return state number.
• Scripted tools cannot be called when simutrans is in network mode. This problem is to be fixed.

....

I have transferred the description to the wiki. Please check the accuracy and correct it if necessary.

[Dwachs]

Looks good. There are now cursor-related settings:
https://forum.simutrans.com/index.php/topic,20577.0.html

Tools should work in network mode. If not, please send a bug report.

[Andarix]

I am trying to use an icon to make "mark tile", the problem is that there is only "mark_tiles (pl, start, end)" for tools that require drag and drop.

Can you make this work with one-click tools?


As seen in the image, if I use the "two_click" mode I must drag the cursor by at least one tile.

If a wt_road Halt extensions building has a building, then these are not removed.

And the name and messages should be adapted.

[Andarix]

A lot of information can be processed with the script function.

Unfortunately, their output in the message window is somewhat limited.
On the one hand, no line breaks are possible and the text length is also limited. A separate output window would be better, which also allows the formatting of the help.

Alternatively, line-by-line output directly from the script tool should be enabled.

A direct execution upon selection would still be helpful. At the moment you have to click somewhere on the map.

The attached script shows the profit and total assets of all players in the message window (provided the text is long enough).



A global script tool directory (simutrans/script/tools) would also be nice. Then the scripts did not always have to be copied into each package.

[Yona-TYT]

If a wt_road Halt extensions building has a building, then these are not removed.

And the name and messages should be adapted.

I only thought about eliminating bus stops, not extension buildings.

I have to check those messages.

[Andarix]

Is it possible that the cursor is also displayed in the load script tool dialog?

[Andarix]

tool to check overrowded passenger stops -> output message window

click on halt, then check connected halts

click out of halt, then check all halts on map



I use halt_x::get_waiting(), which returns all waiting goods. I don't know whether it is possible to query the waiting passengers.

That is why stops with overcrowded goods and mail are also listed.

remove attached files
download latest version

[Dwachs]

Is it possible that the cursor is also displayed in the load script tool dialog?

What do you mean? Which cursor do you want to have displayed?

[Andarix]

left via load dialog

right by button in the menu

[Yona-TYT]

Something that I would love is a customizable window that works in conjunction with sccript tools.

My idea is to create lists of objects, coordinates, factories or anything else, Configure each row of the list some button (it can be an action button or a button to go to an X coordinate or a selection button).

As an example of a concept it can be a tool that allows to replace all the bus stops in a city and allow the player to choose the new stop.

It would work as follows: The new window is configured to show a list of available bus stops each row with a unique select button, this will allow the player to choose a bus stop which will be used to replace all stops existing in a city.

[Andarix]

tool to check overrowded passenger stops -> output message window

click on halt, then check connected halts

click out of halt, then check all halts on map



I use halt_x::get_waiting(), which returns all waiting goods. I don't know whether it is possible to query the waiting passengers.

That is why stops with overcrowded goods and mail are also listed.

update

Stations with no passenger volume are no longer listed.

Stations with passengers and overcrowded goods, on the other hand, are still listed, even if the passengers are not overcrowded.

remove atached files
download latest version

[Andarix]

translate tooltip and title

[Andarix]

fixed version from check passenger station overcrowded

download here