RHW (RealHighway) - Development and Support

[GDO29Anagram]

Are you guys creating a 90 degree RHW-4 curve?

As a ground-level curve, too tight of a radius to even consider (if compact) and too big of a piece to even create (if bigger), so no.

[Haljackey]

Thought I may as well post this here:

New RHW Interchange Guide: Full Roundabout (by Twyla): http://bit.ly/N01wgO



Regarding a 90-degree RHW-4 curve, you can just plop a pair of 45-degree curves next to eachother.

I made a guide on how to do so here: http://sc4devotion.com/forums/index.php?topic=5548.msg175464#msg175464

Hope it helps!

[GDO29Anagram]

Regarding a 90-degree RHW-4 curve, you can just plop a pair of 45-degree curves next to eachother.

That's effectively the next best thing to making an oversized 90-deg curve for RHW-4.

Note that to make an effectively wide-enough RHW-4 90-deg curve, it would probably have to be as large as the 90-deg DTR curve, 9x9. That, in itself, was a nightmare to path, as Alex said.

And then you have to multiply the work by three to account for the inner, outer, and dual curves? No way. And also, anything smaller than that would be deemed too unsafe from a realism standpoint.

90-deg RHW-4 curve? NEVER gonna happen.

EDIT: A curiosity worth noting is that the 8S Wide Lanes Mod (the RHW April Fools Day mod and RHW V4 Easter egg) will no longer work with P57 RHW due to the inner part of it being shared with the 10S and yet-to-be-created 12S. That is, unless you decide to never redraw your 8Ses or you never go wider than 8S.

OR,... Overhanging RKT-3 at specific zoom levels...

[Twyla]

I just had a weird inspiration for how to pull off RHW-C Bridges....  In reality, it's a single-tile bridge - though it looks and acts like a three-tile C-Type bridge!

Whether via some sort of override generated by the median piece of a 6C/8C RHW or simply judicious use by a reasonably-educated user, the bridge is created by dragging the central lanes.  Creating the 6C/8C outer lanes as overhanging models should be a relatively simple matter.

According to

They can, but it only works when perpendicular to the direction of travel.

To simplify it a bit, when a path enters on the Eastern side and exits on the Western side we can move the path further than 8m on either side (North or South). However, we cannot move it further than 8m away from the centre on the East or West sides.

At least, that's my understanding of it.

Also, as far as I'm aware, this does not work with Pedestrian paths, they will snap to the edges of the tile in-game.

the paths can overhang parallel as well to provide the automata and what-not (particularly as bridges don't have pedestrian paths).

The only kicker is capacity.  While the bridge could be rail-based (as with the DDRHW-4), the bridge would only have roughly half the traffic capacity of normal RHW-6C/8C.  This is still a modest capacity improvement over Blue Lightning's Maxis-Based RHW-4 Suspension Bridge in addition to the aesthetics of LOOKING like a fully-functional RHW-6C/8C bridge.

Just an idea...


PS ~ As an afterthought...  Is there any way the 'intersection trick' could be applied to a rail-based network for the 25% capacity increase?  If so, that would give a rail-based 6C bridge approximately the same capacity as normal 6S - so not too bad a trade-off.

[Tarkus]

The overhang method is one that was discussed for C-type bridges, and I believe one of the prototypes that was done used that method.  It gets to be a bit sticky when you're merging back to the non-overhang setup, however.  The other method that has been discussed was using a DBE-type setup.

The Rail approach would not really solve the problem, unfortunately.  Some recent tests that JD and I did found that there's some hardcoded "quirks" to the capacities/speeds when running non-standard path types down a network (e.g. running car-paths on a Railroad) that nullify the efficacy of that technique.  As a result, we're having to reimplement the DDRHW with a different method for the next release. 

One possibility is changing it from the draggable Rail-based setup to a helper/flex setup based on trick MHW CheckTypes, which would correct the capacity issues, and, as I discovered in building a prototype, would also mean that overpasses can be coded with RUL1 instead of RUL2 (meaning less code, and no worries about adjacency stability code).  The other would be a draggable RHW-based setup with the capacity-increasing Distilled Intersection Paths (DIPs), but this would mean that the DDRHW-4 would have the same capacity as an RHW-3.

-Alex

[Blue Lightning]

RHW-6C/8C bridges will probably be implemented via a DBE-esque method. The prototype I have works very well and has full capacity.

Speaking of bridges...

[kassarc16]

Very nice, and good to hear about the capacity!

[GDO29Anagram]

You can fake a 6C bridge by overhanging the median between two half-6C bridges, but capacity would be stripped down by 33% at the least, and you'd still have the trouble of putting up with overhanging paths, let alone transitioning to and from it, if you even decide to keep the paths.

Or you can make a dual-6S bridge, build it in-game, turn off the grid lines, and pass it off as a 6C bridge; That's another way to fake a 6C bridge.

In other words, triple-tile bridges will have to be zero-slope/DBE.

[Wiimeiser]

So the DDRHW may have to be MHW based? I thought dual-tile networks can't have diagonal overrides? What actually happens here?

[GDO29Anagram]

So the DDRHW may have to be MHW based? I thought dual-tile networks can't have diagonal overrides? What actually happens here?

The inherent problem with overriding dual-tile networks is that it's hard to RUL-1 a starter for something that's two tiles, and RUL-1 (the RUL file that handles all of the two-network crossings and starters, hence the term "False Intersection") works on one tile at a time.

However, you can override even a two-tile network using just RUL-2 code, even diagonals if you tell it to. (FlexSPUI, anypony?)

From what I can gather, DDRHW-4 is still gonna be single-tile, but the exact process of how is yet to be seen or tested thoroughly (and I mean thorough thorough)... Unless you like DDRHWs with 50% less capacity.

[jdenm8]

Now that it's been announced, I may as well post the findings.

When Tarkus originally made the DDRHW, he thought that it would inherit the base capacity, the one for Rail. However, we've found out that the game doesn't work like this. It seems that when using a path type on a network not designed to support it, it will not use the "normal" capacity, It will move down a list of options, ending up at a failsafe, the use of which is hard-coded by Maxis. That failsafe, for cars, seems to be whatever setting is in place for the Road network (Which every other network was cloned from).

I personally think it might have been a method used by Maxis to separate the congestion Data View results given by Rail and Road at level crossings.

I had images of my investigation into its behaviour, which also highlighted a few other issues giving us more reason to change the network, but can't for the life of me find the post.

[Tarkus]

I've dug up my initial report that I posted in our private development thread.  I discovered it while investigating Moonraker0's report that the DDRHW's neighbor connections didn't work.  I actually fixed that issue, but this one then reared its ugly head.  I've excerpted the relevant part of the post.

On another note, I wound up doing some experiments with the DDRHW last night, in the wake of Moonraker0's report that the default draggable NCs didn't work on it, despite the fact that it was a single-tile, bidirectional network.  My suspicions that it had to do with the fact that it was a Rail-based network with car paths was entirely correct, and I ended up rigging up a little override that used a little stub of RHW-2 at the neighbor connector that got converted to DDRHW through a little RUL2 work.

However, there was something more distressing that I found in the testing.  The DDRHW is Rail-based and with the simulator I have installed (basically bog-stock "Medium"), it should have a capacity 1.6x that of a standard RHW tile (16000 vs. 10000).  I built a high-density slum right near the DDRHW so I could feed as much traffic on it to test it, but much to my chagrin, I saw this:



The Rail-based section showed up red, while the little stub of RHW was lime green, showing up with 1% congestion when I queried the NC.

I decided to reconnect the little frontage road down at the bottom to the next city tile, rebuilding it as an RHW-2.  And this happened:



The thing's moving a ton of traffic, and, aside from a little intersection congestion, it's all green with more traffic on it than the DDRHW had.

I decided to build another dedicated test city to get more conclusive results.  My new test city had a basic layout of all residential on one side, and all industrial and commercial on the other, and the R and I/C areas were split in half by a pair of RHWs--one a standard RHW-2, the other a DDRHW-4.  There was a Road connecting both on the I/C side (to allow all residents to reach all I/C jobs), but the Road connection was cut off between the R hemispheres, forcing the north side to take the DDRHW and the south side to use the RHW-2 to access the jobs.

Here's a volume view from after I stuffed enough people into the residential districts (somewhere around 30,000) to get some nice congestion:



As you can see, the RHW-2 is getting a fair bit more traffic on it than the DDRHW.  However, here's the congestion view:



The RHW-2 is still fluorescent green, while the DDRHW is showing up yellow and congested.

Here's another look, once I've stuffed about 55,000 residents on to this medium tile in the residential areas, with the congestion view turned on.



The morning commute volume on the DDRHW (well, on the offramp, though that accounts for all the traffic) is 8453, and it's tomato red.

The morning commute volume on the RHW-2, however, is 9783, and is showing up yellow-orange.



I wondered, to an extent, if this is simply emblematic of a quirk in the congestion view, much like the infamous "instant-red" that happened whenever the Rail connections were used on the old Double-Decker Tsing Ma bridge, or if it's an actual sign that the capacity is not what it is supposed to be on the DDRHW.  So I connected the two residential hemispheres, and let the traffic from the two sides choose which highway they wanted to use.

The DDRHW rapidly lost volume and the RHW-2 won out by a large margin.  A few game months after the two residential sides were connected, the RHW-2 was moving almost 19000 cars (in a city with a population of 53,621), while the DDRHW dipped below 4300.  More tellingly, there was a drop on the Commute Time graph.  This seems to confirm that it's not a display issue but an actual capacity issue. 

From what I observed from looking at the volumes and the corresponding color changes, it suggested to me that instead of using the actual catalog capacity of the Rail network, it instead reverted to the Road network's capacity (4000 on Medium, a 60% decrease rather than a 60% increase).  This persisted even when I added proper speeds to the Rail network for car traffic (they're set to 0 by default in the NAM Traffic Simulator), and unfortunately, seems to be a hardcoded limitation.

In short, it means that a Rail-based DDRHW does not work properly, and a new base network needs to be found.  The only other hopes for having an actual capacity increase include using Lightrail (though judging by the results of this experiment, it's likely to suffer the same issue), using a FLEX/helper piece setup involving single-tile strips of Maxis Highways and trick CheckTypes (the MHW capacity is 15000 per tile with Medium, and would become 18750 with DIPs), or to go back to using the RHW with DIPs as the base (12500--same capacity as an RHW-3).

-Alex

[Wiimeiser]

Now that it's been announced, I may as well post the findings.

When Tarkus originally made the DDRHW, he thought that it would inherit the base capacity, the one for Rail. However, we've found out that the game doesn't work like this. It seems that when using a path type on a network not designed to support it, it will not use the "normal" capacity, It will move down a list of options, ending up at a failsafe, the use of which is hard-coded by Maxis. That failsafe, for cars, seems to be whatever setting is in place for the Road network (Which every other network was cloned from).

I personally think it might have been a method used by Maxis to separate the congestion Data View results given by Rail and Road at level crossings.

I had images of my investigation into its behaviour, which also highlighted a few other issues giving us more reason to change the network, but can't for the life of me find the post.

So, in other words, Autoconnect and RCI access are the only thing actually separating the RHW and Road. The Autoconnect makes sense given it was supposed to be used for farms, probably to fix the bug where any traffic causes farms to abandon instantly, the lower capacity would've done this. This would also explain why only rural lots can access it as well, it was intended to fix a major bug with farms or to make them more realistic, but someone decided agriculture went against the very nature of the Simcity brand and it was "removed" after changing only two of the three exe controlled essentials(the one they didn't do was disabling the diagonals).
This also explains why DIRTROAD uses the Road texture by default.

[GDO29Anagram]

This also explains why DIRTROAD uses the Road texture by default.

No; We simply stole the Road network's information and copied it over to the Dirtroad network itself, and it took 'til version 5 for RHW to have its own dedicated textures.

[jdenm8]

The DirtRoad network only uses the Road textures by default because that's how the original ANT was coded, it used the Road Network's textures.

As for the differences what Wiimeiser said is largely correct, that's the same for all networks (except Monorail for reasons unknown to us, it doesn't accept car paths), not just DirtRoad.

As for the speculation on Wiimeiser's  behalf, most of that is untrue or unconfirmed. DirtRoad was, from my understanding, a 0 maintenance transit network with a very low capacity. It was not designed specifically for farms (Neither Industrial or Commercial zones can access it unless it's been overridden, Residential can never access it) but we don't know why it has Freeway properties (The only thing it has in common with the Highways) restricting access.
Autoconnect is probably inherited from Street, considering it was probably meant to work in a similar way.
As far as it being removed, it was probably seen as superfluous by the developers, the street is already cheap enough and most people would already have had Street fulfilling that purpose. It's much easier and makes more sense to provide additional upgrade options than it is to add downgrade ones. Also, you know those annoying "Some of this should be a cheaper network" popups? DirtRoad has them in the game files, they're just disabled.
It's more a matter of duplicity and time, they only had a matter of months to make all the content for the EP and the DirtRoad network is probably one of the things that were cut but left in, like Incinerators and Desalination plants.

[GDO29Anagram]

And I had already dug up even more dirt, so to speak...

Okay, so this is (almost) totally unrelated to the transport data view above and a completely accidental find that's marginally RHW related:

In SimCityLocale.dat, entry #3513

To me, pavement is a wonderful thing - the hard smooth surface, the extreme heat on a summers day. But it can be costly to create and maintain. If you are looking to save a few simoleons you might consider <a href="#link_id#game.tool_plop_network(network_tool_types.DIRT_ROAD)">dirt roads</a > as an alternative. There's something special about the bumpy ride and billows of dust that only an unpaved path can provide. And what a boon to our local car wash owners!

And in case it turns out it's in a different location in someone else's files, the IID id is: 0x0BF0384D

Looks like this really was supposed to be a rural dirt road, which might be another reason why Maxis didn't have it show in the transport map.

Dirtroad was, true to its name, an actual dirt road which was hastily thrown aside, resurrected from the dead, paved, re-paved, re-paved again, re-paved yet again, and re-paved a fifth time (remember that Dirtroad initially borrowed the Road network's textures and paths), and by the time it was done repaving, it had been a highway-building tool for the past several years.

(There was an country song where the lyrics featured a dirt road eventually becoming a paved road... That's what comes to mind.)

My speculations on Autoconnect's origins: Ever notice that when you zone any type of zoning, it comes with its own Streets? What I thought was that if you had a block of zoning and were adding another block to it, the Street networks of each zone block wouldn't mesh together well, and Autoconnect would be a way to "glue" the two grids of Street network together.

[Wiimeiser]

Just a theory, but Residential needs to spawn on certain "hooks" that are invisible through any means. These "hooks" must legally be able to generate statistical car traffic (try experimenting with Pedmall and seeing what happens). But this just runs me into a brick wall... Hrm...

[jdenm8]

All lots that provide jobs simply need to have a non-freeway network with car paths on it on the front side of the lot. No more.

If you put car paths on the pedmall pieces, they will actually sustain Residential growth as has been proven before.

[Blue Lightning]

Hypothesis, not theory

Commercial and Industrial zones require any transit network that's able to carry at least one of the Allowed Travel Types in the traffic simulator (Default: Car, Sim) on its arrow side, contains paths for car OR pedestrian, and is also not a highway network (and probably rail as well). This is why pedmalls work fine. Traffic can access the zone, given that it's an allowed type, on any side of the zone from any transit network. They seem to grow when conditions are favorable, evaluated before growth, but then run additional condition checking after growth and have a wider tolerance.

Residential zones are far more picky: they will only grow/not no-car zot if the network supports at least car and the tile contains car paths. The zone can send out cars or pedestrians onto any network that can support them and have paths for them on any side. Residential zones seem to run all of their checks (excluding destination/pathfinding) before growing. They also seem to have a much narrower tolerance.

[gn_leugim]

RHW-6C/8C bridges will probably be implemented via a DBE-esque method. The prototype I have works very well and has full capacity.

Speaking of bridges...

first, nice brigde

and second. being implemented via DBE, how do a moddler (I) get the model set for final moding? as 16mx16m pieces? or is there any other way?