RHW (RealHighway) - Development and Support

[Durfsurn]

Ahhhh photo editing, confusing new members of the RHW since RHW5.0. I can't remember which pic but there was a stack picture in the manual photo edited to be über compact.

[GDO29Anagram]

Ahhhh photo editing, confusing new members of the RHW since RHW5.0. I can't remember which pic but there was a stack picture in the manual photo edited to be über compact.

[memo]

Ahhhh photo editing, confusing new members of the RHW since RHW5.0. I can't remember which pic but there was a stack picture in the manual photo edited to be über compact.

That, actually, was real.

[Durfsurn]

Naw... really? I thought it had a point of 3 networks on one tile?



So this was actually made? I thought I saw somewhere 3 networks on one tiles was possible but near impossible to code/model etc.

[woodb3kmaster]

IINM, the "networks" to which that statement refers are networks that all carry different types of traffic, e.g. car, tram, pedestrian... The Tram-Avenue-under-MHW puzzle pieces were the first to overcome that specific limitation, and from what I remember of the discussions back then, they were, indeed, a nightmare to code. Since a stack (or, one would hope, FLEXStack) puzzle piece would only contain RHW networks, that caveat might not apply. However, I could be wrong.

[GDO29Anagram]

Naw... really? I thought it had a point of 3 networks on one tile?

So this was actually made? I thought I saw somewhere 3 networks on one tiles was possible but near impossible to code/model etc.

I had to exclude a section on how to draw 3-level crossings on the basis of "it wasn't ready", but left the picture of a 3-level crossing on the basis of "just to see what would happen."

Also, that was me who said the 3-level crossings were near impossible to implement:

Out of curiosity...
It is my understanding that with the next version of the RHW there will be 3 levels of elevated RHW: 7.5m, 15m and 22.5m. If this is so, will it be possible to build elevated RHW at those different levels and have multiple levels overlap on the same tile(s)? That would definitely allow for even more realistic constructions. 

1. It's actually five levels: 0m, 7.5m, 15m, 22.5m, and 30m. All networks (MIS, 2, 3, 4, 6S, 8S, 10S, 12S, 6C, 8C, 10C) will be receiving L0-L2, and only MIS, 4, and 6S will be receiving L3 and L4, giving a grand total of 39 networks. 40 if you add in DDRHW-4.

2. It's theoretically possible, but there are problems of having multi-level overlaps like that:

- The number of overlap crossings would be monstrous. Instead of dealing with OxO, OxD, DxO, and DxD, you need to add OxOxD, OxDxD, DxOxD, OxDxO, DxOxO, and DxDxO for L0-1-2, L0-1-3, L0-1-4, L0-2-3, L0-2-4, L0-3-4, L1-2-3, L1-2-4, L1-3-4, and L2-3-4 for MIS-MIS-MIS, RHW-2-2-2, RHW-4-4-4, and so on. (Give me a while to work up the exact number.)
- Depending on the pathing, there may be cases where the end result is deck-jumping, which is the main issue with same-direction same-network-type double-decker networks.
- It can't be draggable, so it must be in a puzzle piece form. This, coupled with the number of crossings, could make this idea unworkable and impractical to implement for every network.

There were pieces like this back in version 5 development, but they haven't resurfaced as of yet for P57, and if there is, they need to be limited.

However, the first instances of draggable 3LCs first propagated in December, two months after with a conversation that went like this: Alex discovered the potential makings of a 3-level crossing (which, by the way, if you don't know this already, you can already make a 6-way RHW-2 crossing; that was one of the proposed 3LC footprints), I was discussing patterns of how to make a stack interchange and how to make it more compact, and brought up the idea that in order to get a suitably sized stack, there would need to be two different O×O×D crossings involved. After that, Markus brought that he's been toying with the idea of 3LCs... and that he's been thinking about it for weeks prior to either myself or Alex talking about 3LCs ourselves, and the nutsiest part is that he's got EVERYTHING solved before anyone else's brain melted: scheme, coding, models, implementation, everything.

[Tarkus]

I seem to recall at one point that we tried to remove the image before NAM 31.0's release.   I had a version of the PDF of the User Manual that deleted the entire cover page.  However, the cover page, complete with that image, managed to slip in anyway, and has been a source of befuddlement since.  The truth about these things has been known to an extent since October, however, as seen here.  As far as when that particular feature is going to be released, I suspect it won't be until after P57-Mk4 is in place.

When we Photoshop an image, we tend to make things look less impressive rather than more (or outright outlandish, like the really Escherian L1-over-L4 RHW pic memo did), mainly to conceal things we may be developing but aren't ready to fully reveal.  I still remember how much I was able to screw with people when I sneaked one of the first RHWs into a pic.

And the guy you have to thank for tricking the RUL0 and RUL1 limitations with MHW-over-TiA and the like is Chrisim.

-Alex

[GDO29Anagram]

The truth about these things has been known to an extent since October, however, as seen here.

OK, now that reduces the time gap between me saying "3LCs are devilishly hard to implement" and Markus actually implementing 3LCs from weeks down to just five days.

I never read what happens in the Interchange thread these days...

[GDO29Anagram]

Alright, back to ramps.

I kinda forgot when I made these ramps, but it was right before my birthday, if I can remember right.



Yes, all of them are draggable, and yes, the RHW-2 ramps are now 5 tiles long. This is because of how other Type C1 ramps are also 5 tiles long due to super-complicated geometric reasons.

[Durfsurn]

In terms of content (code) is NAM 33 (RHW wise) larger than the MHS (NAM 31)? Becuase there is a lot of cool interfaces included! FLEX (WAVERide?) is getting better as are the EDRI's. Really excellent job guys!

*Now I have to fix those damn paths*

-Durfsurn

I think this got kinda buried.

EDIT2: I still get the 3 weird black squares on the preview model (http://i.imgur.com/zsXweww.jpg). Do I have to delete the s3d offenders or other files as well? One last thing I might have to ask for some help on the rotation of the piece. I have the 'exit' piece almost done but for some reason one of the rotations doesn't appear. Here is my code for it in the RUL0 file:

Code Select Expand

[HighwayIntersectionInfo_0x0005FF1]
;Added by Durfsurn 07/09/2014
;RHW-8S Ramp Type F1 Outside Inverted - Exit Ramp
Piece = -16.0, 0.0, 0, 0, 0x5FF10005
PreviewEffect = preview_rhw8sf1outsideinverted


CellLayout =...........
CellLayout =...........
CellLayout =....AA....<
CellLayout =....AA.....
CellLayout =....AA.....
CellLayout =...AAA.....
CellLayout =...........
CellLayout =...........
CellLayout =....^......

CheckType = A - dirtroad: 0x02000200

ConsLayout =...........
ConsLayout =...........
ConsLayout =....||....<
ConsLayout =....||.....
ConsLayout =....||.....
ConsLayout =...|||....
ConsLayout =...........
ConsLayout =...........
ConsLayout =....^......

AutoTileBase = 0x5FF10000
ReplacementIntersection = 0, 0
PlaceQueryID = 0x5FF10000
Costs       = 410

[HighwayIntersectionInfo_0x00055FF1]
CopyFrom = 0x5FF1
Rotate = 1
[HighwayIntersectionInfo_0x00065FF1]
CopyFrom = 0x5FF1
Rotate = 2
[HighwayIntersectionInfo_0x00075FF1]
CopyFrom = 0x5FF1
Rotate = 3

-Durfsurn

Still getting these problems :/

[jdenm8]

Just remove those parts of the Preview Model (deleting the groups for them will suffice) and the textures tied into them.

[Durfsurn]

Erm Jdenm8 I did delete the groups to no avail. Here is the video showing the rotation issue with the RHW ramp and showing the pathing error I did somehow 

http://www.youtube.com/v/GOORTNRIhSQ

I also attached a .zip of the two dat files (the GLR bend and the FARHW ramp) but noticed that I need to fix the offset issue in the RUL0 of the GLR bend

Thanks for all the help again,
Durfsurn

[jdenm8]

I've got no idea what you've done to that ramp interface's models, it's frikkin' weird. The texture's made one way, but the model's done exactly the opposite. 5FF10200's got no business wrapped around 5FF10000. Looking at the layout of the piece, 5FF10000 shouldn't even exist, it's a completely empty tile.

Though I was able to fix the preview, it's pointless as something is fundamentally messed up. I would recommend regenerating the PP and all of its associated files. Also, typically the texture is made in the same orientation that it is mapped onto the Preview Model, you've done it flipped horizontally. Aside from that flipping, there's a few smaller issues. Slight overcompression and some Holes caused by errors in the Alpha Map are the most glaring.

As for the GLR piece, it does look like you've fixed the error I pointed out, which is good. I noticed a naming error on one of the paths, but that's only ever an issue we'll see, it doesn't effect anything. As for why the paths are wrong... They're not. They match up with the textures fine. You've done largely the same thing you did with the RHW piece, all of the models are wrong. If you're using JMVL's Puzzle Piece Creator, make sure "Mirrored version" is unselected.

[GDO29Anagram]

In terms of content (code) is NAM 33 (RHW wise) larger than the MHS (NAM 31)? Becuase there is a lot of cool interfaces included! FLEX (WAVERide?) is getting better as are the EDRI's. Really excellent job guys!

Technically, the MHS is pretty much all of the RHW's elevated networks and crosslinkages with each other and all the ground networks combined, and that by itself is already large. If RHW were just ground networks (and you can totally do this by uninstalling all of the L1-L4 networks), you'd have a significantly smaller Controller and a significantly more boring installation.

The MHS is more like how the MIS is today; few people ever pays attention to it because of how engrained into the RHW it's become. The MIS was referred to being a component of the Modular Interchange System, which actually consisted of the MIS networks (originally called MIS-1, presumably because MIS-2 and MIS-3 networks could have been drawn, by analogy) and the Ramp Interfaces (of which they were limited and had no consistent naming system). The MIS-1 designation was long since removed (presumably because of me), ramp interfaces became standardised (which was totally me), and now MIS is just simply referred to as being the name of one of the networks; personally, if the MIS network were created today, its name would be either RHW-1 or PIN, for primary interchange network. Similarly, the MHS the same: it's just all of the L1-L4 networks and no one thinks of it as being the MHS.

On the same topic, no one ever uses the term WaveRide anymore; I don't even use the term WaveRide. Vince coined the term WaveRide when he first created the first-ever FlexFly, which, by his standards, was based off of a WaveRide system, which uses anchor points defined in RUL1, overrides defined in RUL2, and a puzzle pieces entry defined in RUL0 (for even placing the thing in the first place). I believe the term WaveRide fell out of use to describe Flex pieces as a whole because of FlexRamps; FlexRamps don't use RUL1 anchor points, it instead uses INRULs, and because of that, the entire piece is its own anchor point. Nowadays, the term "Flex Piece" is used to describe any sort of dynamically self-overriding puzzle piece that can override itself accordingly depending on what networks are connected to it, using either RUL1 anchor points or INRUL-based patterns. By that standard, the FlexFly wasn't even the first-ever Flex piece: it's actually the Diagonal Street Helper Piece.

Or if you prefer how I number things, FlexFly was the first, the Avenue Roundabout was the zeroth, and the DSHP was the -1st.

And another technicality is this: Most of the time, I don't capitalise all of the letters in FlexRamp, FlexFly, or FlexWhatever unless I'm writing official documents or writing the text for a teaservideo: technically, the officially spelling is FLEXFly, FLEXRamp, or FLEXWhatever, but to me, I find it convenient whilst typing to not capitalise and it avoids people asking whether or not FLEX is an acronym. Plus, when you get to something like the FlexHeightTransitions, I write it as FlexHT or FlexOST, but the official spelling is FLEX-HT and FLEX-OST.

And for the record, EDRI and FlexRamps use the same exact override code, so when I write the override code for the RHW-6S Type E1 Inside Ramp, for example, I've already written the overrides used for its DRI pattern and its FlexRamp. (That's the magic of INRUL-based Flex pieces; you can assign two different patterns to code for the same exact thing.) As to how many lines of RUL2 code EDRIFlexRamp uses, before I began, the section for FlexRamps was only about 4500 lines of code, including comments. Now it's nearly 6600 lines of code. I've estimated the FlexRamps section to balloon anywhere between 10000 to 15000 lines of code, but as it stands, it might fall short of 10000. But even then, that's small compared to the FlexFly; the reason FlexFly is far larger is because it's gotta have different networks flying above or below it, sometimes different combinations of networks that are above AND below. The estimate for that was around 50000 lines of code.

Also (and even still I find this shocking), the entire section of Draggable Ramp Interfaces originally consisted of, drum roll please...

SIX RAMPS. Nothing else, and two of those didn't even work properly. Four of those ramps are the Type A1, A1 Dual, B1, and B1 Dual. The two other dysfunctional ramps were the Type D1 and E1. I don't even know the story about the original Type D1 and E1 Ramps, which predate the current naming scheme and were named Type C and D. I'd have to go searching for their backstory...

[Death50]

It's amazing the work that has been done and how far it's come.

Is it possible to have a two lane FlexFly? It's always bugged me. I figured it was a code issue or something like that.

And I doubt it comes up often, but the new piece that splits two ways with three lanes each (one side a FAR) is great!

[GDO29Anagram]

Is it possible to have a two lane FlexFly? It's always bugged me. I figured it was a code issue or something like that.

You could theoretically retrofit the current FlexFlys to be RHW-4 FlexFlys, but 4×4 would be too small for such.

It's technically a coding issue in that it's gonna take a lot of code and the Controller is already weighing us down, so we either add it and people's computers slow down or even crash (and we've had people bring up issues related to controller size), or we don't and we avoid the problem altogether.

It's also for this reason that the following is likely never gonna happen:

FlexStacking: stacking two different FlexFlys on top of one another. Crosslinkages would be a nightmare, especially when you include other networks above, below, or in between the two different Flyovers.

The SAM equivalent of RHW: this is still in the FAQ and no one has ever brought it up in years, but just by the size of RUL2 alone, this is now doubly impossible.

RHW-12S and RHW-10C: Just adding six more networks would call for a 34% increase in controller size.

This can be mitigated by selectively turning on or off certain features of RHW at a time, hence this "decoupling of network rules" you often hear about; you could turn off all of the stuff you don't need and be fine and dandy, and you can be even more selective, for example, by turning off L3-L4 networks, or even individual networks, IF AND ONLY IF you do not plan to build any such networks or, if you have any of them in your city already, you do not touch them.

Thing is, people tend to want all of those features turned on constantly, and that's where things go wrong. Unless something happens that allows us to majorly simplify everything (and ideally I'm talking about being able to create whole new networks without the need for starters and instead have each network have its own unique INRULs, thereby transferring all of the workload off of RUL2 and onto RUL1, where only crossings are needed to be handled), we can't just keep on adding things that aren't necessary or code-hungry.

[Durfsurn]

Wow thanks for all the help and massive info blocks Jdenm8 and Ganaram! I will be sure to try and regenerate the PP's tonight - School starts today so my current working time will be cut short by a lot but still

Thanks,
Durfsurn

[GDO29Anagram]

Wow thanks for all the help and massive info blocks Jdenm8 and Ganaram! I will be sure to try and regenerate the PP's tonight - School starts today so my current working time will be cut short by a lot but still

As nifty as it is to learn how to make a puzzle piece and all, I don't see it as being as nifty as creating a Flex piece. Not once have I ever made a ramp interface using the puzzle piece method of using just RUL0; all the ramp interfaces I've made thus far has solely been INRUL and RUL2.

In fact, I might run you through the process of INRUL modification later on down the line, but we'll wait after you master RUL0 first.

[Durfsurn]

It seems that the PP system for the NAM at least is going out of fashion and in come the FLEX set! I would love to learn more INRUL and I have had a peek at RUL2 and it seems like a lot of uncomplicated strings. Lots and lots and lots of them but still. INRUL I haven't looked into quite yet but maybe soon!

Thanks
-Durfsurn

[jdenm8]

PPs aren't useless yet. There's still several things that are impractical to do with any combination of RUL2 or INRULing.