NAM Poll: Road Turning Lanes

[z1 566]

The NAM Team is currently considering its implementation of Road Turning Lanes.  Before NAM 31, when this option was enabled in the NAM installer, these turning lanes were automatically constructed whenever road intersections were made.  However, this could result in undesirable interactions with the Network Widening Mod (NWM), such as this:

 

 

For this reason, starting with NAM 31, the way Road Turning Lanes work was changed.  Even when this option was enabled, the turning lanes were not constructed unless a piece of rail track were plopped in the intersection.

 

It turns out that this solution had a slight problem, however.  When Road Turning Lanes were enabled this way, the stoplights on all four corners would be stuck on green.  This is being fixed in NAM 31.2 by using a one-way road piece to enable the Road Turning Lanes.  This solution does not cause any problems with the stoplights.  Unfortunately, there is no keyboard shortcut for one-way roads, unlike the 't' for rail track.

 

So one possibility is to make this option available, but also make the old, automatic construction method available in the installer.  To do so would not require that much code.  When the old option is selected, Road Turning Lanes would work as they used to, but in certain intersections with the NWM they would produce undesirable results.  However, users could switch between the old and new type of Road Turning Lanes simply by rerunning the installer and changing the RTL option.  Existing intersections would not be affected.

 

There is one caveat here:  If you switch from auto-to-semi-auto (as we'll call the first option), if you click on the road near one of the RTL intersections built with the auto version, it will revert to being RTL-less, although you can restore the Road Turning Lanes by just plopping an OWR piece in the intersection.  And if you go from semi-auto-to-auto, while the RTLs built with the semi-auto version will remain the same, should you have built a setup like the one pictured above (though built properly), it will turn into a mess if you click on one of the roads near the intersection.  Of course these can be rebuilt, but it's important to be aware of the possible pitfalls here.  On the other hand, if you pick just one mode and stick with it, these two problems do not arise.

 

Please let us know if you like the new method only, which always works with NWM but which requires the OWR plop for each intersection, or whether you would like a choice between the old and new methods.  If you choose the second option, please also let us know what you think the default behavior should be.  Thanks!

[MandelSoft 2,769]

I'd prefer stability and control over less effort. So I chose option #1 on both of them

[Wiimeiser 444]

Don't make it automatic. I've had enough problems with the NWM when it was automatic.

[A Nonny Moose 8,261]

I, on the other hand, chose the fully automatic option.  Let the chips fall where they may.

 

Arcane "then plop this or that" is getting far too exotic.  So make it an option if you like, but i don't want to be bothered with remembering to do some little nuisance action to get the proper appearance.  I have other fish to fry in this game than the roads.

[Haljackey 17,335]

Automatic is far easier for the average user. For NAM veterans, not having them automatic is something we need to get used to.

-I am for the option to include automatic turning lanes in the installer.

 

Ultimately, I would like to see the RTL textures match that of the TuLEPs. The lanes here are far wider, and look much better. Having automatic RTLs for road/ave intersections would be a plus too.

[A Nonny Moose 8,261]

And, of course we realize that they don't exist everywhere, but that is another problem.  Please, everyone, in spite of all attempts at realism, this is a game.  If it gets much more exotic, it will become unplayable for the average bear and the guys at Yosemite will have to give it up.

[Tarkus 6,932]

Speaking from my perspective as one of the developers who has had to "fight" the RTL, the issue is that the auto-RTL is problematic from a software engineering standpoint, mainly due to encapsulation problems caused by its trigger method.  Quite simply, while the RUL override code is quite nicely designed (vintage Teirusu), the trigger involves changing the Instance IDs (IIDs) of two of the most commonly-built intersections in the game, the Ortho Road x Ortho Road + and its T-intersection counterpart, in the Base Individual Network RUL (INRUL) file that handles the basic properties of the Road network.

This:

1,2,2,2,2
3,0,0x00020700,0,0

Gets turned into this:

1,2,2,2,2
3,0,0x5F020700,0,0

And then 0x5F020700 triggers a series of overrides out from that intersection, and goes through a number of different cases, dependent on the network tiles surrounding the intersection (such as figuring out whether or not the road curves out of the intersection, and the proximity of other intersections).

The problem, however, is that the "auto" RTL was dreamed up in 2004.  Back then, people--even those in the upper echelon of the mod-making community--thought that the game would have about another 3 years or so of shelf-life (evidenced by the fact that the original timestamp-based NAM IID scheme hit a "Y2K" point sometime in mid-2007).  The expectation was that the mythical SC5 would ride in like a white knight on a unicorn, sometime shortly before then, and people would lose interest in SC4 as a result.  No one who was active back then expected that we'd be playing SC4 10 years later, let alone that we'd be using starter pieces to mimic new draggable networks, and using that technique to convert Roads to wider versions. 

 

The interference caused by the "auto-RTL" was part of the reason why the Network Widening Mod (NWM), a project first started in December 2006, didn't see release until May 2010, and most of the RHW/NWM-associated NAM Team members have been lobbying to re-implement the RTL with a non-automatic setup since then.  I ended up making the NWM sort of play nice with the auto-RTL by adding a big stack of overrides, basically "bullying" the auto-RTL into allowing the Road-based NWM networks to pass through it.  The NWM base RUL2 override code currently runs about 30,000 lines, which includes base network functionality and Ortho x Ortho intersection capability for 13 networks.  The NWM-RTL "compatibility" code runs 11,000 lines by itself.  It takes almost as much code to make an NWM network deal with the auto-RTL as it does to make that NWM network exist, and it's a big giant kludge that still doesn't cover everything. 

 

The thing that ultimately prompted the switch over to the overclick-based "semi-automatic" RTL for NAM 31 was that the RTL also interfered with the new Draggable Fractional Angle Road feature, which was going to require a big kludge-y mess just like the NWM.  And should we finally implement draggable Elevated Road viaducts, having the "auto-RTL" there, in the way would create the same exact issue.  (The Avenue Turning Lanes also present a similar issue with draggable Elevated Avenue viaducts).  Because the auto-RTL's trigger applies globally to all Road x Road ortho intersections, and immediately tacks a variable 1 or 2-tile-long tail onto the end of it, has to be overridden by brute force anytime one tries to add a Road-based override, .

 

I certainly understand wanting to avoid "exotic" setups from an ease of use standpoint.  The "auto-RTL" certainly is easy to use, if you're just wanting to stick turn lanes on all your Road x Road ortho intersections.  But unfortunately, it comes at a cost with other features--features which have more of a functional impetus in gameplay.

 

 

Having automatic RTLs for road/ave intersections would be a plus too.

 

To my knowledge, people have wanted those since the turn lane plugins began development some 9 years ago (and we periodically get questions from newer users asking why the turn lanes aren't showing up on their Road x Avenue intersections).  The early NAMites looked at doing this, but I don't think they found a satisfactory trigger method.  Being between two different networks, you can't stash the trigger method away in an INRUL, and you'd run into encapsulation issues anytime you had a Road-override cross an Avenue, or vice-versa.  It poses an even bigger problem than the RTL.

 

-Tarkus

[A Nonny Moose 8,261]

You know, maybe it is time to rethink this whole business.  How much of the current work is refinement and how much is research?  With the consolidation of all the parts in V31, are there opportunities to take advantage of commonalities that have yet to be explored? 

 

Larger is not always better as far as code is concerned.  Has anyone formally documented the NAM internally and sought for any redundancies and commonalities that could be used to advantage?  Perhaps after 31.2 there should be a general pause for this.  Because of the scatter of the team, I doubt there is any good way to have a physical meeting.

 

And some of the user requests seem to be rather personal needs than general needs.  How are you handling those?  You can't be everything to everyone.  How about a 'use at your own risk' NAM modders manual?  The fall back position being, you did it to yourself;  if it doesn't work, reinstall the basic NAM.

[MandelSoft 2,769]

We are documenting some stuff about how to mod NAM material, really. There are tutorials about how to handle the RUL2, how to make transit textures and how to make puzzle pieces. Just check the Omnibus or SC4Devotion's NAM HowTo's and Tutorials section. That there is no documentation about modding NAM stuff is nonsense. That very little people pick up this documentation and start work on it is another story. I'm actually disappointed that very, very, VERY little people actually attempted to read my tutorial about how to create puzzle pieces and start work on it (I can count everyone who did on one hand).

Most of what we do is applying already gained knowledge and fine-tuning elements, and find newer and better implementation for some elements. For instance, we see an "evolution" of the Wide Radius Curves -> Fractional Angled Roads -> DragFAR and OWR Ramps -> Modular Interchange System -> Dragable Ramp Interfaces -> FlexRamps and Auto Turning Lanes -> TuLEPs -> (future) FLEXTuLEPs. Also, we are still undergoing major re-organisation under the Project 57 scheme. Some items still need to be converted to that range, but some of those items will get a better implementation in that scheme. There were FlexRAMPs in development for the D1 and E1 ramps, but these turned out to be too unstable and crude for a public release. Research is not much being done at the moment, because we've almost figured out all there is to know about the coding of this stuff...

We do know that a larger code is not better. Heck, we are internally looking for ways to make the code more efficient, but so far, we've almost squeezed every piece of efficiency out of it we can. You have no idea how much we are dealing with this stuff behind the scenes. We try to avoid redundancies as much as possible, but sometimes they are there for either overlooking them or we can't get around them or because it's more user-friendly in that context.

The point of this poll is for instance to reduce quite some lines of code and to make a better implementation of a system that was made in the past, but in the current situation it may pose some issues when playing along with other components.

Best,

Maarten

[Haljackey 17,335]

 

Having automatic RTLs for road/ave intersections would be a plus too.

 

To my knowledge, people have wanted those since the turn lane plugins began development some 9 years ago (and we periodically get questions from newer users asking why the turn lanes aren't showing up on their Road x Avenue intersections).  The early NAMites looked at doing this, but I don't think they found a satisfactory trigger method.  Being between two different networks, you can't stash the trigger method away in an INRUL, and you'd run into encapsulation issues anytime you had a Road-override cross an Avenue, or vice-versa.  It poses an even bigger problem than the RTL.

 

I figured this was the problem since turning lanes don't exist for one-way road or street intersections either.

 

At least we are now able to make road/ave turning lanes with TuLEPs. That's a huge plus!

[z1 566]

You know, maybe it is time to rethink this whole business.  How much of the current work is refinement and how much is research?

 

There's a lot of research going on all the time.  That's where most of the new features, such as draggable FAR, come from.

 

With the consolidation of all the parts in V31, are there opportunities to take advantage of commonalities that have yet to be explored?

 

Again, this is ongoing.

 

Larger is not always better as far as code is concerned.

Boy, do we know that.

 

Has anyone formally documented the NAM internally and sought for any redundancies and commonalities that could be used to advantage?  Perhaps after 31.2 there should be a general pause for this.  Because of the scatter of the team, I doubt there is any good way to have a physical meeting.

 

I think Mandelsoft has given an excellent answer here.  As for the meeting part, we have the private NAM boards, which we use extensively.

 

And some of the user requests seem to be rather personal needs than general needs.  How are you handling those?

 

If the NAM Team likes the request, and someone wants to do it, we'll do it.  If enough people request something, if it's reasonable (always a big if), it will generally eventually get done.  We generally pass on isolated requests that we don't think will fit well into our work, especially if they don't affect many people.  We like to do things that lots of people will appreciate.  This works out well for everyone.

 

How about a 'use at your own risk' NAM modders manual?  The fall back position being, you did it to yourself;  if it doesn't work, reinstall the basic NAM.

 

Because if it doesn't work, they're still going to come to us, and it's still a support issue.  Are you familiar with the "Where's my water?" line that long ago became a joke around the NAM Team?  It came from not following the directions for the Diagonal Bridge Enabler.  And this wasn't even a risky mod.  But there are many instances that have taught us that we need to make the NAM as bulletproof as possible.  Another example is the Traffic Simulator Configuration Tool, which was designed so as to make it very difficult for the user to mess things up.  Users still find ways to abuse it, though, such as checking the Park and Ride option and ignoring the instructions printed right under the option to build additional parking facilities, and then they post questions as to why all their Sims are walking to work.  Or they just fail to read the documentation, and recommend to other users to make certain changes in the TSCT to fix the users' problems, when such changes will do nothing of the sort.

 

For people who are seriously interested in making mods to the NAM, the documentation is already there.  Of course, anything that involves the network controller (which means most of the NAM) can't be modified outside of the NAM Team, because the controller is a shared resource, and its use has to be carefully coordinated.

[A Nonny Moose 8,261]

Good answers, all.  The where's my water fiasco was a proof, if you like, of the lack-a-daisy attitude of people who push the download button.  Too much rush, not enough caution.  Also, red letters don't seem to be an attractant.  Maybe you need a good GIF editor that can animate such things.  Flashing lights might do it.

[Tarkus 6,932]

Good answers, all.  The where's my water fiasco was a proof, if you like, of the lack-a-daisy attitude of people who push the download button.  Too much rush, not enough caution.  Also, red letters don't seem to be an attractant.  Maybe you need a good GIF editor that can animate such things.  Flashing lights might do it.

 

The thing I found that eventually fixed it was that I changed the name of the file on the STEX to "Diagonal Bridge Enabler (Removes Water)".  It's completely unavoidable now.  It probably cut the download rate on it quite a bit, but that's worth the price of admission for sanity.  There were a lot of people using DocRorlach's tool to browse the STEX, and it was cutting off the warnings, leading to many of the "where's my water?" complaints.

 

-Tarkus

[A Nonny Moose 8,261]

As a long-time app programmer, then programming manager I appreciate your angst.  How many times have you wished for a command to end an end-user.  A command like XOI (execute operator immediate) would be nice.