The International Simutrans Forum

 

Author Topic: Oneway Twoway Road Patch for the Extended  (Read 13370 times)

0 Members and 1 Guest are viewing this topic.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Oneway Twoway Road Patch for the Extended
« on: April 07, 2018, 09:23:26 AM »
OTRP has come to simutrans extended world ;D OTRP is the patch in that both 2 lanes of road are fully used when traffic is separated like Highway system. I'll call this patch "ex-OTRP" to distinguish this from OTRP for the standard.

<for players>
※Japanese Information is available here. ←日本語の情報はこちら
Downloads
windows: https://drive.google.com/open?id=1oC8cADnJmKOtxoRH47rlU9aaUnZ6gLvG
mac: https://drive.google.com/open?id=1T19F_re1hnP8r-LSHJF07O6BCXww1b94
source to compile: https://github.com/teamhimeh/simutrans/tree/ex-OTRP-distribute
Also, misc.RibiArrow.pak is required. Please download from here.

Get Started
  • Put misc.RibiArrow.pak into your pakset.
  • Assign an appropriate key to simple tool 37. Add simple_tool[37]=,: into menuconf.tab and you can use ribi-arrow using the colon key.
  • Download an executable file and put it in the directory where simutrans-extended.exe exists.
  • Execute the OTRP file. Please do not overwrite your save data of simutrans standard.

How to use
Select a road icon with ctrl key and you can choose the overtaking mode.
  • oneway: the mode in that the road is oneway. When you use this mode, please confirm the connected direction of roads by pressing colon( : ) key.
  • twoway: the mode in that a vehicle behaves as in the conventional simutrans.
  • only loading convoy: the mode in that a vehicle overtakes only a stopping convoy.
  • prohibited: the mode in that a vehicle can overtake no vehicle.
  • inverted: the mode in that a vehicle goes on the alternative side of the lane.

You can control the open direction of a traffic light. You can see the selection buttons of the open directions when you open a traffic light dialogue. For more information, please refer this topic.

Data Compatibility
You can use any paksets and addons made for simutrans extended on ex-OTRP.
Save data of simutrans extended before revision b9030aa can be loaded on ex-OTRP. Once you save the data with ex-OTRP, the data cannot be loaded with the official simutrans extended.


<For Jamespetts and coders>

In OTRP for standard, Ribi_Arrow patch is separated from OTRP-core, but it is inseparably included in ex-OTRP. ex-OTRP-distribute branch includes the road traffic light direction patch for users' convenience. ex-OTRP branch is always the latest pure ex-OTRP branch.

URLs of branchs
ex-OTRP: https://github.com/teamhimeh/simutrans/tree/ex-OTRP
ex-OTRP-distribute: https://github.com/teamhimeh/simutrans/tree/ex-OTRP-distribute

In ex-OTRP, the version is incremented to EX_VERSION_MAJOR=14 and EX_VERSION_MINOR=0. Please check simversion.h.

OTRP is a huge and complicated patch. The transplantation from simutrans standard took a long time because the patch command didn't work and I had to bring it by hand while checking that algorithms work on simutrans extended. This patch modifies 29 files and adds 4 files.
Only a minimum test was conducted on ex-OTRP. Thus, it is unclear that this ex-OTRP is safe for players. Also, OTRP itself has many issues - performance, functional and aesthetic issues - in its code as indicated on the topic of OTRP for the standard. ex-OTRP is too risky to be integrated immediately into the extended master brunch. However, making OTRP perfect is so hard to achieve, and unfortunately I don't have enough technical and time resource to do that.
So ex-OTRP should be distributed as the separated version of simutrans extended at least for three months, and after it is confirmed that ex-OTRP is good enough for a practical use, it's time to consider the integration.

I hope many people enjoy OTRP with simutrans extended.

EDIT: I added base-texts-OTRP.dat for simutranslator in my repository but git didn't recognize it. So I attached the file on this message.
« Last Edit: April 07, 2018, 10:38:22 AM by THLeaderH »

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #1 on: April 08, 2018, 03:13:07 PM »
Can I update the existing over-taking-mode status, without upgrading the existing road?

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #2 on: April 08, 2018, 03:24:11 PM »
Can I update the existing over-taking-mode status, without upgrading the existing road?


Oh, this needs to be fixed.

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #3 on: April 08, 2018, 03:37:49 PM »
I confirmed the behavior of overwriting. When existing road is one-way, I can change the direction. However when existing road is two-way, I cannot change to one-way.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #4 on: April 09, 2018, 10:26:25 PM »
Thank you very much for this - this is most helpful. I have been quite busy recently, and I have not had a chance to look into this yet. I should be grateful for any feedback from testing for anyone who has used this.

Can I check whether the bug that Phystam has reported has been fixed yet? It would seem sensible for me to begin testing this after that has been fixed.

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #5 on: April 10, 2018, 11:13:17 AM »
I have made sure that way direction can be updated by overwriting.
Okay, I will try it!

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #6 on: April 13, 2018, 01:07:03 PM »
Can I check whether the bug that Phystam has reported has been fixed yet? It would seem sensible for me to begin testing this after that has been fixed.

The issue that Phystam reported was fixed in this commit.



I have a request for Jamespetts.
Could you distribute ex-OTRP with your nightly build system? I do not have an infrastructure to build the code automatically every night and distribute, and that means it's difficult to catch up with the latest simutrans extended features everyday. It's better for players to test ex-OTRP with the latest simutrans extended features.
« Last Edit: April 13, 2018, 01:17:56 PM by THLeaderH »

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #7 on: April 13, 2018, 04:41:34 PM »
In order to use the OTRP-distribute branch, we must have ribi-Arrow add-on in pakset.
So, we have to make a branch for OTRP in pak128.Britain-ex pakset with ribi-Arrow...
Can you create a new branch in pak128.Britain-ex?

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #8 on: April 18, 2018, 04:06:11 PM »
Sometimes city road is downgraded with low-axle-load road, so many "no route" messages are displayed on the window.
I think that the issue cannot happen at non-OTRP Extended version. Did you change the code about road renovation?

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #9 on: April 22, 2018, 06:11:30 PM »
I found another bug about building roads.
When I selected the road builder tool using "s" shortcut key, the "oneway" mode was ignored and the road was built with "twoway" mode.
(This issue cannot be seen when I clicked the road icons.)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #10 on: April 22, 2018, 08:35:48 PM »
Thank you very much, THLeaderH, for your work on this: this is most useful. The plan is not to produce a separate nightly build for this patch, but rather to integrate it into the master branch when it is ready.

Thanks to Phystam for the useful testing. THLeaderH - I should be grateful if you could let me know when the bugs that Phystam has identified have been fixed so that I can begin further testing in preparation to incorporate this.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #11 on: April 24, 2018, 02:41:30 AM »
Sometimes city road is downgraded with low-axle-load road, so many "no route" messages are displayed on the window.
I think that the issue cannot happen at non-OTRP Extended version. Did you change the code about road renovation?
This issue is fatal and needs to be fixed. However, I didn't intentionally write the downgrading code and I can't find the cause. In which file is the renovation process of roads written?

I found another bug about building roads.
When I selected the road builder tool using "s" shortcut key, the "oneway" mode was ignored and the road was built with "twoway" mode.
(This issue cannot be seen when I clicked the road icons.)
I reproduced this issue and am still researching. Perhaps, solving this issue is not so easy because the tool_build_way_t object made with the tool bar is different from that made with the "s" shortcut key. Although I continue to solve this issue, this issue is not so fatal because players rarely build roads with the shortcut key, as they can build only one pre-specified roads with the shortcut key.
« Last Edit: April 24, 2018, 03:33:38 AM by THLeaderH »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #12 on: April 24, 2018, 09:42:53 AM »
THLeaderH - I cannot immediately remember precisely where in the code the road upgrades are (somewhere in simcity.cc, if I recall), but you should be able to find it easily by setting a breakpoint in the set_desc() method of a way, and then, on a clean map with just towns, using the "grow town" special tool.

As to the "s" key, I know that I use this quite frequently - it is very useful for switching between bulldozing and building a road (or building a road and building stops, etc.) during a particular construction project.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #13 on: April 28, 2018, 03:26:05 PM »
I confirmed that the downgrading issue of city road can be exactly reproduced on the master branch. This issue is not derived from OTRP, although the mechanism of this issue is still not understood.
Some players reported me that bridges built as city road have ERROR overtaking_mode status and I fixed this issue.
As to the "s" key problem, I haven't succeeded in solving yet. The tool_build_way_t object that is used with "s" key has to derive overtaking_mode from the object of the tool bar. I struggle to do this without making a mess in the code.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #14 on: April 29, 2018, 10:01:57 AM »
The "s" key problem was solved! ex-OTRP and ex-OTRP-distribute branches contains these fixes and all changes from the master branch of simutrans extended.
The solution commit for the s key problem: https://github.com/teamhimeh/simutrans/commit/fa87cd655e732f57939725f1080ee5709864d8e5

(I apologize for double posting.)

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #15 on: April 29, 2018, 10:10:04 AM »
Splendid! I confirmed that the problem has been solved.
I could not find any issues other than the problem, even when we played Network games.
If there are some issues that I could not find, probably they are small and negligible.
Thank you again for your work!

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #16 on: May 03, 2018, 10:43:23 AM »
The halt mode is now supported on ex-OTRP. Both ex-OTRP and ex-OTRP-distribute branches contain this improvement.

(note: ex-OTRP-distribute = ex-OTRP + signal open direction control patch. It is recommended for players and testers to use the code of ex-OTRP-distribute branch.)

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #17 on: May 03, 2018, 12:00:35 PM »
Very good! It works on my savegame.
I will debug for the patch.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #18 on: May 03, 2018, 11:25:14 PM »
Excellent, that is very helpful, thank you. I will look into testing and integrating this when I get a moment.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #19 on: May 05, 2018, 08:56:36 PM »
Thank you for this. I have now tried merging this with the latest version of Extended. However, on starting Pak128.Britain-Ex, I get an error message:

Code: [Select]
FATAL ERROR: successfully_loaded() - class skin_desc_t-object RibiArrow not found.
*** PLEASE INSTALL PROPER BASE FILE AND CHECK PATH ***
Aborting program execution...

Does this require a specially compiled version of the pakset? If so, it would seem to make more sense to allow it to work, albeit without this feature enabled, with a non-modified version of the pakset, as Simutrans has traditionally always been strongly backwards compatible with older pakset versions, and it would be a great shame to break this now.

Edit: I have tried both the OTRP and the OTRP-distribute branch - both have the same issue. I have made my own OTRP and OTRP-distribute branches with these integrated.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #20 on: May 06, 2018, 12:43:07 AM »
Yes. The current ex-OTRP requires misc.ribi-arrow.pak in the pakset to show the ribi arrow.
To continue the test, you can download it from here.

Quote
If so, it would seem to make more sense to allow it to work, albeit without this feature enabled, with a non-modified version of the pakset, as Simutrans has traditionally always been strongly backwards compatible with older pakset versions, and it would be a great shame to break this now.
I'm working on this issue. Though I'll allow OTRP to work without the ribi-arrow pak,  it is highly recommended to use ribi-arrow to check the connection direction when you build oneway roads. So, Pak128.Britain-Ex should contain the ribi-arrow pak as soon as the OTRP is integrated to the master branch. Ribi-arrow is just a simple misc object and does not require a special makeobj to compile, that means it can be compiled with a conventional makeobj. The zip file which you can download from the link above contains the png and dat file. As you see these file, you'll immediately get how to define the dat.

EDIT: In addition to the ribi arrow pak,
Code: [Select]
simple_tool[37]=,:should be added to the menuconf of the pakset to activate the ribi arrow feature.
« Last Edit: May 06, 2018, 01:51:23 PM by THLeaderH »

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #21 on: May 06, 2018, 01:08:38 PM »
Now this commit allows ex-OTRP to work without the ribi allow pak!
(already commited to both ex-OTRP and ex-OTRP-distribute branch.)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #22 on: May 07, 2018, 09:49:20 PM »
Thank you very much for that. This does now seem to run without crashing. May I ask where in the pakset directory structure that the OTRP_Arrow.dat file should be located?

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #23 on: May 08, 2018, 01:23:47 AM »
I think the OTRP_Arrow.dat should be located in /gui/gui128 of simutrans-pak128.britain repository.
« Last Edit: May 08, 2018, 01:39:23 AM by THLeaderH »

Offline thegamer7893

  • *
  • Posts: 837
  • Languages: EN
[QUESTION] Oneway Twoway Road Patch for the Extended
« Reply #24 on: May 20, 2018, 01:20:33 PM »
Has there been any progress since the last update?

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #25 on: May 25, 2018, 03:15:00 PM »
I'm waiting for James to accept or point out some more issues.

Offline thegamer7893

  • *
  • Posts: 837
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #26 on: May 25, 2018, 03:39:08 PM »
Ah okay. Thanks for the info.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #27 on: May 30, 2018, 10:35:52 PM »
My apologies for the delay in merging this: I have been trying to prioritise fixing the signalling bugs, which unfortunately seem to be both numerous and very time consuming. However, I am away from home this week without access to the computer on which I have a graphical debugger installed, so I can do some work that does not involve debugging.

I have managed to merge the latest code from the master branch into the OTRP-distribute branch, but the on merging the new changes from your OTRP-distribute branch into my merged branch, I get a very large number of merge conflicts. I have pushed my merged version of the OTRP-distribute branch (that is, with the master branch changes merged into the older OTRP-distribute branch, but without the new OTRP-distribute changes merged into my OTRP-distribute branch) to my Github repository.

The merge conflicts no doubt come from some recent changes on the master branch. Would you be able to resolve these merge conflicts so that I can test the OTRP this week? It would be most useful to be able to do this.

Thank you again for your help with this work.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #28 on: May 31, 2018, 09:04:25 AM »
I merged the latest master and solved all conflicts for both ex-OTRP and ex-OTRP-distribute branch. Please check my github repository ;)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #29 on: May 31, 2018, 10:16:52 PM »
Excellent, thank you. I have now incorporated this into the master branch - thank you very much for your work on this: it is much appreciated.

I have amended the GUI slightly by adding translation texts for the various modes. I wonder whether you might assist further by adding some tool-tips for each of these modes? It may not be entirely obvious to a player what these each mean otherwise.

Also, a help text would be very useful.

In any event, thank you again for your work on this.
Incidentally, have you a good graphic or video that I could use to promote this new feature on the Simutrans-Extended Facebook page?

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #30 on: June 01, 2018, 10:34:29 AM »
Thank you very much for the integration. This is the moment that the OTRP supporters have waited for, and that my dream came true at.

Of course I'd like to help by adding tool-tips and writing help texts. However, I'm going to take a trip to California for about a week that starts tomorrow. So it might take some time for these work.

Due to my trip, I cannot immediately make a promotion video of OTRP. Instead of making a new one, please use the video I made one year ago, although the video is made with simutrans standard.
https://www.youtube.com/watch?v=waShbKcFV3s

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #31 on: June 01, 2018, 01:49:49 PM »
Very best wishes for your trip to California - may you enjoy much interesting transport! And thank you for your work again on the feature.

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Oneway Twoway Road Patch for the Extended
« Reply #32 on: June 01, 2018, 10:49:40 PM »
Thank you to @THLeaderH and @jamespetts for working together to bring a new feature to Simutrans-Extended.

I have downloaded the latest nightly .exe and pakset, but so far I cannot see any new icons or other changes in the Roads menu. Is this new feature still 'under construction'? I realize this might just be the first of several changes. Or do I need to wait until motorways become available? Or am I simply missing something obvious (either in the GUI or in the file structure)?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #33 on: June 01, 2018, 11:23:15 PM »
Thank you to @THLeaderH and @jamespetts for working together to bring a new feature to Simutrans-Extended.

I have downloaded the latest nightly .exe and pakset, but so far I cannot see any new icons or other changes in the Roads menu. Is this new feature still 'under construction'? I realize this might just be the first of several changes. Or do I need to wait until motorways become available? Or am I simply missing something obvious (either in the GUI or in the file structure)?

The user interface may need a little polishing perhaps as it is slightly non-obvious - but the way to use this feature is to CTRL+click when selecting a road to build. You  are then given a menu of the different modes available. Building a road over another road of the same type but with a different mode selected will alter the overtaking mode of the underlying road without upgrading it or costing anything.

Offline Matthew

  • *
  • Posts: 335
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Oneway Twoway Road Patch for the Extended
« Reply #34 on: June 02, 2018, 05:48:36 PM »
The user interface may need a little polishing perhaps as it is slightly non-obvious - but the way to use this feature is to CTRL+click when selecting a road to build. You  are then given a menu of the different modes available. Building a road over another road of the same type but with a different mode selected will alter the overtaking mode of the underlying road without upgrading it or costing anything.

Thank you for explaining how to use the new feature; I realize that this is very much a work in progress. I look forward to experimenting with the feature!
Note: This ended up being quite a long post, in which I express quite a bit of frustration. The first half of the post is about specific issues in THLeaderH's changes, many of which had been raised before. The second half is a more general discourse on code quality, both in the context of these changes and the codebase more generally, and about my opinions and aims regarding quality and how they compare with those of THLeaderH, James and the main developers of Standard.


I was looking through these changes last night, and I noticed that many of the issues mentioned in the Standard thread for this patch are still present in this thread. I've made some changes to your code, which James has now incorporated into master, so you should be able to look at them fairly easily. In no particular order.

I'm not qualified to comment on the technical details of this discussion, but there are some things I can say:

@ACarlotti, thank you for taking the time to improve the code for future devs with today's patch. It may not be as obvious as a new vehicle or building, but keeping code quality high is an important contribution to keeping Simutrans alive.

@THLeaderH, thank you for taking the time to learn how Simutrans works and developing a new feature. You've made the game a little bit more fun!  8) You have excellent, fluent written English, but your work must still have been especially painful when the comments and code are written in two languages (German and English) which are very different from Japanese. Getting the patch incorporated into Extended is a great achievement: I hope that the feedback encourages you continue improving the quality of the code as a gift to future developers.

Offline Andyh

  • *
  • Posts: 81
Re: Oneway Twoway Road Patch for the Extended
« Reply #35 on: June 02, 2018, 10:56:54 PM »
Thank you and congratulations to everyone involved in bringing this new functionality into the game.  It really does bring a whole new level of realism to road transportation in Simutrans. 

I have a question: what is the purpose of the "Inverted lane" option?  I know what it does mechanically, but what sort of real life situation is it meant to simulate, or what problem in the game is it meant to solve?  The other road types I get, but I'm scratching my head with this one.

Offline ACarlotti

  • *
  • Posts: 483
Re: Oneway Twoway Road Patch for the Extended
« Reply #36 on: June 06, 2018, 01:06:53 AM »
Originally posted June 02, 2018, 02:07:40 PM; partially reposted to assist splitting the topic. This section of the original post is about specific issues in THLeaderH's changes, many of which had been raised before. The remaing paragraphs can be found here.

I was looking through these changes last night, and I noticed that many of the issues mentioned in the Standard thread for this patch are still present in this thread. I've made some changes to your code, which James has now incorporated into master, so you should be able to look at them fairly easily. In no particular order:

(Also the patch files of github seems uneccessary large since a lot of identical lines (maybe with whitespaces) are contained within.)
This was my first observation too. In fact, while the full diff of your changes (using standard git diff settings) is over 10000 lines long, if I tell git to ignore whitespace changes then the diff is less than 5000 lines long. While it might be good to fix whitespace inconsistencies, this should always be done separately to other changes. The reasons for this are that it allows people to inspect and understand your changes, and that it makes it easier for people to understand the history of the code.
To take one particular example, if I look at boden/wege/weg.cc, there are a lot of changes to whitespace mixed in with actual code changes, all under the commit message "bring from standard". Ideally the code changes would have been separate to the whitespace changes, and that commit message (at least read in isolation) is quite misleading, as these changes were not taken from standard, but from a patch on top of standard.

Logic incomplete and even flagged with TODO's, yet still left.
I spotted and removed one out-of-date TODO relating to version numbers (which is fairly reasonably something to leave in until James merged it). However, there are still some others, among which this one in bauer/wegbauer.cc particularly worries me:
Code: [Select]
// TODO: not edited since it's quite different from that of standard...To me, this TODO suggests that you haven't bothered to port part of the code because it was difficult. I hope this is not the case, but some reassurance here would be appreciated.

Maybe try using this new fangled keyword called 'else'. if(a), if(!a) yeesh.
It took me less than a minute to find an instance of if(a) {stuff} if(!a) {stuff} in your changes, and even though it might take you longer if you're not as familiar with the relevant git commands, you should still be capable of looking at your changes and reading through for things like this. I think I replaced all the instances of this particular non-pattern, but since I haven't read the patch through line-by-line I cannot be certain.

refleshing. what? I can't even...
I think Turfit could have written this better, but I'm pretty sure his gist is that "reflesh" is almost certainly not the word you meant. My guess would be that you meant "refresh" instead, but even that seems like a poor name choice, with "refresh_vehicle_images" probably being a better name for the method in overtaker_t. (I would also make this method take no arguments, and move the check into overtaker.cc).
I also removed the "reflesh" method from vehicles because (as it was implemented) it was duplicating a lot of code that already existed - see my changes for (in my opinion, at least) a better way of doing that.

Another thing I've noticed that could be improved in your code is a lot of places where your manipulation of booleans is unecessarily complicated, or you store intermediate results that don't need to be stored. In one example that I simplified last night, you use about 5 lines of code with an if branch in the middle where you could have used a short boolean expression. A couple of lines later you create a whole new overtaker_t variable just to test if it is null. Storing the object suggested that you would use it again later and that the null check was partly to avoid null dereference errors; in fact I realised after a bit that the null check was the entire usage of the object.

Out of interest, how did you solve this issue? I came across it this morning while reading through the Standard thread, and didn't notice any mention of how you resolved it.
https://forum.simutrans.com/index.php/topic,16659.msg165492.html#msg165492

Edit: Four paragraphs extracted to a new topic - see here.

I also know that there are many more changes that could (and should) be made to improve the code. I'm not going to list every single change that should be made, because that would take me days or more likely weeks, and then I might as well make them myself. (See also 'code smells'.) That is the point Turfit was making - we can tell you the sorts of issues we see, and we can maybe give you some examples, but you then have to be able to extrapolate from this and seek out other instances of these issues yourself. For example, you complained "Please make your issue posts as concrete as possible. For example of if ~ else, please point out at least 1 line that is malformed."  Did you even try looking yourself? As I said, it took me less than a minute of skimming through your changes to find an example of this; it shouldn't have taken you too long to find one yourself, even if you were unlucky and looked in the wrong places first. If you can't look for and find issues yourself, even after you are told what those issues look like, then the only alternative is that someone else rewrites your patch for you. That shouldn't be necessary.

With your knowledge and understanding of the code, you should be able read through it and rewrite bits of it more easily than me, because everywhere that something is written out poorly (e.g. with duplication, unnecessary complexity or vague of misleading code/comments) you already know what it's supposed to do. Fundamentally, what I (and Turfit, and prissi, and Ters) want is for you to read through the entire patch, line by line, and section by section, a couple of times, and think about how you could make it easier for other people to read. I'm sure James will be glad to incorporate such changes, and that is also the only way you're going to get this into Standard.

(James: I think this should enable you to split the topics - posts 34 and 37-41 being the new topic)
« Last Edit: June 06, 2018, 11:25:26 PM by jamespetts »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #37 on: June 06, 2018, 11:25:49 PM »
Thank you - I think that I have split this correctly (and edited your post to insert the links in the designated places).

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1347
Re: Oneway Twoway Road Patch for the Extended
« Reply #38 on: June 14, 2018, 11:27:49 PM »
Note: This ended up being quite a long post, in which I express quite a bit of frustration.
Frustration for sure with this patch, and ultimately somewhat disappointment. From a "Fun patch", to claimed trunk candidates, through sheer obstinance and even outright bold faced lies (Multiplayer tested working while the required code was completely missing!), to a final give up and ceasing work. Not fun, but wait, it's back with a series of 'updates' to fire up the rah rah crowd, all the while not addressing the deep functionality issues, and then into SimEx it goes seemingly duping with it's shiny bauble...
If feeling generous, I'd assign it a 30% completion. If not, a failed proof of concept. In neither case, something 'ready'.

I get there's serious pent-up demand for such a feature, and I truly hoped this patch would've been usable/went somewhere, but the experience has definitely reinforced my gut feeling that this approach in the code is not workable.


To me, this TODO suggests that you haven't bothered to port part of the code because it was difficult. I hope this is not the case, but some reassurance here would be appreciated.
Out of interest, how did you solve this issue? I came across it this morning while reading through the Standard thread, and didn't notice any mention of how you resolved it.
I expect such issues have not been resolved, and TODO's remain undone, even if the TODO itself is removed from the patch after pointing out it's existence. It's trivial to setup tests where the vehicle behaviour fails; Let's not even talk about trying corner cases. Expect bad things whenever the overtaking mode changes, or worse where they meet - aka intersections. Restrict the patch's use to creation of controlled access divided highways, and things mostly work (still issues with the inherent intersection where on/off ramps are...), but for avenues which seem to be the most desired feature, disaster.


refleshing. what? I can't even...
I think Turfit could have written this better, but I'm pretty sure his gist is that "reflesh" is almost certainly not the word you meant."
'tis like something straight out of a horror movie. Tops even the factory boost mechanism 'consuming' passengers we had for a while in development of that patch I thinks.


The signalling code is, I must confess, an example of an erroneous decision on my part about how to handle the project at an early stage. The erroneous decision was to keep as much of the Standard signalling code as possible and build the additional features by adding to that code rather than starting afresh.
That sums up my feelings on the approach taken with OTRP. The existing code for vehicle movement through intersections is already stretched to the limit. Grafting multilane road logic onto it, and the existing overtaking logic takes it beyond breaking; Erroneous to continue in this way.

I intend to revisit getting the previously discussed 'intersection_t' object implemented. That should greatly simplify things w.r.t vehicle control especially with multi tile intersections. Unfortunately my on again, off again enthusiasm for contributing anything, and meandering interests has already delayed that by years...

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #39 on: June 21, 2018, 01:41:07 PM »
Currently, menuconf.tab of 128britain-EX has not been edited so you can not see the OTRP arrow as it is. (Is this intentional?)
If you add it to line 191 in menuconf.tab as follows, you can see the OTRP arrow by pressing ":" key.
Code: [Select]
simple_tool[37]=,:
OTRP arrow is also displayed on tracks, trams, rivers or canals. I believe it is unnecessary on there.
These ways can not be controlled with OTRP and these run on a system different from the road, for example, railway track controls the direction of the train using one way sign, but OTRP arrows are not linked with railway direction restriction, so players will get confused.

When you build the tram track on the road, these two arrows are integrated and the display of the arrow no longer makes sense. This is an obvious bug that should be fixed. (´・ω・`)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #40 on: June 21, 2018, 09:43:52 PM »
The "," key cannot be used for this, I am afraid, since it is already used for reducing the rate at which time passes - do you think that you could find a spare key?

Offline Rollmaterial

  • Devotee
  • *
  • Posts: 597
  • Languages: EN, FR, DE, FI, SE
Re: Oneway Twoway Road Patch for the Extended
« Reply #41 on: June 21, 2018, 09:53:43 PM »
He meant the ":" key, not the comma.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #42 on: June 21, 2018, 10:03:54 PM »
Ahh - I misunderstood, my apologies. The : key appears to be free, so I have integrated this.

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #43 on: June 22, 2018, 12:49:03 AM »
Ranran — I think that the ribiarrow (you say “OTRP arrow”) is not only for road waytype, so it is not a bug. This is also useful for confirmation of railroad oneway sign :)
However, if we can display arrows for each waytype separately, it will be more convenient, I think.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #44 on: June 22, 2018, 11:43:00 AM »
James, thank you for making a change to enable the feature of showing Ribi-Arrow.

As Ranran says, I think ribi-arrow should be only showed for street. I made a pull request.
https://github.com/jamespetts/simutrans-extended/pull/90

As Phystam put it, ribi-arrow might be useful for checking the direction of railroad oneway sign. Ribi-Arrow should be configured separately for each waytypes, but assigning keys for all waytypes is not appropriate. Also, creating GUI selection window is not a good solution. I don't know what is a suitable interface for this...

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #45 on: July 06, 2018, 12:56:25 PM »
Hello, James.
My recent releases of OTRP for standard contain some bug fixes and I brought them into the extended. Please refer the pull request.

P.S. I'm sorry that one of the commits contains an unnecessary change, the removal of spaces, but Atom editor forced me to do so :(

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #46 on: July 06, 2018, 11:57:38 PM »
Thank you for that. Can I ask which bug fixes have been ported to Extended?

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #47 on: July 07, 2018, 12:06:52 AM »
This pull request contains bug fixes that was done in OTRP v14.
  • bug fix for algorithm of vehicle control
  • bug fix for lane yielding
  • do not execute other_lane_blocked when street is twoway
  • allow changing overtaking_mode for elevated way with ground way
The last one is an improvement of UI, not a bug fix.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #48 on: July 07, 2018, 03:31:40 PM »
Splendid, thank you: now incorporated.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #49 on: August 06, 2018, 10:54:01 AM »
OTRP now becomes a kind of fork project of simutrans and continues evolvement. And it's time to bring the improvements into the extended. The latest version of OTRP is v17, so I want to bring the following changes.

  • The ribi-arrow can be called from the display settings window.
  • Some fixes around vehicle movement.
  • Flags for road. "citycars do not enter" and "avoid becoming cityroad" feature.
  • Improvement of citycars. Citycars follows lane affinity signs and the lane yielding rule.

In OTRP, Citycars now determine their route for certain tiles (e.g. 15 tiles). Determination of the route in advance is needed for lane affinity signs and other OTRP's function. Also, routing algorithm is modified so that citycars avoid a sharp turn and congested road. The acceleration of citycars is also changed to simulate a smoother movement. Are these changes acceptable for simutrans extended?

Thanks to @shingoushori, recent versions of OTRP contains some construction tools which are useful for the large scale development. The transplantation of these tools to simutrans extended should be discussed as another topic.

Offline ACarlotti

  • *
  • Posts: 483
Re: Oneway Twoway Road Patch for the Extended
« Reply #50 on: August 06, 2018, 09:00:39 PM »
Are these changes acceptable for simutrans extended?

I think there are at least three questions to ask here:
1) Are these features desirable? (Probably? I haven't tested related stuff yet.)
2) Are these features that would also be accepted in Standard (in theory, not just for the current implementation)? (If so, then I think work should probably be to add them to Standard first, so as to minimise unnecessary divergence between the code for Standard and Extended)
3) Is the code well written and likely to be maintainable? (I have my doubts based upon previous code, but will have a look if/when there is a specific proposed patch.)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #51 on: August 06, 2018, 11:17:13 PM »
Yes, given some of the problems identified with the previous version of this, we do need to be careful about merging anything other than fixes.

It would be helpful to have two things in particular (1) a separate patch just with the fixes; and (2) a more detailed description (and possibly demonstration) of the new features.

Thank you very much for your work on this.

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #52 on: August 07, 2018, 09:46:05 AM »
THLeaderH, thank you for your great works!

I have a question about "avoid becoming cityroad" feature.
Currently there is almost same feature in Extended version, and this is implemented with "waytype=noise_barrier" configuration for wayobj .dat file. (but I have never seen it in pak128.Britain-Ex)
So I do not think it should be incorporated for extended version, at least.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #53 on: March 10, 2019, 02:27:10 PM »
THLeaderH - can I ask whether you might be able to provide:

(1) the fixes on their own; and
(2) a more detailed description of the new features?


Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #54 on: March 10, 2019, 04:12:10 PM »
Quote
(1) the fixes on their own;
Yes, I will do that. I apologize for leaving OTRP related bugs for a long time.
However, I've not heard about the defects of OTRP related feature in extended recently. Could you explain some of the defects that I have to fix?

Quote
(2) a more detailed description of the new features?
I apologize for not having provided the description while it had been requested before. Is there any template of feature description or articles that I should refer to write the description?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #55 on: March 10, 2019, 10:51:39 PM »
Thank you for your reply. I am not aware of any defects other than those that have been reported on this forum (and I think mainly in this thread). As to documenting the new features, there is not a standard template for this. I suggest that, for each feature, you set out a separate heading and describe (1) what problem that it is seeking to solve; (2) in general terms how it does it; (3) how it works algorithmically; and (4) how it works from a user interface perspective.

Thank you for your work on this so far.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #56 on: March 12, 2019, 11:28:21 AM »
A description of OTRP for extended.

Oneway Two Lane Road

The road of simutrans standard supports only two-way traffic. Even when the road is operated as oneway with oneway signs, vehicles use only one of two lanes. When roads are congested, the traffic lane is filled and the passing lane is empty.
With simutrans extended, passing lanes are used more effectively than simutrans standard when road is set "oneway mode" by relaxing the conditions to overtake other vehicles. oneway mode enables you to build a 4-lane highway. To set the mode to roads, please select a road icon holding a ctrl key, and the road configuration dialog appears. Halt mode, oneway, twoway, only loading convoy, prohibited and inverted mode are available. With halt mode, vehicles are allowed to stop on the passing lane. This is useful to build a bus terminal.

Show Road Connection Tool

Conventionally, road tile dialogue that appears by clicking the tile was the only way to check which directions the road is connected. With the oneway mode feature for roads, checking road connection is frequently needed. In simutrans extended, simple_tool[37] is assigned to "show road connection tool". This tool visualizes the directions of road connections with arrow images.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #57 on: March 12, 2019, 12:25:53 PM »
I think that you may have misunderstood the request: my apologies if this was not clear. I was referring to this post. That post referred to a pull request, which contained both bug fixes and additional features for the OTRP. What I was after was:

(1) a separate branch/commit containing only the bug fixes already contained in the commit to which the pull request referred so that I can apply the bug fixes straight away; and
(2) a description of the new features in the commit referable to that pull request so that consideration can be given to whether also to incorporate those features.

The description above seems to be a description of the OTRP generally. I should be very grateful if you could provide the items listed above so that progress can be made. Thank you again for your work on this.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #58 on: March 15, 2019, 01:50:28 PM »
The bug fixes that I planned to post a PR are
https://github.com/teamhimeh/simutrans/commit/bfd5806f6cc3b4a955929fae403e8c9c051c0750
https://github.com/teamhimeh/simutrans/commit/e7266465ada1cb33e7788c0a736f6ddcae85c527
https://github.com/teamhimeh/simutrans/commit/fb76da14392aeaf3e6fcb0147677d3741ee9a391

The new feature is road reservation. With this feature, vehicles reserve tiles in intersections and this prevents dead lock in big intersections that consists of more than one tiles.

I'm working on TWO pull requests separating the bug fixes and the road reservation. However, I have a trouble in compiling the code. I apologize you to take some more time to post the two pull requests.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #59 on: March 15, 2019, 02:01:07 PM »
That is very helpful, thank you. There is no rush as there are many other things to be done - but when you have the time, I shall look forward to the bug fix commits/pull requests.

As to the new feature, this is an interesting idea. Do road vehicles often get stuck at intersections? I thought that Standard had solved this issue a while back (and that this had been incorporated into Extended)? I am playing on the Bridgewater-Brunel server at present with a 'bus company and I have not noticed vehicles getting stuck at intersections, but perhaps the traffic is not busy enough in 1942.

I should be grateful for feedback more generally on the tile reservation feature. In the meantime, I shall look forward to the bug fixes. Thank you again for your work on this - it is appreciated.

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #60 on: March 15, 2019, 02:36:55 PM »
Quote
Do road vehicles often get stuck at intersections? I thought that Standard had solved this issue a while back (and that this had been incorporated into Extended)? I am playing on the Bridgewater-Brunel server at present with a 'bus company and I have not noticed vehicles getting stuck at intersections, but perhaps the traffic is not busy enough in 1942.
Traffic stuck can be often seen in the intersection that consists of multiple tiles with a dense traffic like this.


Vehicles checks the existence of other vehicles in advance when they enters an intersection. However, vehicles only checks, do not reserve the tiles. If two vehicles reache the intersection at the same step (time) , the vehicles cannot recognize other vehicles and enter the intersection. This can cause a traffic stuck. Tile reservation can solve this problem, because vehicles reserves the whole path of the intersection before they enter. As a fact, I implemented this feature because users of OTRP for standard reported me that road vehicles often stuck in a big intersection.

I continue dealing with the compile problems and they can be posted in another thread as a bug report.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #61 on: March 15, 2019, 02:39:25 PM »
Can I clarify - does the problem that intersection reservation addresses exist only when the OTRP features are used, or does it exist even with the roads' default settings?

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #62 on: March 15, 2019, 02:44:20 PM »
Theoretically, this problem exists even with the default settings, twoway mode. However, the traffic stuck phenomenon itself emerges much more frequently when the road is oneway mode. It is not clear why it is.

Offline Phystam

  • Devotee
  • *
  • Posts: 433
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Oneway Twoway Road Patch for the Extended
« Reply #63 on: March 15, 2019, 04:09:24 PM »
Implementation of “intersection_t” is now needed, as A. Carlotti suggests. This class makes more simpler the code.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #64 on: March 15, 2019, 05:21:06 PM »
Thank you both for your replies. Some consideration may be needed of whether it would be preferable to implement intersection_t before making these changes; I should be grateful for A. Carlotti's view on that, since it was he who suggested adding this class.

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #65 on: June 13, 2020, 08:20:38 AM »
Sorry for exhumation the old thread, but I now see some issues.

I used this option to restrict a road, and after a while, when I laid the road again in another place, I forgot that I changed the option before and unintentionally made a one-way road. It may be laid. And sometimes player don't notice it, because player doesn't always display the colorful arrow.
I think it's better to reset the restrict option to default mode once exiting road laying mode.


Secondly I think this arrow has some flaws. First of all, I don't understand why the colors differ depending on the direction.
This may be a design issue, but  in any case we can't change the color due to restrictions.
I think this should be color coded according to one-way, parallel stop mode, etc.
In fact, it is not possible to distinguish the parallel stop mode from the arrows.
And at the end of the road, player may not be able to tell that it is a one-way street, as only half of the arrows are visible.

For example, the default is a color that seems to be unlimited, such as green or blue or light blue. One-way traffic colors appear to be restricted - pink, orange or red.
Then use special colors or arrows for parallel stop mode and overtaking mode.


Thirdly, why does this arrow appear with the highest priority over vehicles? That's why I hide this in most cases.
Block reservations, for example, do not hide the train.


Fourth, the arrow is affected by day and night changes, making it less visible at night. Block reservations do not. It conflicts with the basic UI behavior of simutrans.
« Last Edit: June 13, 2020, 08:41:07 AM by Ranran »

Offline THLeaderH

  • Coder/patcher
  • Devotee
  • *
  • Posts: 370
  • Languages: JP,EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #66 on: June 13, 2020, 09:05:40 AM »
For the first claim, Road options including overtaking mode are preserved in the road construction tool to avoid meaningless re-selection of overtaking mode and etc. This is a design choice.

For example, if you are building a highway on the ground, you want to build a road with "oneway" mode and "avoid becoming cityroad" option. You sometimes need to construct piers and fences while the road construction. If these options are reset every time you select the road construction tool, you will always need to re-select the road construction options and that will sure be bothersome.

For the second claim, ribi-arrow is made to check the connected direction of roads and not to show the overtaking mode. The author of ribi-arrow made arrows colorful so that you can check the connected direction in an instant. Separating the color according to the overtaking mode may be useful, but it needs a remaking of the ribi-arrow addon.

For the third claim, as I put in the previous paragraph, ribi-arrow is made to check the connected direction of roads in an instant. Thus, ribi-arrow has the highest drawing priority.

For the last claim, I agree. I will make ribi-arrow not be darkened in the next release.

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #67 on: June 18, 2020, 10:12:24 AM »
Sorry for the late reply. Working with Dr. Google translate is a pain for me. Ranran's health is almost 0.
But rest assured. Many Japanese wear zombie-like traits to stay alive with HP1. They always seem dead, but they are alive. It's not walking dead.

I'm afraid, but I don't think I got a valid answer. First of all, I think you gave such an answer because you are not aware of the PROBLEM this feature is causing.
You had to see at these bug reports:
https://forum.simutrans.com/index.php/topic,19732.0.html
https://forum.simutrans.com/index.php/topic,20063.0.html

Defects in this design can cause great disaster. You can use this function to easily carry out harancement. Most people don't notice the fact that someone changes all the roads to "overtaking prohibited". Moreover, it is difficult to identify the criminal.
As the administrator may find by looking at the history from the log, but as I explained at the beginning, it can happen not because of the bad faith of the player, but because of the unkindness of the design.

And finding and fixing it is also a laborious task. Because it is not easy to recognize where the trap is set.
Quote
This is a design choice.
The work of discovering that trap is a meaningless work created by an unfriendly design.


Quote
For example, if you are building a highway on the ground, you want to build a road with "oneway" mode and "avoid becoming cityroad" option. You sometimes need to construct piers and fences while the road construction. If these options are reset every time you select the road construction tool, you will always need to re-select the road construction options and that will sure be bothersome.
I can't understand why you are assuming to switch and limit at the same time.
Isn't it easiest to overwrite and limit all of them once they are completed and connected?
It looks like you're making bothersome yourself. And is this bothersome a trade-off with the above problem?


Station stop mode is convenient, but I don't think this mode should be set ignoring both roads and stations.
It forces status with no relation to economy or appearance. That is why I think that color coding of arrows is the minimum necessary.
Also if we don't pay the cost, there is no reason not to set "only loading convoy" for all bus stops on roads that aren't one-way or not on the terminal end. Players who don't set this are so stupid. It only appears to be intentionally blocking traffic.
But setting it up on every bus stop is a tedious task. It's like a Japanese social game.


Quote
avoid becoming cityroad
What are you talking about? Is this a feature for standard? I don't know if that matters here. Can you elaborate?



I think a design change is necessary to solve above problems.
Because even if you prohibit the rewriting of the road restrict of other players, all the streets are public roads in the city, so you can either rewrite it except admin or you can rewrite it.
You may also enter the roads of other players. Visualization of which restriction set on the road is needed. It's rediculous not to know the information unless you click and check all the tiles that pass by.
I mean, currently, only one-way traffic can be identified. But how can you see "overtaking prohivite"?
However, frankly, in most cases, the restricted display is cut off due to excessive display, so even that may not be useful.
I didn't notice until I saw my horse take a weird route that one-way restrictions were imposed in the big city of server games.
This is inconsistent with the traditional simutrans method because it eliminates the one-way road sign and imposes such restrictions. And replaced with sometimes useless arrows.


I enumerate some measures and improvement ideas. It's like brainstorming. In the future I may try to change some if I have the time, but when I do that I will probably start by breaking down and reorganizing features. There is no doubt that a huge amount of time will be required.
However, there are many problems in the current situation, so I hope for early improvement.



Measures against incorrect limits
Although from what I saw that this endevour had become maybe a little too complex (like five overtaking modi and hidden flags by special tools) for the normal casual player.
As prissi pointed out, this is very hard for new players to understand. In addition, I believe the UI is unfriendly and not a universal design.
The one letter abbreviation of the alphabet is the worst for Japanese. Alphabets other than H have no meaning.
People in the Kanji culture will understand how stupid it is to get things understood with one letter of the alphabet.
The alphabets set in these are extremely difficult for Japanese people to understand. And this is not translatable. Is this made only for English?
I think many Japanese who are not good at English think this way. Why is it "L"? Why is it "I"? Why "H"?
Especially normal Japanese people are not familiar with "halt". Ranran thought it is German too(´・ω・`)
So you should know that this is happening in English as well. English is translated as "parallel stop mode". But the alphabet is "H". This is truly Jarapagos LOL
Also, no tooltip is placed.
If at least this color matches the color of the arrow, there is still salvation.
You know what it does because you made it. However, the UI needs to be easy to understand for those who do not know its function.



There are more things you can do to improve the design than just coloring the arrows.
- Change cursor according to mode
- Show an arrow when laying. In other words, when a mode other than the default mode is selected at the time of construction, for example, in the case of one way, the arrow from the start point to the end point is displayed regardless of the display mode.
Rather, I'm wondering if it's showing the arrow now, but not. However, this is only useful for indicating whether it is one way because there is only one type of arrow.
I also thought about writing it in a tooltip that displays the estimated cost, but that will not be very effective.

Quote
Separating the color according to the overtaking mode may be useful, but it needs a remaking of the ribi-arrow addon.
I don't understand why the default mode requires an "arrow". In other words, it is not necessary to use it, and a light blue "straight line" is sufficient. It's in both directions. The exit and entrance are sufficient for the arrow.
And "overtake stationary only", "overtaking prohibited" and "opposite lane driving" do not need arrows in the first place. This is just an area. I wonder if the station stop mode should be combined with road direction restrictions. As mentioned before, I prefer bus stop to have such a setting. Depending on the type of bus stop you decide whether you can overtake or stop in parallel, some modes are no longer needed in the first place.
The direction does not matter. At least you don't have to draw a new arrow to indicate the "area".

Anyway, it is necessary to make it easy to understand where the restrictions are imposed, as the problem is pointed out. Putting strange and colorful arrows everywhere is just confusing.
At least in many cases, I have to say that this display is excessive. I've used block reservations a number of times to compare this, but it's like coloring non-reserved blocks as "here is not reserved". Since it is excessive, it feels very annoying that it is displayed with priority over the vehicle.

I think color distinction is needed, but I think the option to show arrows only in non-default places is needed even if you don't implement it.
Otherwise, players may have restrictions that can only be found by clicking on each tile to see it.


Quote
ribi-arrow is made to check the connected direction of roads and not to show the overtaking mode.
ribi-arrow is made to check the connected direction of roads in an instant.
With the current specifications, it is impossible to know if it is in both directions without the cooperation of the tile next to it. This is a design error. So your goal does not appear to be achieved.
First, the arrow does not have to be on the center line of the road. There should be two lanes on the road. For some reason, I'm going to write the arrow on the centerline, not on the lane. If it's a one-way street, it could be right.
I have left-hand and right-hand traffic problems, but I just shift the offset from the center depending on the settings. This may support "Invert".


I like the combination of appearance, economy and function. That is, cost, appearance, and function are linked. It should be easier for players to understand. But I can understand that implementing it can be tedious.

For example, an overtaking bus stop on one way would look like this.


If it can overtake in both directions, the bus stop will be on the back side.
In case of pararell stop, there should be a bus stop in the same direction. Because the bus has a door on only one side. It's strange that it has a parallel stop at an ordinary bus stop. Passengers who get off the road will be killed by cars in the next lane.

Another thread doesn't point out that it's unnatural for someone to be able to pass on a narrow trail. However, this feature allows overtaking on any road. No additional cost required.

Offline Vladki

  • Devotee
  • *
  • Posts: 3338
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Oneway Twoway Road Patch for the Extended
« Reply #68 on: June 18, 2020, 11:53:15 AM »
For the third claim, as I put in the previous paragraph, ribi-arrow is made to check the connected direction of roads in an instant. Thus, ribi-arrow has the highest drawing priority.

If this is the primary purpose - to find accidentally disconnected roads, then this arrows should be displayed for all waytypes. It is much more common to forget disconnected rail track.

Otherwise I would have this suggestion (combining ranran's ideas):

- The current style of arrows is good for railways (and maglevs, etc.) Different colors for each direction are not necessary, but not a problem either. Different color for road and tram would be good (see below).
- For roads the arrow should be offset to show to which lane it applies. This would allow easy show of "oneway", "twoway" and "inverted" modes. (Also a tram arrows could be shown in the middle lane - perhaps distinguished by color).
- overtaking prohibited = full thin line in the center (a bit like the pink arrow on ranrans picture)
- halt mode - AFAIK it implies oneway so arrows should be like that. To distinguish it from oneway, a full line as for no overtaking could be shown, or some other color used.
- only loading convoi - maybe dashed center line? Or full line of different color?

BTW: I'm not sure setting "only loading convoi" on all stops makes any improvements. AFAIK Stopped vehicles can be overtaken anyway if the rules for overtaking are met (no cars in opposite direction, etc.) This will not relax any of the restrictions. It will just forbid overtaking of non-loading convois. However I'd like to see a mode where loading convois can be overtaken more easily. Especially in situation where you have longer stop (2-3 tiles), used by many 1-tile long buses. So that they could overtake each other and use any free stop (using choose sign).

Single sided bus stops on one way road would be nice, but it would work only if the stop does not have any painting on ground (like old style bus stops in pak-britain). The you could just show only frontimage or only backimage. But the road painting is always backimage, so you would have both in one direction, and non in the other.

EDIT: and one more mode would be nice - parallel bus stop (halt mode) for dead end stops.
EDIT2: and show the arrows when building the road by dragging

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #69 on: June 18, 2020, 12:23:25 PM »
If this is the primary purpose - to find accidentally disconnected roads, then this arrows should be displayed for all waytypes. It is much more common to forget disconnected rail track.

I think the spaced arrows aren't very good at checking connectivity. Also, arrows do not support slopes or diagonals.


BTW: I'm not sure setting "only loading convoi" on all stops makes any improvements. AFAIK Stopped vehicles can be overtaken anyway if the rules for overtaking are met (no cars in opposite direction, etc.) This will not relax any of the restrictions. It will just forbid overtaking of non-loading convois. However I'd like to see a mode where loading convois can be overtaken more easily. Especially in situation where you have longer stop (2-3 tiles), used by many 1-tile long buses. So that they could overtake each other and use any free stop (using choose sign).
I don't know if this involved a bug. It seemed that the passing carriage did not pass the stopping carriage on the two-way road. The carriage stopped for about 7 minutes and was blocking the carriage.


The you could just show only frontimage or only backimage. But the road painting is always backimage, so you would have both in one direction, and non in the other.
I think it's still easy to implement a single-sided bus stop.
Having a central bus stop for parallel stops requires modification. However, the ability to draw objects in the center has other extensibility. (E.g. policeman signal at intersection, center pole of trolley line, but policemen will be run over and killed by trams)

Offline Vladki

  • Devotee
  • *
  • Posts: 3338
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Oneway Twoway Road Patch for the Extended
« Reply #70 on: June 18, 2020, 12:34:50 PM »
I think the spaced arrows aren't very good at checking connectivity. Also, arrows do not support slopes or diagonals.
Oh indeed they do support slopes and are useful - you have to zoom out:

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #71 on: June 18, 2020, 12:49:16 PM »
I wanted to say that it is much less inferior to the one that has continuity because it lacks continuity. (´・ω・`)

And the arrows arranged in a zigzag on the diagonal are strange and honestly speaking, I do not like it.  ::(

If you look only at this, it looks like it is not connected.
« Last Edit: June 18, 2020, 01:13:31 PM by Ranran »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 10001
  • Languages: De,EN,JP
Re: Oneway Twoway Road Patch for the Extended
« Reply #72 on: June 18, 2020, 01:30:01 PM »
This was the main point of not starting to integrate the oneway overtaking patch to standard, which otherwise I would have liked too. However, personally I thought of a single direction wayobj (which would also allow to make other ways single directing) and give at the same time visual clues. For instance a guard rails with signs or arrows at crossings and begin and end.

Unfortunately I never finished my patch. (Partly because I lost motivation, when it became clear, that the code was geared for experimental and there was no intention to work further on standard.)

Offline Vladki

  • Devotee
  • *
  • Posts: 3338
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Oneway Twoway Road Patch for the Extended
« Reply #73 on: June 18, 2020, 02:20:17 PM »
If you look only at this, it looks like it is not connected.
No, it does not look so. If disconnected there would be one arrow skipped. When looking for disconnections you have to zoom out, and look for irregularities. Then it does not matter if the road is one- or two-way, straigh, slope, or diagonal. You just look for irregularities.

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #74 on: June 18, 2020, 02:41:53 PM »
What I mean is that this is not the best way. Does it make sense to find the missing one of the four?
For example, if this is a connected line, or if the color differs depending on the type of constraint, it is obvious. Why do you force users to take unnecessary trouble?
I said it should be done if it makes sense to change it along with the problem mentioned above. First, the above issues are priorities. I'm not sticking to this arrow alone.

However, I think it is impossible to improve the identification method without changing this display method in some way.
« Last Edit: June 18, 2020, 02:52:42 PM by Ranran »

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #75 on: June 30, 2020, 02:17:23 PM »
I have found that this feature can be used to freely destroy public or my own roads without providing alternative roads. (´・ω・`)
Make sure that both the entrance and exit are one-way inward. That way, it's almost as if it was cut, so it can be destroyed.
Occasionally it fails to destroy the entrance, but in that case try another destruction of the inner tile.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #76 on: June 30, 2020, 06:46:44 PM »
I have found that this feature can be used to freely destroy public or my own roads without providing alternative roads. (´・ω・`)
Make sure that both the entrance and exit are one-way inward. That way, it's almost as if it was cut, so it can be destroyed.
Occasionally it fails to destroy the entrance, but in that case try another destruction of the inner tile.

This suggests that it should not be possible to change the one way status on public roads, as there is no algorithm that can be implemented within a reasonable time to check whether one way statuses on these roads in combination make them impassible.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #77 on: June 30, 2020, 08:15:12 PM »
Oh well, even more restrictions that will require killing many people.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #78 on: June 30, 2020, 08:25:13 PM »
Oh well, even more restrictions that will require killing many people.

Can you think of a workable alternative?

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #79 on: June 30, 2020, 09:35:07 PM »
Usually I just trust people not to be too disruptive, but I've just recently noticed some people intentionally seem to be disruptive :(

In any case, all these restrictions have the exact opposite effect: People are forced to be very disruptive to achieve rather small changes and not allowing any oneway changes of PROW ways will make the aspect of road traffic management just impossible, at least without destroying whole city quarters just to remove and rebuild some roads.

If I have built a country road I definitely want to be able to upgrade it to become a motorway later.
There currently is a (rather incomprehensible) system to check for diversary roads. Why can't that system be used when changing the oneway mode either?

Btw. is there a way to entirely disable those diversary route checks? it's the most annyoing feature extended has and not required in a community where people trust each other to not be disruptive. In fact, on my last servergame each player had

If people are intentionally disruptive,  all these current restrictions including the plan to disallow the use of oneway modes in most cases doesn't really solve the issue either. Routes can still be cut by not sharing access and replacing PROW ways by player owned diversary routes, as just happened on Bridgewater at Thurenton.
Further, people are free and sometimes forced to destruct whole city quarters due to these restrictions, as just happened at Bridgewater in Thurenton either.

Further, a system to allow for replacing ways by bridges without causing temporary disruption should be considered as this is the main reason forcing players to destroy buildings just to build a temporary diversion.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #80 on: June 30, 2020, 09:44:54 PM »
I do not think that the problem is solvable simply by trusting other players not to be disruptive. Firstly, there is always a risk that players will be malicious; but secondly and probably more importantly, there will always be cases where players might do things that, whilst not intentionally malicious, are nonetheless doing things which it breaks game play balance for players to be able to do, such as cut off private car routes to towns to prevent traffic congestion and force passengers to use their own transport. This is not malicious to any other individual player, but it breaks the game play realism and the game balance for everyone. There may even be cases where players do not realise that they are destroying the only route between two towns.

A public right of way system is necessary for gameplay balance.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #81 on: June 30, 2020, 10:17:34 PM »
Still, is it possible to disable this? Its current nature is causing more disruption than it solves.


Just to be clear: I am not against PROW ways or something simmilar as a mechanism to prevent players from cutting privatecar connections between towns, but I do not think it should be as restrictive (and annoying) as the current system is, as it's often forcing players to destroy houses in cases where this would not actually be required.
Further, that system should not try to prevent players from abtotaging others as it cannot do this anyway.


All it should do is
a) ensure that connected cities remain connected without huge detours
b) ensure that housings within a city can be reached.


To do so, when initially built, it should be remembered which (pairwise) towns were linked by PROW roads and how long that connection initially was.
Roads inside towns will always be PROW when built adjacent to a PROW way, otherwise they will be unowned, but not PROW (which can happen when cities expand across lakes or something like that)

When players do now attempt to remove or alter the oneway state of a PROW road, it will be checked if
a) The distance in between the affected cities does not exceed the initial distance plus the tolerance and
b) Within towns, all adjacent PROW roads remain connected to the townhall.

That's the only system I can think of to actually ensure what it ite meant to without being as annoying as the current system, which I'd still prefer to disable for that reason.
« Last Edit: June 30, 2020, 10:49:55 PM by Freahk »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #82 on: June 30, 2020, 10:27:40 PM »
What is suggested would be a very, very substantial new feature, and would require extensive new memory structures to the extent that careful performance/memory consumption testing would be needed for very large games, as a great deal of new data would have to be stored in every road tile.

It is unlikely for it to be viable for me to work on such a feature before economic balancing has been achieved.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 239
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #83 on: June 30, 2020, 10:33:23 PM »
Players will often intend to temporarily disrupt a route and immediately restore it in-place. In these situations it It would be useful to have a system where players may promise to do this and are held accountable if they fail to do so. I have plenty of spare time at the moment and would be happy to work on such a system.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #84 on: June 30, 2020, 10:42:54 PM »
Players will often intend to temporarily disrupt a route and immediately restore it in-place. In these situations it It would be useful to have a system where players may promise to do this and are held accountable if they fail to do so. I have plenty of spare time at the moment and would be happy to work on such a system.

May I ask how you envisage that this would actually work and what being held accountable would entail in practice? This would have to be something robust and effective at preventing players from actually ever succeeding in disrupting routes for more than a very short period; it would not suffice to fine players, since many players have large sums of money; it would not suffice to impose some sort of time limit on temporary disruption, since players could repeatedly remove and replace the road so that it is only in place for a very short proportion of the time. It is difficult to imagine what could work effectively.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #85 on: June 30, 2020, 10:52:37 PM »
Is there a way to disable the current system entirely in simuconf?
Won't help me on Bridgewater, but will definitely help for future under-the-radar servers.

Offline Vladki

  • Devotee
  • *
  • Posts: 3338
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Oneway Twoway Road Patch for the Extended
« Reply #86 on: June 30, 2020, 10:55:47 PM »
Is there a way to disable the current system entirely in simuconf?
What I suspect is that there is a bug in the PROW check. As it often does not allow to break city road even if short diversion is available. Maybe if the check works as expected, it should be possible to effectively disable it by allowing quite long diversion.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #87 on: June 30, 2020, 11:01:56 PM »
Maybe if the check works as expected, it should be possible to effectively disable it by allowing quite long diversion.
That doesn't work and will cause quite long diversary route searches.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #88 on: June 30, 2020, 11:02:21 PM »
If I recall correctly, there is no setting for disabling public rights of way. If there is a bug, I should be grateful if somebody could upload a reliable reproduction case.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 239
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #89 on: June 30, 2020, 11:09:04 PM »
May I ask how you envisage that this would actually work and what being held accountable would entail in practice? This would have to be something robust and effective at preventing players from actually ever succeeding in disrupting routes for more than a very short period; it would not suffice to fine players, since many players have large sums of money; it would not suffice to impose some sort of time limit on temporary disruption, since players could repeatedly remove and replace the road so that it is only in place for a very short proportion of the time. It is difficult to imagine what could work effectively.
I don't have anything concrete in mind. I suppose that if there is enough interest to warrant implementing the feature, there will be enough interest to discuss its workings. One possible measure would be an increasing monthly fee for as long as the route is not restored. Even if players were to rebuild and destroy the route periodically to reset the fee, I can't see how this would be more desirable than simply rebuilding it once.

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #90 on: July 01, 2020, 08:45:53 AM »
Can you think of a workable alternative?
How about allowing a one-way traffic for public roads only if there is an alternative road?
That is, if it is not destructible, it rejects the player's request for one-way traffic.
In other words, if there is no other parallel road connecting in the city, one-way traffic will be refused.
At least the current unconditional ability to change all constraints is a big problem. Also, the player may unknowingly make one way when updating the road. To be honest, I think it's easier than accidentally pressing withdraw all. Because the person who builds the road with the shortcut key does not check the display written on the icon in most cases. (As I'm saying again and again, this design is really bad...) And the "s" on the street is easy for anyone to remember, moreover, it is a key that is easy to press as it is one of "WASD".
If you accidentally rewrite an alternative road as one-way, it won't cause much trouble. Without alternative roads, a major traffic disaster could occur.



Also display issues:
Talking about arrow thing, I pointed out the imprecise restrictions that are being imposed, but a display that clearly indicates that a player is impassable will make things more clear. For example mothbold road, tiles that are not allowed access.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #91 on: July 01, 2020, 10:09:31 AM »
Ranran's suggestion seems sensible, as there is already code for checking this. For the reasons given in my previous post, however, I do not think that a monetary disincentive as suggested by Freddy is sufficient.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #92 on: July 01, 2020, 11:00:28 AM »
I agree with Ranran, changing the oneway mode should use a mechanism to validate that there is a diversary route available.
This is essentially the idea of the above, though with a local point of view, using the existing (hard to understand) mechanism of diversary routes. It's still much better than generally disallowing such changes.

Although, the main issue is that there are many cases in which it is required to temporarily cut routes, and the rules to cut such routes are very restrictive, often forcing players to "temporarily" remove houses.
There are two possible solutions essentially different approaches to solve this:
1. Use much losser restrictions ensuring routes to not get cut or
2. Allow players to do such modifications without the need for temporary routes.

The first is described above, although I do still think it's a good idea to actually ensure what we want to ensure instead of using a quite local model that can always be circumvented, it is as mentioned a rather huge overhaul, though I do not think it requires extensive new memory structures, most of the data required is already available at some time and does only need to be remembered.

About the second, we had a brainstorming on the ingame chat yesterday. What came out is a mechnism to allow most conversions of ways in between plain way, bridge, tunnel (and elevated way) without temporarily cutting the route.

Freddy will have a more detailled post about this soon.
« Last Edit: July 01, 2020, 11:39:50 AM by Freahk »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19824
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #93 on: July 01, 2020, 11:26:52 AM »
One complexity with Ranran's suggestion that occurs to me is that, as soon as the diversionary route is confirmed, the diverted route is marked as a public right of way. This may or may not be desirable behaviour in this context, although it may well be better than the current behaviour.

I shall look forward to the details of the proposed amended system arising from the discussions yesterday.

Offline Freahk

  • Devotee
  • *
  • Posts: 1073
  • Languages: DE, EN
Re: Oneway Twoway Road Patch for the Extended
« Reply #94 on: July 01, 2020, 11:43:05 AM »
This may or may not be desirable behaviour in this context, although it may well be better than the current behaviour.
As long as players are always allowed to "downgrade" from oneway to twoway mode, I don't see an issue here.
Downgrading would then still keep both as PROW, but as there then is a diversary route, one of those can simply be removed.
Both directions of a motorway being PROW is actually what I would expect.

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #95 on: July 04, 2020, 06:38:52 AM »
I found an additional issue.
A tunnel porter can be created by pressing with ctrl key, but this feature conflicts with its behavior.
It is annoying because it opens the settings window meaninglessly every time you build it.

Offline Ranran

  • Devotee
  • *
  • Posts: 1007
  • Languages: ja
Re: Oneway Twoway Road Patch for the Extended
« Reply #96 on: Yesterday at 09:46:28 AM »
I found a further drawback of this feature.

One of the unkindness of this feature is that it doesn't consider road upgrades.


When you update the road, it will be overwritten with the newly set limit. So, it is necessary to set the original restriction again. It's like having to re-install signs and signals.
And, as I've explained so far, the arrows only give us a rough idea of what restrictions roads have. The restrictions that show double-headed arrows are likely to be overlooked. So you have to rely on your memory or click on each tile in advance to check the restriction.

I think we need a mode that doesn't overwrite the original settings.