News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

One-way Two-lane road Fun Patch

Started by THLeaderH, February 06, 2017, 02:04:26 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Andyh

Have there been any developments as to this patch?  Would be a huge disappointment if this could not be implemented.  The patch worked great in test; is it not essentially ready for integration?  What else still needs to be done?

killwater


THLeaderH

The development still continues but it's speed is quite slow since I'm so busy now. The latest commits can be always seen in https://github.com/teamhimeh/simutrans/tree/OTRP.
In a functional perspective, OTRP reached its completion in ver9. However, there is still a lot of issues to be integrated.

  • Only overtake_wt wayobj should change overtaking_mode.
  • The name of variables should be fixed as mentioned before.
  • Confirmation that this patch doesn't have any bad effects on performance and stability is required. Without that, the dev team won't do the integration.
I'd be very glad if you carry out the performance and stability test! Prepare a large map and put a lot of vehicles. Compare the performance and stability between the patch and the standard under the appropriate condition. And report here. The test should be done with gdb if you can, and please submit the error log of gdb when this patch crashes. Telling me the method to cause any crashes is also very welcome. With your cooperation, the integration of this patch may come earlier ;)

killwater

Could it be integrated into Extended nightly builds? I think there are quite a few people playing fresh commits at any time so that would be best way to test it.

jamespetts

Quote from: killwater on May 27, 2017, 08:08:45 AM
Could it be integrated into Extended nightly builds? I think there are quite a few people playing fresh commits at any time so that would be best way to test it.

THLeaderH is more than welcome to try to integrate it into Extended, but, since the codebases diverge somewhat, there may be significant numbers of merge conflicts (which I do not currently have time to resolve as this is not a priority compared to other things on which I am working, but THLeaderH might or might not be inclined to try if he would like this to be integrated into Extended sooner rather than later). It would have to be tested on its own branch of Extended to see that it works and does not cause crashes, anomalous behaviour or network desyncs in multi-player mode before being integrated into the master branch, although this preliminary testing need not be exhaustive as players using the feature might be left to find the less critical, more obscure bugs.

I should note, however, that, if this were to be a feature primarily on Extended, my own preference is for the property of a one way road being a property of the way rather than a separate way object: that would make it far easier for players to use (no need to drag a separate tool on the way to make it one way), far easier for players to understand (why should one have to drag a separate thing which has no physical presence over a road to make it one way?), and easier to balance (a motorway would then not be able to be used in single carriageway format as is possible now, thus restricting single carriageway roads to a lower speed limit). It would also prevent the somewhat absurd restriction of not being able to have trolley wires or tram wires on one way roads.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

Quote from: jamespetts on May 27, 2017, 11:56:30 AM
my own preference is for the property of a one way road being a property of the way rather than a separate way object

How feasable would it be for the property to be part of the way, but saved on each tile, much like speed limit. Therefore, a way could come with it's own property, but it could be changed with seperate tools (much like citys can change the speed limit) - I know I suggested that before, but I did not get any feedback on whether that's even possible.

Andyh

I've nothing against the one way flag being attached to a way object, but if it's strictly an either/or I would favor attaching it to the way for the reasons given by jamespetts

Ters

I must say I've lost track of what is being implemented, as well as the pros and cons of the various suggested approaches.

An_dz

On ways

Pros:
  • Less objects for the engine to take care of
    might give better performance and/or cause less problems
  • User can build one-way roads right away
    no need to later add the one-way wayboj

Cons:
  • User is restricted on which roads are one-way
    only those the pakset offers or the user creates - bad for closed source objects or those who don't like to fiddle with maekobj
  • Multiple duplicated tools
    if the pakset wants to offer one road both as one-way and two-way it has to duplicate the road, the tunnel, the bridge and the elevated road
  • More images loaded/duplicated
    because of the above

On wayobjs

Pros:
  • All roads can be made one-way
    one wayobj and it changes all and any roads
  • Less images loaded/duplicated
    because of the above
  • Wayobjs can be dragged across a whole road no matter if there are bridges, elevated ways or tunnels along it
    allows to change the one-way flag with a single tool

Cons:
  • More objects in a single tile
    can reduce performance and/or cause problems or be against some programming ideal
  • User needs to place another object after building the road
    the user needs to build the wayobj to transform the road as one-way after it has been built

Anyway, last time I tried this I ended up in some problems, This was one of them. The others was in case I've built a one-way road but allowed cars entrance from both sides, cars could get stuck. They could also get stuck if I made part of a road become "British lane" and cars came from both sides, it would work for a while, cars would change lanes and move nicely, but eventually they would get stuck as well.

THLeaderH

I think both way and overtake_wt wayobj should be able to have overtaking_mode. If overtake_wt wayobj exists, simutrans uses the flag of wayobj. Without wayobj, it uses the flag of way. Wayobj has priority. This enables user to build one-way roads without adding one-way wayobj. Also, overtaking_mode of all roads can be easily changed by building overtake_wt wayobj. The pakset does not have to offer duplicated roads.

However, there is one problem. When simutrans cannot find required the way add-ons while loading a saved game, it uses default roads defined in simuconf.tab. If ways has the one-way flag, we have to set default roads for all kinds of overtaking_mode to replace missing roads correctly. I cannot find the solution for this problem. ??? Should I abolish the one way flag of way to solve this issue? Or should I ignore the overtaking_mode flag when replacing the missing roads?

QuoteAnyway, last time I tried this I ended up in some problems, This was one of them. The others was in case I've built a one-way road but allowed cars entrance from both sides, cars could get stuck. They could also get stuck if I made part of a road become "British lane" and cars came from both sides, it would work for a while, cars would change lanes and move nicely, but eventually they would get stuck as well.
I have to deal with these issues later. In fact, one way flags ought to restrict the direction but this requires some modifications on wayobj.

jamespetts

Quote from: THLeaderH on May 30, 2017, 09:14:41 AM
I think both way and overtake_wt wayobj should be able to have overtaking_mode. If overtake_wt wayobj exists, simutrans uses the flag of wayobj. Without wayobj, it uses the flag of way. Wayobj has priority. This enables user to build one-way roads without adding one-way wayobj. Also, overtaking_mode of all roads can be easily changed by building overtake_wt wayobj. The pakset does not have to offer duplicated roads.

This seems to be a sensible solution, which would allow pakset authors and/or users to define their preferred behaviour.

QuoteHowever, there is one problem. When simutrans cannot find required the way add-ons while loading a saved game, it uses default roads defined in simuconf.tab. If ways has the one-way flag, we have to set default roads for all kinds of overtaking_mode to replace missing roads correctly. I cannot find the solution for this problem. ??? Should I abolish the one way flag of way to solve this issue? Or should I ignore the overtaking_mode flag when replacing the missing roads?

I suggest as follows: if a specific way with the one way flag cannot be found when loading a saved game, the game should try to find another way with a one way flag. If it cannot find any way with a one way flag at all, it should look for any way, even without a one way flag defined. If players try to load a saved game in which one way roads have been defined with a pakset that does not support one way roads, it is not unreasonable to expect that the one way roads will not work as such.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

THLeaderH

Here is a new release of One-way Two-lane fun patch, OTRP ver10.
This time, the patch file and the executable binaries are simutrans nightly r8250 based, and the patch can be easily integrated to the nightly trunk.
Source code can be seen on git. https://github.com/teamhimeh/simutrans/tree/OTRP

patch:https://drive.google.com/open?id=0B_rSte9xAhLDNUE4OUxZcHd2TU0
~Executable Files~
:simutrans:
win:https://drive.google.com/open?id=0B_rSte9xAhLDUGp4X1Rvc0ptVlk
mac:https://drive.google.com/open?id=0B_rSte9xAhLDVmIzcGpraWNIakU
:makeobj: (new version!)
win:https://drive.google.com/open?id=0B_rSte9xAhLDX1pfT1gtSWFRQW8
mac:https://drive.google.com/open?id=0B_rSte9xAhLDT1p2a3NhSjB6dzQ

This version is the first step to the integration. OTRP reached its functional completion in v9, but it has various problems for the integration. Ver.10 has the improvements.

  • Variables naming problem: overtaking_info is renamed overtaking_mode.
  • The overtaking_mode in ways was abolished. Ways no longer have overtaking_mode. Only wayobjs of overtake_wt define overtaking_mode. Wayobjs of any_wt is no longer used for that. Overtake_wt is the waytype which is specially defined for overtaking_mode and can be used only in wayobj.
  • Rewriting the code using enum is in progress. The enum is declared in simtypes.h. This makes the code more readable.

Here is a sample dat of overtake_wt wayobj below.

obj=way-object
copyright=THLeaderH
name=ot_oneway
waytype=overtaking_mode
own_waytype=road
overtaking_mode=oneway
cost=0
maintenance=0
intro_year=1930
intro_month=1
retire_year=3000
retire_month=12
# Image definition code below...


The value of "overtaking_mode" can be

  • oneway
  • twoway
  • loading_convoy_only
  • prohibited
  • passing_lane_only
If this parameter is omitted, "twoway" is automatically applied.

To use wayobjs of overtake_wt, you need to add
toolbar[6][12]=wayobjs(9) #Adding wayobjs of overtake_wt
toolbar[6][13]=general_tool[33],,o,9 "Adding remover

in the menuconf.tab of the pakset.

This version cannot load sve data of OTRP v9. Sve data of original simutrans can be loaded.
An_dz changed SIM_SAVE_MINOR to 5 but I returned it to 6. Many rdwr methods use SIM_SAVE_MINOR and we have to care for those when we change SIM_SAVE_MINOR to avoid problems. I set SIM_SAVE_MINOR 6 so that OTRP can load sve data of original simutrans.

There are still some tasks for the integration.

  • Renaming of variables. "lane_fix" have to be changed into a nice name.
  • The bug which An_dz reported here
  • Rewriting numbers of overtaking_mode to enum is still in progress. I haven't done that in simvehicle.cc, simconvoi.cc, and simroadtraffic.cc yet.
  • Hajo name corruption. I don't know why this occures, but maybe, Atom, an editor I'm using for coding, does some harmful things.
  • Getting overtaking_mode have to be done with less calculation. Ways should store overtaking_mode internally, not searching overtake_wt wayobj every time.

Any bug reports and ideas for improvement are welcome!

sheldon_cooper

Hello! I'm not used to these code nomenclatures, can you tell me what is '' overtaking_mode ''?
And '' any_wt ''? And "simtypes"? (Remembering that I use google translate, and some words can be obvious more sometimes, google translates wrong)
And what does that version change in the game on the move?
Thanks for the update! :)

jamespetts

I thought that you had written that both ways and wayobjs should have overtaking modes?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

THLeaderH

QuoteI thought that you had written that both ways and wayobjs should have overtaking modes?
Yes. However, if ways have overtaking_mode, we have to consider overtaking_mode when we replace missing ways. I haven't come up with a good algorithm, so I decided to abolish overtaking_mode of ways. If overtaking_mode with ways is required for the integration, we can implement it with a method which makes up missing paks with ways which have appropriate overtaking_mode.

jamespetts

That is an interesting idea - it does seem worthwhile. It would be silly if one could not have one way roads with trolley wires, for instance, or for players to have to drag twice for each section of motorway.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

THLeaderH

Abolition of the flags of ways is just because of a technical reason. Ideally, both ways and wayobjs should have overtaking_mode.

Quotewhat is '' overtaking_mode ''?
OTRP supports 5 conditions for overtaking. Overtaking_mode is the parameter that defines which condition is imposed.

Quoteany_wt?
any_wt means decoration_way. In ver9, I used decoration_way as a marker of overtaking_mode, but this should be used only for decoration purpose. So I stopped using this way type for overtaking_mode.

Quotesimtypes?
It's a source file which defines various constants, simtypes.h. Enum of overtaking_mode is declared in this file.

sheldon_cooper

thank you! :)

I have a problem, when I try to run Sim.exe, and open the game, gives this error. What can it be?

jamespetts

This usually means that you have an incompatible settings.xml file. If you delete this and try to run the game again, it should work, although you will lose your preferences (e.g. whether you had disabled MIDI, etc.).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

An_dz

I have one question, why one-way is zero and two-way is one?

THLeaderH

It's just for compatibility. In previous versions of OTRP, I used number 0 for oneway_mode, and 1 for twoway_mode. I haven't finished rewriting of overtaking_mode yet. So, I used these numbers so that the current code works.

An_dz

I developed a new approach to using the overtaking functions, instead of creating new objects, cluttering the UI and making things harder to the user (ways with different overtaking and wayobjs possibly changing them).

First I moved all overtaking flags inside the way itself (the weg class), every way always have this flag just like the other flags or ribis. This should make calculation faster as you are sure every and any way has the flag, no need to check for wayobj or some other parameter first, just return the overtaking data.

The usage is simple, when the user clicks on a road way, elevated way, tunnel or bridge five buttons show up, each button define an overtaking option. The chosen option will define the overtaking flag automatically, in case of building one-way roads ribis are also set according to the dragged direction, if you drag the road N->S the way will be one-way N->S.

This patch is partial, the backfront code needed for the OTRP patch is complete as far as I can see but it has bugs and is incomplete on the forefront. So far the following is planned and incomplete:

  • (Bug)(one-way) Masked ribis not being set for one-way bridges and tunnels
  • (Bug)(one-way) Masked ribis being lost on load
  • (Bug)(one-way) Masked ribis being lost when building object on the road (signals/intersections)
  • (Bug)(one-way) Masked ribis not being reset when changing overtake mode
  • (Feature) Graphics for buttons to select overtake mode
  • (Feature) Graphics to overlay on all roads
  • (Feature) Graphics to overlay on specific roads

Advantages:

  • Simple
    User just has to drag once, changing the flag can be done by re-dragging.
  • Fluid
    The last active overtaking option is kept so while building a one-way road the one-way option is kept until you choose a new option.
  • No new ways and/or wayobjs
    Ways and wayobjs are unchanged, the game automatically affects all road ways. No duplicated objects.
  • No pakset change required
    All paksets are automatically affected, the only thing is that no visual hint will be present by default.
  • Faster
    Data is saved on the way as ribis are, no need to check for wayobj, just return value.

Here's a recording of how it works:


PS: Two-way is index 0 so it's the first option on the toolbar.

THLeaderH

#197
This is an awesome approach and I'd like to follow An_dz's method!
Is this code uploaded on the repository of GitHub?

An_dz

Quote from: THLeaderH on July 04, 2017, 11:42:33 PM
Is this code uploaded on the repository of GitHub?
Not yet. And this code does not contain the OTRP patch yet, only the interface and the flags.

Leartin

I really like this concept, but I need to point out it does not follow the UI-implementation of other existing Simutrans functions, and it would be nice to have those streamlined.

I'm talking about stuff like the signal-distance-menu or the extension-building-rotation-menu. Both of those are very similar to one-way options, in that they are
  • not required to be able to play the game
  • altering the exact result of what a button does
  • independent of the pakset


    So for the sake of consistency, it would make a lot of sense if using control-click on roads, bridges and tunnels opens a window with radio buttons, and the five different options written as plain text.
    Otherwise, clicking on an extension building or a signal should automatically open a sub-menu to set up distance or rotation, rather than a window.

    Or perhaps it would make sense to have both windows that come up at control-click and buttons in menu that do the same thing.
    Your five buttons that control overtaking behaviour would be available for pak-developers to put in the menuconfig if they have icons for them (because really, which icons are used if the pakset doesn't specify them?) It stays open and works globally, that is once you set 'one-way', even if you change which road tool you use it will stay at one-way. It's not shown by your example, but I guess once you change tools your submenu disappears and resets when it reappears?
    Similarly, there would be a menu-button that shows the global signal distance, and any signal you drag will be buildt with that global distance. Buttons to Increase or Decrease the global signal distance varible. Five buttons to make extension buildings face north, east, south, west or random.

    I'm not certain myself which option would be best, but I really think there should be a streamlined, consistent way across all similar options.

jamespetts

An interesting discussion. Some observations: firstly, if I have understood this correctly, I agree with Leartin, in that clicking on a road tile in the menu should not always force a user to navigate a menu about overtaking. Only occasionally will users want to have one way roads: most of the time, they will just want to build roads and not worry about one way.

Secondly, it would make sense if there were an option in each way's .dat file to allow pakset designers to specify whether the way is allowed to be (1) one way; or (2) two way.

This is useful, as it makes very little sense to have one way dirt roads, but also, if a pakset has a special road, with a higher speed limit, intended to be a motorway/autobahn/freeway (etc.), it does not make any sense to allow this road, with its higher speed limit that in real life depends on being a dual carriageway, able to be built as a two way, single carriageway road. This can make a real difference to pakset balancing if players are allowed to get the advantages of a fast road without the cost of building both carriageways.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

Quote from: jamespetts on July 05, 2017, 10:58:00 AM
An interesting discussion. Some observations: firstly, if I have understood this correctly, I agree with Leartin, in that clicking on a road tile in the menu should not always force a user to navigate a menu about overtaking. Only occasionally will users want to have one way roads: most of the time, they will just want to build roads and not worry about one way.

I don't think navigation is an issue, it appears to me that the overtaking-submenu appears, but does not need to be used, and it appears on the left edge of the screen, where it could hardly obstruct anything. That is, by itself, a rather elegant solution. My point is simply about consistency in context with the rest of the game, so either this should work like the stuff we already have, or the stuff we already have should be updated to work like this, or both.

jamespetts

Ahh, yes, I see. I agree in any event that consistency is to be aimed for wherever possible, although CTRL+click is often not transparent to users.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

An_dz

Quote from: Leartin on July 05, 2017, 04:58:09 AM
Similarly, there would be a menu-button that shows the global signal distance, and any signal you drag will be buildt with that global distance. Buttons to Increase or Decrease the global signal distance varible.
I think that each signal needs a different value, as it is, as I think depending the signal type one might need to have different distances, but we can move it to be global as well, it's not hard, just duplicate code.

Quote from: Leartin on July 05, 2017, 04:58:09 AM
Your five buttons that control overtaking behaviour would be available for pak-developers to put in the menuconfig if they have icons for them
That's why I've set them as toolbar buttons, if you want to place them somewhere else as well you can. I have not coded that yet, but the default icons will be images in the SimpleTools menu pak.

Quote from: Leartin on July 05, 2017, 04:58:09 AM
(because really, which icons are used if the pakset doesn't specify them?)
As you can see in the bug list I have not coded that part yet, but I'll probably use the vehicle list icon or the road toolbar icon.

Quote from: Leartin on July 05, 2017, 04:58:09 AM
It stays open and works globally, that is once you set 'one-way', even if you change which road tool you use it will stay at one-way. It's not shown by your example, but I guess once you change tools your submenu disappears and resets when it reappears?
No, it's totally global and persistent. It will only reset when you reload Simutrans.

Quote from: Leartin on July 05, 2017, 04:58:09 AM
I really like this concept, but I need to point out it does not follow the UI-implementation of other existing Simutrans functions, and it would be nice to have those streamlined.

I'm talking about stuff like the signal-distance-menu or the extension-building-rotation-menu. Both of those are very similar to one-way options, in that they are
  • not required to be able to play the game
  • altering the exact result of what a button does
  • independent of the pakset
Quote from: jamespetts on July 05, 2017, 10:58:00 AM
An interesting discussion. Some observations: firstly, if I have understood this correctly, I agree with Leartin, in that clicking on a road tile in the menu should not always force a user to navigate a menu about overtaking. Only occasionally will users want to have one way roads: most of the time, they will just want to build roads and not worry about one way.
Well, (1) the extension rotation is totally eye candy, no game functionality is affected, it's completely irrelevant unless for scenario builders (like myself) and (2) the signal spacing is important to change only once, after you have set a default on your session you are done.

On the other hand setting the road "rules" is more common (that's why NAM on SimCity exists), and it's important for the user to get a visual hint of which "rule" is currently set. Or users would be really pissed if they went on building a new road to then find out they just built a road forbidding overtaking.

I forgot to add that in the bug list, but the menu should go away when you deselect a road tool.

Quote from: jamespetts on July 05, 2017, 10:58:00 AM
Secondly, it would make sense if there were an option in each way's .dat file to allow pakset designers to specify whether the way is allowed to be (1) one way; or (2) two way.

This is useful, as it makes very little sense to have one way dirt roads, but also, if a pakset has a special road, with a higher speed limit, intended to be a motorway/autobahn/freeway (etc.), it does not make any sense to allow this road, with its higher speed limit that in real life depends on being a dual carriageway, able to be built as a two way, single carriageway road. This can make a real difference to pakset balancing if players are allowed to get the advantages of a fast road without the cost of building both carriageways.
Tell me the difference with the current behaviour.

Anyone who plays online can explain how people build roads on network games?

And why make things complicated to the user? And with the code? The user is building a one-way road, but then selects one that is not allowed to be one-way, and has to find out which can be built one-way. You would need to go back and fourth finding which combines with what. Games are built to please gamers, not designers, my personal opinion.

jamespetts

I am not sure that I fully understand the questions relating to my comment regarding pakset balancing and one way roads. In particular, are you referring to the "current behaviour" being the behaviour in the game as it is now without the patch, with the patch in its current state as written by you, or with the patch in the state written by The Leader H?

The point in general terms is that it is common for dual carriageway roads to have higher speed limits than single carriageway roads because they are dual carriageway roads. This could have a significant effect on pakset balance for the reasons given in my previous post. The only way of enforcing this with the system as you have written it is to add the options as I suggest.

As to simplicity, it should be easy for a player to understand that some roads with higher speed limits should be dual carriageways. The system as you have written it is actually more complex (albeit with the benefit of greater flexibility) than a system in which every type of road is either one way or two way and this cannot be changed by the player. Allowing the player the ability to change types of roads between one and two way on the fly is the thing that adds the complexity; it does not add significant further complexity to add what is necessary for balance, viz. a feature allowing pakset authors to specify which roads may be made one way or two way.

As to the interface, it should be simple to communicate through the sub-menu (for example, by greying out) what options are not available.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

Quote from: An_dz on July 05, 2017, 01:25:07 PM
Well, (1) the extension rotation is totally eye candy, no game functionality is affected, it's completely irrelevant unless for scenario builders (like myself) and (2) the signal spacing is important to change only once, after you have set a default on your session you are done.
Sure, rotating those extensions is just eye candy, and while I disagree with your assessment about signals spacing (if you really care, you would change it more often when your trains get longer or shorter over time; If you don't care, you never change it at all), I understand that those functionalities are less important then one-way-roads, and definitelly not worth spending too much time on in their own right. I'm not even saying you personally should change anything about them - rather, I think WE, the community, should come to some common concensus about how Simutrans menus should work, which can then be implemented by whoever happens to have enough time. Which I realize would likely be noone, but still.

I think the way you designed your menu has implication you don't yet realize. The revolutionary thing about it is that up until now, we had buttons to call menus, we had buttons to call windows, we (rarely) had buttons to toggle something, and we had buttons that called a cursortool; you change all road icons to do both, call a menu AND call a cursortool. Once you do this, why not do it more often?
For example, p192c has a demolish-tool and a demolish-menu, currently two icons, which could very well merge into one without any loss in functionality either way. Same (perhaps to a lesser degree) for the view-tool and the view-toolbar. And perhaps it would even be rather easy to implement with a simple boolean flag in every icon that calls a menu, which would indicate that the first tool of that menu is auto-selected - quite straightforward.
If that would be done, you could eg. create sub-menus for each type of signal - since you always call the first signal, you can always build a signal with the function you wish for, or you first select one that looks different. Since you said it's persistent, that would be true for such sub-menus as well, so once you choose one, the main-icon will call that one next time. And because of that, you could even use it for stuff like tracks... so essentially, your menu would consist of "build a way", "build a tunnel", "build a bridge", "build electrification", "build a block signal" to "build an end of choose signal", "build goods station", "build pax station", "build station extension", "build depot". I don't think that would be too bad, and if it would be done, I wouldn't mind at all. It's just very different to the current behaviour.

If, instead, you would just add those five icons but NOT show them automatically whenever you call any road tool, the functionality would be largely the same; if they are in the road menu nothing would change at all. The user would perhaps need one more click over the course of the whole session, the one to call those tools to put them in some corner - if they are not part of the road tools anyway - so essentially nothing. However, since you don't mix up menu-calling with tool-calling, there is no reason to do it with anything else either, it would have no resemblance to all the control-click-options, and therefore it would fit in the canon of how Simutrans works a bit better.


Yes, I'm fully aware that you might say it's a slippery slope arguement, but the problem is that the slippery slope would be the better option over plain design inconsistency. That's why I think it's important to talk about this in general, not just in relation to this function.

Ters

Quote from: jamespetts on July 05, 2017, 10:58:00 AM
This is useful, as it makes very little sense to have one way dirt roads, but also, if a pakset has a special road, with a higher speed limit, intended to be a motorway/autobahn/freeway (etc.), it does not make any sense to allow this road, with its higher speed limit that in real life depends on being a dual carriageway, able to be built as a two way, single carriageway road. This can make a real difference to pakset balancing if players are allowed to get the advantages of a fast road without the cost of building both carriageways.

I think this is an issue from a few pages back: whether one-way roads should be separate road, which means that pak sets and add-ons must be modified to enable this feature, or some sort of overlay (not necessarily in a visual sense) on any road, which means that players can use the feature immediately without having to wait for new paks from authors who might not even be around anymore.

I certainly can see use for one-way dirt roads, but probably not with overtaking. In those situations, signs and/or waypoints should be adequate, though.

An_dz

Quote from: jamespetts on July 05, 2017, 02:10:00 PM
I am not sure that I fully understand the questions relating to my comment regarding pakset balancing and one way roads. In particular, are you referring to the "current behaviour" being the behaviour in the game as it is now without the patch, with the patch in its current state as written by you, or with the patch in the state written by The Leader H?
The current behaviour without any patches, default Simutrans or Simutrans Extended.

Many paksets have roads with pretty high speeds for two-way roads, yet they offer it.

Quote from: jamespetts on July 05, 2017, 02:10:00 PM
The system as you have written it is actually more complex (albeit with the benefit of greater flexibility) than a system in which every type of road is either one way or two way and this cannot be changed by the player. Allowing the player the ability to change types of roads between one and two way on the fly is the thing that adds the complexity
Yes, but it's less complex than both at the same time.

Quote from: Leartin on July 05, 2017, 03:02:02 PM
Yes, I'm fully aware that you might say it's a slippery slope arguement, but the problem is that the slippery slope would be the better option over plain design inconsistency. That's why I think it's important to talk about this in general, not just in relation to this function.
No, I agree, actually I always wanted something more a la SimCity.

jamespetts

Quote from: An_dz on July 05, 2017, 04:13:49 PM
The current behaviour without any patches, default Simutrans or Simutrans Extended.

Many paksets have roads with pretty high speeds for two-way roads, yet they offer it.

I can only speak for Pak128.Britain-Ex, but I suspect that it may well be the same for the other paksets; the pakset has such a road precisely and only because it is not possible to require that it be built only as a one way road, and there is no other way of having a motorway in the pakset but by having a road that allows motorway speeds as a single carriageway road, even though this would never be permissible in reality.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Leartin

Quote from: jamespetts on July 05, 2017, 05:04:48 PM
I can only speak for Pak128.Britain-Ex, but I suspect that it may well be the same for the other paksets; the pakset has such a road precisely and only because it is not possible to require that it be built only as a one way road, and there is no other way of having a motorway in the pakset but by having a road that allows motorway speeds as a single carriageway road, even though this would never be permissible in reality.
Essentially the same for p192c. If the option would have existed, high-speed roads would be one-way only. It's a bit like saying every way had steep slopes before half slopes were introduced, therefore an option to disable those would not be required.