OWR-1 Override Texture Problem

[11241036 5,100]

I've been working on an override for the straight parts of the OWR-1 network, coming with the NAM. The purpose was adding parking lots at one side of the network, and grass at the other one. For the part with the parking lots and the grass themselves, I created a texture override, nothing special, but I can live with it. I also added some trees, shrubs, and cars with a T21 mod. It should be noted that I want the parking lots to be at the right-hand side (I'm playing with RHD) - in the screenshot below, they are supposed to be right adjacent to the residential zones.

The result, however, doesn't make much sense to me: Somehow, when the OWR is leading to the north or east (north is at the top of this picture), the textures are displayed properly, but when the OWR is leading to the west or south, the textures are mirrored and thus wrong.

How can I fix this?

[Tarkus 6,932]

Unfortunately, you've run into one of the strange quirks of the One-Way Road network, which extends to all of the additional One-Way Road-based override networks in the Network Widening Mod plugin: the (mostly) dreaded Tidal Flow.

When Maxis programmed the One-Way Road network, rather than having the directionality of the network be controlled through the RUL files, they seem to have overlaid some sort of other mechanism (which I've named "Tidal Flow") which handles the directionality separately, allowing for the directional flipping one gets when re-dragging an OWR in the opposite direction, and automatically reversing paths that might be going the wrong direction, provided they line up with the network flags in the RUL (and in the case of RUL0, the specified direction in the OneWayDir command). 

To the game on the RUL end, the One-Way Road network looks practically identical to the Road network, and other two-way networks, rather than resembling half of an Avenue, as one might expect.  In fact, if you examine the path file for the orthogonal One-Way Road tile in SimCity_1.dat (0x09004b00), you'll find it's identical to the one for the orthogonal Road tile (0x00004b00).  Tidal Flow flips whichever of the two Car paths is facing the wrong direction.  By virtue of being based on the One-Way Road network, the NWM OWRs inherit Tidal Flow properties.

This also means that there's only two flag combinations for the One-Way Road network orthogonal tiles--which, using INRUL ordering, would be 0,2,0,2 (North and South entry/exit, rotation 0) and 2,0,2,0 (East and West entry/exit, rotation 1).  Rotations 2 and 3 don't exist on the INRUL end--they can't, as they'd have the same flags as the existing combinations.  And as such, the game expects the network to be symmetrical on both sides, and your asymmetrical parking lots will unfortunately always be stuck on one side. Despite its similarities, the OWR-1 does not work like the RHW's MIS Ramp networks (and sticking the MIS's texture on the OWR-1 would result in some Tidal Flow situations where the pathing is going the opposite direction of what is indicated by the textures).

The quirks of Tidal Flow are also part of why the One-Way Road network does not have traffic signals facing its approaches (it also does not allow functioning stop points, so they're stuck on green anyway), and the caveat of the automatic path reversal only working if it is in the direction of the network flags is also why the NWM's OWR-4 and OWR-5 are prone to having car automata in the center lanes drive the wrong way, or do "donuts" in the middle of the road.  The crossover paths that are necessary for those networks to function properly go "against the grain" of the network flags (with the base orientation of both networks, the crossovers are entering/exiting the east on one side), so Tidal Flow can't flip them.  But if only one side is covered, the network will actually be broken in two of the four possible orientations, so the crossovers must be pathed bidirectionally. 

There has been proposals within the NAM Team pretty much as long as I've been a part of it to basically shelve or repurpose the OWR network, and make Road-based OWR-style override networks.  There were also specificially some proposals to redesign the OWR-1 itself to be Road-based or even Street-based, in order to give it a lower capacity, but there were complaints when the proposal was aired publicly for consideration in 2010, so it was shelved.

-Tarkus

[11241036 5,100]

Oh. Well, interesting to know; it seems that a quick solution is pretty much impossible. My primary goal was to make something like collector lanes along avenues in urban settings, but with trees, so not everything is just concrete and asphalt. Guess I'll either have to make the textures symmetrical, or find another approach to my goal.

[Tarkus 6,932]

It's definitely unfortunate that the OWR network's design is such a complication here, as having those collector lanes for what they often call around here a "Multi-Way Boulevard" would be rather nice.  I think the ultimate solution to that is going to be to have a "one-way" SAM set--even with keeping the OWR-1 in place as it is, I've been toying of revisiting the Street-based idea, in large part because it would be useful for replicating the Multi-Way Boulevard concept.  I have so many partially finished NAM projects here I'm still trying to finish (under our new release engineering paradigm, probably enough to last until at least NAM 50!), but it's definitely on my list.

-Tarkus

[matias93 7,535]

Just an idea: it is possible to make a transit enabled lot with unidirectional pathing, as to serve as a direction filter? That way, without having to implement any new network (which would be great, but seems to be lot of work), one could have, for example, an effectively unidirectional length of street.

[11241036 5,100]

1 hour ago, matias93 said:

Just an idea: it is possible to make a transit enabled lot with unidirectional pathing, as to serve as a direction filter? That way, without having to implement any new network (which would be great, but seems to be lot of work), one could have, for example, an effectively unidirectional length of street.

This should surely be possible. I don't know anything about making paths, but I've already made such lots. The modding is quite simple. First, for people unfamiliar with how to edit a lot to make it a transit switch, a short explanation:

For every lot that allows traffic to pass/switch, you must edit the Transit Switch Property. In this property, all values come in groups of 4, containing info about (in this order):

1. Does traffic enter the lot or exit it?
2. From which side (N, E, S, W)?
3. Which type of traffic is it when outside the lot?
4. Which type of traffic is it when inside the lot?

As an example: Outside-to-inside, NE, bus, pedestrians. Such a lot allows bus traffic to enter, but only from the north and east, and transforms it into pedestrians (which are being "kept" inside the lot). To allow the pedestrians (or any other type of traffic) to leave, just add another group of 4 to allow them to leave (number 1 must be set to "inside-to-outside").

Number 3 and 4 need not be the same. This way, it is achieved to allow switching between different types of traffic.

To make sure a lot only allows traffic passing into one direction, you basically need a pair of groups for each type of traffic: In the first group, the 2nd entry allows entering from only one side, in the second groud, it allows exiting through the opposite side only. This is a screenshot of how this can be achieved in SC4Tool: (Please note that it is highly recommended to allow entering from the north and exiting to the south, this way, the lot's orientation arrow can be used as a visual indicator showing in which direction the traffic will flow):

If someone wants this lot, I'll send them to you via PM or just put these lots (I've got several of them, based on various SAM networks and decorated with simple traffic signs, in order to have a visual reminder of where I placed these lots) online. The drawback of this, however: It only works on the lot itself - even if you place two lots cleverly at the beginning and the end of a street, between these two lots, traffic can travel in both directions. If you don't want this to happen, lay out only one type of zones between two such lots.

As for this particular problem with the OWR-1 override: As for now, I just modified the straight SAM 7 filler puzzle piece from the Rural Roads plugin. I barely use anything from there, anyway, and with the arrival of the FLEX piece to connect different types of SAM streets, I do have a good alternative to use in case I need to connect SAM 7 to another street-based network. It has the drawback of still allowing traffic to pass in both directions - but I can most likely solve this problem by creating another unidirectional lot, and puzzle pieces are very good for cosmetic purposes because I have better control about what happens - the other way, I would have collector lanes everywhere I use OWR-1, even when I don't want to have them.

[BartonThinks 3,416]

15 hours ago, Tarkus said:

Unfortunately, you've run into one of the strange quirks of the One-Way Road network, which extends to all of the additional One-Way Road-based override networks in the Network Widening Mod plugin: the (mostly) dreaded Tidal Flow.

When Maxis programmed the One-Way Road network, rather than having the directionality of the network be controlled through the RUL files, they seem to have overlaid some sort of other mechanism (which I've named "Tidal Flow") which handles the directionality separately, allowing for the directional flipping one gets when re-dragging an OWR in the opposite direction, and automatically reversing paths that might be going the wrong direction, provided they line up with the network flags in the RUL (and in the case of RUL0, the specified direction in the OneWayDir command). 

To the game on the RUL end, the One-Way Road network looks practically identical to the Road network, and other two-way networks, rather than resembling half of an Avenue, as one might expect.  In fact, if you examine the path file for the orthogonal One-Way Road tile in SimCity_1.dat (0x09004b00), you'll find it's identical to the one for the orthogonal Road tile (0x00004b00).  Tidal Flow flips whichever of the two Car paths is facing the wrong direction.  By virtue of being based on the One-Way Road network, the NWM OWRs inherit Tidal Flow properties.

This also means that there's only two flag combinations for the One-Way Road network orthogonal tiles--which, using INRUL ordering, would be 0,2,0,2 (North and South entry/exit, rotation 0) and 2,0,2,0 (East and West entry/exit, rotation 1).  Rotations 2 and 3 don't exist on the INRUL end--they can't, as they'd have the same flags as the existing combinations.  And as such, the game expects the network to be symmetrical on both sides, and your asymmetrical parking lots will unfortunately always be stuck on one side. Despite its similarities, the OWR-1 does not work like the RHW's MIS Ramp networks (and sticking the MIS's texture on the OWR-1 would result in some Tidal Flow situations where the pathing is going the opposite direction of what is indicated by the textures).

The quirks of Tidal Flow are also part of why the One-Way Road network does not have traffic signals facing its approaches (it also does not allow functioning stop points, so they're stuck on green anyway), and the caveat of the automatic path reversal only working if it is in the direction of the network flags is also why the NWM's OWR-4 and OWR-5 are prone to having car automata in the center lanes drive the wrong way, or do "donuts" in the middle of the road.  The crossover paths that are necessary for those networks to function properly go "against the grain" of the network flags (with the base orientation of both networks, the crossovers are entering/exiting the east on one side), so Tidal Flow can't flip them.  But if only one side is covered, the network will actually be broken in two of the four possible orientations, so the crossovers must be pathed bidirectionally. 

There has been proposals within the NAM Team pretty much as long as I've been a part of it to basically shelve or repurpose the OWR network, and make Road-based OWR-style override networks.  There were also specificially some proposals to redesign the OWR-1 itself to be Road-based or even Street-based, in order to give it a lower capacity, but there were complaints when the proposal was aired publicly for consideration in 2010, so it was shelved.

-Tarkus

Apologies for hijacking the thread a little bit, but is there a way to turn off the tidal flow feature on the OWR network? That is, is there a way to remove the one-way functionality of the network so that it can act as a second type of draggable road network?

Also, if it's possible to turn off the tidal flow feature, would doing so disrupt the functionality of other OWR-based networks? That is, if you turned off the tidal flow for the main OWR network, would this mess up the functionality of the OWR-1, OWR-4, and OWR-5 networks?

[matias93 7,535]

Had to try a little experiment: draw an avenue, delete half of it (either with the disconnector or drawing rail over it) and connect the stubs with another network (here I used OWR in both sides to keep it lineal). What you get is an unidirectional network that is not subject to tidal flow, has stop points and signals, and has native support for asymmetric T21, with compatible paths for most combinations. I guess some override network could use this to create single tile versions of semi-draggable OWR from double tile base networks.

[Tarkus 6,932]

4 hours ago, BartonThinks said:

Apologies for hijacking the thread a little bit, but is there a way to turn off the tidal flow feature on the OWR network? That is, is there a way to remove the one-way functionality of the network so that it can act as a second type of draggable road network?

Also, if it's possible to turn off the tidal flow feature, would doing so disrupt the functionality of other OWR-based networks? That is, if you turned off the tidal flow for the main OWR network, would this mess up the functionality of the OWR-1, OWR-4, and OWR-5 networks?

Tidal Flow appears to be controlled at the EXE level.  Everything I know about it has been learned from over a decade of trial and error. 

As SC4Fix has shown, it's possible to modify EXE-level aspects of the game via DLL-based mods (and this is a viable, officially sanctioned way to make these sorts of modifications), but doing so requires knowledge of how Maxis structured things on that end.  And unfortunately, there's not enough knowledge of that side of things on the transportation network end--there's not been much research there among the (very few) modders capable of making DLL plugins.

If Tidal Flow were to be shut off, it would affect the OWR network and all override networks based on it--the OWR-1, OWR-3, OWR-4, OWR-5, L1 OWR, and L2 OWR.  Of course, if you're at the point of being able to affect network properties at the EXE level, you're probably close to being able to actually add true new networks to the game, so that brings up lots of interesting existential questions about the future of override networks. 

2 hours ago, matias93 said:

Had to try a little experiment: draw an avenue, delete half of it (either with the disconnector or drawing rail over it) and connect the stubs with another network (here I used OWR in both sides to keep it lineal). What you get is an unidirectional network that is not subject to tidal flow, has stop points and signals, and has native support for asymmetric T21, with compatible paths for most combinations. I guess some override network could use this to create single tile versions of semi-draggable OWR from double tile base networks.

If people are okay with FLEX Piece-based override networks (along the lines of what was done with Hybrid Railway (HRW) for NAM 38) instead of draggable override networks, there's the potential for a lot of interesting things that can't be done otherwise--including new network capacity levels and functionality, and even the ability to manipulate Tidal Flow.  FLEX Pieces allow us access to RUL1 and INRUL network flag combinations that aren't possible through draggable means. Indeed, the public reaction and acceptance level of HRW is going to prove an interesting study in whether or not such approaches are feasible.

I'll note on the stop point/signal end, the SITAP (Signalized Intersection and Turn Arrow Project) plugin that's been part of the mod since NAM 34 does allow such functionality on the OWR, by using a workaround involving appropriately placed tiles of the Road network.  For those not familiar with SITAP, the NAM's documentation does actually cover it in some detail.  I'm actually looking to expand SITAP and add FLEX Piece-based versions of its intersections at some point down the line.

-Tarkus

[EffTheGrid 3,675]

On 9/11/2020 at 6:32 PM, 11241036 said:

 

I think this looks fantastic! I'd love to download this piece to redo some of my arterials!!

[11241036 5,100]

1 hour ago, Sloppyjoemess said:

I think this looks fantastic! I'd love to download this piece to redo some of my arterials!!

I'm entirely thinking of releasing this, but there's an issue: my really limited graphics making skills. I literally made this piece by painting some white lines (with 75% opacity, and I used MS Paint and GIMP) onto the grey concrete, and in this screenshot, it only works and is applicable because I'm using a sidewalk mod replacing the white pavement by Maxis concrete. Puzzle piees don't adapt to the sidewalk mod, I need to bake it into the texture, and the issue is: I seriously lack the graphics editing skills to make it look good. For white pavement, it would make sense to separate the parking lot from the sidewalk with a curbstone instead of white lines, and making this look really good is most likely beyond my skills.

[EffTheGrid 3,675]

For what it's worth, I think you're more than halfway there. I respect your decision if you don't want to sink in the time, but they already look very convincing. I would use them everywhere. 

[11241036 5,100]

I meanwhile made anther try, this time with using Jeronij's parking bays. They are a bit too dark for my taste, but they offer two great advantages: Since they are a prop (even with RKT1 and thus they can be placed on slopes), I can handle the parking bays with a T21 mod, which gives me more options, such as adding the parking bays only to certain zones, and leaving them out on agricultural zones where they would look odd. Plus, they can be combined with more sidewalk mods. The edges between the props can be hidden underneath the flower boxes.

All of this, however, doesn't change the fact that these collector lanes are literally only possible on straight orthogonal streets. No curves, no diagonals, no FAR. This is pretty common with Avenues, anyway, so I'm still pursuing that idea, but modifying the textures of any network whatsoever on diagonals would give odd results because since this is an asymmetrical type of network override, the parking bays would alternate between righthand and lefthand side.

[11241036 5,100]

The final product. Although I'm all thumbs when making graphics, somehow, by pure luck, I'm actually satisfied with how it worked out. I made some parking bays with the same asphalt texture that is used on the street itself. There's also a version with Maxis sidewalk, and I'm playing with the thought of making an additional texture with the parking bays on both sides, for dense urban settings, a bit similar to the JRJ Streetside Mod.

@Sloppyjoemess You can still have it if you want, but there's only one piece available, the straight orthogonal. And it's overriding a puzzle piece from the Rural Roads plugin. I seriously lack the graphics editing and modding skill to make an entire comprehensive network override with this (although, technically, several pieces would only need some grass to be added, the fact that this type of network is asymmetrical makes things really difficult). If you want it, I'll send you a PM (I need to change some settings so you can use it, I've already adapted SC4 to my needs in a lot of quirky ways, so it will take a while).