Menu

LEX File Exchange
EA Support Files
SC4 Wikipedia
Network Addon Mod
Dependencies
Chat

Author Topic: RHW (RealHighway) - Development and Support  (Read 2741975 times)

0 Members and 1 Guest are viewing this topic.

Offline Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11458
  • Total likes: 5008
  • Reputation: 73
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: RHW (RealHighway) - Development and Support
« Reply #13020 on: September 09, 2020, 10:07:09 PM »
There's pretty much been a de facto moratorium on standard puzzle pieces for the last 5 years.  FLEX Pieces--maybe.  In any case, it needs to be pretty much redesigned from the ground up, and that's going to take time.  And if you're okay with the stack not being perfectly symmetrical on all four sides . . . I came up with this solution back in 2016 (during NAM 35 development, no less), which doesn't require Three-Level Crossings:



FLEXFly currently only supports orthogonal under/overcrossings.  Diagonal support has been discussed at times, and it'd certainly be nice to have for compact diagonal RHW x RHW interchanges, but there's never been any sort of concrete move toward it, or even an attempt to define an IID scheme for it.  It'd likely require about a 250,000 line chunk of RUL2 code, at least.

-Alex


Offline roadgeek

Re: RHW (RealHighway) - Development and Support
« Reply #13021 on: September 10, 2020, 10:13:44 AM »
There's pretty much been a de facto moratorium on standard puzzle pieces for the last 5 years.  FLEX Pieces--maybe.  In any case, it needs to be pretty much redesigned from the ground up, and that's going to take time.  And if you're okay with the stack not being perfectly symmetrical on all four sides . . . I came up with this solution back in 2016 (during NAM 35 development, no less), which doesn't require Three-Level Crossings:



FLEXFly currently only supports orthogonal under/overcrossings.  Diagonal support has been discussed at times, and it'd certainly be nice to have for compact diagonal RHW x RHW interchanges, but there's never been any sort of concrete move toward it, or even an attempt to define an IID scheme for it.  It'd likely require about a 250,000 line chunk of RUL2 code, at least.

-Alex

I seem to recall seeing that image, and eventually, I plan on incorporating something like that in my cities, albeit, I think I want to go 5 levels, and now that we have L3 and L4 FlexFLYs, I think that is doable. Also, I saw a mention that we might get RHW 10C and 12S in either NAM 39 or NAM 40. That would be pretty awesome. More FARHW would be awesome as well, as currently you cannot do a whole lot with FARHW as far as on-ramps, off-ramps underpasses, overpasses, or Y interchanges. Here's a crazy idea, and I don't know if you have already thought of it: Wouldn't it be awesome to have a FA FlexFly!
« Last Edit: September 10, 2020, 10:16:01 AM by roadgeek »

Offline Indiana Joe

  • NAM Team
  • Forums Governor
  • *
  • Posts: 450
  • Total likes: 69
  • Reputation: 2
  • Of Fruit Flies and Bananas
Re: RHW (RealHighway) - Development and Support
« Reply #13022 on: September 11, 2020, 03:10:36 AM »
I think FLEXfly is in a pretty good place at the moment, you can do a lot with the current 4 levels and 45/90 degree pieces.  You can go even smaller with stacks, this was also possible a few versions ago:


Offline roadgeek

Re: RHW (RealHighway) - Development and Support
« Reply #13023 on: September 11, 2020, 11:37:24 AM »
I think FLEXfly is in a pretty good place at the moment, you can do a lot with the current 4 levels and 45/90 degree pieces.  You can go even smaller with stacks, this was also possible a few versions ago:



I looked at the Namdoc on the wiki page, which has not been updated to reflect the new L3 and L4 pieces, but I looked to see if it shows the radii of the different pieces, and that information appears to be missing.

https://www.wiki.sc4devotion.com/index.php?title=Namdoc:RHW_FLEXFly

Offline Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11458
  • Total likes: 5008
  • Reputation: 73
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: RHW (RealHighway) - Development and Support
« Reply #13024 on: September 11, 2020, 11:48:16 PM »
Regarding the Namdoc section of the Wiki--aside from a couple of pages that Naomi57 updated last year (still during the long reign of NAM 36), pretty much nothing on there has been updated since NAM 35. 

We began examining the use of the Wiki as a new source for documentation in the wake of the issues of the PDF-based "User Guides" that came with NAM 31 (and pretty much never got updated, because the source documents were almost impossible to edit).  But when we decided to go back to HTML-based documentation for NAM 36 (something we last had with NAM 30), the Wiki efforts, which hadn't gotten very far, anyway, were pretty much abandoned. 

Anyone looking for up-to-date online NAM documentation should instead head over to https://sc4devotion.com/namdoc, which currently hosts exactly the same documentation as is included in the NAM 38 package.  I'll note it's still lacking in some departments, in large part because our focus has been getting the NAM's release engineering schedule onto a much faster track, instead of the 17-month average that was the norm between NAM 31 and NAM 37, but it should catch up relatively soon.

With regards to the RHW-12S and RHW-10C, they're indeed still planned--as are additional even wider networks beyond them.  The 12S and 10C were originally part of the plans for the notorious NAM 31 release, but were shelved relatively late in development--a state which was prolonged by an effective moratorium on adding new networks after the disaster that NAM 31 ended up being.  The base networks for them (L0, L1, and L2) are basically done, and there's FLEXHeight and FlexOnSlope transitions designed for them already. 

The main reason they got shelved was that the were exactly zero ramp interfaces designed for them at that late stage in development (and thus, no way to make interchanges with them), plus the fact that they didn't really add anything new to the capacity landscape, due to their having a shared footprint with the other S and C networks.  And being of the width that they are, the demand for a wide variety of ramp interfaces (especially the borderline-mythical "X3" ramps--the only extant example being the RHW-10S C3) was going to be very high.  Having none or only a couple wasn't going to go over well with the general public.

I probably wouldn't put much stock into "this is planned for future NAM Version X" statements--even those coming out of our own mouths/keyboards as late as 2-3 months ago, and especially anything said on that front prior to NAM 37's release. 

This new "Agile"-type release engineering that we began implementing while finishing up NAM 37 means more frequent releases with smaller feature sets.  Indeed, some of these features might end up arriving around the same time on the calendar as "NAM X" would have under our old paradigm, but it'll probably end up having a much higher version number attached to it, provided we're able to keep up the intended pace.  I've actually been instructing the other developers to refrain from making such proclamations going forward, as well as trying to keep myself from doing so (old habits die hard), unless something is actively on the release track for the version currently in development (as is the case with "New FLUPs" and NAM 39).

This is an actual quote of mine from the big "manifesto" post I made on our private boards about this new approach, just before the NAM 37 Release Candidate went live:

Quote from: Tarkus date=1587230952
Additionally, again getting back to that notion of reducing the release cadence, let's not overplan what feature will go into what NAM release.  Focus on the project, and we'll figure it out from there.  Much as we tell our own userbase whenever they ask us about release dates, it will be ready when it is ready.  And if you're dying to get something out sooner, again, look at doing things in smaller chunks.

And another related quote from the same post:

Quote from: Tarkus date=1587230952
What's the key to shorter release cycles?  Taking a closer look a feature scope.  We don't need to cram all the features into one release, or have some massive, sweeping project.  Focus on smaller features that make a difference, or break larger groups of features into manageable phases.  For example, for the long-anticipated NWM diagonal intersection/crossing capacity, we can do it on a by-crossing-network basis.  One release, for example, we could cover all the NWM networks crossing Road and Street.  The next, Elevated Rail and Monorail.  And so on.

As far as FARHW goes, I think eggman121's approach with FA in the RRW really shows the way forward there--going for FLEX pieces.  There's been some preliminary steps in that direction, which Shadow Assassin started years ago, but I'm not sure when that will happen.  There's been a push toward improving diagonal functionality first on the RHW side.  And while the prospect of FA-FLEXFly is certain possible, it's very unlikely to happen anytime soon.  Adding diagonal undercrossing support to the existing FLEXFly setups, or even adding RHW-6S FLEXFly setups (3-lane flyovers) would happen before we'd start to really think about adding new angles to the system.

-Alex

Offline Wiimeiser

Re: RHW (RealHighway) - Development and Support
« Reply #13025 on: September 12, 2020, 12:37:23 AM »
Would RHW-8 X3 work? The inside lane would become a MIS. The idea is already being used with a dual C-type D3 and the RHW-6S.

And I don't know of any IRL freeways with more than 10 lanes. That's how many the Eastern Freeway has here (I think that particular junction is 10S splitting into two 6S, one of which immediately transitions to 8S then 10S with the outermost lane being for buses. Take out the bus lane and that's a RHW-8 X Ave-8 intersection responsible for the Eastern Carpark)
Pink horse, pink horse, she rides across the nation...

Offline Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11458
  • Total likes: 5008
  • Reputation: 73
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: RHW (RealHighway) - Development and Support
« Reply #13026 on: September 12, 2020, 03:37:54 AM »
Would RHW-8 X3 work? The inside lane would become a MIS. The idea is already being used with a dual C-type D3 and the RHW-6S.

And I don't know of any IRL freeways with more than 10 lanes. That's how many the Eastern Freeway has here (I think that particular junction is 10S splitting into two 6S, one of which immediately transitions to 8S then 10S with the outermost lane being for buses. Take out the bus lane and that's a RHW-8 X Ave-8 intersection responsible for the Eastern Carpark)

Indeed, the RHW-6S does have D2/E2 ramps that have MIS out the bottom of the mainline--that's the smallest network that can support that configuration, and the math works out that the 8S would be the smallest to support D3/E3. 

While the largest freeway I know of in Oregon is also only 10 lanes (a brief stretch of Interstate 5 just south of the Oregon 217 interchange in Tigard), I've driven on plenty of wider stretches in other states.  The largest I'm personally aware of driving on has to be the Loop 202 in Tempe, Arizona--which happens to get to 14 lanes in quite a few spots on the mainline between interchanges.  The Downtown Connector (Interstate 75/85) in Atlanta, Georgia (which I've not driven) is generally considered to be the widest mainline in the US- this bit is 16 lanes.

The plan is to cap the proposed "Ultra-Wides" at 16 lanes, accordingly--the P57 IID scheme uses the fourth digit to designate width, and being hexadecimal, there's 16 slots.  11 are taken:

0 - RHW-2
1 - RHW-3
2 - MIS
3 - RHW-4
4 - RHW-6S
5 - RHW-8S (and S-Inner tile)
6 - RHW-10S
(7 - RHW-12S)
8 - RHW-6C
9 - RHW-8C
(A - RHW-10C)

That leaves five spots open.  The scheme has B assigned to the RHW-14S, C to the 16S, D to the 12C, and E to the 14C.  F remains unassigned.  This ultimately leaves a capacity continuum of 2 (1-tile) -> 3 (1-tile DIPped) -> 4 (2-tile) -> 6S (2-tile DIPped) -> 8C (3-tile) -> 10S (4-tile) -> 12C (5-tile) -> 14S (6-tile).  (All networks with full mainlines spanning 3 or more tiles have crossover paths, which act like DIPs, and networks can't be "double DIPped".)

It'll probably be quite some time before those networks come to fruition, though, as gap-filling on the existing networks remains a much higher priority.  And I don't think we'll be making X4 ramps.  I've yet to see anything beyond an X3 personally in RL (and that includes in Phoenix and vicinity).

-Alex

Offline Wiimeiser

Re: RHW (RealHighway) - Development and Support
« Reply #13027 on: September 12, 2020, 09:08:59 AM »
So F would logically be 16S. Barring that I suppose you could make WRHW-2 draggable as a last resort...

Incidentally, I just found a part of the Warringah Freeway in Sydney that's 9 lanes northbound, albeit in two separate carriageways of 6 and 3 and the outermost lane is an onramp merging into the next lane over. The opposite direction is 7 lanes plus a 2-lane offramp, so in theory you arguably have an 18-lane road (though, again, it's a collector-express/anti-weaving setup with multiple carriageways each way and includes two ramps...)
Pink horse, pink horse, she rides across the nation...

Offline Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11458
  • Total likes: 5008
  • Reputation: 73
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: RHW (RealHighway) - Development and Support
« Reply #13028 on: September 12, 2020, 09:12:56 PM »
So F would logically be 16S.

16S is already at ID C, so I'm guessing you meant 18S?  Noting that, it appears the Arizona Department of Transportation plans to outdo that 14-lane section of Loop 202 . . . by widening the Broadway Curve part of Interstate 10 at the Phoenix/Tempe border to 18 lanes.  Technically, it looks a little more C-ish with having those inside exits for the HOV lanes.

<a href="https://www.youtube.com/v/4l_Ee8VRZa0" target="_blank" rel="noopener noreferrer" class="bbc_link bbc_flash_disabled new_win">https://www.youtube.com/v/4l_Ee8VRZa0</a>
(fixed video link)

-Alex

Offline Wiimeiser

Re: RHW (RealHighway) - Development and Support
« Reply #13029 on: September 13, 2020, 02:36:04 AM »
I must have misread. I see you said the 16S now.
Pink horse, pink horse, she rides across the nation...

Offline roadgeek

Re: RHW (RealHighway) - Development and Support
« Reply #13030 on: September 13, 2020, 10:34:40 PM »
So F would logically be 16S. Barring that I suppose you could make WRHW-2 draggable as a last resort...

Incidentally, I just found a part of the Warringah Freeway in Sydney that's 9 lanes northbound, albeit in two separate carriageways of 6 and 3 and the outermost lane is an onramp merging into the next lane over. The opposite direction is 7 lanes plus a 2-lane offramp, so in theory you arguably have an 18-lane road (though, again, it's a collector-express/anti-weaving setup with multiple carriageways each way and includes two ramps...)

I would think that if we had 12S, we could already do separate carriageways of 6 and 3, and if we had 14S, we could likewise do,separate carriageways of 7 and 2. Thus eliminating the need for any 18S.

Offline Wiimeiser

Re: RHW (RealHighway) - Development and Support
« Reply #13031 on: September 13, 2020, 11:11:11 PM »
16 is a sensible place to stop, I think. Many games, especially older ones, stop there (and default regions are 16X16). Draggable WRHW-2 seems like the best option for F, then.
Pink horse, pink horse, she rides across the nation...

Offline LucarioBoricua

Re: RHW (RealHighway) - Development and Support
« Reply #13032 on: September 14, 2020, 09:26:25 AM »
Are there any plans for new inner ramps (left lane ramps for right-hand drive) with 2 and maybe 3 lanes? These would be useful to create more beefy collector-distributor lane arrangements, even if they're generally not advised for interchanges (aside from directional T and Y configurations.

I also concur with Wiimeiser on keeping the ultimate 2-way mainlines capped at 16 lanes total / 8 per direction. I can see these ones being especially useful for players who want to create extra wide highway merge/diverge areas, where there can be merging and diverging of 4 + 4, 5+3 or 6 + 2 lanes; and for players who want to have open HOV lanes. Mainlines with more than 6 lanes per direction, however, are extremely uncommon, but certain very large North American cities feature them. It also opens up the possibility of recreating extra wide traditional toll booths.

Offline roadgeek

Re: RHW (RealHighway) - Development and Support
« Reply #13033 on: September 16, 2020, 02:43:59 PM »
Are there any plans for new inner ramps (left lane ramps for right-hand drive) with 2 and maybe 3 lanes? These would be useful to create more beefy collector-distributor lane arrangements, even if they're generally not advised for interchanges (aside from directional T and Y configurations.

I also concur with Wiimeiser on keeping the ultimate 2-way mainlines capped at 16 lanes total / 8 per direction. I can see these ones being especially useful for players who want to create extra wide highway merge/diverge areas, where there can be merging and diverging of 4 + 4, 5+3 or 6 + 2 lanes; and for players who want to have open HOV lanes. Mainlines with more than 6 lanes per direction, however, are extremely uncommon, but certain very large North American cities feature them. It also opens up the possibility of recreating extra wide traditional toll booths.

Actually, I like what I have seen with the REW. I know that there are plans to get REW to work with NWM OWR, but I haven't seen a whole lot of activity on that thread lately.

Offline Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11458
  • Total likes: 5008
  • Reputation: 73
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: RHW (RealHighway) - Development and Support
« Reply #13034 on: September 16, 2020, 05:20:40 PM »
I'm not fully sold on having the WRHW-2 take Network Code F . . . especially since RHW FTLs are planned to be a thing, and it's really little more than a "T-End" FTL setup.  Plus, being in the same footprint as the RHW-3, and given that the RHW-3 doesn't have L3 or L4 (or DD) versions, there's some IID space in there, if it were to be built up further.

As far as X2-Inside and X3-Inside, I think they'll probably eventually make it in (much better chance with X2-Inside), but they're pretty far down the priority list for ramp interfaces.  The top priorities on that end right now are diagonal ramp interfaces, FLEX versions of the last remaining PP-only ramp interfaces, elevated versions of currently ground-only ramps, and once FlexFARHW gets to active development, FLEX versions of the Type Cx and Fx ramps.

The REW suffered a lot of setbacks due to Tidal Flow issues with the One-Way Road network, plus, AFAIK, eggman121 has been dealing with pretty heavy RL of late.  If you're curious about Tidal Flow, I posted a detailed explanation of it at ST in response to some issues that 11241036 had with an OWR-1 texture mod he was designing.  I'll quote it below:

Quote from: Tarkus
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 have 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.

But yes, ultimately, REW plus the expansion of SITAP is going to be the ticket for proper frontage roads with zone access alongside RHWs. 

-Alex