RHW (RealHighway) - Development and Support

[Tarkus]

Any chance the RHW-6C to 6S symmetrical transition will get FLEXed, or is that likely to stay a PP given it's specificity?

Yes, the plan is for symmetrical versions of all six of the width transitions mentioned in my post to be covered with a FLEX piece.  That's the next step.  I haven't shown it yet, but the more straightforward transitions (i.e. RHW-6S-to-4, etc.) have already been FLEXed.  After all of that, the only width transitions left would be the RHW-2-to-4 and RHW-3-to-4 setups.  In total, it'll take a total of five FLEX-WT pieces to replace the current contingent of 30 static width transitions, plus cover a few new setups not included in those 30 (like the 8C-to-10S transition).

The announcment of the QCX (or QLX regarding to APSMS's mad idea) and upcoming FLEX-WT reminds me to ask, whether there is something like a list of acronyms/register people can use to translate. I think this could be pretty useful in respect to the tons of acronyms the NAM has already produced. I asume I am not the first to think about that, so has anybody done it already?
A search in the SC4 Wiki found things like FLEX and RHW, but ERHW, DRI, FTL or QCX were negative. Anyway, a simple list with short explanations, maybe as a sticky thread, might be useful?

(in case none exists, I think I could start to work on that)

I know of at least three glossaries posted around the community--there's one here on the SC4D forums from 2012, one at ST of the same vintage (both forum posts are already stickied), and the one on the Wiki that you already mentioned (which was created from the previous two).  The biggest thing these need is just needs a minor update--there haven't been that many acronyms added since then.  (Edit: DRI and ERHW are already on there.)

-Alex

[Tarkus]

One huge advantage of the new FLEX system--asymmetrical setups where an RHW-6C transitions into an RHW-6S on one side and an RHW-4 on the other become viable.



All of the base FLEX-WT pieces are now in place.  The last override work that's needed is to get these beasts to support RHW-3 input:





After that, it's cleanup (color correction and overhang adding) and pathing.  Presently, I have the FLEX Width Transitions (FLEX-WT) under the same button as the FLEX Height Transitions (FLEX-HT), and the TAB loop with both combined is about a third of the length of the existing one for the static puzzle piece width transitions.

-Alex

[dyoungyn]

Alex,

Looks VERY PROMISING and OUTSTANDING.  Only one concern is in the first pix with the RHW6C splitting into RHW6S/4S has a shoulder in the middle which looks weird when connecting with existing RHW.

dyoungyn

[compdude787]

Looks nice! I really like the merge arrows too!

[Tarkus]

Thanks, dyoungyn and compdude!

Only one concern is in the first pix with the RHW6C splitting into RHW6S/4S has a shoulder in the middle which looks weird when connecting with existing RHW.

The textures are coming right off the non-split ones, where it doesn't look quite so obvious.  I'm going to adjust that in my cleanup phase.

Looks nice! I really like the merge arrows too!

Thanks!  Between what I was able to do with the length standardization (the in-line S-to-S and C-to-C versions are all 4 tiles, save for the MIS-to-RHW-4, and the S-to-C ones are all 6 tiles), and my experiences with the chevrons on the FLEXRamps/DRIs, the merge arrows became a viable possibility.  I modeled the placement right after the MUTCD section on them, and they're built into all the FLEX-WTs where appropriate, without having to use the Cosmetic Pieces.  (And LHD users, worry not--it's just a matter of swapping some IIDs around to get them on the correct side.)

In any case, the RHW-3-to-4 overrides on the RHW-2-to-4 FLEX-WTs are now operational.  I've also determined the footprint also works for the DDRHW-4-to-L1/L2-RHW-4 transition, so it'll be getting FLEXed as well.  The override would work exactly like these RHW-3 versions, except that you'd plug in the DDRHW-4 in place of the RHW-3.  With that completed, the existing RHW Width Transition Puzzle Piece button can be retired.





And here's the one base FLEX-WT setup I haven't shown:



It starts out as an RHW-2-to-3 transition, but it actually supports all of these setups:

• RHW-2-to-3
• MIS-to-RHW-4
• RHW-4-to-6S
• RHW-6S-to-8S (placed in-line with the 8S shoulder)
• RHW-6C-to-8C
• RHW-8S-to-10S

Elevated versions exist of the latter five in the existing puzzle pieces, and so the FLEX-WT will incorporate those as well, making this single piece capable of replacing 16 puzzle pieces.  L3 and L4 support for the MIS-to-RHW-4 and RHW-4-to-RHW-6S will be added, and as soon as the models are made, it'll support L1 and L2 RHW-2-to-3 as well, upping that total to 22.

-Alex

[Gugu3]

This is becoming incredible!

[vinlabsc3k]

I can't waiiiiiiiiit!!

After this, it's the time for Flex-MRC for all height of Road, OWR and NWM

[Tarkus]

Thanks, Gugu3 and vinlabsc3k!

I'd like to show another handy aspect of the new FLEX-WTs--slope tolerance.  Many of the old static puzzle piece-based width transitions had starters on them, which made them rather difficult to use around any sort of slope, even a slight incline.  The FLEX-WTs, however, are extremely slope tolerant, as this rather ridiculous test I put together with a very steep ridge and no slope mod shows:





-Alex

[spot]

RHW has come a long way since the last time I checked. Good job guys! Amazing stuff!

[Jimmyson]

Awesome! That's going to make my rural highways better with steep hills! If I can ever move to a hilly terrain map!

Would the same apply to FARHW pieces? I have tried in the past to build diamond FARHW ramps in my cities, but become a problem with the puzzle piece structure, as I try to level them out, and they easily destroy other RHW roads around it.

[Gugu3]

This is great!building highways in hilly terrains it's going to become fun rather than a pain

[jdenm8]

To be fair, that first one's never had starters. Mandelsoft's prototype was entirely PP-Based and I didn't bother putting on starters (Or an RHW stub on the RHW-3 end, oops) when I polished it up for release.

That doesn't stop it looking awesome though.

[Seaman]

With that completed, the existing RHW Width Transition Puzzle Piece button can be retired.

and

The FLEX-WTs, however, are extremely slope tolerant, as this rather ridiculous test I put together with a very steep ridge and no slope mod shows:

hallelujah!!! christmas seems to be early this year (I hope  )

The cool RHW-3 transitions would go nicely along with some additional ramps for RHW-3 (like d1 or splitter) 

[roadgeek]

I would like to see the median barriers continue all the way through the transition.
I prefer that the shoulder line on one side remains straight as well.

Asymmetry and slope tolerance are definitely worth salivating over!!! FlexFly over FlexFly...well that is just too good to be true...or is it... 

[Allein]

Great work

I've spotted some others bugs by the way.




Yellow can be solved by rebuildind L1 section but seems unstable

[Tarkus]

Thanks, everyone, for the continued support and kind words!   Now, to get to a few comments/questions:

Would the same apply to FARR pieces? I have tried in the past to build diamond FARR ramps for RHW in my cities, but become a problem with the puzzle piece structure, as I try to level them out, and they easily destroy other RHW roads around it.

Provided any new FARHW implementation uses similar techniques with the network flags, slope tolerance would exist there as well.  I suspect it'd be some time before we got to fully FLEXing that whole feature set with the diamond ramp intersections, as that'd likely entail some sort of FTL interface with FARHW.

The cool RHW-3 transitions would go nicely along with some additional ramps for RHW-3 (like d1 or splitter) 

The RHW-3 is one area we're looking at improving in the near future.  Stay tuned.

I would like to see the median barriers continue all the way through the transition.
I prefer that the shoulder line on one side remains straight as well.

Asymmetry and slope tolerance are definitely worth salivating over!!! FlexFly over FlexFly...well that is just too good to be true...or is it...

Barriers have been planned from the get go--they just haven't been made yet.  The alignment of everything works out better with the shoulder line as-is, however, due to the way the pieces operate when mirrored.  I don't have much to add on FLEXFly-over-FLEXFly situations, other than that they would involve a lot of code--definitely not a project for this release cycle.

I've spotted some others bugs by the way.

Thanks for the report!  Those first two are at points where there would be a ton of really complicated adjacency stability involved, so I'm not too surprised.  memo had plans to use his MetaRUL system (which made the new FLEXFly implementation possible) to fix up the RHW base network code, which would have covered those situations, but he's been inactive for a year now, and it's unknown if/when he'll be back.  I do have pieces of what he had done on that project, though some of the specifics of how he put that together are above my paygrade.  I'd rather not code those by hand in light of that, so they probably won't get fixed until either he returns, or I figure out how to decipher what he did to the point where I can get it operational for release usage.

The third one is simply the result of the Elevated Avenue/MIS T-intersections lacking adjacency stability.  In general, T-intersections are going to be a lot more prone to breakage, because they're more complicated, and often coded in a completely different phase of development than the +-intersections.  That one is more likely to get a look in the near future.



While we're on the subject of transitions and swapping from static puzzle pieces to FLEX, the main questions/complaints we've gotten with the creation of the non-default "Deprecated RHW Height Transitions" option has been the curved MIS height transition, which swamp_ig designed for the RHW 4.1/NAM 29 release, almost exactly 6 years ago.  It's pretty much the only real reason why someone who isn't a staunch puzzle holdout and/or really wed to the old elevated paradigm, and would really want to check that box. 

As one would expect from that, this particular transition has been on our radar screen for awhile for re-implementation.  However, given the fact that it's also a product of the old days when L2 was *the* elevated height, its existing models don't match well with the current standards, the new implementation plans also required new models, which is usually a huge bottleneck in the pipeline for these sorts of features. 

However, after digging around some in the private RHW development thread, looking at posts of 2010-2011 vintage, I happened to discover that swamp_ig, being the rather unsung transit modding hero that he was, had actually attached the Max models he used to create the original transition.  After a few days of thrashing about in 3ds Max, learning a few new things in the process, I managed to adapt the source files to produce the elusive FLEX-based L0-L1 90-Degree Curved MIS Transition.  Its dimensions are designed to match with the new 5x5 FLEXFly specifications introduced in NAM 33.



It still requires pathing--and I'm sure the "Pylon Police" probably want to write me a ticket for that image--but this officially puts the old Height Transitions button into full deprecation.  It'll also now be possible to include as a component in future QuickChange-related items, where it should come in handy.

-Alex

[APSMS]

Ah, that explains the FLEXFly. I was trying to rebuild a better version of an interchange I had seen over on ST, and the 45 deg FLEXFly kept breaking at the curved ends on a number of underpasses. It's a shame that memo has been away, but hopefully that bug can get earmarked for fixing when he comes back or when we figure out better how to work the MetaRUL system.

Funnily enough, that one piece is the only reason I've kept the deprecated transitions around. Who knew? well I guess you did....

[Seaman]

Funnily enough, that one piece is the only reason I've kept the deprecated transitions around

me too. I love the curved hight transition for saving space and keeping my cloverleaf turns in a nice shape without a lot of terraforming.

But unfortunately, I didn't get the whole point. I infer from Tarkus' post that a FLEX-based L0-L2 90-Degree Curved MIS Transition already exists  (by him stating that the L0-L1 officially puts the old Height Transitions button into full deprecation).

What exactly will the Flex part in this curve be? To support other RHW types like RHW-4 or is there a integrated Flexfly capability? (with the last one beeing the most awesome and therefore most unlikely feat  )

[Tarkus]

But unfortunately, I didn't get the whole point. I infer from Tarkus' post that a FLEX-based L0-L2 90-Degree Curved MIS Transition already exists  (by him stating that the L0-L1 officially puts the old Height Transitions button into full deprecation).

The old L0-L2 one is a static puzzle piece, hence why it's under the old Height Transitions button.  There won't be a new L0-L2 curved transition made, as it would have to be enormous to fit with present-day RHW standards.

What exactly will the Flex part in this curve be? To support other RHW types like RHW-4 or is there a integrated Flexfly capability? (with the last one beeing the most awesome and therefore most unlikely feat  )

The full features of what it'll be able to do are still up in the air.  The fact that it is FLEX-based does give us the option to eventually support FLEXFly-type functionality, if we decide to implement it.  The more immediate thoughts are of overriding it in various ways, to produce different height levels, like the other FLEX Height Transitions.

Right now, it works about like the 180-degree L0-L1 MIS transition that made its debut in the initial QuickChange launch in NAM 32.  The fact that it is FLEX will, at the very least, allow us to use it in future QuickChange and QuickChange Xpress setups.

-Alex

[APSMS]

FLEXFly like support for higher levels would be amazing, assuming it can be coded just like existing FLEXFly. I assume that would destroy any slope tolerance the piece might currently have?