r11463 - macro building tool

[Andarix]

...
 It features especially a macro building tool, i.e. you can mark an area and that infrastructure can be then constructed elsewhere (the last tools in the special tools).

...

The tool files are saved even without entering a name. click OK

When you reapply, the building area is not displayed. Since this is not checked, the construction is incomplete.



It is also strange that the subsoil is not adapted for the construction. But the slope corners that were present during the survey are created on level ground.



Debots seem to be ignored.

[prissi]

Usually, it fails with an error message. The building is done with a script. Unfortunately, I knew very little about scripting. I think the script does not remove groundobjects and thus fails. In principle, the slopes of the area are recorded. These is a newer version of the toolkit, but it did not work for me: https://github.com/teamhimeh/hm_toolkit/releases

The idea is for complex things like the Japanese bridges or two-level stations to be transferred.

And also empty savegame names are allowed. So I guess, empty toolnames should be allowed as well.

[Andarix]

According to redme, depots are not included.

[Andarix]

Usually, it fails with an error message. The building is done with a script. Unfortunately, I knew very little about scripting. I think the script does not remove groundobjects and thus fails. In principle, the slopes of the area are recorded. These is a newer version of the toolkit, but it did not work for me: https://github.com/teamhimeh/hm_toolkit/releases
...

The version 1a used does not work correctly either. The taxiway and runway are not connected. The reason for this is that the connection should be made with the runway, which would result in a prohibited branch.


Strangely, command_x.build_way can build over the runway with the taxiway.

Even though the tool was created with v3, it can be used with v1a.



tool.nut

Code Select Expand

include("hm_toolkit_v1a")

function hm_build() {
  hm_way_tl("taxiway",[0,-1,0],[-1,-1,0])
  hm_way_tl("taxiway",[0,-2,0],[-2,-2,0])
  hm_way_tl("taxiway",[-1,0,0],[-1,-3,0])
  hm_way_tl("runway_modern",[0,-4,0],[-2,-4,0])
  hm_way_tl("runway_modern",[-3,-1,0],[-3,-3,0])
  hm_way_tl("taxiway",[-2,-2,0],[-3,-2,0])
  hm_way_tl("taxiway",[-1,-3,0],[-1,-4,0])
  hm_station_tl("PlainAirStop",[-1,0,0])
  hm_station_tl("PlainAirStop",[0,-1,0])
}

If the runway is after the taxiway, then the airport is being built correctly.

[Andarix]

https://github.com/teamhimeh/hm_toolkit/pulls

I have submitted the changes for building depots as a PR.

For testing purposes, simply rename the hm_toolkit_v3.nut to hm_toolkit_v1a.nut.

Depots are built, but not recorded. I think the recording is in the Simutrans code, as this writes the tool.nut.

This is probably where the error is that the wrong way is taken.

The messages still need to be adapted for translation.

[prissi]

Ok I worked on bridges support in r11470. Somehow stations on bridges are not build even though the command is created correctly.

Where did you put the v3 files? In my trials, the hm V3 never worked if there was more than one file.

Also, as soon as there are changes, the more restrictive license (our artistic license) applies ...

[Andarix]

...
Where did you put the v3 files? In my trials, the hm V3 never worked if there was more than one file.

...

extract to simutrans/script

...
Also, as soon as there are changes, the more restrictive license (our artistic license) applies ...

I have created a fork.
https://github.com/Andarix/hm_toolkit

The change so far is an extension.

I also see the changes to the texts for translation as rather uncritical.

However, more changes are needed for the script recorder.

Since only the directly specified objects are currently used, recordings only work if all objects are available.

Script tools themselves do not have any availability data.

There are now two options for this:

a) check all objects for availability before building
b) replace unavailable objects with others


toolkit
https://github.com/teamhimeh/hm_toolkit/blob/main/LICENSE

The base of the file lib_obj_finder_v2.nut comes from here
https://github.com/128na/sugoi-simutrans-squirrel-scripts/tree/master


Another possibility is independent further development.

Ok I worked on bridges support in r11470. Somehow stations on bridges are not build even though the command is created correctly.
 ...

Bridges and tunnels are likely to be very complex and, if used, very expensive, as they require adaptation of the terrain.

[Andarix]

...
Script tools themselves do not have any availability data.

There are now two options for this:

a) check all objects for availability before building
b) replace unavailable objects with others

...

Since only the object name is saved, it is currently not possible to perform a replacement.

The reason is that the available objects can be retrieved from timeline, but not all objects.

[Andarix]

Airport build works correct in 11474


Cursor is not correct working

In the description.tab, icon must appear instead of cursor.

Furthermore, there must be a corresponding cursor pak file called BuilderScript in the pakset.

[Andarix]

r11474

Bridges on flat ground with ramps work.

Bridges between 2 slope tiles do not work.

[Andarix]

Since only the object name is saved, it is currently not possible to perform a replacement.

The reason is that the available objects can be retrieved from timeline, but not all objects.

Alternatively, the construction instructions can be expanded. For ways, expanded to include Waytype and Systemtype.

Waytype would be necessary for almost all objects.
For stations, acceptance is also required in addition to Waytype.

Code Select Expand

  hm_way_tl("taxiway",[3,3,0],[2,3,0],wt_air,st_flat)
  hm_way_tl("taxiway",[3,2,0],[0,2,0],wt_air,st_flat)
  hm_way_tl("taxiway",[2,4,0],[2,0,0],wt_air,st_flat)
  hm_way_tl("runway_modern",[3,0,0],[1,0,0],wt_air,st_runway)
  hm_way_tl("runway_modern",[0,3,0],[0,1,0],wt_air,st_runway)


[prissi]

The script would probably rather return numbers than strings for these but adding waytype and systemtype is no problem.

Also, the slope bridge are fixed, both in the squirrel script and the generator.

And since the pakset needs editing for a matching toolbar, it could add at that time also a cursor:

Code Select Expand

Obj=cursor
name=BuilderScript
copyright=none
Image[0]=builder_script_cursor.1.0


[Andarix]

script_toolkit_r1

It is now possible to specify the way type for ways, bridges and signals.

For ways, the system type is also specified.

Ways are only replaced if the way type and system type are specified.

[Andarix]

...
Also, the slope bridge are fixed, both in the squirrel script and the generator.
...

r11479

As long as the slopes are saved with bridges, they do not work properly.

The bridge is not built between the slopes.

A trench is created on level ground in which the bridge is then built.


The ground should be checked during construction.

[Andarix]

script_toolkit_r1

It is now possible to specify the way type for ways, bridges and signals.

For ways, the system type is also specified.

Ways are only replaced if the way type and system type are specified.

I had to recreate the release because the first one contained a bug.

added wayobjects



The attached tool creates a bridge between 2 slopes with 3 fields of distance. Although it is created with pak64.german, it should also work in other paksets using the linked toolkit files.

[Andarix]

Script Toolkit v2

Add new syntax (waytype) for sign, station and depot.

Todo:
- sign add sign type
- stations add enables freight, mail and pax


The attached tool builds a small airport. The selection area must currently be flat.

[Andarix]

If the following line was inserted into the description.tab, the tools could also be inserted into the toolbar.

Code Select Expand

menu=BUILDER_SCRIPT
menuconf.tab

Code Select Expand

toolbar[x][x]=scripts(BUILDER_SCRIPT)
Of course, this requires a cursor file with a button.

There is a problem with this. The tools from the user folder are not read when starting if the program is started without add-ons. This currently means that the dialog reads and displays the tools, but the icons do not appear in the toolbar.

However, if it is loaded with add-ons, the tools from the user folder also appear in the toolbar.

For me, however, it only works correctly if icon=BuilderScript is in the description.tab.

[Yona-TYT]

Five messages in a row, how great!. You are doing a good job here. 

[Andarix]

Everything in one post would have been very long.

Simutrans r11480 has it built in.

thanks prissi

[Yona-TYT]

I was wondering if with this mechanism there is a possibility of copying an entire city, that would be great!.

[prissi]

Since these tools are to be generated by a normal user and maybe use 1-3 times per map, I do not think the toolbar integration is the most urgent thing.

About the slopes: Maybe skip adding slopes of empty (nature) tiles and tiles with objects that cannot be removed.

Adding waytype and system type has been done.

Copying public infrastruture and cities could be done and was on my mind. Maybe doing it only as public player.

[Andarix]

https://dwachs.github.io/simutrans-sqapi-doc/index.html

The file description.tab
This is a plain text file with the following entries:
title=Name of tool to be shown in tool selection dialog
type=one_click or two_click
tooltip=Tooltip for the icon in the toolbar
restart=Set to 1 if the virtual machine has to be restarted after each call to the work functions.
menu=Parameter that can be used to load tools with menuconf.tab
icon=Name of cursor object (loaded from some pak-file), used images: 0 = cursor, 1 = icon, 2 = marker image

[prissi]

If nothing is there, the first cursor in skinverwaltung_t:: is matching the empty string. Hence it was working even with the wrong entry. Corrected in r11503.

Moreover, these tools cannot load a pak file, and can only use already loaded files. Hence, it must be a name of an existing cursor. If the images are empty, then no icon and no marker is defined: No problem for the makro tools.

[Yona-TYT]

I get this error message when trying to copy a city.

tool.zip 

[Andarix]

hm_city_tl and also hm_city_set_population_tl are missing in the script toolkit

[Andarix]

The construction of city buildings of any kind is currently not supported by the Squirrel API.

[Andarix]

The question arises whether the title and tooltip should be translated.

That would mean that the translated text would be written into the description.tab.

[prissi]

How could there a translated text for such a tool? Moreover, why the need for a tooltip for an automated tool the player has generated himself?

City buildings can be constructed already. Player owned city buildings will be copied.

r11522 recreates cities (minus the pavement)

[Andarix]

How could there a translated text for such a tool? Moreover, why the need for a tooltip for an automated tool the player has generated himself?

....

In principle, you don't need the tooltip at all. It is only used if there is a button in the menu.

[Yona-TYT]

City buildings can be constructed already. Player owned city buildings will be copied.

This works well for me.

(minus the pavement)

pavement?, I don't understand this.

[prissi]

Cityroads have usually a sidewalk. That is currently not transferred.

[Andarix]

Cityroads have usually a sidewalk. That is currently not transferred.

.../src/simutrans/script/api/api_const.cc line 98

Code Select Expand

  /// build city road with pavement
  enum_slot(vm, "tool_build_cityroad", TOOL_BUILD_CITYROAD | GENERAL_TOOL);

City streets have their own tool and should therefore work.

[prissi]

I know but those recreate the current street, not the original one. But maybe an option.

[Yona-TYT]

The script tools are generating debug files in their respective directories, is this intentional?.

[Andarix]

simutrans r11533

I have added the new function hm_test_area_tl().

This can be used to check whether the tiles are free to build before construction.

hm_test_area_tl([start tile],[end tile])

Code Select Expand

hm_test_area_tl([x,y,z],[x,y,z])
For single tile [start tile] = [end tile].

[Andarix]

The script tools are generating debug files in their respective directories, is this intentional?.

The script AI and script scenarios in the simutrans main directory also does this.

Was probably set up in the API by Dwachs for troubleshooting. But there is nothing else in the logs by windows.

[prissi]

I think a tile is essentally free if it has a way or a building (i.e. ground type fundament) and cannot be removed. This is the is_natur test. Thus, a hm_clear_area_tl is probably needed after the test. Or unite these two funtions?

[Andarix]

I think a tile is essentally free if it has a way or a building (i.e. ground type fundament) and cannot be removed. This is the is_natur test. Thus, a hm_clear_area_tl is probably needed after the test. Or unite these two funtions?

With hm_test_area_tl you can check all the fields to be built on before the first construction.

This avoids a field that is not free causing unnecessary construction actions and thus expenses during construction. Changing the terrain in particular can quickly cause high costs.

It is certainly possible to extend the function to permitted objects (existing roads or rails)

Currently, there is no testing for water.

If this function is extended to the ground, unnecessary changes to the terrain could probably also be avoided if the terrain is unsuitable overall. A rough cost check would then probably also be possible.

You don't have to use everything in the macro tools.

But the integration makes it possible to create script tools by hand. And when you pass them on and use them with other users, it's not necessarily known which fields of the cursor area are being used.

For example, I have in mind a station tool that builds multi-track stations like TTD. This would also require checking existing tracks. It would be very interesting with the two-track station hall in pak64.german.

The difficult part will be displaying the costs for changing objects. The problem is that script tools do not have availability data (intro, retire). I have no idea how the Squirrel API would have to be changed to do this and Dwachs is no longer active.

[Yona-TYT]

The difficult part will be displaying the costs for changing objects. The problem is that script tools do not have availability data (intro, retire). I have no idea how the Squirrel API would have to be changed to do this and Dwachs is no longer active.

Do you mean time_x? http://dwachs.github.io/simutrans-sqapi-doc/classobj__desc__time__x.html

[Andarix]

Do you mean time_x? http://dwachs.github.io/simutrans-sqapi-doc/classobj__desc__time__x.html

This refers to the objects.

I mean the script tool itself. So it is not displayed in the dialog or as a button outside of a defined period of time.

For this, the description.tab and its evaluation would have to be expanded.

That was the problem with hm_toolkit. It defined the objects by name. If the object was not available, the build failed.

That's why I added object replacement for the macro tools.

[Yona-TYT]

I understand, so an additional parameter is needed for the tab file, it doesn't seem that difficult to do.

Edit.
Two, one for intro and one for retire

[Andarix]

I understand, so an additional parameter is needed for the tab file, it doesn't seem that difficult to do.

Edit.
Two, one for intro and one for retire

There are still more open issues. Unfortunately some of them are in German, as Dwachs also accepted German. This avoided misunderstandings through translation.

https://github.com/Dwachs/simutrans-scenarios/issues

[prissi]

One could certainly add a creation year/month to the script an warn of it too early.

[Andarix]

...
I mean the script tool itself. So it is not displayed in the dialog or as a button outside of a defined period of time.
...

I think deactivating it would be better than hiding it.

One could certainly add a creation year/month to the script an warn of it too early.

That would be possible.

However, it is disadvantageous in that script tools are not automatically deselected. And as far as I know, there is nothing in the code to do that.

[Yona-TYT]

However, it is disadvantageous in that script tools are not automatically deselected. And as far as I know, there is nothing in the code to do that.

Yes, there is something like that, although it is not a script function.

If you look at the tutorial, if you advance to a new chapter and the selected tool is no longer available in the other chapter, then you automatically switch to the inspection tool (the loupe).

I propose to make this a function for the script tools, it would be very useful.

[Andarix]

simutrans r11533

I have added the new function hm_test_area_tl().

This can be used to check whether the tiles are free to build before construction.

hm_test_area_tl([start tile],[end tile])

Code Select Expand

hm_test_area_tl([x,y,z],[x,y,z])
For single tile [start tile] = [end tile].

r11538

Add optinal terraform flag.

Code Select Expand

hm_test_area_tl([x,y,z],[x,y,z],[terraform])
[terraform] = 0 -> terraform not allowed
[terraform} = 1 -> terraform allowed (not check ground)

If terraform = 0 then it is checked whether all tiles have a flat surface with the same z.


Attached is a tool that builds a small airport on an area of 4x5 tiles. It should work with r11538 in all paksets where script tools can be called and there is airport construction.

[Yona-TYT]

Was probably set up in the API by Dwachs for troubleshooting. But there is nothing else in the logs by windows.

I don't know, this started to happen after the macros were implemented.

If I run with debug 2 it shows "squirrel_types_ai.awk" ¿¿??.

[ceeac]

In simtool-script-generator.cc, functions write_city_at and write_slope_at are unused.

[prissi]

Currently.