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.

[victor_18993]

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.

Andarix, did you try it after the API update and the new features revealed?

[Andarix]

I haven't looked at the tutorial scenario for quite some time.

[victor_18993]

I haven't looked at the tutorial scenario for quite some time.

OK, I'll check if this is resolved with the existing features or if I need to expose any additional ones in the API.

Thank you very much.

[prissi]

I think the scenario could do with consistent reformatting and some renaming too. Maybe this could a good place to use the AI tools.

[Andarix]

I think the scenario could do with consistent reformatting and some renaming too. Maybe this could a good place to use the AI tools.

Unfortunately, every developer tends to have their own style.

And when it comes to scripting in particular, there are no established coding standards.

That is why it would likely make more sense to first define a coding style and mandate it for Simutrans.

For instance, while shorthand notations are great for experts, beginners often struggle with them.

Documentation and commenting are also rather sparse. I have taken some initial steps to address this, though doing so retroactively can be difficult and time-consuming.
https://doc.simutrans-germany.com

Unfortunately, it is easy to lose track of things in this code because there is a lot of duplication and similar code. That is why I wouldn't set an AI loose on it. Also, the constant testing required after making changes or optimizations takes up a lot of time.

And since there is so little feedback, I find myself wondering how much sense it makes to invest a lot of time here. My most recent work involved modifying the routing to make it more flexible (using `astar.nut`). Unfortunately, I am having trouble disabling Yonna's code in a way that still allows the tutorial to function.

...tutorial_multipak/tree/test_chg_railbuild

[prissi]

For C++ there are formatting tools. Not sure there is one for squirrel, AI may help there to get at least identation right. Ok, I was wrong, there is one for squirrel: https://github.com/Bobbyperson/sqformat

The C++ problem is that MSVC reformats everything it touches, which is super annoying as I cannot set it to what I want. But we are getting more and more offtopic ...

[Yona-TYT]

Unfortunately, it is easy to lose track of things in this code because there is a lot of duplication and similar code. That is why I wouldn't set an AI loose on it. Also, the constant testing required after making changes or optimizations takes up a lot of time.

And since there is so little feedback, I find myself wondering how much sense it makes to invest a lot of time here. My most recent work involved modifying the routing to make it more flexible (using `astar.nut`). Unfortunately, I am having trouble disabling Yonna's code in a way that still allows the tutorial to function.

...tutorial_multipak/tree/test_chg_railbuild

The truth is, I don't really understand astar.nut, but implementing common functions in the tutorial should be the right approach. Any bugs in the tutorial should be easy to fix, or so I think.

I'm a bit rusty when it comes to scripting, I'm afraid.

[victor_18993]

I think the scenario could do with consistent reformatting and some renaming too. Maybe this could a good place to use the AI tools.

I've launched several AI agents to inventory the tutorial and look for possible fixes. As soon as the investigation is finished, I'll let you know the tutorial's current status.

[victor_18993]

I checked this against the current trunk (r12243), and the good news is that no new Script API function is needed.

Code Select Expand

command_x.build_bridge(player, start, end, bridge)
can already build the exact bridge between two known endpoints.

The important detail is that scenario permissions are checked at different heights:

• the two bridge ends are checked at ground level
• the bridge span is checked at deck level

That is why one large

Code Select Expand

allow_way_tool_cube()
can accidentally allow shorter bridges inside the same area.

The solution is to split the permissions:

• allow the two endpoints separately
• allow the interior span only at the bridge deck height

With that setup, the intended bridge builds correctly and shorter unwanted spans are rejected.

I also found two separate engine issues while testing:

• scenario permission can be skipped if the endpoint already has a compatible way
• Code Select Expand
  build_bridge() can lose the scenario rejection message

Neither of those blocks this use case, so the original bridge problem can be solved with the current API.