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 (https://github.com/teamhimeh/simutrans/blob/ex-OTRP-distribute/documentation/ex-OTRP_information.md). ←日本語の情報はこちら
Downloadswindows: https://drive.google.com/open?id=1oC8cADnJmKOtxoRH47rlU9aaUnZ6gLvG (https://drive.google.com/open?id=1oC8cADnJmKOtxoRH47rlU9aaUnZ6gLvG)
mac: https://drive.google.com/open?id=1T19F_re1hnP8r-LSHJF07O6BCXww1b94 (https://drive.google.com/open?id=1T19F_re1hnP8r-LSHJF07O6BCXww1b94)
source to compile: https://github.com/teamhimeh/simutrans/tree/ex-OTRP-distribute (https://github.com/teamhimeh/simutrans/tree/ex-OTRP-distribute)
Also, misc.RibiArrow.pak is required. Please download from here. (https://drive.google.com/open?id=0B_rSte9xAhLDanhta1ZsSVcwdzg)
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 useSelect 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 (https://forum.simutrans.com/index.php/topic,18019.0.html).
Data CompatibilityYou 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 (https://github.com/teamhimeh/simutrans/tree/ex-OTRP)
ex-OTRP-distribute: https://github.com/teamhimeh/simutrans/tree/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. (https://forum.simutrans.com/index.php/topic,16659.0.html) 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.
Can I update the existing over-taking-mode status, without upgrading the existing road?
Quote from: Phystam on April 08, 2018, 03:13:07 PM
Can I update the existing over-taking-mode status, without upgrading the existing road?
Oh, this needs to be fixed.
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.
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.
I have made sure that way direction can be updated by overwriting.
Okay, I will try it!
Quote from: jamespetts on April 09, 2018, 10:26:25 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 (https://github.com/teamhimeh/simutrans/commit/4e2f30b721aa099e78c24a9245f2f4519acb0ebc).
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.
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?
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?
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.)
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.
Quote from: Phystam 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?
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?
Quote from: Phystam 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.)
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.
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.
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.
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 (https://github.com/teamhimeh/simutrans/commit/fa87cd655e732f57939725f1080ee5709864d8e5)
(I apologize for double posting.)
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!
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.)
Very good! It works on my savegame.
I will debug for the patch.
(https://simutrans-germany.com/files/upload/simscr141.png)
Excellent, that is very helpful, thank you. I will look into testing and integrating this when I get a moment.
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:
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.
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 (https://drive.google.com/open?id=0B_rSte9xAhLDanhta1ZsSVcwdzg).
QuoteIf 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,
simple_tool[37]=,:should be added to the menuconf of the pakset to activate the ribi arrow feature.
Now this commit (https://github.com/teamhimeh/simutrans/commit/fc6c03cacdeb832dc1d983f91862d60589c1247c) allows ex-OTRP to work without the ribi allow pak!
(already commited to both ex-OTRP and ex-OTRP-distribute branch.)
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?
I think the OTRP_Arrow.dat should be located in /gui/gui128 of simutrans-pak128.britain repository.
Has there been any progress since the last update?
I'm waiting for James to accept or point out some more issues.
Ah okay. Thanks for the info.
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.
I merged the latest master and solved all conflicts for both ex-OTRP and ex-OTRP-distribute branch. Please check my github repository ;)
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?
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 (https://www.youtube.com/watch?v=waShbKcFV3s)
Very best wishes for your trip to California - may you enjoy much interesting transport! And thank you for your work again on the feature.
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)?
Quote from: Matthew 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)?
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.
Quote from: jamespetts on June 01, 2018, 11:23:15 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!
Quote from: ACarlotti on June 02, 2018, 02:07:40 PM
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.
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.
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. (https://forum.simutrans.com/index.php/topic,18262.0.html)
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:
Quote from: prissi on March 27, 2018, 07:47:00 AM(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.
Quote from: TurfIt on October 15, 2017, 09:16:41 PMLogic 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:
// 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.
Quote from: TurfIt on October 15, 2017, 09:16:41 PMMaybe 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.
Quote from: TurfIt on October 15, 2017, 09:16:41 PMrefleshing. 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 (https://forum.simutrans.com/index.php/topic,16659.msg165492.html#msg165492)
Edit: Four paragraphs extracted to a new topic - see here (https://forum.simutrans.com/index.php/topic,18262.0.html).
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)
Thank you - I think that I have split this correctly (and edited your post to insert the links in the designated places).
Quote from: ACarlotti on June 06, 2018, 01:06:53 AM
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.
Quote from: ACarlotti on June 06, 2018, 01:06:53 AM
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.
Quote from: ACarlotti on June 06, 2018, 01:06:53 AM
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.
Quote from: ACarlotti on June 06, 2018, 01:06:53 AM
Quote from: TurfIt on October 15, 2017, 09:16:41 PM
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.
Quote from: jamespetts on June 02, 2018, 11:57:44 PM
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...
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.
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. (´・ω・｀)
(https://i.imgur.com/wR1f4At.gif)
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?
He meant the ":" key, not the comma.
Ahh - I misunderstood, my apologies. The : key appears to be free, so I have integrated this.
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.
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 (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...
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 (https://github.com/jamespetts/simutrans-extended/pull/91).
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 :(
Thank you for that. Can I ask which bug fixes have been ported to Extended?
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.
Splendid, thank you: now incorporated.
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 (https://twitter.com/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.
Quote from: THLeaderH on August 06, 2018, 10:54:01 AMAre 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.)
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.
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.
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?
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?
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.
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.
I think that you may have misunderstood the request: my apologies if this was not clear. I was referring to this (https://forum.simutrans.com/index.php/topic,18073.msg174345.html#msg174345) 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.
The bug fixes that I planned to post a PR are
https://github.com/teamhimeh/simutrans/commit/bfd5806f6cc3b4a955929fae403e8c9c051c0750 (https://github.com/teamhimeh/simutrans/commit/bfd5806f6cc3b4a955929fae403e8c9c051c0750)
https://github.com/teamhimeh/simutrans/commit/e7266465ada1cb33e7788c0a736f6ddcae85c527 (https://github.com/teamhimeh/simutrans/commit/e7266465ada1cb33e7788c0a736f6ddcae85c527)
https://github.com/teamhimeh/simutrans/commit/fb76da14392aeaf3e6fcb0147677d3741ee9a391 (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.
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.
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.
(https://simutrans-germany.com/files/upload/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88_2019-03-15_%E5%8D%88%E5%BE%8C11.03.47.png)
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.
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?
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.
Implementation of "intersection_t" is now needed, as A. Carlotti suggests. This class makes more simpler the code.
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.
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.
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.
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.
QuoteThis is a design choice.
The work of discovering that trap is a meaningless work created by an unfriendly design.
QuoteFor 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.
Quoteavoid 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 limitsQuote from: prissi on March 27, 2018, 07:47:00 AM
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.
QuoteSeparating 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".
(https://i.imgur.com/tcLvr5O.png)
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.
Quoteribi-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.
(https://i.imgur.com/AH0JfTP.png)
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.
Quote from: THLeaderH on June 13, 2020, 09:05:40 AMFor 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
Quote from: Vladki on June 18, 2020, 11:53:15 AMIf 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.
(https://i.imgur.com/YF3LVKg.png)
I think the spaced arrows aren't very good at checking connectivity. Also, arrows do not support slopes or diagonals.
Quote from: Vladki on June 18, 2020, 11:53:15 AMBTW: 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.
Quote from: Vladki on June 18, 2020, 11:53:15 AMThe 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)
Quote from: Ranran on June 18, 2020, 12:23:25 PMI 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:
I wanted to say that it is much less inferior to the one that has continuity because it lacks continuity. (´・ω・｀)
(https://i.imgur.com/ZxuQ1eL.png)
And the arrows arranged in a zigzag on the diagonal are strange and honestly speaking, I do not like it. ::(
(https://i.imgur.com/7G9l2Qb.png)
If you look only at this, it looks like it is not connected.
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.)
Quote from: Ranran on June 18, 2020, 12:49:16 PMIf 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.
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.
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.
Quote from: Ranran 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.
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.
Oh well, even more restrictions that will require killing many people.
Quote from: Freahk on June 30, 2020, 08:15:12 PM
Oh well, even more restrictions that will require killing many people.
Can you think of a workable alternative?
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.
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.
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.
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.
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.
Quote from: freddyhayward 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.
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.
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.
Quote from: Freahk on June 30, 2020, 10:52:37 PMIs 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.
Quote from: Vladki on June 30, 2020, 10:55:47 PMMaybe 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.
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.
Quote from: jamespetts on June 30, 2020, 10:42:54 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.
Quote from: jamespetts on June 30, 2020, 08:25:13 PMCan 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.
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.
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.
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.
Quote from: jamespetts on July 01, 2020, 11:26:52 AMThis 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.
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.
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.
I made a change to remove the arrow when it's not one way. (Pull request #212)
I would appreciate if you guys could tell your thoughts on this.
As for Vladki's point of view of road connectivity, I'm reaffirming that this isn't suitable for it.
I've run into a situation where the roads aren't connected on the server several times but it didn't help at all.
1) When zoomed out, the arrow can hardly recognize the direction. (This may have a bad arrow design. However, I think that it is not suitable if it wants to check "continuity" but is itself discontinuous. I mean, the arrow is not connected to the next tile.)
2) Arrows are hidden by buildings, bridges, tunnels and terrain.
EDIT:
I'm currently looking at these codes a bit. I won't fix it now because it's a tedious task, but I'll leave a small note.
You should pass player information to set_overtaking_mode(overtaking_mode_t o) to prevent others from changing the road restriction (and add the process of comparing the owner and the executor). Or judge before calling the function.
Note that this is in many places and there are five similar functions.
And when rewriting this, please also consider the case where you do not change it as in my previous post.
I made a display improvement change like I suggested before.
Please check this:
(https://i.imgur.com/76mpjWK.gif)
I would appreciate if you guys could tell your thoughts on this.
EDIT:
Additional note Further problem with Oneway Twoway Road Patch:
Please note that "overtake stationary only" works as "Overtaking prohibited" in places where there is not the bus stop.
So we need to reconsider this feature and its behavior and processing.
Much better than what we currently have :)
Some thoughts:
The colors are easy to see, but these are comletely unintuitive.
Wouldn't it be better to draw an icon on top?
Draw nothing in case of "Two way (default)" is fine.
Drawing the arrows in case of oneway is fine either, but might better be the oneway sign (https://cdn-01.media-brady.com/store/stuk/media/catalog/product/cache/3/image/85e4522595efc69f496374d01ef2bf13/1563981682/d/a/dal.image.26753_std.lang.all.gif).
Not exactly sure about Parallel stop mode, but it might be an adaption of the oneway sign.
Overtaking prohibited is an a real-world roadsign either, so we could use that sign (https://www.motsigns.co.uk/ekmps/shops/motsignscouk/images/1q-no-overtaking-sign-3022-p.jpg).
About "overtake stationary only" I'm not sure either.
About opposite lane driving I'm not sure if such a roadsign exists. It might simply be two arrows in opposite lanes direction.
It would be quite awesome if that layer highlighted dead ends in general. It is very hard to find unconnected ways, especially on slopes, as there does not exist a dead-end way graphic.
Yes, drawing nothing in default mode is good. One way mode too.
I do not like the colored background. We already use that for reservations and player ownership.
For the other modes, how about these:
parallel stop mode - show two parallel arrows
no overtaking - show solid centre line
overtaking only stopped vehicles - show dashed or dotted centre line
opposite lane, show red arrows in respective lane and direction.
dead end, show colored line at the tile border opposite the tile's exit
Thank you for your thoughts.
QuoteWouldn't it be better to draw an icon on top?
Draw nothing in case of "Two way (default)" is fine.
Drawing the arrows in case of oneway is fine either, but might better be the oneway sign.
As already pointed out, it is the same as the existing arrow design is bad.
I think that one of the factors that should be considered is the visibility when zoomed out.
The three-dimensional like drawing reduces the visibility during zoom out. Simple image is better than complex picture.
(https://i.imgur.com/xjkJ09t.png)
Quoteno overtaking - show solid centre line
overtaking only stopped vehicles - show dashed or dotted centre line
opposite lane, show red arrows in respective lane and direction.
dead end, show colored line at the tile border opposite the tile's exit
I think this kind of simple expression is better, but even then, the visibility when zoomed out may not be good and I think it still requires some work.
Coloring tiles is a minimal change that uses existing code. There are many priority issues that must be resolved for this feature...
Anyway, improved visibility will make it easier to find errors.
QuoteThe colors are easy to see, but these are comletely unintuitive.
Do you think the color of block reservation is intuitive? I think it's the same. Also, the idea of coloring tiles may be consistent throughout the game.
About color
1) Color that does not conflict with Block reservation
2) the constraint should be near red, otherwise blue or green
To judge from the image:
Yellow-green is similar to the station color and may have poor visibility.
Pink may be slightly hard to see. Could a darker color be better?
Please note that these two are basically used only for bus stops.
I don't know what inverted is for.
Bus stop restrictions are only required for bus stops. There is no reason to set this to anything other than a bus stop. It's just confusing. And, as explained above, stationary only means no overtaking on tiles other than bus stops. I think a lot of work is required to change this, such as rewriting set_overtaking_mode above.
Regarding the drawing of arrows, there is currently no prospect of what to do. However, as a temporary change, I think that measures such as making the shape simple and changing the color may be possible. It should be considered in conjunction with the tile constraint colors.
QuoteWe already use that for reservations and player ownership.
(https://i.imgur.com/zQuwm0R.png)
The problem is not so different in any way, and I think that tile coloring may be the best.
Finally I hope you understand that this is a simple fix. I'm not familiar with these codes so I may not be able to do any further.
I wondered if I could color the tiles with, for example, "no entry sign" or "mothbold", but it seemed complicated. Coloring in overtaking mode was easy.
Quote from: Ranran on July 16, 2020, 12:43:32 PMDo you think the color of block reservation is intuitive?
Yes, it's unintuitive either and on top of it does not show most important information of a directional reservation, which is it's direction.
I do think these should be highlighted in the same way as usual reservations but with an additional arrow to show the direction. That's another issue though.
Quote from: Ranran on July 16, 2020, 12:43:32 PMColoring tiles is a minimal change that uses existing code. There are many priority issues that must be resolved for this feature...
OK, if it makes things simpler, I'm fine with it. Much better than arrows everywhere.
Quote from: Freahk on July 16, 2020, 01:46:56 PMYes, it's unintuitive either and on top of it does not show most important information of a directional reservation, which is it's direction.
Certainly, I agree that a blue directional reservation needs a directional indicator.
But I don't think it is easy to display it properly and properly in the current system.
1) It is necessary to properly deal with zoom out.
2) It is necessary to deal with slopes and diagonals.
3) It is necessary to support different pakset sizes.
4) It is necessary to properly deal with intersections.
If we could create a system to draw it, it could be used on both roads and tracks.
Tips:If you find it difficult to see the road restrictions, try reducing the brightness in the display settings. The restrictions will be easier to see.
(https://i.imgur.com/4FJCK27.png)
Currently, the arrow won't light up, but it will be fixed as THLeaderH said he would fix it.
I think that blue is better for the one-way arrow (A little closer to light blue to avoid overlapping with block reservation). The one-way sign in Japan is also blue.
Therefore, I chose a tile color that is not close to it.
Thank you for your work on this: this is interesting. On one level, it looks better than the current system; on another level, however, it is not as obvious from the colours what system is in use as there is no pre-existing association between these colours and these behaviours.
Freakh's suggestions have some merit in this regard; I wonder what other people's views are on this?
Quote from: jamespetts on July 19, 2020, 10:36:51 AMhowever, it is not as obvious from the colours what system is in use as there is no pre-existing association between these colours and these behaviours.
There are some changes I haven't posted yet.
1) The color of the icon text changes depending on the mode
2) Arrows will be displayed in the preview of the construction plan in case of one-way mode
1) has already been pushed to the branch.
As for 2), it is not possible to handle correctly when using shortcut keys and when roads and bridges are separated at the moment, so it is necessary to deal with it. So I haven't pushed yet.
(https://i.imgur.com/GZVKiAp.gif)
Again an improvement, as there is an ingame association to the tool constructing the road, which is kind of on on-the-fly help page.
Still, I don't think those colors can easily be remembered (and there are already too many colors to remember in Simutrans elsewhere), so players will have to look them up. Either in the "real" hel page or by using the construction menu.
What matters more is what "H" and "L" represent. Normal players can't look it up. (you may get its hint from the code). And it is not related to the word displayed in the "set overtaking mode" menu. Therefore, it is more difficult to remember than to remember colors. (In a sense, the menu description is misleading.)
Also, as I have already explained, bus stop mode selection should not be here, so we plan to separate the list. That is more intuitive.
And I wonder if Overtake stationary only mode is necessary. As already mentioned, if this can be done for free, there is no reason not to set it at a bus stop on a two way road. It just forces the player to waste extra effort. It also works as an overtaking prohibition except on tiles with bus stops as I said above.
Road vehicles will automatically be able to overtake if you meet the conditions for overtaking at the busstop.
On the contrary, if this is not set, the bus stopped at the bus stop will not be overtaken. On ordinary roads, road vehicle can overtake if it meet the conditions at where not a bus stop, but unless player set it, it will be limited. Here is the ambiguity of the specification.
When overtaking is impossible at the bus stop, I think that overtaking is prohibited. So we can remove this nonsensical mode by disabling overtaking a stoping bus only if overtaking is set.
In that case, memorizing what the green tile and "L" represent is no longer necessary.
I may not have properly understood your request.
What you guys are saying is adding a symbol to the tool icon (and "set overtaking mode" menu)?
It's not too difficult. On the other hand, displaying symbols on the main game screen is just problematic as it is not possible to recognize the shape of the arrow when zoomed out.
Quote from: Ranran on July 19, 2020, 03:23:07 PMOn the other hand, displaying symbols on the main game screen is just problematic as it is not possible to recognize the shape of the arrow when zoomed out.
Use the same highlight color for all special road modes, so players will know "there is something special" even on high zoom levels.
Use icons to indicate the exact type of roads mode, so people can see the important information without searching the help pages.
Those icons might be hidden at high zoom levels if it turns out to be rather confusing than helpful on high zoom levels.
Instead of those letters, a mini version of these icons could be shown on the button.
Quote from: Freahk on July 19, 2020, 05:20:06 PMThose icons might be hidden at high zoom levels if it turns out to be rather confusing than helpful on high zoom levels.
As I have already explained, the reason such a method is not suitable is that it also depends on the size of the pakset. It also depends on the person who designed it. The small pakset is no longer visible after zooming a little. Large paksets may use a finer grained design to allow more design options. As a result, it is not always correct that a particular zoom becomes a boundary value.
And it must be a design that takes direction and
continuity into consideration. I can't think of such a design.
For example, consider that there are 10 tiles of the icon that means overtaking prohibited. There is no reason to do so unless it is a good design that is more visible and intuitive than colored tiles. It's very bad if it just displays the same icon in 10 tiles in a row. And if it's invisible when zoomed out all the way, I think colored tiles are better.
I'm afraid but what is the purpose of
inverted lane mode? ???
Quote from: Andyh on June 02, 2018, 10:56:54 PMI 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.
This question has been asked by Andyh before, but it seems that no answer is available.
This mode creates an unrealistic situation by ignoring the position of the bus door, ie the relationship with the bus stop. And if we don't have this mode, we can reduce the variation of colored tiles to two. It eliminates one of the incomprehensible colors that Freahk points out.
Next, another new issue:I noticed the following GUI display.
(https://i.imgur.com/8HcTUTt.png)
It is a check button of
"Left" "Right" at the bottom. ???
Quote from: THLeaderH on August 06, 2018, 10:54:01 AMThe 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.
I guess it is one of the features in this list (perhaps last one I guess) but currently at least this switch seems not working.
And this button can also be changed regardless of the owner. (´・ω・｀)
And that
1) the other features mentioned above don't seem to be implemented at least in the current extended (Looking at your previous answers, it's possible you're confusing that you implemented a feature that doesn't exist in extended.)
Quote from: THLeaderH on August 06, 2018, 10:54:01 AMAre these changes acceptable for simutrans extended?
2) You just made a suggestion to Extended but haven't responded afterwards
Thinking from these two, only the switch for the feature that was planned to be implemented I suspect that is mixed in with the GUI.
@THLeaderH - I would appreciate it if you could explain about these. :-[
In addition to the above, I think there are some omissions of explanation.
I was looking at the code and noticed that I could set the helpfile to Overtaking mode. The help file is not currently available in extended.
I do not speak English, but you can provide a help file.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/blob/fix-overtaking-patch-issues/simutrans/text/en/overtaking_mode_frame.txt
I generated a file that was almost empty. You guys can edit it. ;)
Quote2) Arrows will be displayed in the preview of the construction plan in case of one-way mode
I completed this work and pushed it to the branch.
Quote from: Ranran on July 19, 2020, 03:23:07 PMI wonder if Overtake stationary only mode is necessary.
I integrated some modes as suggested yesterday and removed
overtake stationary only mode.
Before:
| mode | can overtake at busstop | can overtake at road |
| Two way(default) | NO | YES |
| Overtake stationary only | YES | NO |
| Overtaking prohibited | NO | NO |
As already explained, there was a problem because
Overtake stationary only mode works as
Overtaking prohibited on tiles without a bus stop.
Therefore the
green tint of the tile is actually
orange. So we had to fix this somehow. So I changed it like this:
After:
| mode | can overtake at busstop | can overtake at road |
| Two way(default) | YES | YES |
| Overtaking prohibited | NO | NO |
This change reduces the coloring of the tile by one, reducing the need to remember colors.
I think that it will reduce the troublesome operation for the player, and the rules on the road will be simple and easy to understand.
Ideally, the ability to overtake at the bus stop is limited by the width of the road, the width of the car, the shape of the bus stop, etc. The width of the road and the cost of the bus stop affect the cost and can be linked to the economy. But I think it's a different story. I don't think there is an advantage to limiting if there is no such link to the economy. Therefore, it is better to be able to overtake by default because it does not force the player to bother.
However, it is important to note that convoy cannot overtake unless it meet multiple overtaking conditions. No oncoming convoy, no intersection near, no convoy at the overtaking point. So don't overestimate it. If there is an intersection nearby, it is the same as overtaking prohibited.
- Two-way mode does currently allow overtaking at bus stops, subject to the usual overtaking conditions.
- I don't think realism concerning road width and bus doors are relevant, because the road can be any arbitrary width, 125m in 128.britain.
- Overtaking conditions should be as simple and generous as possible, because of this limitation.
- I agree that overtake stationary only and inverted mode should be removed because they add unnecessary comlpexity.
Inverted lane can be useful in some cases to build special types of motorway exists, though, these cases are pretty rare and I can only remember once using it, so it might just be removed.
That "left" and"right" checkboxes are a feature of the so called lane affinity sign. It does not work for private cars at all, at least that's the information I got half a year ago or something like that.
In any case, the GUI is confusing, though I don't know how to improve it.
I agree with the changes to the overtaking modes.
Throwing myself into the discussion, I agree that it might actually be too complex and fiddly with the "overtake stationary" and "inverted lane" (Inverted lane means that the vehicles drive at the oposite side of the road than what they usually do). At least I have never come to use them, although I could imagine they could be usefull for some people.
Regarding coloring the road tiles, I do think that coloring the way has some merit. Highlighting objects with colors is something that is well established in Simutrans, so I think this could indeed be usefull in this case as well. The colors needs to be established somewhere, though, and I think just coloring the very tiny letter (which is easily oversighted) is not enough. I would suggest that you create a color square (like you have done in the factory window), so that the player is always looking at the colors when choosing which mode to build. I do not agree with the concerns that the coloring of ways would clash with the reservation coloring, as these two display modes should not be used at the same time! Already the color red is used in multiple modes (block reservations, schedule stops, factories), so this should be no problem IMO.
I agree with the problem of the directional modes. I read in the thread that it was compared to the directional reservation made by trains, but I dont think it is a fair comparasion: Directional reservations will always be the same direction throughout the entire blue field, and the direction can be seen by clicking on the tile. The overtaking mode, however, can have two tiles next to each other, with opposite directions, and this would be very cumbersome to check EVERY tile for its correct direction. Therefore I agree that there preferably should be *something* that tells us wether we have the correct orientation, and I do have a slight experimental suggestion which features only the colors and no icons:
The default color for oneway is, say, blue or yellow.
I dont know how way tiles with three and four directions are handled with the one way mode. Either the one way constraint affects only the entry of the tile, the exit of the tile, or both entry and exit. If the latter, it is pretty useless for three and four directional way tiles.
In either way, whenever two tiles with with the one way modes set, and the one way modes of the two tiles are incompatible, those two tiles are highlighted in red.
This way of displaying the tiles would not give you the direction of the one-way, however, this should be printed in the info window of the waytile. And with this approach, you are guaranteed that all blue (or yellow) waytiles connected to this tile, are also set in the correct direction.
If you find a red area of tiles, this means that something is messed up, and you will have to fix it. You would probably anyway resolve it by rebuild the entire stretch, instead of turning the direction of each individual wrong direction tile, hence the indidual directions are not really necesary.
Quote from: Ves on July 20, 2020, 10:50:44 PMThis way of displaying the tiles would not give you the direction of the one-way
Please no!
Don't do the same issue as was done with directional reservations. This requires ye another unneccessary click and due to the perspective of the map, it is not clear if for example right-up is north or east.
For sue an experienced player knows it's North, any anyone else could have a look on the minimap to know this, but why shouldn't we keep things intuitive if we can?
I do not see any problem with showing arrows in addition to colors (just as I don't see any issue with showing icons in addition to colors for any other mode)
For the letters and colors - just show them next to the check box like:
- - (T) two-way
- - (O) one-way
- - (H) halt/stop only overtaking
etc.
Color can be either only on the letter (T,O,H,...) or as background for the whole translated text
Thank you for your feedback. I have made some changes.
- Removed
inverted lane modeIf we still need it, you can restore it by reverting commit number 3d0c4a63a0c7205229756f6498388ab0ae2ee138.
- Prevented changing the overtaking mode of roads owned by other player
- Players cannot change the overtaking mode of a non-destructible public or without adequate diversionary routes road.
Previously, one-way signs had similar rules. However, THLeaderH added a specification that ignored that specification. First of all, the existing sign and overtaking modes exist independently, which is somewhat difficult. Now the change to One-way mode will be subject to the same rules as one-way sign placement.
(As a known issue resulting from this issue of my patch, the road arrow and one way sign are not currently linked correctly.)
I tried to display an error when setting the overtaking mode failed, but it was too annoying and the implementation is postponed. (´・ω・｀)
Quote from: Ranran on July 20, 2020, 12:07:15 PMNext, another new issue:
I noticed the following GUI display.
(https://i.imgur.com/8HcTUTt.png)
It is a check button of "Left" "Right" at the bottom. ???
I delved into the behavior of this. As I guessed, this is obviously an unfinished work and just a papier-mache.
The lane_affinity flag of the sign is only called in here (https://github.com/jamespetts/simutrans-extended/blob/707795d85a6a750d3d87d190d4e6c8e584fcb56e/vehicle/simvehicle.cc#L4393), there is no actual condition and there is only a comment.
// If there is one-way sign, calc lane_affinity. This should not be calculated in can_enter_tile().
if( roadsign_t* rs = gr->find<roadsign_t>() ) {
if( rs->get_desc()->is_single_way() ) {
if( cnv->calc_lane_affinity(rs->get_lane_affinity()) ) {
// write debug code here.
}
}
}
Some variables may be rewritten in calc_lane_affinity, but at least for the moment I haven't seen this working.
calc_lane_affinity() is also used here only, but I'm wondering if it's working properly.
From the commit history, it seems difficult to identify only the part related to this. So I'm not sure how much such a thing exists, but I would appreciate any comments on this.
About review of system design:
I suspect the intersection may not need restrictions and arrows. The display of the arrow and tile coloring at the intersection is somewhat incorrect.
Coloring the intersection has no meaning. Convoy can't stop there in parallel, and of course overtaking.
Quote- Two-way mode does currently allow overtaking at bus stops, subject to the usual overtaking conditions.
Then I can't understand why
Overtake stationary only existed. (´・ω・｀)
I think the features that players expect are the ones in "Road stop improvements" here (https://forum.simutrans.com/index.php/topic,8172.0.html).
At first I thought that the width of the road was wide enough to reproduce a bus stop with a side road.
Quote- I don't think realism concerning road width and bus doors are relevant, because the road can be any arbitrary width, 125m in 128.britain.
Yes, lining up two roads means occupying 250m, destroying a large number of houses, driving out residents, and occupying the city.
Regarding door issues, I just wanted to know if inverted mode makes sense.
Quote- Overtaking conditions should be as simple and generous as possible, because of this limitation.
I agree. It is very unrealistic to be able to overtake unless there are only two cars on a few tiles, a few hundred meters oncoming cars, and only a few hundred meters. There is a horse running in the opposite direction 375m ahead, then we cannot overtake the slow horse in front. So I think the current overtaking constraint is too strict even on intercity roads. Especially in the age of carriages. There are many intersections in the city and it is almost impossible to overtaking. And as mentioned above, a four-lane road requires a great deal of sacrifice.
QuoteThe colors needs to be established somewhere, though, and I think just coloring the very tiny letter (which is easily oversighted) is not enough. I would suggest that you create a color square (like you have done in the factory window), so that the player is always looking at the colors when choosing which mode to build.
QuoteFor the letters and colors - just show them next to the check box like:
the very tiny letter (which is easily oversighted) is not enough - yes. It's just better than nothing. I don't like the one-letter English display. It is hard to understand the meaning. As I said before, it's not good for Japanese people, it's not universal design. (I think there are many such languages, Simutrans supports multiple languages...)
As I have already pointed out, there is a flaw in that when you select it in shortcut mode it is not visible. So displaying colored boxes there is likewise pointless. Therefore, the display is for associating the color with the display and is not always displayed and is not important. However the current characters aren't good, so I think it's a good idea to replace them with something other than characters. It may be good to have a dedicated symbol.
So I suggested showing it in preview or
cursor. I have successfully added only the preview arrow.
Unfortunately, there are currently no prospects for anything else. Coloring the tiles in the preview messes up the preview because its looks is hard to see.
Displaying symbols is a burden for pakset authors. Note that the tile
cursor size depends on the pakset size. Note that the symbol for GUI is not available on the cursor or main game screen. It is best for the GUI to be close to the character size. The appropriate size of the main game screen changes depending on the zoom ratio. The tile has a width of 256px at 256size.
I think parallel stop mode can be abolished from this list because it is a bus stop mode only. It works as a one-way street only for tiles other than bus stops. So it can be moved to the bus stop icon. In that case, the mode is reduced to three - default/one way/overtaking prohibited. Then, all we need is to solve the overtaking prohibited mode display issue.
In that case, preparing a overtaking prohibited
cursor may not be so difficult. For example, in Japan, the sign of overtaking prohibited is like this.
(https://i.imgur.com/x4aToMv.png)
I'm sure most countries have something similar. So we add one such picture to this. (https://raw.githubusercontent.com/jamespetts/simutrans-pak128.britain/master/gui/gui128/ls-cursors.png)
Also note that it is necessary to add a mode other than the above three that does not overwrite the mode. When laying a new one, lay it in two ways. This should be the default.
QuoteI do not agree with the concerns that the coloring of ways would clash with the reservation coloring, as these two display modes should not be used at the same time! Already the color red is used in multiple modes (block reservations, schedule stops, factories), so this should be no problem IMO.
At least red should not be used. Because it's used in the schedule as you point out.
(https://i.imgur.com/mh1Fj2W.png)
I believe competing for it only creates a problem and has no advantage.
I often check this red display to see where the bus line is set to use on the bus terminal. When checking it, it is more convenient to be able to check at the same time what restrictions are set on the bus terminal.
QuoteTherefore I agree that there preferably should be *something* that tells us wether we have the correct orientation, and I do have a slight experimental suggestion which features only the colors and no icons:
I think you may be misunderstanding my opinion. I don't recommend erasing arrows from directional ones.
However, as already pointed out some issues, there are issues with the existing arrows, also does not match the somewhat new spec, so I am considering redesign. I'll post about this later.
Quote from: Ranran on July 21, 2020, 04:09:07 PMAlso note that it is necessary to add a mode other than the above three that does not overwrite the mode. When laying a new one, lay it in two ways. This should be the default.
I added this feature and pushed it to my branch.
Currently this mode is labeled "default". We need to modify it to a proper expression together with "two way (default)".
That is, "two way (default)" is no longer default. The default value for road laying is two way, but overwrite mode is not the default.
The "two way (default)" designation in the mode select window looks strange and dishonest.
I would appreciate any feedback on this.
Wouldn't it make more sense to select the construction mode "override" or "retain" independantly of the road mode?
In principle it could be useful with any of the road lane modes.
In fact, I wouldn't expect the construction of new roads to change the mode, except if I am force-building.
That means, it might be an option to couple this behavior to ctrl-build.
Quote from: Ranran on July 21, 2020, 04:09:07 PMI'm sure most countries have something similar. So we add one such picture to this.
Quote from: Freahk on July 15, 2020, 03:51:19 PMOvertaking prohibited is an a real-world roadsign either, so we could use that sign (https://www.motsigns.co.uk/ekmps/shops/motsignscouk/images/1q-no-overtaking-sign-3022-p.jpg).
That's the UK version of it, which is roughly the same all over Europe.
Thank you for all your work on this: this is very helpful. I agree with removing the inverted lane mode - there is only one road in the UK where driving on the right is the standard, and that is the very short road forming the entrance to the Savoy Hotel in London. I do not think that we need to replicate this in Simutrans-Extended. The removal of the overtaking stationary only mode is also sensible as it is not clear what problem that this solved.
The fixes to prevent players altering the one way status on other players' roads are definitely helpful - thank you for these.
As to the UI, it is definitely better to have the arrows displayed only on one way roads: this is much clearer, and makes one way roads much easier to find. It is also helpful to use the pink and orange to demarcate the special settings of parallel stop mode and overtaking prohibited mode. It would further be helpful to have the suggested icon in use here at the cursor (and possibly on the road itself over the orange) to designate that overtaking is prohibited.
One thing that I notice that will need to be changed is that there are two separate entries for the two way mode: one marked as "Two way (default)" and the other marked as "default". It is not clear why this should be and I suggest simply removing "default".
I am also not a fan of the letter, although the letter with a colour is better than the letter without a colour. Ideally, one would have a symbol (1) on the cursor; (2) in the set overtaking mode menu; (3) on the individual road tiles when the overtaking mode overlay is enabled ; and (4) on the active road icon for each type of mode bar the default two way mode, for but I can understand if this is too much work. Because these symbols would be cross-referenced to text describing their meaning in the only place where one can invoke the display of this symbol on one's own roads, there should be no danger of players coming across this symbol and not understanding what it is.
As to the actual mechanics for overtaking, it would be better to separate the discussion of that from the discussion of the UI, or else it will be very hard to follow the thread. I wonder whether we should separate the UI discussion into its own thread?
As to directional reservations on railways, it would certainly be a nice feature to have arrows in addition to the blue colouring, but I do not consider this as a priority at present as it is less important for players to know the current directional reservation of railway track than to know the permanent setting of a one way road, as the former is automated whereas the latter is player controlled.
In any event, thank you very much for your work on this, Ranran - it is much appreciated.
QuoteOne thing that I notice that will need to be changed is that there are two separate entries for the two way mode: one marked as "Two way (default)" and the other marked as "default". It is not clear why this should be and I suggest simply removing "default".
The reason for adding this is as described in above post.
Quote from: Ranran on July 10, 2020, 09:46:28 AMOne 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.
Quote from: Ranran on July 22, 2020, 01:33:44 AM
Quote from: Ranran on July 21, 2020, 04:09:07 PMAlso note that it is necessary to add a mode other than the above three that does not overwrite the mode. When laying a new one, lay it in two ways. This should be the default.
I added this feature and pushed it to my branch.
Currently this mode is labeled "default". We need to modify it to a proper expression together with "two way (default)".
That is, "two way (default)" is no longer default. The default value for road laying is two way, but overwrite mode is not the default.
"default" is a temporary name. It needs to be changed. In this mode, settings are not actually overwritten. It is troublesome to set the mode again when upgrading the road. This mode is selected by default, and if you are laying a new road, it will be laid in two way mode. Select an existing two way mode if you want to overwrite the road with two ways.
Quote from: Freahk on July 22, 2020, 02:46:24 AM"override" or "retain"
Freahk made the above suggestion about this mode name.
Ahh, I understand - the name "default" was misleading. I suggest a different type of control for this, since it does something different to the others. What we want is a control that keeps whatever is the existing one-way mode when upgrading, but uses whatever of the others is selected for new roads. The name of this additional control should be "do not change the mode for existing ways".
Fixed the mode name as suggested by James.
I think this solves some of the many problems. I'm going to break fixing work. All other changes are complex and time consuming. As mentioned above, the size of symbols/icons is different for GUI and cursor, one is scalable.
Treatment of non-functioning GUI and code-There are many unknowns without waiting for THLeaderH's reply.
I hope that those who want to solve other problems can solve them.
Excellent, thank you very much. Now incorporated.
I like the patch, but it was very bad timing to combine it with the restriction to change the overtaking mode of existing ways.
The patch caused or pointed out many places where the mode is set wrongly and we cannot fix those places, because of the new restriction.
I'd kindly ask to remove that restriction, at least for some time, so those places can be fixed.
Another thing I'd like to mention is that the diversionary tiles should be increased pretty much, otherwise cut-and-cover constructions will be effectively impossible, but I guess that's not related to this patch.
May I ask for more detail as to the issue as to the problem with the overtaking mode on existing ways? Is this in the Stephenson-Seimens server?
No, it's in Bridgewater.
There are non default road modes in many places where these do not belong.
For example, in Telbourne there is a oneway road bridge that should be twoway, in Fleckwater at the dock, there had been a mistaken "Parallel stop mode" road tile, which caused "no route" to all vehicles using the staging inn and the only way to fix this involved killing the inhabitants of the houses at the coast.
Independantly of this, the lack to remove most PROW ways will now cause the need to kill many further people.
I would really appreciate a much higher max diversion value until a better solution is implemented.
It will still ensure its key purpose, which is ensuring that players do not cut the connection between two towns.
Edit: The inability to update the mode of roads will cause significiant issues with the automatic road connection feature of industries!
New industries will simply destroy motorways and players won't be able to fix it.
Please undo this restriction until we have a proper solution for those two major issues. I cannot imagine anyone will be interessted in maintaining motorways in the future under these circumstances. Well, at least I am not.
The problem is that there are equally bad consequences to removing the restriction, as players can then block public rights of way. As to motorways, these are generally not public rights of way; do these end up being taken over by industries and converted to public rights of way? If so, this is an exceedingly complex issue, and no simple solution is likely to make things any better overall.
Trying this out, I have noticed that road connections are not built at all with a new industry, so this is not an issue anyway.
Though, I am wondering why that was disabled?
Checking stephenson-Siemens, where player roads were obstructed by industry generation in the past, the afected stretches of road had been converted to PROW with roads mode being changed to bidirectional.
We had fixed this as it was still posible, but with the new restrictions, we will effectively get broken motorways that nobody can fix anymore.
The likely easiest soltion to this is using the "keep mode for existing ways" when building those automatic roads to prevent the AI from being obstructive.
This might lead to situations where the newly built road cannot be used on stretches, but this can be fixed by players whilst the former cannot be fixed.
Alternatively, I guess it's the better solution, disallow the AI to connect to anything other than "Two way (default)".
The "please provide an adequate diversary route" issue can be fixed by simply setting the max diversion tiles to a higher number. It will then still protect connections in between towns from being cut entirely.
That's an interims solution, though until there is a proper solution adjust existing roads without cutting them.
The situation as-is prevents players from being obstructive, which they usually are not anyway, whilst adding automatic very obstroctive behavior to the program code.
That is really a much worse experience imho.
I am afraid that I cannot reproduce the failure of newly built industries to build roads. I should be grateful if you could post a new thread with a reliable reproduction case of this error, as this is a separate thing to the matters discussed on this thread. Thank you.
I'm afraid I can't.
All i did was creating a new game with one city and placing new industries using the "increase industry density button". New industries spawned, but they were not connected.
So I loaded a stephenson-siemens save and did the same with the same results.
I did nothing special, so if it works for you, I have no idea what's going on.
I am afraid that I have not been able to reproduce this: virtually all of the industries that spawned when I tested this were in towns and immediately adjacent to existing roads. The one occasion when an industry out of town spawned triggered a crash in unrelated code which I believe that I have now fixed, but I have been unable to test this since no industries other than those in towns and connected immediately to existing roads have been spawned since the first test run.
When I tested with a freshly generated map in 1750, however, new industries routinely appeared outside towns and were connected automatically by road. That was how I tested the change of preserving the one way mode of underlying ways as now implemented.
Quote from: jamespetts on July 29, 2020, 02:40:23 PMThe problem is that there are equally bad consequences to removing the restriction
These consequences are not equally bad: without, players had the ability to obstruct others, but almost never chose to use it, and could be easily reverted. Now, anomalies are frequently obstructing players, and players cannot do anything about it. The latter is far worse.
The restriction introduced is highly flawed: it uses the existing public right of way system that checks whether a road could be deleted. It does not check whether the route would be altered more than the acceptable diversion length, nor whether it would be altered at all. This creates a perverse situation where improving a route by changing one-way roads to two-way is prohibited.
I am experiencing guaranteed desyncs on bridgewater-brunel after a vehicle departs through a road after its overtaking mode has been changed since this patch.
I also observed probably the same desync issue on my server. When I change overtaking mode (using public player), desync occurs after a while. Re-joining after the desync, the overwritten overtaking mode has not been applied.
I think some points are incorrect. Many
"illegal" one ways can be removed with one way. It has a problem with intersection handling, but this is a problem with the original patch.
So in this example, the intersection is eliminated first.
(https://i.imgur.com/5GJ9nvv.gif)
You may find that there are unnatural one ways here and there. But it may be working like a two way. That too is an original issue.
And, as I have already pointed out, the arrow design is flawed.
1) You can remove the arrow from the one way tile in some case.
It is possible to create many examples where the arrow is not displayed on the tile even though it is one way.
2) I don't know if the arrow is two or one
For example, something like this could be created before my patch. My patch just made it easier to identify.
(https://i.imgur.com/17xBYQe.png)
This means that it is virtually impossible to enter this intersection. But so far this was recognized as a 2-way display.
The way it should be is that the two arrows pointing to the two lanes face outward.
The opposite - you can also remove the arrow from the intersection.
This suggests that it may be better to color the tiles, even the usual one way. (At least until the arrow becomes sane)
And note that the problems that are currently pointed out to have created the situation by ignoring the limits in most cases with loose limits. I wonder if we can create the same situation again.
In other words, in order to create a new one way that cannot return one way to two, it may not be easy to create under the current specifications. But at least there are big problems at intersections.
I'm in favor of being able to turn one way back into two ways. In that case, the owner's check is sufficient.
QuoteRe-joining after the desync, the overwritten overtaking mode has not been applied.
I think this is a big clue, but I'm not sure.
I figured out exactly why: you put the player checking logic in strasse_t, a class that does not and should not know which player is trying to edit it - this logic should be handled by way_builder_t which has access to player_builder. You used welt->get_active_player(), which returns a different result for every client, leading to desync.
edit: I hope I didn't project a harsh tone. It is not your fault for being tangled in the existing spaghetti code.
In relation to the restriction, I had stated in a different thread (it is rather difficult to manage when the same issue is discussed in multiple threads) that I have now prevented roads built by industries from altering the underlying overtaking mode, which should deal with those concerns.
The new display of overtaking modes is excellent. I found quite some places with unexpected overtaking restrictions. Thank you very much.
EDIT: but it seems that after changing a city (public) road to two-way (from one-way) causes desync. Not immediate though. After reconnect the one-way mode is as it was before change.
It seems to be related to public player and public right of way roads. Modifying players own roads does not desync.
EDIT2: PROW does not affect it. But public player modifying private road causes desync too. If the owner does it, no desync happens.
I believe that I have now fixed the loss of network synchronisation - thanks to Freddy for identifying the cause of this.
Quote from: jamespetts on July 30, 2020, 03:15:15 PM
I believe that I have now fixed the loss of network synchronisation - thanks to Freddy for identifying the cause of this.
Looking at the code, your fix should work, but I am worried that the spread of player logic into classes and files where it had not previously existed will make future synchronisation issues harder to identify. It would be much better to handle this in wegbauer.cc, which was designed for such logic.
This causes a segfault when the player parameter is passed as NULL by cities. An interim fix would be to add more if(player) checks. I still think it would be better to move the logic elsewhere.
the segfault happens very often on my server... Overwriting overtaking mode by cityroad (by NULL player) is one of the causes, as freddy reported.
Quote from: Phystam on August 01, 2020, 10:03:58 AM
the segfault happens very often on my server... Overwriting overtaking mode by cityroad (by NULL player) is one of the causes, as freddy reported.
In your case I would certainly recommend reverting the server and clients back to 26a357. It will still cause desync issues when modifying overtaking modes, but that is better than crashing.
Thank you for the report - I believe that I have now fixed the crashes. I should be grateful if people could re-test with the next nightly build.
Quote from: jamespetts on August 01, 2020, 11:15:39 AM
Thank you for the report - I believe that I have now fixed the crashes. I should be grateful if people could re-test with the next nightly build.
Your fix seems to have worked - running the bridgewater-brunel save offline has gone without crashes for a long time. edit, nearly forgot: thank you!
Splendid!!!
As I've already explained, there is a case where the arrow is not displayed in the usual one way now, so I changed it to blue for this measure.
(https://i.imgur.com/qquckyF.png)
Please check pull request #229.
Soes that mean the arrows are not displayed at all anymore?
The missing arrow is the original defect in the Oneway Twoway Road Patch for the Extended.
That is why the one way tiles need to be colored blue.
Players can have difficulty recognizing what is happening due to invisible arrows, but this coloring allows player to notice defects in the system.
I've tested pak192.comic and found it to cause a crash due to missing ribi arrow so I fixed it. It brought by my fix patch - I apologize.
Thank you for this fix - now incorporated.
Quote from: THLeaderH on July 07, 2018, 12:06:52 AMThis 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.
I think I found a bug that originated from this patch. Check the thread below.
https://forum.simutrans.com/index.php/topic,21630.msg200360/topicseen.html#msg200360
As I pointed out earlier, there seems to be a lot of nonsensical buttons and code that doesn't work. Note that I'm not sure if this button is what turfit pointed out earlier, but the button has been removed anyway, but the code for its behavior has not been removed.
What I recently noticed is that bool prev_based doesn't seem to be used.