Topic: Fording a river?

[wlindley]

Would there be any way to create a 'zero-height bridge' for bridleways so cattle and pack horses could ford a river? 

[ACarlotti]

It would presumably be like a road/rail level crossing. I don't know how easy it would be to create a road/river crossing - it just depends on how much of the crossing logic has been hard-coded in the game engine.

[makie]

that is possible

Unfortunately, it is not possible to limit which way or which road may cross which type of river. Thus, a motorway may also take a ford through a deep river.

This lack of precise specification is also a problem at crossing between roads and railways. A highway knows no crossing gates.

[Vladki]

But you can limit the speed of both ways on crossing. Typically it would be road=50, rail=160 for rail crossing, and road=5, water=0 for ford...

[makie]

yes, but as you can see in the screenshot, it is not possible to restrict the crossing to dirt road and small river. The graphics is created for this combination, all other looks funny and illogical     

[jamespetts]

It would be good to have fords, but there is the problem noted by Mackie that one cannot restrict the road types; however, in one sense, it would not make sense to restrict the road types, since a player could simply manually switch over to the lesser road type anyway just for the ford - and one may then wonder why this is not done automatically. There may be an issue with the way constraints on the forded way, however; I have not looked into this, so I cannot remember whether it is possible to impose such constraints on a ford irrespective of the waytype used to draw the ford accross the river.

Fords in Pak128.Britain-Ex are something that I have wanted to do, but the graphics might be a little tricky.

[DrSuperGood]

Each road type would need its own graphics. A motor way could ford a river but it would be in the form of a flat/low bridge over it.

[jamespetts]

Each road type would need its own graphics. A motor way could ford a river but it would be in the form of a flat/low bridge over it.

That would not work economically, as fords do not cost any more than basic road tiles (and there is no code to allow them to cost more). Thus, for economic accuracy, the automatic river/road crossing can only be modelled as a ford, and not as a bridge.

[makie]

My intention is not to forbid the player insert a piece of dirt road into a Highway and cross a great river with a ford.
The problem is: simutrans do this automatically and you have to destroy the ford and rebuild a bridge. And in addition, the result looks graphically bad.
If there is no ford, simutrans stop building a highway at the river. This is what simutrans should do, if there is no fitting crossing.
The same is for high speed railways, there should not allowed any crossing, same for great river and Highways.

[wlindley]

The datfiles for crossings currently use syntax as

Code: [Select]

waytype[0]=road
waytype[1]=track
speed[0]=60
speed[1]=100although I only find those documented in the German dat-file reference.  Apparently, waytype[0] is the superior way when vehicles cross, closing the junior waytype[1] until waytype[0] is clear of approaching vehicles.  (in german: "der zu sichernde Verkehrsweg" is "the secured way".)

For our ford, then, we would like:

Code: [Select]

waytype[0]=road
waytype[1]=water
speed[0]=8
speed[1]=0But according to crossing_writer.cc, a speed[] of zero is disallowed (starting at code line 99).
It might be possible to change crossing_writer.cc so that speed[1]=0 is allowed when waytype[1] is water; and then change the in-game builder to regard a crossing speed of zero (formerly disallowed) to mean, Regard both speed[n] as upper limits of the waytype[n]; if both the existing way and the new way have a speed less or equal, permit building the crossing.   With the dat definition shown above, this would mean you could only lay bridleways across non-navigable streams; attempting to build a highway across a major river would do nothing as currently.
Thoughts?

[Matthew]

It might be possible to change crossing_writer.cc so that speed[1]=0 is allowed when waytype[1] is water; and then change the in-game builder to regard a crossing speed of zero (formerly disallowed) to mean, Regard both speed[n] as upper limits of the waytype[n]; if both the existing way and the new way have a speed less or equal, permit building the crossing.   With the dat definition shown above, this would mean you could only lay bridleways across non-navigable streams; attempting to build a highway across a major river would do nothing as currently.
Thoughts?

I am not qualified to comment on the technical merits of this proposal, but as a player it seems that this would be a nice bonus, so long as it was explained in pakset documentation.

[Vladki]

I like that proposal too. That would nicely prevent players from making crossing on high-speed tracks and motorways, as well as fording navigable rivers.

[wlindley]

This little modification (one bit to makeobj, the other to main program) permits fords to be constructed only when building bridleways over non-navigable streams and brooks.  Any other construction routes around, as before. (Naturally, if there is a dirt-road ford, that would work as well, based on the crossing's maxspeed; this is left to the pakset designer.)

Edit: In testing, this does not prohibit building a canal through an existing ford; the ford, however, will block the canal from being used, and the player will have to remove or replace the ford with a bridge to permit watercraft passage.

Code: [Select]

diff --git a/bauer/wegbauer.cc b/bauer/wegbauer.cc
index 51b234d10..bc9c8fcb3 100644
--- a/bauer/wegbauer.cc
+++ b/bauer/wegbauer.cc
@@ -460,7 +460,17 @@ bool way_builder_t::check_crossing(const koord zv, const grund_t *bd, waytype_t
                return false;
        }
        // crossing available and ribis ok
-       if(crossing_logic_t::get_crossing(wtyp, w->get_waytype(), 0, 0, welt->get_timeline_year_month())!=NULL) {
+       const crossing_desc_t *crd = crossing_logic_t::get_crossing(wtyp, w->get_waytype(), 0, 0, welt->get_timeline_year_month());
+       if(crd!=NULL) {
+               // special case if crd->maxspeed(1) is zero: require maxspeed of
+               // new way to not exceed crd->maxspeed(0).
+               // This permits very low-speed fords of non-navigable streams.
+               if ((crd->get_maxspeed(1)) == 0 &&
+                       ( (crd->get_maxspeed(0) < desc->get_topspeed()) ||
+                         (w->get_desc()->get_topspeed() > 0) )) {
+                       return false;
+               }
+
                ribi_t::ribi w_ribi = w->get_ribi_unmasked();
                // it is our way we want to cross: can we built a crossing here?
                // both ways must be straight and no ends
diff --git a/descriptor/writer/crossing_writer.cc b/descriptor/writer/crossing_writer.cc
index 03e9951d0..11be4c2fd 100644
--- a/descriptor/writer/crossing_writer.cc
+++ b/descriptor/writer/crossing_writer.cc
@@ -103,7 +103,8 @@ void crossing_writer_t::write_obj(FILE* fp, obj_node_t& parent, tabfileobj_t& ob
        }
        node.write_uint16(fp, uv16, 4);
        uv16 = obj.get_int("speed[1]", 0);
-       if(uv16==0) {
+        // Zero speed permissible for water as secondary type
+       if(uv16==0 && wegtyp2 != water_wt) {
                dbg->fatal( "Crossing", "A maxspeed MUST be given for both ways!");
                exit(1);
        }


[wlindley]

A matching bridleway ford datfile and images for Pak128.Britain-Ex  are here

[jamespetts]

W. Lindley - thank you for your work on this. I am concerned that this is a little hackish, however: it depends on the actual underlying speed limit of the river being not more than the speed limit of the crossing road, which seems potentially arbitrary. However, I also note that any other solution would require much more substantial coding.

Do people have any views on the desirability of this implementation of fords as against the desirability of not having possibly anomalous behaviour in any cases where the assumptions about the speed limits of bridleways and/or streams do not hold?

[Vladki]

I would prefer a more generic solution. When crossing is built both ways should be checked for  max speed, and crossing forbidden if either way is faster than the crossing.

[makie]

if I had a wish free, I would prefer a test on the name of the way.

waytype[0]=road
waytype[1]=track
wayname=[0][0]=mud_road
wayname=[0][1]=dirt_road
wayname=[0][2]=lane
wayname=[1][0]=local_train_track
wayname=[1][1]=ancient_track
wayname=[1][2]=slow_train_track

but i need this in standard not in extended 
or in both
That would solve a lot of problems and graphics errors.
Then you could assign the graphic exactly and logically, to the crossings

[jamespetts]

This is certainly the sort of thing that does not depend on any of the Extended-specific features and therefore could perfectly well go into Standard.

[jamespetts]

I have briefly looked into this. It is good to have river fording, and the graphics are nice, but I do think that I will have to look into a better algorithm for this before implementation. Also, it is apparent that it is common for it to be possible for wheeled vehicles to pass over fords, so the type should not be limited to bridleways, but should also allow dirt roads. It would be helpful to have graphics for this in advance of any implementation.

Also, the better coding of a ford, I think, would be to have water as the dominant waytype and road as the servient waytype. Perhaps this could be added to the list of minor coding projects?

[Freahk]

Also, the better coding of a ford, I think, would be to have water as the dominant waytype and road as the servient waytype. Perhaps this could be added to the list of minor coding projects?

As it seeems to be accepted now, I just added it.

As a moderator, you should also be able to edit that post, so if you wish to add something, feel free to do so
Otherwise, I will add any request as soon as it got accepted. Also, I expect requests to be accepted if they were not explicitly revoked after a few weeks. So, suspect I have forgotten to add this one before.

edit: It was already listed.