r11463 - macro building tool

[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.