RHW (RealHighway) - Development and Support

[dyoungyn]

Help, I thought this was addressed with NAM 33.  What am I doing wrong.  I tried clicking EVERYWHERE and with no success.  I know I have done this before and not sure why this is doing this.  Problems at 15m and at 7.5m and with Flex Slopes.  Not even sure if this was reported or not.

dyoungyn

I now have an update to this bug.  I tried this interchange once again with the same result; however, I did find a work around.  I ended up placing a filler 6C which fixed the paths.  Only hope this will be corrected in the next update as I truly do appreciate the capability from the entire NAM team for giving us this option for interchanges.

dyoungyn

[DJSun1981]

How can i build curves from Level 0 to level 2?
45 and 90 degree curve?
With the Nam 34

Hmm, is that possible or not?

[matias93]

How can i build curves from Level 0 to level 2?
45 and 90 degree curve?
With the Nam 34

Hmm, is that possible or not?

Considering that the L0 to L2 flex ramp is 8 tiles long, you had to have a curve long enough to preserve that minimum slope. Up to what I've seen, there's no such curve. What you could try is to make the curved slope terraforming and then plopping a legacy puzzle-based flat curve (not a L0 flexfly), but maybe this workaround does not match your specifical trouble.

[DJSun1981]

@matias93 thank you for your help:

Sadly, the static puzzle pieces are no longer inside the NAM 34, coz with the static puzzle pizzes such curves (45 and 90 degree L0 to L2)was possible to make

[Tarkus]

The static piece is still there, but it's not installed by default anymore--it's under the "Deprecated RHW Height Transitions" option.  There is only a 90-degree version--a 45-degree version was never made.  The idea of coming up with a new FLEX equivalent has been discussed, but the current one was built to the old standards, when L2 was still considered low elevation.  Any replacement is going to be L0-L1, probably with a slightly wider radius (more akin to the current FLEXFly specs), so it's going to require new models before we can even consider implementation.

With as large as the RHW is, the transition to the newer specifications has had to be a long-term, gradually-implemented project--we're over 4 years into it (the first Project 57 specs went into internal usage in October 2011), and we still have quite a few features that haven't yet gotten the modern treatment.

-Alex

[eggman121]

Spot the new Piece 



-eggman121

[woodb3kmaster]

Well, that was easy.

That being said, it's a most welcome addition to the RHW (and a long time coming, I might add).

[omgitskosc]

So awesome...

Will there be 4 and 6S versions as well?

[APSMS]

It's FLEXed, so a RHW-2 and RHW-4 version are probably a given.

RHW-6S might require a new model, but it is probably going to be supported too.

Great work! I've been pining for something like that for awhile. Makes McDuell's method obsolete (though, obviously his method has other uses; I just realized what I could use it for in my cities, too ).

[Gugu3]

Great stuff Stephen!

[dyoungyn]

I agree that it is great to see diagonal slope piece at L1.  GREAT JOB.

[Simcoug]

More L1 development... yipee!   

[compdude787]

Yaaay, a diagonal on-slope transition sure is awesome!!

[woodb3kmaster]

While development continues behind the scenes, I just want to bring a little bug to the team's attention. As I just discovered last night, there's a problem with the orthogonal L2 RHW-4 over diagonal L0 RHW-6C overrides:



No amount of clicking around could fix this situation. Given that the two circled tiles are identical in the code, and that the L2 RHW-4 is simply facing the wrong way, I suspect that a single rotation flag was set incorrectly in the RULs for this setup.

EDIT 2016-03-05 0132U: I've taken a look at the RUL2 code for this particular setup, and I think I've found the problem. In the section for the L0 RHW-6C, the lines that handle Ortho L2 RHW-4 over Diag L0 RHW-6C (lines 9207-9223) are as follows on GitHub:

Code Select Expand

0x57080200,3,0,0x57234A00,0,0=0x57080200,3,0,0x57235405,0,0
0x57080200,0,0,0x57234A00,2,1=0x57080200,0,0,0x57235405,2,1
0x57080200,3,0,0x57234A80,0,0=0x57080200,3,0,0x57235405,0,0
0x57080200,0,0,0x57234A80,2,1=0x57080200,0,0,0x57235405,2,1
0x57080300,3,0,0x57234A00,0,0=0x57080300,3,0,0x57235400,0,0
0x57080300,0,0,0x57234A00,2,1=0x57080300,0,0,0x57235400,2,1
0x57080300,3,0,0x57234A80,0,0=0x57080300,3,0,0x57235440,0,0
0x57080300,0,0,0x57234A80,2,1=0x57080300,0,0,0x57235440,2,1
;> TILE 2
0x57235400,3,0,0x57234A80,1,0=0x57235400,3,0,0x57235405,1,0
0x57235405,3,0,0x57234A80,1,0=0x57235405,3,0,0x57235480,1,0
0x57235400,1,1,0x57234A80,3,1=0x57235400,1,1,0x57235405,3,1
0x57235405,1,1,0x57234A80,3,1=0x57235405,1,1,0x57235480,3,1
0x57235440,3,0,0x57234A00,1,0=0x57235440,3,0,0x57235405,1,0
0x57235405,3,0,0x57234A00,1,0=0x57235405,3,0,0x57235400,1,0
0x57235440,1,1,0x57234A00,3,1=0x57235440,1,1,0x57235405,3,1
0x57235405,1,1,0x57234A00,3,1=0x57235405,1,1,0x57235400,3,1

The last two lines of the first section (lines 9213-4) reference IID 0x57235440, which doesn't seem to exist in the L2 RHW-4 dat. The corresponding lines in the Orth L1 RHW-4/Diag L0 RHW-6C section reference 0x57235480 instead, which definitely exists (and appears to be the mirror of 0x57235400). The same reference is also found in lines 9220 and 9222, in the "Tile 2" block. My hypothesis is that changing the seemingly-erroneous references to better resemble their L1 counterparts will solve this issue. Am I on the right track here?

EDIT 2016-03-05 0147U: I almost forgot to mention that the same references to 0x57235440 are also present in the code for higher-level Orth RHW-4 over Diag L0 RHW-6C.

EDIT 2016-03-05 2253U: After making a few other corrections to the IID references, I succeeded in fixing the L2 DxO intersection above. However, in testing the other RHW-4 height levels (3, 4, and DD), I found it impossible to continue the overrides across the whole width of the diagonal L0 RHW-6C without plopping an extra set of RHW-4 starters opposite the original ones. A cursory look at the override code for the C Median DxO intersections revealed yet more errant references - this time, to an exemplar (0x57X35380) with no associated model or path files. The L1 RHW-4 code block lacks these references, and I had no issues dragging it as a control. I suspect that changing the references for the higher-level RHW-4 intersections will likewise solve this issue.

EDIT 2016-03-06 0034U: Well, my fix works for the L2 RHW-4 intersection, but not entirely for L3/L4/DD; the overrides for those networks still won't continue across the other half of the diagonal L0 RHW-6C without a second starter on the other side. I suspect this issue is lurking somewhere else, perhaps in the code for these other heights. For now, however, I'm satisfied that my edited code works for L2. For the team's benefit (and possible further testing), I am including my L2 code below.

Sec7b_09_L0_RHW-6C.txt, lines 9206-9223:

Code Select Expand

;L2 RHW-4
0x57080200,3,0,0x57234A00,0,0=0x57080200,3,0,0x57235405,0,0
0x57080200,0,0,0x57234A00,2,1=0x57080200,0,0,0x57235405,2,1
0x57080200,3,0,0x57234A80,0,0=0x57080200,3,0,0x57235485,0,0
0x57080200,0,0,0x57234A80,2,1=0x57080200,0,0,0x57235485,2,1
0x57080300,3,0,0x57234A00,0,0=0x57080300,3,0,0x57235400,0,0
0x57080300,0,0,0x57234A00,2,1=0x57080300,0,0,0x57235400,2,1
0x57080300,3,0,0x57234A80,0,0=0x57080300,3,0,0x57235480,0,0
0x57080300,0,0,0x57234A80,2,1=0x57080300,0,0,0x57235480,2,1
;> TILE 2
0x57235400,3,0,0x57234A80,1,0=0x57235400,3,0,0x57235485,1,0
0x57235480,3,0,0x57234A00,1,0=0x57235480,3,0,0x57235405,1,0
0x57235405,3,0,0x57234A80,1,0=0x57235405,3,0,0x57235480,1,0
0x57235485,3,0,0x57234A00,1,0=0x57235485,3,0,0x57235400,1,0
0x57235400,1,1,0x57234A80,3,1=0x57235400,1,1,0x57235485,3,1
0x57235480,1,1,0x57234A00,3,1=0x57235480,1,1,0x57235405,3,1
0x57235405,1,1,0x57234A80,3,1=0x57235405,1,1,0x57235480,3,1
0x57235485,1,1,0x57234A00,3,1=0x57235485,1,1,0x57235400,3,1

Sec7b_08_L0_RHW-C median.txt, lines 3961-3970:

Code Select Expand

;L2 RHW-4
0x57080280,3,0,0x57234A80,0,0=0x57080280,3,0,0x57235380,0,0
0x57080280,0,0,0x57234A80,2,1=0x57080280,0,0,0x57235380,2,1
0x57080280,3,0,0x57234A00,0,0=0x57080280,3,0,0x57235300,0,0
0x57080280,0,0,0x57234A00,2,1=0x57080280,0,0,0x57235300,2,1
;> TILE 2
0x57235300,3,0,0x57234A80,1,0=0x57235300,3,0,0x57235380,1,0
0x57235300,1,1,0x57234A80,3,1=0x57235300,1,1,0x57235380,3,1
0x57235380,3,0,0x57234A00,1,0=0x57235380,3,0,0x57235300,1,0
0x57235380,1,1,0x57234A00,3,1=0x57235380,1,1,0x57235300,3,1

I hope some good will come of my sharing this code.

[dyoungyn]

I think we have a color discrepancy here.  The pix below is what RHW 8C diagonal looks like in the region view  Even the FAAR 8C gentle curves.  Personally, I would rather have 6C look like this and 8C the same color as Real Highway.

[Tarkus]

Due to how the RHW Transportation View plugin works, there's likely no way to fix that.  It seems some model-based items (which the FARHW-8C would be, being puzzle-based right now) have some quirks with that.

-Alex

[Geometry123]

A couple of bugs I have discovered:

* RHW-8C lane reduction cosmetic piece is completely blank. Not sure about paths, but the piece appears completely blank.
* Not sure if it affects all the 3-tile cosmetics, but I couldn't override them on top of starter pieces.

[Haljackey]

Been about 10 years since I made this stretch.

https://c2.staticflickr.com/2/1613/25639900493_f173da199f_o.jpg

Time flies, eh?

https://c2.staticflickr.com/2/1607/25637804184_140e0deba7_o.jpg

[InvisiChem]

Beautiful work as always Haljackey. I love watching your network progressions. They teach me alot. BTW, loved the building a city from scratch series. I originally watched them to learn how to use the NAM, but found my networks became more fluid from your work. Thank you and enjoy.

[GMT]

there's no on/off ramps for diag 8s yet, widest is 6s, right?