Assigned to Tóth András (tothxa) ( @cb/tothxa )

Mirrored from Codeberg
On Sun Oct 19 12:38:38 CEST 2025, Tóth András (tothxa) wrote:

I reused the original water animation frames, but reordered them to give the back and forth look.
The reordering algorithm was first take frames 0 to 32 in steps of 2, then from 31 to 1 in steps of -2. This also smooths the direction changes a bit.

If accepted, I'd consider swapping the 2 for all climates to match the intended uses better: unwalkable water for large water bodies with standing waves, and bridgeable water with flowing look for rivers.

Mirrored from Codeberg
On Sun Oct 19 14:29:40 CEST 2025, Tóth András (tothxa) wrote:

I forgot the glitch that waterways should not be allowed to connect to flags in the middle of bridgeable water.

Mirrored from Codeberg
On Mon Oct 20 00:55:03 CEST 2025, Benedikt Straub (Nordfriese) wrote:

While the idea seems interesting in principle, I'm not sold on whether this is not too much a stretch on realism. Especially if walkers are allowed to walk on nodes not directly connected by an actual bridge.

Several tribes' ships are pretty large and appear to require a certain amount of water under their keel, so I question whether the depth of the water required for the ships to safely pass doesn't altogether exceed the depth of what workers can comfortably (or at least safely) walk in. A quick search claimed that 1.5 to 3 meters is a reasonable estimate for a medieval tradeship's flotation depth.

For context, in my homeland Northern Frisia it used to be very common for people to drown while trying to walk or ride from one island to another, which is possible under good conditions across tideways that are also sailable. (These days, they are usually rescued by helicopter, and this happens quite frequently actually, but unfortunately help does not always arrive in time.) So in my personal experience the idea of walking on foot across terrain where small ships can also sail is connoted as extremely unsafe unless you have an experienced local guide and fair weather and an accurate tide calendar and set out at just the right time of day; and even then, the definition of "walkable" includes fording hip-deep tideways (while watching out for any ships that might cross your path); and naturally walking through deep water is very slow, even when you avoid getting stuck entirely in the invisible mudholes.

So, while I accept that a small ferry can share a coastal area with workers, I am not convinced that workers can walk where full-size ships can sail. What depth would you say the water has, and what the ships would at least require?
And even though the weather in Widelands is 24/7 perfect sunshine, I worry a little about the safety of the workers, and I find it hard to believe they would be able to walk there without a major slowdown.

If the walkability is restricted to bridges only, this does not really simplify things, since the point remains that each bridge segment is just one edge long with the nodes as connector points, where the workers still have to ford a channel of deep water. And how can the broad ships fit through these extremely narrow straights between two directly adjacent bridge segments?

Widelands is not always highly realistic, but to me this sounds like a too-major suspension of disbelief. However, I think this feature would be a superb addition for map design, and I am quite open to being convinced that this is not as unrealistic as it at first impression appears to me :)

P.S. Screenshot from a quick test:

Mirrored from Codeberg
On Mon Oct 20 01:53:43 CEST 2025, Tóth András (tothxa) wrote:

Well, I take it as you want me to do it the other way:

The last one though requires a completely new terrain type, and probably deeper changes to the road creation and pathfinding code. My idea would be what I wrote in the forum: bridgeable terrain would allow building roads, but would only get MOVECAPS_WALK where roads are already built.

That's fine. Although I have to throw out most of what I've written so far, but that's not a problem as writing it helped me understand a lot about these parts, that will help implementing the new terrain type.

The only thing I'm afraid of is that it very likely needs extra code in the AI...

Mirrored from Codeberg
On Thu Nov 06 17:32:29 CET 2025, Tóth András (tothxa) wrote:

I was able to reproduce the bug with the carrier not being able to occupy the bridge, but it's not always repeatable, so there's some special condition that triggers it. When I just replicated your setup with the flag in the middle of the water, my carrier got there without a problem and the stonecutter was able to reach the other side despite the missing last segment. (so your stonecutter's problem was very likely the same) However, later when I built a shortcut parallel to an existing bridge, it got stuck, but when I removed and rebuilt it at the exact same place, it worked.

That waterways cannot connect to the middle of bridges is by design because it doesn't make sense to me. But I'm not strongly attached to that decision if it's voted down, and it actually required extra code to prevent. I guess there's a real-world example for something similar though: A pier extending into the water with the ferry stop at the end. So yes, you could then create a map with some water body that's wider than the ferry range, and with some bridgeable water to narrow it down to the ferry range... but that's a rather special case and most players wouldn't recognise it, so I'd consider it a dirty trick...

Mirrored from Codeberg
On Thu Nov 06 17:38:34 CET 2025, Tóth András (tothxa) wrote:

Sorry, forgot about the lost carrier in the middle of water: Indeed, that's a bug I didn't think about, and it's probably quite tricky to solve properly... the easiest solution seems to be a new leave_bridge worker task that would allow him to walk on water to the nearest flag or shore... (well, even easier is to just let the poor guy drown (remove him from the game like we do with wares at removed flags), but that would be cruel, wouldn't it? :)

Mirrored from Codeberg
On Thu Nov 06 18:45:02 CET 2025, frankystone wrote:

I am still not convinced that this pr provides a good approach to solve "bridgeable rivers". In theory one can just connect Europe with Amerika with bridges, e.g by accidentally (or on purpose) using the wrong water terrain 😄

A river is two, three, max. four nodes wide, in widelands terms, imho. It shouldn't be possible to span more than this with a bridge, or several bridges, imho.

I would prefer something like a "big bridge" which spans those two or three nodes. The visual glitch with ships crossing will still remain, though. But i am not a c++ developer and unfamiliar with the road mechanics. So i can't judge how difficult it will be to implement something like that.

Mirrored from Codeberg
On Sun Nov 09 16:15:12 CET 2025, Tóth András (tothxa) wrote:

I tested the lost carrier issue, and it's like the unable to occupy issue: normally it just works (I actually didn't expect it), but sometimes he gets stuck. It'll be real fun to debug both... :/

I've found an inconsistency with waterways: it is possible to start from a flag in the middle of water, just not to finish at such a node. I'll have to fix that. (or just allow waterways to connect to bridges or not allow flags on bridgeable water at all)

Re width of bridgeable water: I think we can leave it to the map designers to use it responsibly. After all it's already possible to create bad maps with the existing terrain types.

Mirrored from Codeberg
On Fri Nov 14 19:45:54 CET 2025, Tóth András (tothxa) wrote:

I decided to not allow flags after all. There are much fewer problem cases, so the code is much simpler. And I made nice graphics too that I get to use this way... 😄

The bugs should be fixed. I hope there are no regressions...

Mirrored from Codeberg
On Fri Nov 14 22:23:58 CET 2025, Tóth András (tothxa) wrote:

BTW, here are the sources for the graphics. (the terrain type icon is its own source, I did it by hand, pixel by pixel)

Mirrored from Codeberg
On Fri Nov 14 22:43:34 CET 2025, Tóth András (tothxa) wrote:

And some screenshots:

Mirrored from Codeberg
On Mon Nov 17 16:39:42 CET 2025, frankystone wrote:

Two remarks:

1. is it possible to have new graphics for those bridges? The carriers get whet legs:
2. don't know if this is related to this changes: If i attack a port with a warship the game slows down drastically. FPS is ok, but the game runs at 0.1 speed. The attached save game is a continuation of a save game of my first test, if related. Try to attack the port with 6 soldiers …

Mirrored from Codeberg
On Wed Nov 19 20:40:27 CET 2025, Tóth András (tothxa) wrote:

We have working 3D models of the bridges, so I can try making them longer/bigger. There's one possible problem though: the apparent height of bridge segments along their length is hardcoded in the worker movement code, so it may not look right with the bigger bridges. The other option is to add some more flat padding at the ends (or update the code too).

I was able to reproduce the slowdown with your save. Then I tried in a new game without bridgeable water, and there I couldn't reproduce it, neither with master, nor with this branch. I'll investigate it.

Other than this the current state is much better imho :)

Thank you! :)

Mirrored from Codeberg
On Tue Dec 16 22:34:14 CET 2025, Tóth András (tothxa) wrote:

I've investigated the slowdown. It happens with master too. (you can test with the above attached savegame by creating a new normal water terrain with the name summer_bridgeable_water)

It is caused by the enemy sentries on the other side of the river, which are close in direct map distance, but are too far in walking distance:

1. The naval invasion soldier task looks for attackable buildings in a large radius to find anything that could have a military influence on the portspace. This takes a relatively long time and it's done by each soldier individually.
2. The building with the lowest straight-line map distance is picked for attacking. (In this case it's actually quite far in real walking distance.)
3. The soldier tries to walk to the building (in task attack), but it fails because of the long walking distance. Trying to calculate the route takes a long time again (and is done by each soldier too), and it ends up a complete waste.
4. The attack task is cancelled, and the naval invasion task is restarted with step 1. above.

IOW in about every 3rd clock tick most invasion soldiers spend a lot of time doing expensive calculations that normally should only be done once.

The time of route calculations is about the same with master and this branch, though it doesn't mean much because only one bridgeable node is present in the affected area.