In one of my cities, an interchange I am building calls for a overpass across a depression in the middle for another highway; if I build the overpass at an altitude of 15 meters all the way across, it will dip where that depression is instead of staying flat all the way through. I had originally excavated the trench to an inverse altitude of 15 meters and wanted the overpass to have an altitude of 30 meters when crossing that trench.
How do I get the NAM to respect my decision to avail 3rd/4th lvl elevation RHW for part of the overpass without it leaving a gap at the edges of the trench? I do not want the sunken highway to have an unsightly rise just to go under an elevated RHW nor do I want the elevated RHW dropping 15 meters simply to cross a sunken highway?
What you do is put a flex onslope transition where the depression is. Then drag the viaduct into it. With a bit of clicking around and use of starter pieces, you should get a transition between levels with the elevated RHW staying level all the way across this depression.
Yeah, don't forget the L3/L4 starter, without it such a setup won't work. So you need to make sure the depression is wide enough to accommodate that and the on-slopes.
These two screen capture show the results of heeding your counsel about availing the OST and the starter 4th lvl e-RHW starter pieces. It worked on a 3rd lvl e-MIS but not on this viaduct. Any ideas?
It seems there is a bug with the onslope transitions for L4 RHW (L3 seems to be ok). Other people have the same problems and reported it already to the NAM/RHW team. Maybe there will be a patch in the next iterations of the NAM??
http://sc4devotion.com/forums/index.php?topic=990.msg505702#msg505702 (http://sc4devotion.com/forums/index.php?topic=990.msg505702#msg505702)
No bug I'm aware of, I'm happily using such transitions with NAM 34.
The issue you linked to is a specific setup where the RUL simply cannot resolve the intersection. Of course that could be improved, but that doesn't make it a bug either. The code to cope with multiple networks intersecting at the same point gets pretty complex. There will always be some situations that will not work. Often, just moving things a tile apart is sufficient for the code to be able to work correctly. Such things are in a constant state of improvement, but there will always be limitations where the best solution is to adapt your approach slightly.
What the duck does "RUL" stand for?
RUL is short for "Network Rule". The game uses RUL files, filled with code, which control the placement of transportation networks. Almost everything in the NAM works because of new code added to those RUL files. All the draggable systems which emanate from starter pieces in the NAM rely most on a RUL file that is most often referred to by transit modders as "RUL2", which, officially, is the "NetworkOverridesRUL". It's one of the RUL files contained in NetworkAddonMod_Controller.dat, one of the most critical files in the entire mod.
To get a little more technical, the code there basically looks at segments of transit network two tiles at a time, and then overrides them into a new setup. The code that allows the L0 RHW-4 to continue into an orthogonal stretch from a starter piece looks like this:
0x57030000,1,0,0x57000000,1,0=0x57030000,1,0,0x57030000,1,0
0x57030000,1,0,0x57000000,3,0=0x57030000,1,0,0x57030000,1,0
0x57030000,3,0,0x57000000,1,0=0x57030000,3,0,0x57030000,3,0
0x57030000,3,0,0x57000000,3,0=0x57030000,3,0,0x57030000,3,0
0x57030000 is the hexadecimal instance ID for the ortho RHW-4, while 0x57000000 is the ID for the ortho RHW-2. Because the RHW-2 is a bi-directional network, and could be facing one of two ways, we have to account for both rotations 1 and 3 in continuing the RHW-4.
When one gets to an intersection situation, the base setup requires code to convert the intersection to fit the override network, and then to continue the override network past the intersection. However, if one wants to build an intersection or overpass using that override network right next to another intersection/overpass, there has to be additional "adjacency" code to handle that specific setup, or else it won't resolve and will "deconvert" to whatever would happen when the base RHW-2 wants to do in that situation. Having an additional tile in there allows the network to fall into a more stable situation, because the game doesn't require adjacency code to handle those cases.
The RUL2 file itself is, as of NAM 34, just shy of 1,200,000 lines, and about 900,000 of those are for the RHW, simply because there's so many adjacency situations we're having to cover, and there's still more we could cover (the line count would become truly scary at that point).
-Alex
thanks for the explanation. I had the adjacency thing in mind, when I built the example, provided here: http://sc4devotion.com/forums/index.php?topic=990.msg505702#msg505702 (http://sc4devotion.com/forums/index.php?topic=990.msg505702#msg505702)
but I thought one or two tiles between height transition and starter piece would be enough. Nice to hear, that they do work (if prolongued and fiddled around).
I'm not sure how long you've been using RHW, but you only have to go back to NAM 31 to get a sense of the leaps and bounds of the improvements since. I'm just wary of saying bug in some of these cases, 1.2 million lines of code can't begin to cover every possibility, but it's constantly evolving and getting better.
I am a RHW fan for quite a while now, but I encountered this problem several times and was not able to solve it in the usual RHW way: clicking around and/or adding an extra tile in between. The search on this forum for some hints brought me to some posts from 2014 http://sc4devotion.com/forums/index.php?topic=990.msg476597#msg476597 (http://sc4devotion.com/forums/index.php?topic=990.msg476597#msg476597)
The confirmation of the problem by Tarkus back then (some posts later) made me think that this problem is equivalent with the problems I encountered with NAM recently. And since I know how busy the NAM team is/how many lines of code are behind the innocent look of the RHW, I considered the problem to somehow slipped through the testing. My bad, if I am wrong. sorry for that.
Regarding the fact, that the NAM is evolving and getting better and better with every iteration, I hoped to contribute to that by bringing the attention to this problem. I sincerely hope no one feels offended.
Nothing to apologise for, I seem to have a knack of coming across the wrong way it seems :/... apologies for that.
Obviously we're always grateful for any feedback we can get. You are quite right to point out that certain things we are simply unaware of being broken. I'm sure you can imagine, with our limited resources, it's not possible to check everything to see if one code change has caused problems elsewhere.
I'll double-check the specific situation outlined here, just to be sure, later today. I'm by no means the RHW expert, but I do know from my own experience a degree of flexibility in terms of putting interchanges together is a solid approach sometimes. If It turns out to be an actual bug, you can be sure we'll attend to it. But the term bug has specific connotations that don't always apply when referring to such a complex beast as RHW. So I hope you don't feel let down if sometimes we don't simply say "yup, we'll fix it". It's no reflection of the validity of your comments, more an attempt to manage expectations.
:Edit:
OK for starters I was confusing your issue with the post above it, so that didn't help ::). Indeed I can't get any on-slope transitions to work when involving a connection to a L4 network. For now I'd use the Ramps, I can't give a time for fixing it, since I've no idea if it will be a simple fix or not. I'm sure I had it working through the Alpha builds of NAM 33, but I could be mistaken.