r11892 (Sqirrel Script) - bridge build

[Andarix]

I consider all this code unnecessary. It's perfectly sufficient to simply align the two bridge ends with the click positions.

I believe the current behavior is a bug. When I drag the bridge with the mouse, the coordinate doesn't jump to the mouse pointer (field 3) but back to field 1 (the river) one level higher.

This seems suspicious to me.

If I click on the level field as a second click, then position 104,158,-1 is displayed, which is correct.

However, if I click on the slope field 103,158,-1, then position 105,158,0 is displayed. This is the field with the river one level higher. And that doesn't match the clicked field.

[prissi]

A bug in simutrans? The coordinates for the mouse pointer should be the same as the ones in the lower right corner as these are the only ones the code uses. (When dragging a bridge there is a temporary bridge ground existing though.)

[Andarix]

If I move the mouse from the other side, the field above the river is returned for the slope field.


is_work_allowed_here()

The function description includes a note. It's possible that this behavior is what's meant by that note.

...
Attention
Does not work with waybuilding and all tools that need path-finding, use the functions provided in rules in this case.
...

It's possible that the function `is_valid_pos()` can be used. However, I don't yet know how to use it.

[prissi]

During pathfinding, is_work_allowd_here() is called for all tiles of the path. So of course also for the bottom of the river and all tiles in between. (And for way building even more tiles.)

Excatly for this reason there is forbid_way_tool_rect()/allow_way_tool_rect() ...

[Andarix]

...

Excatly for this reason there is forbid_way_tool_rect()/allow_way_tool_rect() ...

The only question is how that's supposed to work.

I tested it with various combinations.

Either it's not built at all, or the short bridge is built as well.

[EDIT]

I've found a solution. The code still needs improvement.
https://github.com/simutrans/tutorial_multipak/commit/458a8fd1ed5ac85069df6cb8fcee51a90f9d962e

[Yona-TYT]

I think we could use rules in other places, like in the tunnel construction in Chapter 3, but I don't have a computer right now, so I'll do it later.

[Andarix]

There are further problems.

Although an allowed area is defined, construction can still occur outside of it.

If I restrict the tool to bridges, the adjacent track is no longer built.

[Yona-TYT]

I wanted to implement something to help simplify this, using the preview (the template before building the bridge or ways), but these are types of objects that don't actually reside within the map, and I still don't understand how to use them to create a useful API script function.

The mechanism would work as follows:

- Always allow the cursor and the preview to be drawn without restrictions on the map.

- When the click is released, the restrictions are activated, and the size (number of tiles covered by the preview) is obtained from the cursor to determine if the size of the bridge to be built matches the diameter we need.

In theory, it should be possible to implement something like this, but I still don't fully understand it. I'll investigate further when I get my new PC.

[Andarix]

There are already plenty of things available. The problem is, their use isn't very clear.

For example, what's the difference between `xxx_way_tool_cube()` and `xxx_way_tool_rect()`? And, more importantly, how do you use these functions?
Simutrans-Squirrel-API

The cube has a z-coordinate. But which corner (NW or SE) must be at the top and bottom at z?

The rect has no z-coordinate. Does this apply to the map floor, even if it has multiple layers? Or does it only apply to a single layer? Which layer is that?

If the former applies, what is the point of the cube?

[ceeac]

The cube has a z-coordinate. But which corner (NW or SE) must be at the top and bottom at z?

The NW corner should have the bottom coordinate, but I believe it is also possible to swap the z values.

The rect has no z-coordinate. Does this apply to the map floor, even if it has multiple layers?

No, allow/forbid_way_tool_rect applies to all height layers (from -127 to +128).

The tools can also be stacked, so one can just forbid all building on the map using forbid_way_tool_rect and then selectively enable some areas using allow_way_tool_cube. Look at test_scenario_rules_allow_forbid_tool_stacked_rect etc. in test_scenario.nut.

[prissi]

The mechanism would work as follows:

- Always allow the cursor and the preview to be drawn without restrictions on the map.

- When the click is released, the restrictions are activated, and the size (number of tiles covered by the preview) is obtained from the cursor to determine if the size of the bridge to be built matches the diameter we need.

This is not a good idea and would not work. Allow/forbid is asked before sending the tool out and ONLY VERY LITTLE ACTION shoudl be done in the allow checking script. Especially all map altering actions, which the adding of rules is one.

[Andarix]

I'm giving up for now.

It seems impossible to block off the fields between the bridge ends and still build the bridge.

The short bridge will be built. After its demolition, the track behind it will remain. A bridge cannot be built there afterward.

The code is purely test code.