NAM 31 Central Bug Tracker Thread

[Tarkus 6,932]

Just out of curiosity, where the hell is the transition from L0 to L1 6 and 8S?

 

It's a FLEX Height Transition (FLEX-HT) setup.  Use the 1-level FLEX-HT or FLEX OnSlope (FLEX-OST) to connect those networks.  I don't know how stable they necessarily are, though.

 

-Tarkus

[Zodicus 34]

Thank you Sir I'll give that a whirl. I played around all day with it trying to figure that one out lol. I knew you guys just didn't leave it out.

[deathtopumpkins 43]

Apologies if this has been addressed already, but making starter pieces now only have a stub on one end was, to be perfectly blunt, a terribly stupid idea. Ramps that don't have stubs (like some of the elevated MIS ones, and the new Symphony ramps) Need several extra tiles of space along the ramp just to fit a starter in, because where previously you could just place a starter on the next tile, so it sticks a stub on the tile immediately adjacent to the ramp, you now can only do that for one direction (westbound or nothbound) but not the other (eastbound or southbound). Eastbound or southbound ramps have to have a full 2 blank tiles dedicated just to the starter, because if you plop it with the starter itself on the tile immediately adjacent to the ramp, it removes the base network stub, meaning you can no longer drag from your next-tile stub into the ramp. This means that you have to place your starter 2 tiles away from the ramp, and thus your stub 3 tiles away, which is terribly annoying in tight, urban situations. This could be very simply remedied by either making the stub rotatable, i.e. when you rotate it it changes which direction it is oriented, or restoring the double-ended stubs.

 

I know I've done a terrible job explaining this, so if pictures would help I can easily supply them.

[Titanicbuff 1,262]

interesting glitch in project symphany.

[Tarkus 6,932]

Apologies if this has been addressed already, but making starter pieces now only have a stub on one end was, to be perfectly blunt, a terribly stupid idea. Ramps that don't have stubs (like some of the elevated MIS ones, and the new Symphony ramps) Need several extra tiles of space along the ramp just to fit a starter in, because where previously you could just place a starter on the next tile, so it sticks a stub on the tile immediately adjacent to the ramp, you now can only do that for one direction (westbound or nothbound) but not the other (eastbound or southbound). Eastbound or southbound ramps have to have a full 2 blank tiles dedicated just to the starter, because if you plop it with the starter itself on the tile immediately adjacent to the ramp, it removes the base network stub, meaning you can no longer drag from your next-tile stub into the ramp. This means that you have to place your starter 2 tiles away from the ramp, and thus your stub 3 tiles away, which is terribly annoying in tight, urban situations. This could be very simply remedied by either making the stub rotatable, i.e. when you rotate it it changes which direction it is oriented, or restoring the double-ended stubs.

 

I know I've done a terrible job explaining this, so if pictures would help I can easily supply them.

 

I think I know to what you're referring, with respect to the rotational aspect.  But given that we have the vanishing construction lot now, there's no need for double-ended pieces--they'd appreciably increase the footprint, which is why the old setup was eliminated.  When you place it, while the network one tile in front of/behind (depending on rotation) goes away, but it can be dragged immediately back through without bulldozing.  I can see about the rotation thing--it would entail a little modification to the RUL0 entries.

 

 

interesting glitch in project symphany.

 

That's Issue #78.  It's been diagnosed as missing exemplars.

 

-Tarkus

[deathtopumpkins 43]

Apologies if this has been addressed already, but making starter pieces now only have a stub on one end was, to be perfectly blunt, a terribly stupid idea. Ramps that don't have stubs (like some of the elevated MIS ones, and the new Symphony ramps) Need several extra tiles of space along the ramp just to fit a starter in, because where previously you could just place a starter on the next tile, so it sticks a stub on the tile immediately adjacent to the ramp, you now can only do that for one direction (westbound or nothbound) but not the other (eastbound or southbound). Eastbound or southbound ramps have to have a full 2 blank tiles dedicated just to the starter, because if you plop it with the starter itself on the tile immediately adjacent to the ramp, it removes the base network stub, meaning you can no longer drag from your next-tile stub into the ramp. This means that you have to place your starter 2 tiles away from the ramp, and thus your stub 3 tiles away, which is terribly annoying in tight, urban situations. This could be very simply remedied by either making the stub rotatable, i.e. when you rotate it it changes which direction it is oriented, or restoring the double-ended stubs.

 

I know I've done a terrible job explaining this, so if pictures would help I can easily supply them.

 

I think I know to what you're referring, with respect to the rotational aspect.  But given that we have the vanishing construction lot now, there's no need for double-ended pieces--they'd appreciably increase the footprint, which is why the old setup was eliminated.  When you place it, while the network one tile in front of/behind (depending on rotation) goes away, but it can be dragged immediately back through without bulldozing.  I can see about the rotation thing--it would entail a little modification to the RUL0 entries.

 

Yes and that works in some cases, but only some. Take for example trying to place a starter against a FAMIS transition piece that leaves a RHW-2 stub. If you plopped the starter one tile away from the FAMIS piece, like you suggest, it would then erase the RHW-2 stub, meaning you can no longer drag straight into the FAMIS transition, and would need to use a filler piece or something, because there is no eastbound stub that does not have another tile to the east of it.

The specific situation I first encountered this annoyance in is building a Type A Symphony ramp. The westbound offramp only needed 5 tiles adjacent to the highway (3 for the ramp and 2 for the curve away) but the eastbound onramp needed 6 tiles (2 for the curve, one blank tile, and 3 for the ramp) because you can't place an eastbound stub directly adjacent to the ramp anymore.

 

 

Also, another thing that may have been mentioned - there are no ramp transitions from ground to 7.5m for road or avenue - only on-slope transitions. This renders the 7.5m height essentially useless in the majority of cases.

[Wiimeiser 444]

Don't know whether this is already noted:

 

 

"Cannot

be placed on occupied tiles". It doesn't create starters and existing

stretches of MIS cannot be attached to it either. Forgot to turn

drawpaths on, if you need another with that on I can totally get that,

too.

 

I can't place the Y pieces on existing RHW...

[Tarkus 6,932]

 

Apologies if this has been addressed already, but making starter pieces now only have a stub on one end was, to be perfectly blunt, a terribly stupid idea. Ramps that don't have stubs (like some of the elevated MIS ones, and the new Symphony ramps) Need several extra tiles of space along the ramp just to fit a starter in, because where previously you could just place a starter on the next tile, so it sticks a stub on the tile immediately adjacent to the ramp, you now can only do that for one direction (westbound or nothbound) but not the other (eastbound or southbound). Eastbound or southbound ramps have to have a full 2 blank tiles dedicated just to the starter, because if you plop it with the starter itself on the tile immediately adjacent to the ramp, it removes the base network stub, meaning you can no longer drag from your next-tile stub into the ramp. This means that you have to place your starter 2 tiles away from the ramp, and thus your stub 3 tiles away, which is terribly annoying in tight, urban situations. This could be very simply remedied by either making the stub rotatable, i.e. when you rotate it it changes which direction it is oriented, or restoring the double-ended stubs.

 

I know I've done a terrible job explaining this, so if pictures would help I can easily supply them.

 

I think I know to what you're referring, with respect to the rotational aspect.  But given that we have the vanishing construction lot now, there's no need for double-ended pieces--they'd appreciably increase the footprint, which is why the old setup was eliminated.  When you place it, while the network one tile in front of/behind (depending on rotation) goes away, but it can be dragged immediately back through without bulldozing.  I can see about the rotation thing--it would entail a little modification to the RUL0 entries.

 

Yes and that works in some cases, but only some. Take for example trying to place a starter against a FAMIS transition piece that leaves a RHW-2 stub. If you plopped the starter one tile away from the FAMIS piece, like you suggest, it would then erase the RHW-2 stub, meaning you can no longer drag straight into the FAMIS transition, and would need to use a filler piece or something, because there is no eastbound stub that does not have another tile to the east of it.

The specific situation I first encountered this annoyance in is building a Type A Symphony ramp. The westbound offramp only needed 5 tiles adjacent to the highway (3 for the ramp and 2 for the curve away) but the eastbound onramp needed 6 tiles (2 for the curve, one blank tile, and 3 for the ramp) because you can't place an eastbound stub directly adjacent to the ramp anymore.

 

 

Also, another thing that may have been mentioned - there are no ramp transitions from ground to 7.5m for road or avenue - only on-slope transitions. This renders the 7.5m height essentially useless in the majority of cases.

 

I've opened the starter situation as Issue #83.  SA stated earlier today in the SC4D edition of this thread that he'll be adding the "ramp style" transitions for NAM 31.1.

 

-Tarkus

[Jazzmaster 716]

Not sure if I'm being too ambitious here or if this particular setup is meant to work.

 

 

 

 

 

I tried dragging the ERHW L1-6S over/under the two flex-fly curves (per an image I saw in the documentation) but it's a no go.  Is this type of work currently unsupported or should it work at this point?

 

The ERHW-8S L1 over/under MIS L0/L2 is broken as well, and so is the L0 to L2 MIS transition (lower left and upper left of the picture, respectively).

 

 

EDIT:  Did some tweaking to the setup, still no cigar:

 

[Zodicus 34]

 

Just out of curiosity, where the hell is the transition from L0 to L1 6 and 8S?

 

 

It's a FLEX Height Transition (FLEX-HT) setup.  Use the 1-level FLEX-HT or FLEX OnSlope (FLEX-OST) to connect those networks.  I don't know how stable they necessarily are, though.

 

-Tarkus

 Still not getting that to work. Got a tutorial on that hidden somewhere?

 

  BTW I did get a work around for one of those bugs posted earlier. You do need a 1 tile gap between the L3 pieces.

[Ganaram Inukshuk 906]

Not sure if I'm being too ambitious here or if this particular setup is meant to work.

FlexCurve over FlexFly - Nonfunctional feature.

[Jazzmaster 716]

Not sure if I'm being too ambitious here or if this particular setup is meant to work.

FlexCurve over FlexFly - Nonfunctional feature.

 

Thanks for the info!  I updated my post after I tweaked the setup.  The FlexFly is no longer crossing the FlexCruve, but it's still giving me errors.

[Zodicus 34]

Heres another one.

 

 L3 6S attempting to cross over L2 Flxfly and L0 8S. I have a feeling I am trying to make this damned thing too intricate.

 

Uploaded with ImageShack.us

[deathtopumpkins 43]

Other things I've found:

• SPUIs now require at least 5 tiles of plain old RHW-4 coming out of each of the ramp stubs to maintain the SPUI override (this is with the ramps immediately adjacent to the highway, and the SPUI on the ground). If you try to, say, transition the RHW-4 to an RHW-2 in fewer than 5 tiles, it breaks the SPUI override and just shows RHW-4 going up to the avenue.
• This shouldn't come as a surprise considering things as basic as road overpasses don't work for Symphony, but it doesn't work with SPUIs.
• I've been informed this has already been reported, but in case it hasn't: the MIS-OWR transition is gone.
• MIS ramps ending at avenues in a T-intersection are broken - the second tile is AVExRHW2.

I understand needing to get this out after setting a release date, but I've found the NAM on the whole to have LESS working functionality now than it did in v30, and I honestly don't think it should have been released in this condition.

[Ganaram Inukshuk 906]

Heres another one.

Also a nonfunctional feature, as in, it's not because there's missing code, but there was never any code at all.

[Tarkus 6,932]

 

 

Just out of curiosity, where the hell is the transition from L0 to L1 6 and 8S?

 

 

It's a FLEX Height Transition (FLEX-HT) setup.  Use the 1-level FLEX-HT or FLEX OnSlope (FLEX-OST) to connect those networks.  I don't know how stable they necessarily are, though.

 

-Tarkus

 Still not getting that to work. Got a tutorial on that hidden somewhere?

 

  BTW I did get a work around for one of those bugs posted earlier. You do need a 1 tile gap between the L3 pieces.

 

To override the FLEX-HT and FLEX-OST into RHW-6S versions, drag the L0 RHW-6S into the ground side of the transition.  It'll cascade up the transition, changing it from RHW-2 to RHW-6S, and you can then drag L1 RHW-6S out the elevated end.  I've verified that both FLEX-HT and FLEX-OST are stable for me for L0-L1 RHW-6S.

 

 

 

Other things I've found:

• SPUIs now require at least 5 tiles of plain old RHW-4 coming out of each of the ramp stubs to maintain the SPUI override (this is with the ramps immediately adjacent to the highway, and the SPUI on the ground). If you try to, say, transition the RHW-4 to an RHW-2 in fewer than 5 tiles, it breaks the SPUI override and just shows RHW-4 going up to the avenue.
• This shouldn't come as a surprise considering things as basic as road overpasses don't work for Symphony, but it doesn't work with SPUIs.
• I've been informed this has already been reported, but in case it hasn't: the MIS-OWR transition is gone.

I understand needing to get this out after setting a release date, but I've found the NAM on the whole to have LESS working functionality now than it did in v30, and I honestly don't think it should have been released in this condition.

 

The MIS-OWR was issue #55.  It's been corrected on our end.  The SPUI issue hasn't been reported yet--I'll look into that one and get a report together.

 

As far as the release date/functionality issue goes, it's the last time we're going to do a release date, ever.  We're treating this like it's a public release candidate test at this point.  We've left NAM 30 available for download at ModDB, though as all of our resources are dedicated to improving NAM 31, we cannot provide tech support to NAM 30 users.

 

-Tarkus

[deathtopumpkins 43]

Another one that I just checked to make sure did not have an open issue: the RHW-4 to Avenue transition is gone.

 

And one more: L1 RHW-4 over avenue doesn't work. Just reverts to L1 RHW-2.

[Durfsurn 539]

The MIS to 2x MIS Y splitter is glitched. Not the puzzle piece but one you can draw like having a othogonal MIS and dragging a diagonal MIS off it glitches paths and everything. Did work in NAM 30

[Zodicus 34]

 

 

 

Just out of curiosity, where the hell is the transition from L0 to L1 6 and 8S?

 

 

It's a FLEX Height Transition (FLEX-HT) setup.  Use the 1-level FLEX-HT or FLEX OnSlope (FLEX-OST) to connect those networks.  I don't know how stable they necessarily are, though.

 

-Tarkus

 Still not getting that to work. Got a tutorial on that hidden somewhere?

 

  BTW I did get a work around for one of those bugs posted earlier. You do need a 1 tile gap between the L3 pieces.

 

To override the FLEX-HT and FLEX-OST into RHW-6S versions, drag the L0 RHW-6S into the ground side of the transition.  It'll cascade up the transition, changing it from RHW-2 to RHW-6S, and you can then drag L1 RHW-6S out the elevated end.  I've verified that both FLEX-HT and FLEX-OST are stable for me for L0-L1 RHW-6S.

 

That is actually an L3 transition to 6S I am working on. I've tried that way too. I noticed that there are OST and Flex-HT for lvl 1 and 2 but that is it. I've been poking around and there is a lot of stuff for L3 and L4 but as far as I can find there is no way to actually get traffic access to those levels. OR just maybe I am completely retarded because I have been up 48 hours straight playing with the new NAM you guys graciously gave us Yea, on that note, goodnight folks!

[jdenm8 362]

The MIS to 2x MIS Y splitter is glitched. Not the puzzle piece but one you can draw like having a othogonal MIS and dragging a diagonal MIS off it glitches paths and everything. Did work in NAM 30

 

That's because the code wasn't written before release. Also, It's Issue #44.

[Jazzmaster 716]

It seems like after I've dragged L2 MIS out of either ends of the FlexFly, dragging anything under it is impossible.  At least in the configuration I posted above.  Any ideas?

 

EDIT: dragging anything under a L2 MIS that has been drug out of a FlexFly curve doesn't work.

 

Edit (again): L2 MIS doesn't seem to like crossing anything at all, lol.

[Tarkus 6,932]

That is actually an L3 transition to 6S I am working on. I've tried
that way too. I noticed that there are OST and Flex-HT for lvl 1 and 2
but that is it. I've been poking around and there is a lot of stuff for
L3 and L4 but as far as I can find there is no way to actually get
traffic access to those levels. OR just maybe I am completely retarded
because I have been up 48 hours straight playing with the new NAM you
guys graciously gave us Yea, on that note, goodnight folks!

 

I had no problem just now going from L2-to-L3.  Drag an L2 RHW-6S into the bottom end of an L0-to-L1.  The whole thing will turn into an RHW-6S and will raise 2 levels, and you can drag L3 RHW-6S out of it.  Basically, those transitions are there to accomplish transitions between adjacent levels (L0-to-L1, L1-to-L2, L2-to-L3, L3-to-L4).

 

 

The 1-level transitions are generally fairly stable on at least the single-tile networks.  The 2-level ones (which are designed for L0-to-L2, L1-to-L3, and L2-to-L4 situations) are much less so at present.

 

As far as the rest of the setup you have pictured, it looks like you're doing some things FLEXFly can't (and probably won't anytime soon) be able to handle.

 

Edit:

It seems like after I've dragged L2 MIS out of either ends of the FlexFly, dragging anything under it is impossible.  At least in the configuration I posted above.  Any ideas?

 

EDIT: dragging anything under a L2 MIS that has been drug out of a FlexFly piece doesn't work.

 

L2 MIS isn't terribly cooperative at the moment.  There's likely some RUL2 code in there that has the same thing on both sides of the equals sign, which acts as a prevent.  It's pretty easy to accidentally insert something like that when you're batch processing RUL2 code.

 

-Tarkus

[NatNat 0]

I've just noticed that I traffic can't drive north through the piece indicated below. I would assume that there is a missing path on this piece, or its just a problem on my end.

thanks.

[Jazzmaster 716]

It seems like after I've dragged L2 MIS out of either ends of the FlexFly, dragging anything under it is impossible.  At least in the configuration I posted above.  Any ideas?

 

EDIT: dragging anything under a L2 MIS that has been drug out of a FlexFly piece doesn't work.

 

L2 MIS isn't terribly cooperative at the moment.  There's likely some RUL2 code in there that has the same thing on both sides of the equals sign, which acts as a prevent.  It's pretty easy to accidentally insert something like that when you're batch processing RUL2 code.

 

-Tarkus

 

 

Thanks for the update.  Is the L1 ERHW-6S supposed to be able to cross the L0 FlexCurves or is this something that'll come in a future release (not NAM 31SE)?

 

EDIT: And for that matter, L1 RHW 6S under the L2 FlexFly curves doesn't seem to work either...

[Tarkus 6,932]

I believe the FLEXCurves were coded to handle newer multi-height stuff (they were developed right as we started transitioning into the early phases of P57).  The old FLEXFly definitely can't.

 

There was some initial work done on a completely revamped FLEXFly/Curve system, but as the main developer had a lot of RL in the past couple months, it didn't make it into NAM 31.

 

-Tarkus

[bradgo 4]

selecting a monorail/HSR UDI causes a CTD every time

 

tested on a blank city tile with two stations and a single dragable HSR line

 

i have the HSRP installed via NAM 31 custom install, no BTM installed 

[Gurning_Chimp 398]

selecting a monorail/HSR UDI causes a CTD every time

 

tested on a blank city tile with two stations and a single dragable HSR line

 

i have the HSRP installed via NAM 31 custom install, no BTM installed 

 

I think that may be an issue with your PC, it doesn't do that for me.

[GeometryMath Algebra 614]

There's a bug at the DDRHW-4's exits. I can't connect it to the main DDRHW-4! And also, there are missing pillars on the DDRHW-4. Will that be fixed during the update??

[bradgo 4]

will re-install to test again

 

vanilla monorail UDI works fine but when i change the rail texture to EL-HSRP it CTD

[surfingsimtropolis 0]

Just want to emphasize that I have little idea what I'm doing and aplogize formost for what is probably user error. I'm learning NAM and it's compontents, first time starting yesterday. Anyway, I cannot get on/off ramps to connect properly from RHW.

Also tried with one-way road tiles any and all directions...produces similar results. Tried going up hill...increasing the distance...lowering it back and forth. Watched a dozen tutorials and read a fair bit. Just wondering if there is a simple answer to this. Also, the only thing in my plugins folder is NAM 3. I'm fully updated 1.1.640.0 etc etc.

Thank you