News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

One-way Two-lane road Fun Patch

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

fam621

Will this be available for Simutrans Extended, James?

jamespetts

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.

prissi

I will review the code; but I am currently on the last few day during move houses (for a family of five to another continent). So no quick action before the end of the month, sorry.

jamespetts

Quote from: prissi on March 12, 2017, 09:36:18 PM
I will review the code; but I am currently on the last few day during move houses (for a family of five to another continent). So no quick action before the end of the month, sorry.

Goodness, that sounds like hard work. Very best wishes for that!
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

#144
QuoteI will review the code; but I am currently on the last few day during move houses (for a family of five to another continent). So no quick action before the end of the month, sorry.
So I have to do refactoring before Prissi reviews my code because Ver8 code is so dirty...
Actually this project was my first time of modifying a big software :-[
Is there anything to do as a reviewee?

Andyh

Thank you THLeaderH!  I tested this in a number of different scenarios over the weekend.  It really works very well.  Both player vehicles and city cars behave as expected and very realistically.  I'll leave it to smarter people than me to comment on the code, but from a functionality perspective I would definitely support immediate integration into Simutrans standard.

THLeaderH

I uploaded a minor update, OTRP ver8.1, on Google Drive. See from here.
This time, the code patch is simutrans nightly r8141 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

The aim of this update is adaptation for the latest nightly code, fixing code style, and fixing a minor bug. In ver8, vehicles sometimes fail to avoid head-on crash and block the street. I don't make executable binaries this time.

This version, ver8.1, can read settings.xml and sve data of standard, but cannot read these of past OTRPs. I think this is because there were changes in rdwr methods between r8128 ~ r8141 and that causes conflict. However, I couldn't find the exact reason. Is there any changes in rdwr methods between r8128 ~ r8141?

An_dz

Yes, the 16 bit colour patch. r8134

Commander Noddy

The mod is good:) However, when I test it when the patch v8, my bus (set by human player) can't overpass the citycar (default citycar). The bus has already changed into the faster lane. However, the bus suddenly stop and then it can't overpass the citycar until it left the highway. I want to know what is the problem, thanks:)

May The Force Be With You Always!

THLeaderH

QuoteThe mod is good:) However, when I test it when the patch v8, my bus (set by human player) can't overpass the citycar (default citycar). The bus has already changed into the faster lane. However, the bus suddenly stop and then it can't overpass the citycar until it left the highway. I want to know what is the problem, thanks:)
I can't reproduce the problem. Could you share a video or sve data with the pakset?

THLeaderH

#150
Here is a new release of One-way Two-lane fun patch, OTRP ver9.
This time, the code patch is simutrans nightly r8151 based, and the patch can be easily integrated to the nightly trunk. Executable binaries are nightly r8128 based for a reason - I'll explain it later. Of course you can make a latest nightly based binary by compiling the nightly based patch.
Source code can be seen on git. https://github.com/teamhimeh/simutrans/tree/OTRP

patch:https://drive.google.com/open?id=0B_rSte9xAhLDb1M3U1F5aVk1Zzg
~Executable Files~
:Simutrans:
win:https://drive.google.com/open?id=0B_rSte9xAhLDMFVMZ1d2R2Y5SEE
mac:https://drive.google.com/open?id=0B_rSte9xAhLDM291R3pUYWpHdkE
:makeobj: (new version!)
win:https://drive.google.com/open?id=0B_rSte9xAhLDWkhZMTRlQWhrX0E
mac:https://drive.google.com/open?id=0B_rSte9xAhLDR2pNbkZYVl90WG8

I uploaded r8128 based binaries because r8151 based binaries cannot load sve data of previous versions of OTRP. This is because r8151 integrated color patch. r8151 based binaries can load data of simutrans standard stable version and r8151 based binaries.

Since this version, way-obj also has overtaking_info flag. You can rewrite the condition for overtaking by building way-obj with overtaking_info.
I also integrated decoration way patch. Overtaking condition can be re-written by wayobj-road and wayobj-255. If both wayobj has the flag that changes overtaking_info, wayobj-255 has priority.
This feature enables you to enjoy one-way overtaking on conventional roads! You can use conventional road's wayobj by using wayobj-255.

Making wayobj with overtaking_info is easy. Just add
overtaking_info=0
to the dat file. If you write
overtaking_info=-1
the wayobj does not change overtaking_info.

To make wayobj-255, set waytype like this.

waytype=decoration
own_waytype=decoration


Sample road addon with overtaking_info can be downloaded from here. Also, sample wayobj-255 with overtaking_info can be downloaded from here.

To use wayobj-255, you need to add wayobj(255) in the menuconf.tab so they show in any or some of the menus. For examle, add
toolbar[6][12]=wayobjs(255)
in the menuconf.tab of the pakset.

I uploaded a demo video on twitter. This video shows that you can rewrite overtaking condition and use one-way overtaking on the conventional road.
https://twitter.com/himeshi_hob/status/845469009571069952

Any bug reports and ideas for improvement are welcome!

An_dz

Adding other patches will only make your patch worse to be checked, and you'll only create more work when the patch is committed and it creates conflicts.

THLeaderH

QuoteAdding other patches will only make your patch worse to be checked, and you'll only create more work when the patch is committed and it creates conflicts.
Of course I know that. Adding other patches should be avoided but it was inevitable this time.
When I firstly thought about the condition changer, I came up with implementing a completely new object, named road-marker. However, it resulted in completely failure because of its complexity. So, I decided to use way-obj as a condition marker.
However, I had to preserve the role of wayobj of road. I had to implement other kind of wayobj that can be build on road, otherwise it does a huge bad impact on SIS project. Decoration-way patch is the ideal solution for this. Though I can make a new kind of waytype, not any_wt, for wayobj, it will make the conflict worse.
Perhaps I should have waited until deco_way patch is integrated, but I don't know when the integration is done. So, I decided to integrate the patch to this project. I have to apologize for making a cause of conflict.

I think solving this conflict is not so hard. When deco patch is integrated, I'm willing to solve the conflict, of course :)

THLeaderH

Note: The candidate for integration is still ver8, because ver9 makes a terrible conflict with deco_way patch.
After the completion of deco_way patch, some lines will be added to weg.h and OTRP should be completed.

An_dz

Once I commit the deco_way we can create another wayobj for this patch that should clean up a lot the code, and it will also allow to create a couple wayobjs to be used on any road with any speed.

Hum, I really need to test the speed limit for both the deco_way and this new one.

Dwachs

Why would you need new object and way types for the overtaking patch?

My idea would be to use a new type of sign, similar to one-way sign: It marks everything behind as one-way and allows for overtaking. Of course, then the book-keeping is much more complicated.
Parsley, sage, rosemary, and maggikraut.

prissi

A single way (directional) wayobj would be very useful for other purposes, like sidewalls, catenaries on the correct side etc. beyond marking just roads. So I think it is worth the effort, even if it requires twice the pictures.

THLeaderH

Please consider city roads. In city limits, city roads are automatically paved and unexpected intersections might appear. If overtaking conditions are controlled by the signs, players always have to check intersections which were made by automatically paved cityroads. Also, there can be cars which have different overtaking conditions on same road since the overtaking condition depends on its route.

Isaac Eiland-Hall

Maybe one can hope for a way of marking roads as not being able to be connected to or taken over by cities? In the US, freeways do often go through the hearts (or very very near to the hearts) of cities :)

I would imagine such marked roads would be seen by the city as something like tracks, i.e. not useful for building; left completely alone - like elevated ways. :)

killwater

Any news on this awesome patch integration?

THLeaderH


An_dz

I've been very busy, lot of stuff happening, but I'm working on it. Hopefully I'll finish it today.

An_dz

I've been testing this and noticed that the vehicles lose the overtake info at some points.

The whole way is set to use the passing lane only (British like), but all buses move for a second to the right lane at the curve at the top. The two green buses though only have this on the north road near the tram way. And the two-piece bus does not have this problem.


An_dz

Me and THLeaderH are starting to work together in the patch, I already added the new waytype and cleaned some pollution that the code had.

We believe that only wayobjs should have the overtake flags, this will make things much simpler code-wise, dat-wise and user-wise. We will follow this path, but if anyone disagrees you can voice your opinion. I know that some roads will require the wayobj to be built to visually work but this makes things more consistent as the user knows that all roads will be always built as two-way roads.

jamespetts

I am not sure that I fully understand the utility of using wayobj for this rather than having this as a parameter of roads: can you elaborate?
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

The advantage are that you give more liberty to the user, make it easier to build and reduce the amount of images.

As I said in a previous post that's buried in this thread, you just need to take into account pak128.

pak128 has 9 roads, if you only think that the pak128 team decide to only offer both two-way and one-way versions for each road, you already end up with 18 roads, if you wish to add all OTRP possibilities, which are 5, pak128 will have 45 roads. And I'm not including bridges, tunnels and elevated ways, this blows to 150 objects.

With a wayobj you just need to create 4 wayobjs (one-way, no-overtaking, overtake stopped only, inverse two-way) and the user will be able to change the overtaking rule of any road and not be restricted to those that only the paksets maintainers added support. And it's much easier to build as you are able to change the overtaking rule of a whole road, even if has tunnels, bridges and elevated ways.

jamespetts

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

A few more ideas (expansions, if you so will)

First, one should probably be able to build these new 'wayobj' over each other without requiring control (and the according patch), but simply by building it. Thus the user would be truly able to change overtaking rules on the fly.

Second, I propose a fifth wayobj that normalizes behaviour. Thus, you don't need to use a seperate removal tool, which would work kinda odd (e.g. you already have a one-way road with an intersection. The intersection is not a one-way tile. Thus, deleting the one-way by clicking the ends would not work, since it's seperated. However, building a "normalizing" obj over it would work.)

Third, directional graphics - if they get implemented for the new object, I'd love to see them for ways and normal wayobj as well, even if they have no functionality except for graphical representation.

Fourth - what if a way could specify one of these 4 (5) wayobjs, and get buildt with that? You would keep the customization aspect, but at the same time, road graphics could be made with a specific behaviour in mind. For example, an asymetric Autobahn with breakdown lane and noise protection wall to one side would automatically be buildt as a one-way road, while staying customizable for the player to do what he wants.

Fifth - and now we are in wishful thinking territory - what if the graphic of a way could be changed based on which wayobj is buildt on it? Again, use the Autobahn. If you had an asymmetric Autobahn as described in my fourth suggestion, it would always look rather silly if cars would move both directions on it. So instead, you'd have an additional graphic for Autobahn that uses both directions, with wall and perhaps breakdown lane on both sides. Or you have a wayobj with both no-overtaking and one-way, which means only one lane would be used. The Autobahn could change appearence to be a thinner Autobahn ramp instead.
Or take the "Bundesstraße" in p192c - it has posts on both sides, with red and white indicators. But if you suddenly go british, those don't make any sense anymore and would need to switch sides. If you forbid overtaking, you could change a broken line in the middle of a road to a solid line. If no specific graphic exists, the basic one is used - much like vehicle loading graphics.

All in all, making the graphics of a road sensitive to which wayobj is buildt on it would mean that you can have pretty much all benefits from using wayobj AND all benefits you'd have from actually creating those 45 or more roads ;)

An_dz

Quote from: Leartin on April 17, 2017, 05:38:54 PM
First, one should probably be able to build these new 'wayobj' over each other without requiring control (and the according patch), but simply by building it. Thus the user would be truly able to change overtaking rules on the fly.
Yes, good idea, maybe we should expand to decoration wayobj.

Quote from: Leartin on April 17, 2017, 05:38:54 PM
Second, I propose a fifth wayobj that normalizes behaviour.
It can already be done, it's either 0 or 1. Can't remember now

Quote from: Leartin on April 17, 2017, 05:38:54 PM
Fourth - what if a way could specify one of these 4 (5) wayobjs, and get buildt with that? You would keep the customization aspect, but at the same time, road graphics could be made with a specific behaviour in mind. For example, an asymetric Autobahn with breakdown lane and noise protection wall to one side would automatically be buildt as a one-way road, while staying customizable for the player to do what he wants.
I thought about this. But I think we first need to create the directional wayobj. This can be created as a future patch after integration.

Quote from: Leartin on April 17, 2017, 05:38:54 PM
Fifth - and now we are in wishful thinking territory - what if the graphic of a way could be changed based on which wayobj is buildt on it?
Can't you just draw the wayobj to paint over those and change them? That's why I thought about wayobjs in the first place, because they can overwrite graphics.

TurfIt

I've not been able to spend enough time looking at this, and no time in foreseeable future, so initial thoughts re trunk commitment.

1) Is it finished? Seems to have TODOs stating things are not appropriate, etc.

2) Naming.
  overtaking_info - seems more like modes, or flags, definitely not info.
  is_info_changer() - huh?
  lane_fix - are the lanes broken... force, or pinning maybe.
  vehicle_base_t::left_driving - why? settings_t::drive_on_left is source, no need to copy it.

3) Stowaways? 
  Mac core-audio files - if this is the posted patch to update them, it's missing a replacement for volume control, hence not committed.
  Hajo name corruption.
  /opt/local/... ?  <png.h> is correct, not some local mangling...

4) Road trains - taking into account the position of trailers (tractor+3 trailers allowed currently) before changing lanes?

5) Performance - totally unfair test on map with 5000+ busses and overtaking_info forced to 0 for patch even though most roads were actually 2 way. Game becomes unresponsive - need much work here to handle larger maps. More fair testing not really possible yet as no large maps created with this patch already in place exist.

---
As a 'Fun' patch - great, for trunk - wrong approach IMO.
The intent appears to be to allow travel in multiple lanes in the same direction on one way roads, yet the code mangles up the existing the overtaking on two way road logic to do so. The vehicle movement logic is borderline unmaintainable now, one-way two-lane logic needs to be separate.

I would suggest implementation of one-way roads as separate waytypes. The construction tools would need an update to handle building and GUI to display the directionality.
The existing overtaking logic, is_way_free, and no_cars_blocking would remain untouched and used for two-way waytypes. The one-way waytype would have its own vehicle movement code.
On one-way roads, forbid construction of trams (that would also free up the center position for 3 lane highways in paks with small vehicle graphics), and rail crossings to simplify logic. And no need to consider oncoming traffic.
In the interim, I'd suggest freeway style only - hence forbid intersections with any roads except a special entry/exit ramp to join the freeway with regular roads. The logic to handle multilane road intersections is beyond daunting with the current way_free and no_cars_blocking routines - requires an overhaul (implementation of previously discussed [>5 years ago?] intersection_t object to traffic cop the flow through the intersection).

I think that would provide a more flexible and code maintainable one-way roads design.

---
On the wayobj as overtaking_info flagger - adding yet more objects to tiles is not performance friendly at all. Vehicles wading through all the objects in their current movement logic is quite time consuming. Again - wrong approach IMHO.

Leartin

Quote from: An_dz on April 18, 2017, 01:04:23 AMCan't you just draw the wayobj to paint over those and change them? That's why I thought about wayobjs in the first place, because they can overwrite graphics.

Kind of, but not really. For that to work, I'd need to use a barebone Autobahn with no railing, and create directional wayobj specifically for the Autobahn - which I would not want to be used with a dirt road, since a dirt road with an asphalt breakdown lane is kinda silly - I'd need something with a wooden fence or something similar. So I end up with incomplete, barebone roads and tons of wayobj, which I wouldn't want to be combined with the wrong road.
With this setup, it seems to me the best a pakset creator could do is completely break the system:
- get rid of all electrified road vehicles
- make all other road vehicles require electrification
- have only one "base road" that's pretty much a placeholder, with a speed limit of 999km/h
- use way-objects for the actual road graphics, complete with actual speed limit and electrification tag.
Vehicles can't use the placeholder road, they require the way object to work, because of electrification. So essentially, I'd break the system you propose with directional wayobjects instead of directional ways by using wayobjects as ways. Nice to have a system flexible enough to allow such atrocities. Though it makes one wonder if it really is such a good idea to use wayobjects.

And perhaps the most silly problem (unless there was a change I'm not aware of) - wayobj don't have seasons, not even snow graphics. Even something as simple as a solid middle line for "no_overtaking" becomes a pain, since you would need to make sure all roads are snow-free where the line would be in winter, since otherwise the snow is painted.



Here is another suggestion:
Scrap wayobjects and add those flags to the roads.
Add tools to change the flags in the roads once buildt.
Add support for multiple road graphics in one road for different occassions, but no requirement.
Add a "direction overlay", which visualizes the flags used in each tile (like the reserved route overlay for tracks)

IIRC, ways already store their max-speed on each tile in case you start the game without that way, so it would be replaced with something of similar speed, and to keep network games stable. But if the speed is stored in the tile, it would be possible to alter that value in the tile and have the same way, but with a different speed. The same should be true for overtaking flags, they would need to be stored just like the max speed anyway, in case you start the game without the wayobj/road that was used, so it could be replaced by something of similar properties instead of being lost.
Instead, just replace the road based on speed, but keep the flag-bits. And use the same flag-bits plus a "direction bit" for one-way to change the appearence of the road, if there are alternate graphics.


This pretty much allows for all the advantages using wayobj would give you, plus more - even if the wayobj/tool that would allow you to get a one-way road is removed, the behaviour of the roads already buildt would not change, and you would probably be more performant by scraping an extra object and all it's overhead. But that's said by someone who is too dumb to get Simutrans to even compile, so what do I know...

THLeaderH

QuoteWe believe that only wayobjs should have the overtake flags, this will make things much simpler code-wise, dat-wise and user-wise.
QuoteFourth - what if a way could specify one of these 4 (5) wayobjs, and get buildt with that? You would keep the customization aspect, but at the same time, road graphics could be made with a specific behaviour in mind. For example, an asymetric Autobahn with breakdown lane and noise protection wall to one side would automatically be buildt as a one-way road, while staying customizable for the player to do what he wants.
I think that only ways and wayobjs of overtake_wt should have the overtake flags. I mean wayobjs of road_wt or decoration_way should not have the flags. The flags of ways are used as the default condition, and the condition of overtaking can be customized by building wayobjs of overtake_wt. If ways don't have the flags, we have to build the wayobjs every time we build highway with specified roads and that would be silly.

Quote1) Is it finished?
I once thought that this project was completed when I released OTRP v8. However, it was revealed that there is a lot of things to be done. Thus, I have to say this project is not finished.

Quote2) Naming.
I'm not familiar to the naming style of simutrans yet. We have to fix inappropriate naming in the code.

QuoteMac core-audio files - if this is the posted patch to update them, it's missing a replacement for volume control, hence not committed.
  Hajo name corruption.
  /opt/local/... ?  <png.h> is correct, not some local mangling...
These code pollution is partly fixed by An_dz and we have to continue removing the pollution. Code pollution is caused by my lack of skills.

Quote4) Road trains - taking into account the position of trailers (tractor+3 trailers allowed currently) before changing lanes?
Road trains are taken into account in the overtaking process. Is there any problem with road trains?

QuoteThe intent appears to be to allow travel in multiple lanes in the same direction on one way roads, yet the code mangles up the existing the overtaking on two way road logic to do so. The vehicle movement logic is borderline unmaintainable now, one-way two-lane logic needs to be separate.
Actually it needs careful investigation whether separating the movement logic produces no problems.

I'm currently busy and I'll answer to the rest of suggestions tomorrow.

prissi

Well, I think with a wayobj enabling overtaking, the combination with directional road may not be neccessary. Just leave the decision whether this is oneway or twoway to the builder by using signs. The overtaking wayobj could be then just a guardrail.

killwater

Is this patch abandoned? Please don't be abandoned...

THLeaderH

#174
Still I don't have enough time to engage in this patch but I want to start with the naming issue.
Since I'm not a native English speaker, I'd like to get your advice about naming.

  • overtaking_info (a variable which holds the condition for overtaking) -> overtaking_condition
  • is_info_changer (a method which tells whether the way_obj overwrites the condition which is set by way.) -> does_overwrite_overtaking_condition
  • lane_fix (a variable which holds the information whether the vehicle keeps running certain lane.) -> lane_pinning

How do you think about these?