• Welcome to SC4 Devotion Forum Archives.

REQUEST: New NAM/Roads Menu layout

Started by nathkel, May 17, 2017, 08:30:43 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

nathkel

I'm hoping this Feature Request is in the right place, as i think this can best be addressed in the NAM installation....


Getting around the Road Network menu is extremely clunky, and i'm constantly having to go in and out of different menu items, i feel, unnecessarily. Perhaps a bit of streamlining is in order.

It seems to me that menu items should be separated not by road direction but road type. That is, instead of a menu item with only curves, diagonals or FARs, menu items should be separated by network type — Road, Street, Avenue, etc. Since the user is usually working on one NETWORK type at a time, he shouldn't have to go digging into submenus for the right direction.

For example, if i'm creating a non-sidewalk country road along a mountainside, right now i have to go to the SAM menu to find the right SAM starter, Gravel Road. Plop once.
Then i have to go to the Streets submenu to choose the Street draggable item, or use the shortcut, Alt-R. Drag the street from the starter piece until i get to my curve.
I then must go the Curves submenu, and Tab thru to the Street — no wait, it's not this one, we must go to the OTHER Streets submenu, where i can find the Gravel Roads curves; scroll down the menu to find that one and Tab thru for the right curve (it's actually easier to Shift-Tab thru the list). Plop once.
Since the other side of this curve reverts to a standard street, i need to choose the SAM Gravel Road Starter on the opposite side of the new curve and cycle thru AGAIN. &ops

What would be quicker is to group the submenus by network TYPE rather than pieces or direction, so that roadways of the same type require as few menu clicks as possible.
So then we would have one Submenu for SAM Country Roads (which are streets without the sidewalk), which has the starter, fillers (orth & diag), curves, and maybe future FAR puzzle pieces.

So here's how we could modify the Roads menu for more efficient use.

Roads (standard black asphalt, two lanes in opposite directions)
    Starter (shortcut is R)
    Curves ortho & diag (Tab thru for different radiuses)
    Cosmetic pieces & Fillers
    FAR (Tab thru for various curves and intersections)
    Transitions (Tab thru for transition types, such as NRD-4, TLA-3, etc)
    Overpasses (Tab thru for overpass network type)
One-way (standard black asphalt, two lanes in one direction)
    Starters (Tab thru for higher lane counts)
    Curves ortho & diag (Tab thru for different radiuses)
    Cosmetic pieces & Fillers
    FAR pieces (Tab thru for various curves and intersections)
    Transitions (Tab thru for transition types)
    Overpasses (Tab thru for overpass network type)
Streets (standard gray paving, two lanes in opposite directions)
    Starter (shortcut is Alt-R)
    Curves ortho & diag (Tab thru for different radiuses), plus diagonals
    Cosmetic pieces & Fillers, incl. SAM blockers
SAM X Streets (where X is each SAM type  — Parking Lot, Dirt Road, Gravel Road, etc, all are two-lanes in opposite directions)
    Starter
    Curves ortho & diag (Tab thru for different radiuses)
    Cosmetic pieces & Fillers
    Transitions (Tab thru for transition types, or blockers for other SAM networks)
Avenues (standard black asphalt, four lanes, pairs in opposite directions)
    Starter (shortcut is Ctrl-R)
    Curves ortho & diag (Tab thru for different radiuses)
    Cosmetic pieces & Fillers
    Roundabouts (Tab thru for different roundabout setups)
    Transitions (Tab thru for transition types, such as NRD-4, TLA-3, etc)
    Overpasses (Tab thru for overpass network type)
Pedestrian Walkways (Malls)
    Fillers (Tab thru various Ped Mall types)
    Overpasses (Tab thru various overpass network type)

Similar methods can be used for the RHW/NAM menu.

Now since some people don't like change, no matter how inefficiently they must do things, i think any new menu re-organization should be opted out at installation.

Is too much of the Roadways menus hardcoded to get this done? Would love feedback on this...

Andreas

Now while this is thought through nicely, the big obstacle is that we cannot modify the existing transit menu items. We can add menu buttons and arrange various puzzle pieces there, which means that with your suggestion, the roads menu will have at least 30 menu buttons, making it at least as hard to use as it is now. That's really one of big downsides of the game, the menus are way too inflexible for the sheer amount of custom content that has been created over all those years.

As you might have noticed, the NAM Team is trying to reduce the number of puzzle pieces slowly, making more stuff draggable, and using "FLEX" items that can be created with a certain draw pattern for getting roads with various curve radii etc. This works pretty good with the RHW and the RRW already, and I presume the next NAM release will feature a lot more of those items for other transit networks. Re-arranging the menu items for the various pieces is a good idea, though, maybe something like that could be achieved on a small scale alright. :)
Andreas

mgb204

The other argument I'd give here is that's what's good for you, may not be good for everyone. One of the biggest conundrums a developer has is change, whatever you do, people overwhelmingly don't like it. For those used to the current system, there would inevitably be some complaints if we changed everything.

For the most part, the draggable/flex solutions are the NAM teams effort to remove the need to dip into the menus as often. Allowing you to use patterns to create all those pieces from simply one network tool. Take the RHW for example, you can now make ramps, WRCs and all sorts of things without ever needing to open the highways menu. Similarly, with the road tool you can make WRCs, FAR networks with ease. The drawback being, now you need to remember a bunch of patterns to place these items.

The number of tab-rings and their organisation has been a continual source of complaints over the years. But the truth is, there is no perfect system that everyone would be happy with.

nathkel

True, but i'm opting here for a little more logic to the whole matter... ;)

And while i like the idea of draggable networks, i don't think all puzzle pieces are going to (or should) go away, in case the user want to override the default behavior. For example, i hope one day to finish my project on Tangential Curves, which will allow for roads to come off curves cleanly. As an example if i have a Road that curves at a 90-deg angle in one tile, but i want a Street to come off the curve (continuing on in the same direction), the current construction would have me create a T-intersection, with a traffic light for the curving Road, which is not the desired effect.

Since puzzle pieces will always be necessary for some setups, let's begin now to apply a logic based on how players work and create, rather than how devs organize the data structures. That's all i was going for...

And i know not everyone wants a new menu setup, which is why i mentioned the opt-out during installation. Consensus might be called for if you're truly considered about player acceptability.

I kind of thought some of the menu placement might be HC'd, but i still think we can do better than what we have. Someone had to make the decision to make it how it is now. I think we should just revisit it. Especially if there are plans in the pipeline to expand NAM or SAM.

Tarkus

Quote from: nathkel on May 19, 2017, 11:03:06 AM
And while i like the idea of draggable networks, i don't think all puzzle pieces are going to (or should) go away, in case the user want to override the default behavior. For example, i hope one day to finish my project on Tangential Curves, which will allow for roads to come off curves cleanly. As an example if i have a Road that curves at a 90-deg angle in one tile, but i want a Street to come off the curve (continuing on in the same direction), the current construction would have me create a T-intersection, with a traffic light for the curving Road, which is not the desired effect.

The official stance (or at least, the closest thing to one) is that while existing static puzzle pieces will be kept essentially in tact, the majority of them are planned to be classified as "legacy/deprecated" items, as soon as FLEX and/or draggable equivalents with an equal amount of functionality are developed.  There's been a de facto freeze on the creation of any new static puzzle piece items since late 2014.

The idea behind the FLEX/draggable stuff we're currently doing is indeed overriding default behavior, and unlike static puzzle pieces, which are "stuck" in a given configuration, FLEX/draggable items generally support further overrides. 

Say, for instance, with the Tangential Curve example, you decided you wanted to replace the Road with an NWM network, or the Street with a SAM network.  Perhaps, even, you wanted to have an option for turn lanes.  With a static puzzle piece, that Road x Street setup is stuck as a Road x Street setup.  If you want to add support for TLA-3 x Street, you'd have to create another static puzzle piece.  Road x SAM Set 2?  Another static puzzle piece.  With all the crosslink options, you very quickly get to the point of drowning in puzzle pieces.  That's the main reason we stopped making them.  Paradoxically, users were simultaneously complaining about how difficult it was to navigate all those puzzle pieces, and requesting new features.  Fulfilling those requests would have only added to the navigation difficulty, unless we did something different.  Static puzzle pieces just weren't efficient or conducive to what we needed to do to move NAM development forward. 

A FLEX piece can be plopped just like a puzzle piece.  However, since it is overridable, Road x Street, TLA-3 x Street, Road x SAM Set 2, and even hooking in the new FLEX Turn Lanes can be accomplished with just a single FLEX piece for a given base configuration.  If one is clever enough with the implementation, it's potentially possible to do even more, and since just about everything in a FLEX piece is treated just as it is a draggable item, it can actually be added onto any larger setup with ease (which is how the in-development QuickChange Xpress system works for the RHW).

The fact that we still have a mixture of FLEX/draggable items and soon-to-be-deprecated static puzzle items has left our menu system for many components in an awkward transitional state.  That's mainly because of the scope of the endeavor, and because we're still determining just how much we can condense things down once we've gotten things to a relatively stable spot in that process.  I do think your proposal has some merit, certainly.

-Alex

ChiefZDN

#5
I think, context menu-based additional menu solves this problem. When a user click a network, it will show its additional menu (this menu is called flow additional menu, not to be confused with Fractionally-angled Networks). Some network have 'optional' additional menu (called non-flow additional menu) so if the user click it, it will immediately show the default network and the user can change the default by right-clicking it. The challenge is the dependencies. If we use DLL to accomplish this, it can't be embedded on NAM. And, the DLL & Lua documentation aren't much. The menu structure is like below:
- Roads & streets
  - Road
    * NFAM: Rural street and its PP, road PP, and road-NWMs (like NRD-4) and its PP
  - Street
    * NFAM: SAM and its PP and street PP (including diag street PP)
  - Ave
    * NFAM: Ave-NWMs (like AVE-8) and its PP
  - OWR
    * NFAM: OWR-NWMs and its PP
- Highways
   - Maxis Highway
   - RealHighway
      * FAM: RHWs and theirs PP
   - Interchange
      * FAM: MH Interchanges and RHW interchanges
      * TAB: Interchange switch (not highway-type switch)
...

All networks in the future are including elevated-version of the network (except for ferries) and all networks include TAB-triggered elevation switcher. Also, for PP, tab clicks aren't just for changing the elevation. They also change the pieces. FLUPs are seperate network (but, they are compatible with any networks). So, it's on Misc Networks menu. Also pedmall also on Misc Network menu.

And, the network are GENERATED on-the-fly with Lua scripts. So, elevations and more features aren't problems again.

Sorry if I can't explain detaily (this is might be typo).

Thank you.

Tarkus

Quote from: ChiefZDN on May 20, 2017, 07:23:50 PM
If we use DLL to accomplish this, it can't be embedded on NAM. And, the DLL & Lua documentation aren't much.

Including a DLL in the NAM would actually be no different than including a DAT file--a file is a file.  The main issue is that one would have to be created that would actually add the submenus, and there's only one individual with heavy RL who is capable of making DLL miracles.

Quote from: ChiefZDN on May 20, 2017, 07:23:50 PM
And, the network are GENERATED on-the-fly with Lua scripts. So, elevations and more features aren't problems again.

memo's MetaRUL system accomplished a similar feat, albeit he used Scala to design it.  That's actually what made the FLEXFly revamp from NAM 33 possible.  He had started on a MetaRUL solution for the RHW and NWM, but hasn't been active since mid-2015.  I've been able to salvage part of the RHW work that, in its current form, is an improvement over the existing setup (the RHW x RHW crossings portion), so it's possible that at least the existing networks could see some significant improvements.  But expanding upon his work in its existing form in Scala is above my pay grade--I've tried.

While SC4 does have some LUA scripts included within it, there's no known spot for the LUAs to actually hook into the transit networks in any meaningful way.  They're very limited in their modding potential, and are mostly used for automata spawning and news ticker items.  (That said, daeley's DAMN menu system has a LUA basis, exploiting news ticker items, and droric did do a NAM DAMN setup some time ago.)

-Alex

Wiimeiser

Isn't there also the fact that DLLs only work if placed in the base folders, not subfolders? Shouldn't affect a NAM DLL in any way, though.

One menu change I'd like to see is separating the deprecated RHW ramps from the non-deprecated ramps, though I'm not sure how easy that would be... (On the subject of FLEX versions of those pieces, I could see the construction tile for the RHW-6C splitter occupying either the RHW-2 stub or the median stub, though there's the fact you'd need 8C compatibility and RHW-3 and (potential) draggable WRHW-2 support...)
Pink horse, pink horse, she rides across the nation...

Kitsune

Some of the ramps labelled depreciated actually have no known flex (ie the the RHW-2 wyes).... if we could just get those moved to the front like the others that would be nice.
~ NAM Team Member

Tarkus

Quote from: Kitsune on May 21, 2017, 08:30:43 AM
Some of the ramps labelled depreciated actually have no known flex (ie the the RHW-2 wyes).... if we could just get those moved to the front like the others that would be nice.

The RHW-2 Wyes do indeed lack a FLEX form, but they're being labeled as deprecated is still largely accurate, due to the fact that there are draggable versions of all of them (and a few more that never existed in puzzle form).  That said, it wouldn't be too much difficulty to move them up the order on the old TAB Loop.

Quote from: Wiimeiser on May 21, 2017, 05:01:53 AM
Isn't there also the fact that DLLs only work if placed in the base folders, not subfolders? Shouldn't affect a NAM DLL in any way, though.

That is true, but given all the stuff the NAM installer does, making it such that it'd install any hypothetical DLL in the root plugins folder would be a piece of cake.

Quote from: Wiimeiser on May 21, 2017, 05:01:53 AM
One menu change I'd like to see is separating the deprecated RHW ramps from the non-deprecated ramps, though I'm not sure how easy that would be... (On the subject of FLEX versions of those pieces, I could see the construction tile for the RHW-6C splitter occupying either the RHW-2 stub or the median stub, though there's the fact you'd need 8C compatibility and RHW-3 and (potential) draggable WRHW-2 support...)

You've hit upon one of the awkward transitional situations I described earlier.  The goal is to make FLEX and/or draggable versions of everything under the puzzle-based ramps button, so all of the existing puzzle ramps will end up being deprecated at some point down the line.  The non-deprecated ones are mostly more specialized setups that involve some sort of C-to-S transition as part of the design, so it may end up that they share some overrides with the FLEX Width Transitions.  I'm hoping to dust those off at some point soon.

-Alex

Kitsune

There's a dragable rhw-2 wye (as in it splits into two opposite RHW-1's?) The namdoc does not have the pattern... hmm.
~ NAM Team Member

Tarkus

It's escaped our documentation, but all the patterns are in one of GDO29Anagram's teaser videos for NAM 33:

https://www.youtube.com/v/b2PeDUDlwvw

-Alex

nathkel

While there is an inherent problem in using FLEX as opposed to puzzle pieces (that is, one must know the correct drag sequence, which is not always intuitive), I would support FLEX wholeheartedly only if they can handle overrides efficiently without guessing at the right sequence.
Given my example above (the one-tile, 90-deg turn in a road with an offshooting street), is it possible for that to be FLEX-coded? I mean, this is a perfect example when a puzzle piece is needed to override the default behavior. Which goes to my point that a few will be needed, deprecated or not.
For me, puzzle pieces, while MORE cumbersome than remembering drag sequences, are preferable, because you know what you get every time. At this point, this thread was just for better organization of what we have, even if we label these pieces deprecated.
Perhaps an installation option to install puzzle pieces?

eggman121

Hello nathkel

Making flex equivalents are high on the agenda for many of the NAM Pieces.

That includes many of the projects that have come online in the past few years.

The fact that there aren't that many flex pieces is due too the fact that we wanted to get the base functioning first.

I have only recently discovered how to make flex pieces and have had alot of success in the testing phase.

So depending on time the next few releases will have flex pieces that can be overridden.

That is all for now. Time for work.

-eggman121

mgb204

Quote from: nathkel on June 07, 2017, 01:48:09 PM
While there is an inherent problem in using FLEX as opposed to puzzle pieces (that is, one must know the correct drag sequence, which is not always intuitive), I would support FLEX wholeheartedly only if they can handle overrides efficiently without guessing at the right sequence.

This tells me you are a bit out of date with your thinking. Sure, Flex isn't perfect, but RHW stability for example is the best it's ever been. It's seriously improved since NAM33. Most of the other flex pieces rarely do anything unexpected for me, provided you drag the right pattern. Not only that, using RHW is so much quicker and more fluid in practise, I barely need the menus any more. I wholeheartedly disagree with anyone who thinks the old approach was better. Old RHW (Pre NAM 32), IMO was terribly clunky, these days I genuinely enjoy using it more and more. Using the newer methods has also enabled the number of crosslinks to be vastly improved.

Puzzle pieces are such a chore to make, by comparison, code can be copy/pasted with ease. In a few hours you can code an entire new network using Copy/Paste and altering the ID scheme of the code. If I'd had to make a puzzle piece for each SAM tile, I wouldn't have bothered making my SAM11 mod. Another example of how this approach benefits development, Eggman made some new SAM WRCs and added support for OxO crossings to ERRW. Adapting the code to support SAM11 took no time at all. Put simply, from a development perspective it's a smarter way of working and hugely more efficient. Which in turn means more crosslinking gets added and the NAM as a whole is becoming more and more integrated.

QuoteGiven my example above (the one-tile, 90-deg turn in a road with an offshooting street), is it possible for that to be FLEX-coded? I mean, this is a perfect example when a puzzle piece is needed to override the default behavior.

Can you explicitly state which PP you are talking about (which menu it's in). Honestly, I have no clue what you might be referring to. Drag a normal 90° road and you can drag a street from it. (That's Draggable functionality right there)... It works every time and no PP should be necessary? In fact adding a puzzle piece would be inefficient. For example, that piece can be overridden to support all the SAM networks. Similarly we could code it so the road can take on one of the NWM networks, which in turn could also interact with SAM. If it was a puzzle piece, it would have one single static use, every possibility would need a new piece, vastly less flexible or user friendly.

A better example IMO is the Draggable Elevated Road Viaducts. Look to the initial release, there were stability issues, necessitating starter pieces and other workarounds. But as the code has matured, the basic OxO crossings are becoming rock-solid and even more powerful than their PP counterparts. Eventually these will totally replace and surpass the PP versions in every way. The key world however is matured, it takes time and code to make it all work. But it's constantly improving and so this argument for going back to PPs is just plain flawed. Now you just plop a height transition or ramp and drag away, compared to placing each piece one by one, it's a breeze.

QuotePerhaps an installation option to install puzzle pieces?

It's really not that simple. To add menu entries for these pieces takes resources, if they need to be proper PPs in terms of their function, those have to be created and coded into the menus. Not only would that distract from our attempts to mature the code for Drag/Flex, it goes against the future plans and philosophy of the team.

I'm sorry, like it or not, puzzle pieces are dead. They are the past, not the future.

Tarkus

Quote from: nathkel on June 07, 2017, 01:48:09 PM
While there is an inherent problem in using FLEX as opposed to puzzle pieces (that is, one must know the correct drag sequence, which is not always intuitive), I would support FLEX wholeheartedly only if they can handle overrides efficiently without guessing at the right sequence.

I think you're also misunderstanding what exactly is entailed with FLEX.  While there is a substantial draggable component to what we have been doing of late, a large part of the equation also includes ploppable items ("FLEX Pieces"), which don't require remembering drag patterns.  Compared to static puzzle pieces, these "FLEX Pieces" are actually handled by the game as if they were draggable items, allowing them to accept overrides and making it such that a single "FLEX Piece" can do the job of as many as 40 conventional static puzzle pieces.

"FLEX Pieces" have been around for awhile now--the Diagonal Streets Helper Pieces were the first instance (from NAM 20 in 2006), followed later by FLEXFly (from NAM 28/RHW 4.0 in 2010) and FlexSPUI (from NAM 30/RHW 5.0 in 2011).

Quote from: mgb204 on June 07, 2017, 03:18:20 PM
QuoteGiven my example above (the one-tile, 90-deg turn in a road with an offshooting street), is it possible for that to be FLEX-coded? I mean, this is a perfect example when a puzzle piece is needed to override the default behavior.

Can you explicitly state which PP you are talking about (which menu it's in). Honestly, I have no clue what you might be referring to. Drag a normal 90° road and you can drag a street from it. (That's Draggable functionality right there)... It works every time and no PP should be necessary?

To clarify, nathkel seems to be referring to a not-yet-extant design in which a Street branches off some sort of 90° Wide/Multi-Radius Curve--definitely something that could be better supported with FLEX and/or draggable solutions.

-Alex

nathkel

Don't get me wrong - i love FLEX, but i don't use it as much as i could because i can't remember the sequences (like for example the Road wide 90-deg curve (5x5). Puzzle pieces i can find more easily than printing out whatever sheet you've created outlining the drag sequences. If they're not intuitive, it's not very convenient, no?  ???

Quote
QuoteGiven my example above (the one-tile, 90-deg turn in a road with an offshooting street), is it possible for that to be FLEX-coded? I mean, this is a perfect example when a puzzle piece is needed to override the default behavior.

Can you explicitly state which PP you are talking about (which menu it's in). Honestly, I have no clue what you might be referring to. Drag a normal 90° road and you can drag a street from it. (That's Draggable functionality right there)... It works every time and no PP should be necessary? In fact adding a puzzle piece would be inefficient. For example, that piece can be overridden to support all the SAM networks. Similarly we could code it so the road can take on one of the NWM networks, which in turn could also interact with SAM. If it was a puzzle piece, it would have one single static use, every possibility would need a new piece, vastly less flexible or user friendly.

The example i gave is the best example: drag a road to a 90-deg turn, then drag a Street into the 90-deg curve (forming essentially a T with the Road constituting the 90-deg turn). Now in the game, this creates an intersection, which is not what i need a majority of the time - i need the Street to shoot off the curve, because the Road gets the right-of-way. My Transitional Curves add-on would add this, if not as a puzzle piece then a FLEX-drag (if someone can code it for me) ;)

And i know puzzle pieces aren't going away, because the drag sequences can create a problem in themselves. Case in point: diagonal streets. Drag it (with a few mouseclicks) and you definitely get a diagonal street - but it flattens the terrain!  :bomb:
But use a Diagonal Road puzzle piece and it (mostly) conforms to the slope).

It's these puzzle pieces which was the point of starting this thread... :satisfied:

eggman121

Hello nathkel

Indeed the NAM team knows that remembering all those patterns can be a pain. That is why in future editions of the NAM there will be a bigger focus on making Flex Pieces (Not to be confused with draggable counterparts!) The old way of making static Puzzle Pieces is outdated and to cover the vast majority of setups and make use of the Pieces already in the NAM.

So what is a flex piece? A flex piece is basically a set of pieces that a are chained together to resemble a puzzle piece but has the functionality of flex/draggable since it uses the same tile types. So a Win Win for developers and users alike. Flex Pieces by there inherent nature can feel like puzzle pieces but your less likely to have the drawbacks and indeed the static nature of the pieces.

That is all for now. I am happy to clarify if needed.

-eggman121

Tarkus

#18
Quote from: nathkel on June 23, 2017, 10:22:04 AM
And i know puzzle pieces aren't going away, because the drag sequences can create a problem in themselves. Case in point: diagonal streets. Drag it (with a few mouseclicks) and you definitely get a diagonal street - but it flattens the terrain!  :bomb:
But use a Diagonal Road puzzle piece and it (mostly) conforms to the slope).

The Diagonal Street pieces actually are "FLEX pieces", and the first ones ever made (originally, the term was "helper piece").  They're overrideable, and can change to match the context of what's around them--i.e. accepting SAM overrides, intersections, etc.  They're plopped, but act like draggables once placed.  Pieces that behave like that aren't going away, and in fact, we're making more of those, because they're efficient and can have new functionality added to them later, thereby mitigating the need to create more. 

It's the older, more prevalent type of puzzle piece that isn't overrideable--the "conventional" or "static" puzzle piece--that is being phased out.  Those are the ones that once you plop them, if you need to change something, the only thing you can do is bulldoze.  Examples of these would be the old pre-draggable Road Viaducts, or the old Fractional Angle Road puzzle pieces.  We're not going to be making any more of those, and we have hundreds, if not thousands of those static pieces around, many of which are headed for obsolescence.

The end result of moving toward the ploppable items being overrideable "FLEX" pieces is going to be quicker navigation through the mod.

-Alex

nathkel

OK, so there are 3 types of road placement (and this is where i was getting confused) - puzzle pieces, which you just rotate and plop, but don't offer any road type flexibility; draggable pieces, which only show up when you drag the road type in the right way; and FLEX pieces, which plop, but adapt to the road type it's connected to.

With this crystallized info, i now have a better understanding what i'm asking for: and that is, the road types should go together more logically in the menus, whether they're FLEX or puzzle pieces (and i'm assuming that eventually puzzle pieces will be done away with as soon as the NAM team creates FLEX counterparts).

Yes, i GENERALLY do like the FLEX pieces more, but there have been times when, if you destroy the wrong road piece, it wipes out the whole piece or makes it impossible to use. But i do agree this is the way to go.

As long as the NAM team has heard my imploring, i will let them do what they do without a peep from me! ;D