• Welcome to SC4 Devotion Forum Archives.

NAM 33 Pre-Release -- Discussion, Support, and Bug Report Thread

Started by The NAM Team, July 29, 2015, 09:56:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Tarkus

Thanks, Moonraker--if it's a D1, that's one that couldn't be done with those networks due to the overhang issue (the 6S overhang would collide into the MIS).  I'll correct the LTEXT to remove the reference to the L1 and L2 8S.

-Alex

roadgeek

I ran into an issue with RHW-6C L1 over RHW-6C L0. I will add an image as soon as I have a chance to capture it, but it is the center piece in the bridge that reverts to RHW-2xRHW-2. The other eight tiles render correctly.

Fantastic job NAM team!!!! This release is simply AMAZING!!!  &apls &apls &apls &apls &apls

Tarkus

I've confirmed that one--an oddly annoying one to come up.  I'll add a band-aid in now to fix it, until the MetaRUL system is fully in place.

Edit: It's now been fixed.

-Alex

Geometry123

You will never know when will the next NAM be released. Only time teasing will tell. :P

"We're making SimCity, not some dopey casual game"
                                                 -Ocean Quigley


JoeST

Copperminds and Cuddleswarms

Tarkus

That one may have to wait until the MetaRUL system is in place.  I'll give it a look, but it may end up being a needle-in-the-haystack sort of search.

-Alex

noahclem

Those kinds of flipping occur in quite a number of situations, at least when you start building interchanges at the level of complexity that your appears to be. ~75% can be solved easily by clicking around nearby and another 15-20% will eventually work if you are determined enough and really try every possible combination of clicking. Unfortunately there remain a number of situations that persistence can't yet solve at this time. In the likely case that you already knew all that hopefully someone else reading is helped and most importantly it's great to know there's a solution on the horizon for these cases  :thumbsup:

LReyomeXX



Has this actually been documented yet. I stumbled on it earlier when playing around with RHW-6S ramps

Tarkus

If you're referring to those dedicated ramp interface drag patterns, they are documented in the DRI diagrams that woodb3kmaster did awhile ago, as well as Ganaram's videos.

-Alex

GDO29Anagram

Quote from: LReyomeXX on August 20, 2015, 05:45:59 PM
Has this actually been documented yet. I stumbled on it earlier when playing around with RHW-6S ramps

It's a documented feature, and has been for ages now. The relevant documentation's been available in the past pages already.
<INACTIVE>
-----
Simtropolis | YouTube | MLP Forums

Tarkus

Quote from: noahclem on August 20, 2015, 02:11:24 PM
Those kinds of flipping occur in quite a number of situations, at least when you start building interchanges at the level of complexity that your appears to be. ~75% can be solved easily by clicking around nearby and another 15-20% will eventually work if you are determined enough and really try every possible combination of clicking. Unfortunately there remain a number of situations that persistence can't yet solve at this time. In the likely case that you already knew all that hopefully someone else reading is helped and most importantly it's great to know there's a solution on the horizon for these cases  :thumbsup:

Having just tested this particular instance, clicking around does indeed fix it.  Some of its counterparts with other networks (i.e. L2 MIS over L1 RHW-4, L2 RHW-4 over L2 RHW-4) work perfectly fine, without any wrong flipping, so the solution may lie there. 

Edit: Found the needle in the haystack by comparing the working MIS-over-RHW-4 with the MIS-over-MIS version.  It was on the L2 side, and I've just fixed it.  I'm going to check to see if it's affecting any other MIS-over-MIS DxO situations.

Edit 2: Now fixed.  It affected all L2 Diagonal RHWs going over L1 Orth RHW-3, MIS, and RHW-6S.

-Alex

JP Schriefer

I installed the Pre-release and doesn't matter what I do, I choose people to drive on the left and they keep driving on the right. In NAM 32 I did almost the same configurations and it worked, is there something in this version which can conflict with it?

Tarkus

The NAM doesn't change drive side, so if you tried to install left-side NAM files on your game, all you ended up with is a broken right-side driving game.  You'll need to go in and modify the registry to fix it.  This post by RippleJet should get you set up.  There's also an alternate method involving shortcut modification as described by smoncrie, later in that same thread.

-Alex

mgb204

That would probably work, but there is a much easier way without messing with the registry.


  • First you need to ensure you've a folder in the default install folder (usually C:\Program Files (x86)\Maxis\SimCity 4 Deluxe\) named "UKEnglsh".
  • This needs to contain a copy of whatever locale file you want to use with the game, this can be copied from either the English folder or any of the other language folders, the file you are looking for is named SimCityLocale.DAT.
  • Once that's setup, edit the shortcut target to add this line; -l:"UK English".

Basically setting the game to UK English mode makes sims drive as in the UK on the left side.

Jimmyson

Something doesn't seem right. I'm sure it was fixed, but it can't handle a L0 fly-over in this configuration. Please correct me if I am wrong.


Tarkus

The issue is an adjacency stability one--the FLEX Height Transitions are too close to the diagonal RHW-4.  There is no any code to support FLEX Height Transitions next to diagonal crossings, so it's reverting to RHW-2 there--it's not really a bug, as much as it is something we haven't added yet.  If you put an extra tile or two in between the transitions and the point where the L1 MIS is supposed to cross over the Diag RHW-4, it should work.

-Alex

Jimmyson

Thanks Tarkus.

And I have just spotted another, but first, congratulations goes to the RRW team for jumping onto this. I have previously posted before (SC4D and Simtropolis) about the rail crossing markings and boom gates. I thought to test this out. I remember that the locality can be changed to LHD with Regedit, or a shortcut parameter (as the Aussie SC4 is RHD by default.

Here are my findings:

Sample A:


       
  • SimCity 4 LHD
  • NAM not installed
  • US Markings
  • SRM Installed
Sample B:


       
  • SimCity 4 LHD
  • NAM 33-PR1 installed RHD (testing only)
  • RRW Installed
  • AUS Road Markings
  • SRM Installed
Sample C:


       
  • SimCity 4 LHD
  • NAM 33-PR1 installed in LHD
  • RRW Installed
  • AUS Road Markings
  • SRM installed


This leads me to conclude that the T21 pieces for rail-crossings now match the road driving side, the textures still need updating. Now, maybe because I am using the AUS road markings, its only be implemented for the RHD side. The LHD textures are missing or not yet implemented...

EDIT: And it may seem other textures in the AUS Road Markings set have not been implemented for LHD




mgb204

All the base RRW crossings are made for LHD, I believe there was some implementation error caused when the RRW folder was moved to a new home, that should be resolved for the final release, until then you can drop the attached files into the z___NAM\y_RealRailway folder and they should work. One note, you may have to rename the existing EU (RHD) crossing texture file, shown here in red, in order to ensure with the two added files that the load order is as follows:


  • aRRW Crossings LHD.dat
  • RRW Crossings EU Cosmetic.dat (this file should exist in the RRW folder already)
  • z_RRW Crossings EU Cosmetic LHD.dat

There does appear to be a problem with the auto turning lane textures, but I could never quite get a handle on them, I think some are incorrectly flipped or ID'd for EU/LHD users. If I remember correctly the $ and $$$ wealth textures are correctly orientated, the problem is only with the $$ wealth textures reverting to RHD).

I don't think the Road-OWR texture was ever converted for LHD use, but that's a simple fix I should be able to sort. I'll take a proper look at the ATLs problem today and see if we can get them fixed for release also.

JP Schriefer

Thanks Tarkus and mgb204 for your support, now it's fixed :)