RHW (RealHighway) - Development and Support

[Bob2005]

Ah, yes. I did wonder what those letters meant. I have all but the L3 and L4 networks selected, and of those the DDRHW Networks option is prefixed with *NR*, and the others all have *SR*. The FARHW has no prefix, but is listed in bold.

*NR* indicates No Rules which means that none of the networks will be installed with rules, thus, they don't convert if you drag them in the game. *SR* stands for Some Rules which means that rules for some of the networks are selected, for others they aren't.

This can only occur, if the 'decoupling' option is selected, or has been selected previously. It gives the network nodes three different states: unselected, selected, and selected with boldface font. You would want to toggle those nodes until they are selected, but not displayed in boldface, so as to get rid of all the *SR* and *NR* prefixes.

Some of the other category names are also in bold (Traffic simulator and related options, and Road textures and markings, to name a couple), but they all seem to work fine, so I'm guessing that's unrelated.

Indeed, this is unrelated. These root nodes will always be displayed that way.

Well, I guess it's quite possible I checked it once when installing a previous NAM version or something. I've been playing this game on and off for years, so I may well have completely forgotten about it.

It took a bit of fiddling to get it to let me toggle all the nodes so that they include all the rules, but that seems to have done the trick. Thank you very much!

[vinlabsc3k]

Sorry if the wrong place, but I have a strange issue with NAM 32.
After some weeks, I play SimCity 4 and load a city with draggable El-RD and the viaducts are vanished. I go to the Roads Menu and the icons aren't there.
I open the Plugin folder and, in the Elevated Road Networks folder, I find 2 files:
NetworkAddonMod_RoadViaducts.dat (3.117.828 byte) and NetworkAddonMod_RoadViaducts_Draggable.dat(62.853 byte).
I've tried to re-install the NAM, but the issue persisted.

What happened?

[CahosRahneVeloza]

I've been trying my best to follow this guide for building a T Interchange:

http://sc4devotion.com/forums/index.php?topic=14073.msg422944#msg422944

But I'm stuck at the 3rd photo. Whenever I drag the diagonal ground RHW as Haljackey said and connect it to the other stub the RHW & ERHW would mess up:



I can get it to work somehow, if I add an extra nub of diagonal RHW to where it should meet the other transition stub. But as soon as I demolish the nub the thing gets messed up immediately.

[woodb3kmaster]

It looks to me like you didn't follow that guide precisely enough. The third picture in it (where you've been getting stuck) shows that you're supposed to drag the diagonal ground RHW before you drag any overpasses. Only after dragging the ground RHW can you then drag the overpass across it. I can confirm that the method I just described works perfectly, since I've tested it myself and run into no issues like yours.

[CahosRahneVeloza]

Thanks woodb3kmaster  finally got 'em to play nice:

[vinlabsc3k]

I'm still waiting for a reply for this issue.

[Pat]

I'm still waiting for a reply for this issue.

HI there Vinlabsc3k when waiting for help for an issue there is no need to re-link to it if its on the same page, just wait patiently as I am sure someone is out there who can help you with this matter OK

[Tarkus]

I'm still waiting for a reply for this issue.

The team as a whole is not terribly active at the moment (save for the MTA), as quite a few of us on the development/bugfixing side are actually taking a bit of a break at present.

The file size you've cited for the viaducts is way smaller than the actual file should be (it should be 1,065,495 bytes, not 62,000-something), so it sounds like somehow, your draggable viaducts file became corrupt.  I don't know how or why that happened, but it sounds like it's the cause of your issue.  Sounds like you'll want to reinstall it.  A slightly updated version is available here.  If the issue pops up again, or anything related to a non-RHW item like the viaducts, try posting in the general NAM Issues Thread.

-Alex

[vinlabsc3k]

Thanks Alex for the reply and solution.
I sensed that there was something wrong.

@Pat: I know I was a bit pushy, but I can conceive a period of 4-5 days or a week to wait and
it would be more polite a courtesy reply if those concerned are busy than to be waiting.
(Ex. "We're working on." or "We are busy, it will take some time.")

I was anxious in this 17 days, but it's my nature.

[Durfsurn]

Would it be possible to rotate the existing height transition models 45^o to make diagonal transitions? I'm sure it would take a lot of coding but when you guys get back into the groove after a well earn't break could this be looked into?

Just an idea -
Durfsurn

[Tarkus]

Unfortunately, it's not that simple.  Simply rotating them results in pretty significant misalignment, due to how they fit with the grid.  Diagonal transitions will require completely new geometry.  The coding, pathing, etc. is the easy stuff.  If we had the models for those diagonal transitions, or for things elevated ramp interfaces, we could add them pretty quick (the latter especially so).  It's just that the models (and their integration) are a very specialized task. 

-Alex

[Durfsurn]

So a reskin of the existing diagonal transitions for road, OWR and ave would work either? (I know their old style e.g. steep as but still would be cool). Same with the onslopes?

Thanks
Durfsurn

[GDO29Anagram]

So a reskin of the existing diagonal transitions for road, OWR and ave would work either? (I know their old style e.g. steep as but still would be cool). Same with the onslopes?

Reskinning existing diagonal height transitions wouldn't be viable. Since there are only 15m height transitions for Road/OWR/Avenue and no 7.5m equivalents, the slope would be too far extreme, and given the future-proofing effort for all RHW network models done by a long-retired NAM team member (RHW-4 diagonals actually have a properly widened shoulder, compared to past iterations of RHW), they would not mesh properly.

[eggman121]

Diagonal OSTs have been something on my wishlist for some time now so I took it upon myself to implement a prototype in game. The modeling was easy enough but the importing into the game is another story  .

This is as far as I got... Forgive my rushed modding



I anticipate that there would only be single tile networks for the Diagonal OSTs since double and triple tile would be too hard to achieve. 

-eggman121

[Durfsurn]

Wow. That is awesome! Will that be ready for the next release Eggman?

[Pat]

Thanks Alex for the reply and solution.
I sensed that there was something wrong.

@Pat: I know I was a bit pushy, but I can conceive a period of 4-5 days or a week to wait and
it would be more polite a courtesy reply if those concerned are busy than to be waiting.
(Ex. "We're working on." or "We are busy, it will take some time.")

I was anxious in this 17 days, but it's my nature.

LoL vinlabsc3k I can totally understand 17 day wait for help I wont hold it against you this time as im a nice guy lol 

[GDO29Anagram]

I anticipate that there would only be single tile networks for the Diagonal OSTs since double and triple tile would be too hard to achieve. 

Will that be ready for the next release Eggman?

Let me point out something here:

- First, with proper models, diagonal OSTs can be made; it's just a matter of, 1, making the needed models (which would likely beset the development of >6S pieces), and 2, (if such pieces get made) getting adjusted to the large amount of dead space that the wider transitions would have.
- Second, with the Flex piece paradigm, normal puzzle piece versions would not be desirable, even as an interim piece. The matter here, then, would be to create a base RHW-2 FlexOST (and all Flex pieces have to be this way, by default), and then add the needed code to create the MIS OST. As a note, however, an RHW-2 OST model can be easily converted to an RHW-4 OST model, so if an RHW-2 piece is made, an RHW-4 piece can easily follow.

[eggman121]

With the Flex piece paradigm, normal puzzle piece versions would not be desirable, even as an interim piece. The matter here, then, would be to create a base RHW-2 FlexOST (and all Flex pieces have to be this way, by default), and then add the needed code to create the MIS OST. As a note, however, an RHW-2 OST model can be easily converted to an RHW-4 OST model, so if an RHW-2 piece is made, an RHW-4 piece can easily follow.

In terms of showing the Diagonal OST the MIS diagonal OST was the first model that I had made. There are no dedicated IIDs for these pieces that I know of (I'm sure that they will become available if I put forward a viable case!) but I wanted to show that the Diagonal OSTs can be created. It just requires some calculations for the modelling.  I fully understand that final DOSTs will be FLEXed. I do plan to make a base RHW 2 and therefore RHW 4. It is just a matter of when

-eggman121

[CahosRahneVeloza]

Following this guide...

http://sc4devotion.com/forums/index.php?topic=14073.msg422944#msg422944

... again. I've been trying to make a 10-S T-Interchange but am having some difficulty making the RHW conform to the 6-S & RHW-4 textures where they should appear when crossing the Elevated RHW sections.

Could someone please post a tutorial on how to make one easily?

[APSMS]

Could you post some pictures of your problems? Usually a 10s wouldn't work for a directional T because the exit in one direction would be the wider RHW, but from the other direction it'd be the narrower RHW. (or it'd be the same width if you use the 10S to 6S FARHW split, but 6s is a lot bulkier to work with).

It's not clear how a tutorial would help you if we don't know what issues to address.