RHW (RealHighway) - Development and Support

[AngryBirdsFan436]

Hello, I encountered a problem while dragging an RHW-8C over an EMIS:

P.S. sorry for PNGs

[GDO29Anagram]

RUL-2 problem associated with network tile adjacencies.

Can't be easily fixed using just an attachment. You'd have to write in brand-new RUL-2 code for that. It's therefore a bug that can only be fixed using a Hotfix-type of patch, but we don't have enough bugs to warrant that, and that's gonna be rewritten in P57 anyway.

Worth noting that networks such as the 6C, or its asymmetrical counterpart, the 7C (which I'll be using as my example), isn't one whole network. It's actually three different override networks strung together side-by-side: The 6C Outer/Shoulder, the "6C+" Inner/Median, and the 8C Outer/Shoulder. The starters for the 6C and 8C outer parts are, respectively, the RHW-4 and MIS network. It becomes the 6C and 8C shoulder when it's adjacent to the 6C median piece, a sort-of override trigger.

This is related to why you have a MIS crossing, but the necessary RUL-2 override that turns the MIS crossing into the 8C shoulder is simply not there.

[Wiimeiser]

Correct me if I'm wrong, but,
doesn't plopped residential abandon immediately because it doesn't add to the population so no one lives there and as a result it's technically abandoned the tick/frame immediately after it's rendered, and also the fact that abandoned buildings can only be reused if they were grown? I may be wrong.

[jondor]

Hello, I encountered a problem while dragging an RHW-8C over an EMIS:

P.S. sorry for PNGs

RUL-2 problem associated with network tile adjacencies.

Can't be easily fixed using just an attachment. You'd have to write in brand-new RUL-2 code for that. It's therefore a bug that can only be fixed using a Hotfix-type of patch, but we don't have enough bugs to warrant that, and that's gonna be rewritten in P57 anyway.

Worth noting that networks such as the 6C, or its asymmetrical counterpart, the 7C (which I'll be using as my example), isn't one whole network. It's actually three different override networks strung together side-by-side: The 6C Outer/Shoulder, the "6C+" Inner/Median, and the 8C Outer/Shoulder. The starters for the 6C and 8C outer parts are, respectively, the RHW-4 and MIS network. It becomes the 6C and 8C shoulder when it's adjacent to the 6C median piece, a sort-of override trigger.

This is related to why you have a MIS crossing, but the necessary RUL-2 override that turns the MIS crossing into the 8C shoulder is simply not there.

That could also be an overcrossing too close to a starter piece.  One problem with the modular starters is that the game overrides a stretch of RHW into the underlying starter network and then again into the final target network and for simplicity, only a few pieces (mainly ortho and diag straight tiles) are coded to switch from one override to another.

[kings_niners]

So I've got this problem, not sure if its NAM related or whatnot but since I've installed the NAM and RHW traffic only moves in the morning commute direction... so even when the day clock is showing it to be in the afternoon traffic only moves in the morning commute direction, making it not very aesthetically pleasing however overall functionality doesnt appear to be affected... any ideas what might be causing this

[GDO29Anagram]

So I've got this problem, not sure if its NAM related or whatnot but since I've installed the NAM and RHW traffic only moves in the morning commute direction... so even when the day clock is showing it to be in the afternoon traffic only moves in the morning commute direction, making it not very aesthetically pleasing however overall functionality doesnt appear to be affected... any ideas what might be causing this

For the record, saying that it's a problem with the NAM doesn't help at all since RHW is a part of it. The only thing I can think of is that your sims might be having an alternate evening commute. Try the Route Query Tool, but for the evening commute.

Additionally, a picture helps, a lot.

New hypothesis: You know how when you query AVE or MHW, it shows traffic flow for both sides? All override networks derived from single-tile networks (RHW and NWM) can't do that. You have to query the individual sides.

[noahclem]

So I've got this problem, not sure if its NAM related or whatnot but since I've installed the NAM and RHW traffic only moves in the morning commute direction... so even when the day clock is showing it to be in the afternoon traffic only moves in the morning commute direction, making it not very aesthetically pleasing however overall functionality doesnt appear to be affected... any ideas what might be causing this

For the record, saying that it's a problem with the NAM doesn't help at all since RHW is a part of it. The only thing I can think of is that your sims might be having an alternate evening commute. Try the Route Query Tool, but for the evening commute.

Additionally, a picture helps, a lot.

New hypothesis: You know how when you query AVE or MHW, it shows traffic flow for both sides? All override networks derived from single-tile networks (RHW and NWM) can't do that. You have to query the individual sides.

I think he's referring to automata, not actual traffic. I have the same problem and never figured out what caused it. Can anyone shed any light?

[Tarkus]

It may be an automata controller thing from the sounds of it.

-Alex

[Elydion]

I had the same problem, but when i re-installed the nam with another traffic simulator, the problem was solved (though i can't remember what kind of simulator it was)

Ely

[Twyla]

...  The other method that has been discussed was using a DBE-type setup. ...

Please pardon my ignorance, but what does 'DBE' mean in this context?

[AngryBirdsFan436]

...  The other method that has been discussed was using a DBE-type setup. ...

Please pardon my ignorance, but what does 'DBE' mean in this context?

DBE means Diagonal Bridge Enabler. It drains the water level to 0 and lets you build diagonal bridges.

[GDO29Anagram]

The means of building diagonal bridges, curved bridges, and multi-tile bridges (beyond two tiles) is referred to Zero-Slope. DBE is just a zero-slope mod, a no-water terrain mod, and just the button for the Diag bridge starters, nothing else. The S3D and path info is stored within one of the NAM's own DATs.

Diagonal bridges is just merely a subset of Zero-Slope, strictly speaking, and even more so, a 6C bridge wouldn't be DBE-class unless it were diagonal itself. Left orthogonal, it's just a Zero-Slope bridge. The reason we say DBE is because it has all the slope and terrain info needed for this extremely advanced network construction technique.

[jondor]

...  The other method that has been discussed was using a DBE-type setup. ...

Please pardon my ignorance, but what does 'DBE' mean in this context?

DBE means Diagonal Bridge Enabler. It drains the water level to 0 and lets you build diagonal bridges.

It also uses a trick slope mod that forces the road (and RHW) networks to draw perfectly level, even if the land underneath slopes away.  The rest of the DBE uses starters and RUL-2 code to build a small selection of diagonal bridges that mimic the look of their ortho counterparts.

Since the game treats these "bridges" as regular draggable tiles, they can be placed directly adjacent to each other, turn mid-span and can even form neighbor connections.  Although the last two cases are not accounted for when building diagonal override bridges.  Also, since it's RUL-2 code like any other override, it's not limited to diagonal cases.  So it's a perfectly viable method for making 3-tile wide bridges with full capacities and no automata glitches.

[GDO29Anagram]

I'd edit my post but I've been interjected again...

The following is pretty much the first ever instance of Zero-Slope techniques ever documented before the NAM ever had the DBE. Everything that Jon about RUL-2ing a bridge applies, but this is the primary base. The images, however, went missing...

http://sc4devotion.com/forums/index.php?topic=11555.0

[Twyla]

Hate to seem like I'm beating a dead horse, but I'm wondering if this old post of mine has garnered any consideration in the Project 57 revisions.

I've yet to see or hear of any reason why such "true 4m lane" modularization wouldn't simplify things tremendously, fully unlocking RHW's potential.  True, it'd involve a considerable amount of effort, but that's being done anyways...

[kings_niners]

it must be automata then because the traffic query indicates that both sides of the hwy are being used. I would upload a picture but I don't know how...

[Twyla]

I would upload a picture but I don't know how...

Along the bottom city menu (Save, Exit to Region, Exit to Desktop, etc) you'll see an icon that looks like a camera (and a smaller camera next to it).  Click that, tap the spacebar to change the image size, and click to snap a screenshot.

Upload that to an image site like PhotoBucket or Flikr and post a link using the forum's IMG button.

[GDO29Anagram]

Hate to seem like I'm beating a dead horse pony, but I'm wondering if this old post of mine has garnered any consideration in the Project 57 revisions.

I've yet to see or hear of any reason why such "true 4m lane" modularization wouldn't simplify things tremendously, fully unlocking RHW's potential.  True, it'd involve a considerable amount of effort, but that's being done anyways...

Since this is rather similar to the idea of Ultra-Wide, several considerations are to be noted, and pretty much all of these were already brought up during our "super-secret" discussions: Capacity, measurements, RULing, convenience, and practicality.

Capacity:

RHW capacity is on a per-tile basis, but theoretical averages can still be made. RHW-4, for example, would have a theoretical lane capacity of 1/3 its full-tile capacity times 1.25. The same applies for all RHW widths: Theoretical lane capacity is 1/3 of a DIPped network tile.

Diagonal are the tricky part, because you can comfortably fit four paths along the diagonal, so the theoretical lane capacity would really need to be 1/4 that of a DIPped tile. The orthogonal average is 3 lanes per tile except for 10C, but the diagonal average is 4 lanes per tile.

Depending how you align diagonals, you may end up with a network tile with 5 or even 6 lanes per tile, rendering a 10S and 12S ineffective in terms of capacity.

Measurements:

This ties in closely with capacity when you deal with diagonals. When dealing with diagonal measurements, you effectively enter the world of Trigonometry. The diag measurement across a tile would be 16 meters times the square root of 2, or 22.63 meters. Considering overhangs and aligning the very edge of the inner shoulder with the corner, you can effectively render a 10S into being no better than 8S. Narrower lanes make it worse, and even those small differences in width can make a huge difference.

Yes, they're no different orthogonally, but the 10S should at least have some benefit. Scaling up from there would become a nightmare, and one of the other NAM Team members has already done the math. Because of the inherent problem with diagonals, the footprints grow more than the lane widths can keep up with.

Measurements, part 2:

The texture revisions back in NAM 30 dev were meant to bring it closer to real-life as possible, as well as bringing it closer to Maxis design specification, save for some MUTCD-compliant lane markings (30-foot gaps between 10-foot long dashes, or anything scaled up from there, so long it follows the 3:1 ratio). Narrowing such networks from about 35/128ths of a tile (4.375 meters, or 14.35 feet) to 1/4th of a tile (4 meters, or 13.12 feet) would mean that transitions between RHW and non-RHW networks would look rather bottleneck-y, and those 0.375 of a meter eventually add up, and they already look rather bottleneck-y with the TLA-7 to 6C transition, considering TLA-7's lanes are slightly wider.

RULing:

Only the orthogonals of such a proposal sound practical to RUL. Given the measurements with diagonals in terms of dimensions and capacity, it becomes impractical to scale up. Therefore, there has to be a limit, and even so, there would have to be dedicated networks for each width; It cannot be modular in this fashion.

Convenience:

This was brought up during our discussions on Ultra-wides in our "super-secret" dev thread (which, for the record, has also set the limit on both draggable and U-Wide): How easy would it be for the user to draw such a network? If ultra-wides were left draggable, it would take 50% longer to draw an ultra-wide S-network compared to a standard-wide S-network, and 67% longer to draw an ultra-wide C-network compared to a standard-wide C-network. Unlimited modularity in a 4m lane proposal makes it worse. Because of this, puzzle-based Ultra-wides were proposed, because you can just plop all three tiles in quick succession. (Also, variable-length puzzle pieces can be made that can be placed in quick succession.)

Practicality:

You don't see a lot of ultra-wides in real-life (and we're all well-aware of the examples in California and Gerogia), and when they do appear, they don't last for very long.

Measurements, part 3:

The v5 texture spec is pretty much the final iteration of RHW in terms of textures. Any modification to it will undermine the whole scheme again.

RULing, part 2:

The P57 IID scheme had to be revised many times (and we're only at Alpha Build 3), and the absolute limit on what to add is pretty much final: 11 different widths of draggable RHW, times three to account for L1 and L2 variations, plus an additional 6 for L3 and L4. The final widths are RHW-2, RHW-3, MIS, RHW-4, 6S, 8S, 10S, 12S, 6C, 8C, and 10C. All of which will be receiving L1 and L2 variations, and only MIS, RHW-4, and 6S are receiving L3 and L4 variations. Only two widths (12S and 10C) won't be making a début.

8S, 10S, and 12S will all be sharing a common inner tile, and 6C, 8C, and 10C will all be sharing a common median. As far as modularity, this is as far as it can go given the above limitations, and as far as 4m-lane modularity or ultra-wides in general, it would only be limited to what's practical. Anything wider would be restricted to ortho-only puzzle pieces, with only L0 and L1 variations.

Any more than that would undermine everything that has been done thus far... Again.

[Exla357]

GDO29Anagram: I read about half of that , tried to understand it , and then decided the ultra wide RHW isn't actually a that necessary .
Really though, thanks for clearing up that grey area. I learned a lot 

-Alex

[Twyla]

Dumb question time....

Will turning OFF the intersection (DIP) override on multi-tile networks interfere with pathing functionality?

Just as examples (using NAM Medium capacities):

• 8S ~ All Off - 40,000 network (vs current 50,000), 5,000 per lane
• 10S ~ Inner Off, Outer On - 45,000 network (vs current 50,000), 4,500 per lane
• 12S ~ All On - 50,000 network, 4,166.7 per lane
  
  
• 6C ~ All Off - 30,000 network (vs current 37,500), 5,000 per lane
• 7C ~ Outer Off, Inner Off, Outer On - 32,500 network, 4,642.9/lane
• 8C ~ Inner Off, Both Outers On - 35,000 network (vs current 37,500), 4,375 per lane
• 9C/10C ~ All On - 37,500 network, 4166.7/3,750 per lane

(In the cases of 12S and 10C, I'm presuming that the outer tiles for these networks could have the capability of activating the DIPs for their corresponding (adjacent) inners.)

Should the technique of selectively activating the intersection overrides be feasible, the solution for capacities (both orthogonal and diagonal) becomes simple:  The orthogonal 4m 1/2-lane segments wouldn't use them, while the 3/4-lane segments would - also, the 1/3-lane segments would disable the overrides of their inward neighbors while the 2/4-lane segments would enable them.  (This, of course, could be adjusted in regards to diagonals as needed).

The above (using the true-4m approach) would result in the following capacities (again, using NAM Medium):

• 4S ~ 20,000 network - 5,000 per lane
• 6S ~ 25,000 network - 4,166.7 per lane
• 8S ~ 40,000 network - 5,000 per lane
• 10S ~ 45,000 network - 4,500 per lane
• 12S ~ 50,000 network - 4,166.7 per lane
• 14S ~ 55,000 network - 3,928.6 per lane
• 16S ~ 60,000 network - 3,750 per lane
• 18S ~ 65,000 network - 3,611.1 per lane
• 20S ~ 70,000 network - 3,500 per lane
• 22S ~ 75,000 network - 3,409.1 per lane

Assuming such a technique is possible, user-customization becomes unlimited AND the real-world diminishing per-lane capacities realistically reflect the diminishing returns (due to increased weaving of traffic) of additional lanes.

RealHighway, indeed!

(May be nothing more than a pipe dream, but at least it's an idea.  )