• Welcome to SC4 Devotion Forum Archives.

NAM 37 Release Candidate -- Discussion and Support Thread

Started by Tarkus, April 23, 2020, 06:01:23 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Tarkus

This thread is intended for general discussion and support purposes pertaining to the NAM 37 Release Candidate.

-Alex

matias93

First, congratulations on getting to the release candidate phase, this has been a very arduous development cycle and you have done a great work!  &apls &apls &apls

I just installed the RC and I'm already finding some bits to be fixed for the definitive version. I'll be posting them here as they appear.

1. The OWR-3 x OWR-2 crossing is correctly pathed but the textures are rotated 90°:




2. The RHW-6 Box Girder bridge dissappeared



I was able to rebuild it, though:



3. The pathing on the AVE-4 x RD looks disconnected



4. The 4x4 AVE-4 roundabout appears to have pathing issues:



"Lets be scientists and as such, remember always that the purpose of politics is not freedom, nor authority, nor is any principle of abstract character,
but it is to meet the social needs of man and the development of the society"

— Valentín Letelier, 1895

Tyberius06

#2
Quote from: matias93 on April 23, 2020, 01:00:01 PM
First, congratulations on getting to the release candidate phase, this has been a very arduous development cycle and you have done a great work!  &apls &apls &apls

I just installed the RC and I'm already finding some bits to be fixed for the definitive version. I'll be posting them here as they appear.

1. The OWR-3 x OWR-2 crossing is correctly pathed but the textures are rotated 90°:


2. The RHW-6 Box Girder bridge dissappeared


I was able to rebuild it, though:


3. The pathing on the AVE-4 x RD looks disconnected


4. The 4x4 AVE-4 roundabout appears to have pathing issues:


1. Thanks for the catch. I can confirm it...
2. Hm... Indeed. I don't know the techy details on this, but I can confirm the strange effect.
3. Hm... It's a funny one. It was already in NAM 36 (and probably prior that too). I can not be sure, but I think this kind of basic crossing were made by Maxis. That pathing issue can lead back to the original release of the game. I don't know if it is buggy functionally or it is just a visual glitch. Original Avenue sometimes has these. Interesting.
EDIT: it's a visual glitch only. The paths are fine.
4. I can confirm it, although I don't know if it has effect on functionality. It was already present in NAM 36. Although the gaps in the paths would be filled up if you drew out the avenue orthogonally too... Hm... Thinking a bit further on this, I think that could be a pathing limitation and or intentional (maybe drawing the diagonal AVENUE to and from the roundabout, never meant to be "legal" in that way), since the "legal" diagonal AVE into AVE roundabout has it's own FLEX piece and that has perfecly fine pathing.
But I'm just guessing on this one. The diagonal AVE-AVE roundabout flex piece however shows the paths properly. I think the way how you used it was meant for supporting the set-up for ONE AVE Roundabout with 8 connecting avenues.


- Tyberius
You may find updates about my ongoing projects into my development thread here at SimCity 4 Devotion: Tyberius Lotting Experiments
or over there on Simtropolis into the Tyberius (Heretic Projects) Lotting and Modding Experiments.
I'm also member of the STEX Custodian and working on different restoration projects on behalf of non-anymore-active custom content creators.
Current projects: WMP Restoration and SimCity Polska Restoration.
Member of the NAM Team and RTMT Team.

b22rian

hey everyone ,

I just wanted to Remind everyone .. that "live help" is also available in our discord sc4D/ Nam chat rooms .., especially related to any issues involving NAM 37 RC .. but really any questions related to sc-4 are fine to ask ..
We usually have plenty of knowledgeable chatters in there (general channel) to answer questions

So we would love to have you join and java is always free !!

https://discordapp.com/invite/NsNZHEC

rivit


I've run the entire suite through SC4Datanode as an Audit. 

TLDR - pretty good -- please see attached zip file showing details, and candidate fixes for "faulty" exemplars.


b22rian

Hello again :)

I just wanted to add one more quick update about our Live help/ nam support discord chat room interface-

We have now added a new channel there called # help desk

So its specific function to answer questions related to sc4 and the NAM mods..

Also if no one is available in the # general channel who can answer your question, this channel is a nice option to post your questions there and check back at a later time , to see if someone responded to your question ( so similar to postings in the forums in that respect ).. ,  :thumbsup:

but again than here is the link to our sc4/ nam chat server rooms -

https://discordapp.com/invite/NsNZHEC

Tarkus

Thank you all for the kind words on finally getting to the Release Candidate stage--it's really a huge relief for us to have the end of this marathon release cycle in site, and to give y'all something new to enjoy.

rivit, thanks for the audit report on the files--I've picked that up and have started giving it a look over.  The thought of separating the textures out is on my mind (it has some other advocates on the team), though I wanted to get the RRW vs. Maxis Rail/MHW vs. MHO crosslink nightmare cleaned out first.  The prospect of making all the ground RHW networks be model-based might also save a bunch of overhead as well, since all those wealth-level textures take up a ton of space.  It'd actually cut an installation with the RHW down by about 180MB, per my last estimate.

And matias93, thanks for the report!  The NWM x Road and OWR intersection textures were all revamped back in 2018 (about a year into NAM 37 development), inspired by the FTL intersection textures.  For some reason, when we originally designed the OWR-3, the intersection with OWR-2 was rotated 90° from all the other such intersections for other networks, and that wasn't caught in the re-texture (in large part because it was a minor change 5 months before we even had an Alpha Build).

I've attached an interim fix below.  Make sure it loads after the Network Addon Mod\2_Additional Network Features\Road, One-Way Road, and Avenue\Additional Widths and Turn Lanes folder in your Plugins.  It'll be addressed in the finalized NAM 37 release.

-Alex

JAndrewJ86

Hi NAM Team,

First off, thank you for your continued hard work! I downloaded the new NAM version this afternoon, and I seem to be having a texture issue with the elevated highways and ramps.

The first attachment is what it looks like with NAM 36. The second is what it looks like with NAM 37. The third is the display setting I'm using, though I fiddled with them and it didn't seem to make much of a difference.

I also tried a few troubleshoots:

1) I removed all other plugins except for NAM 37 from the folder. No effect.
2) I used both SimCity Deluxe for Mac 1.1.1 and 1.2.1 (the 64-bit upgrade). Both still had the same error.

It should also be noted that I had this same issue when I played with NAM 36 on my newer MacBook Pro laptop that is running MacOS Mojave, but the issue is not present when I run it on MacOS Sierra (which is what my MacBook Air is running).

Not sure what could be causing this, and I don't know if anyone else has had the same issue, but I thought I'd raise it in hopes that you have a solution. Thanks!

Wiimeiser

Haven't seen much new so far except the L3&4 FlexFly, the two available REW setups, and the RRW stuff, but I did find a few bugs:
-The RRW piece "Between base texture and override" or whatever it's called is missing LHD paths.
-The new FlexSPUI is missing LHD EU textures, and probably LHD US textures too. The RHD textures are fine, and DrawPaths shows LHD paths are in the proper place as far as I was able to tell, it's just missing proper LHD textures at least for L0 EU, which is the one I tried.
Both of these should be easy enough to fix.
EDIT: Found another one: The last piece on the FlexRamps ring has its EU texture override in the wrong spot. The split half of the EU override is overriding the joined half instead of the split half, and it looks like two copies of the same half of the piece where one is US and one is EU. This is purely a texture override bug, the paths look perfectly fine to me.
Pink horse, pink horse, she rides across the nation...

eggman121

Ok... Time to answer some questions.

JAndrewJ86

I think a texture is missing, Try the one attached "$Deal"$.  If it does not work than you may have to change the texture settings form Low to Medium or High. If it does not work we will go from there.

Wiimeiser

Much of the content is still getting fine tuned. Thanks for the update on the LHD side of things for the RRW. The transition pieces will receive the LHD paths for the RRW. I went all out of trying to get the LHD paths into shape. I dare say there will be more.

The Flex SPUI is @Tarkus' Domain... He should be able to give you an answer in due course.

-eggman121

JAndrewJ86

Quote from: eggman121 on April 24, 2020, 08:54:30 PM
Ok... Time to answer some questions.

JAndrewJ86

I think a texture is missing, Try the one attached "$Deal"$.  If it does not work than you may have to change the texture settings form Low to Medium or High. If it does not work we will go from there.

-eggman121

Thank you for responding and for your help! Unfortunately the texture file and the texture settings did not have an effect. Any other ideas on what may be causing it?

gaoting

Will these two functions appear in the Released version?




Tyberius06

@Gaoting
Nothing newer element won't be in the final release, what is not already in the RC. The final will contain further fixes. So these features won't be in the current NAM 37, as far as I know.

- Tyberius
You may find updates about my ongoing projects into my development thread here at SimCity 4 Devotion: Tyberius Lotting Experiments
or over there on Simtropolis into the Tyberius (Heretic Projects) Lotting and Modding Experiments.
I'm also member of the STEX Custodian and working on different restoration projects on behalf of non-anymore-active custom content creators.
Current projects: WMP Restoration and SimCity Polska Restoration.
Member of the NAM Team and RTMT Team.

rivit

Continuing my experiments with the new NAM37RC - the first thing I noticed on loading SC4 was the large delay at the first test city I loaded after start-up. This felt much slower than I had been used to with relatively full cities with NAM36 so I decided to benchmark a bit.

here is my setup for comparison:
rivit i5-3570K 3.4GHz, 16GB Ram, SSD   CPU Benchmark = 2015  @https://www.cpubenchmark.net/singleThread.html

in each experiment its just plain old SC4 + some config of NAM and we measure time to region from program start, and time to load an empty city from region view.
Stats are in image below - I don't know how to insert the image directly into post

What conclusions can we draw from this?
0) I wasn't hallucinating the timing difference
1) A full controller exists for all NAM37 configurations by default - this is a regression from NAM36 and for the moment unavoidable.
2) there is a sizeable penalty due to the full controller affecting the First City loaded (which is when SC4 seems to parse/process the controller) but not subsequent maps.
3) slower/faster CPUs will show a larger/smaller delay at the first city loading - this is still quite a jump from previous NAMs and may surprise negatively. I expect smaller CPUs will appear to baulk. Time needed looks to be linear with Controller size. This delay is before considering getting city content and rendering.
4) For Euro NAM there is less advantage in selecting less NAM as the Euro textures (for now) are mostly in one 193MB File - this is a regression in some ways.
5) SC4 will always keep a live cache of about 1200MB in addition to working memory, so cache free space will be about 5-600MB, enough for a lot of plugins given enough RAM. Selecting less NAM will improve this a bit, but the large controller is a given at this stage.
6) because the Controller is precompiled there is no time advantage from selecting less NAM.  Memory is handled with caching by SC4 but the cache will come under strain in cities with a lot of NAM and building content - likely texture duress forcing paging. Windows will page temporarily in RAM, so lotsa ram and 4GB patch is always good.

Recommend:
Short term - somehow making the first city start-up behaviour an expectation rather than a surprise. Something along the lines of:
When using NAM expect a longer delay when you load the first city in your gaming session to allow SC4 to process all of the additional features of NAM. If you work in a long session going in and out of cities in a region, only very first time is affected. Keep SC4 running to avoid getting the delay more than once when gaming.

Longer term - partial controller and compiles made easy, File splitting on Euro textures to mirror US texture sets.

~~~~
I've also had a reasonable look at RRW - love the new flex pieces. There are some things needing action - will report soon with some fixes.

Ron

Tarkus

Ron, thanks for reporting your further findings on the RC--it's fascinating stuff, and quite useful, and definitely something that has me thinking about what all we can do going forward to improve the experience. 

I thought quite a bit about whether or not there was a feasible way to involve the Controller Compiler directly in the installation, at least without having to massively rework the installer system itself.  The only thing I came up with was a batch file that one would use to initiate all the install routines, but because the new installer can only install things in a single directory, all those .txt files with the RULs (which are the same size as the NAM Controller itself) would end up in Plugins, which is not at all desirable.  Pulling the bridge readmes out of the installation path is also on the radar for the finalized version.

The only way we're really going to be able to tamp down NAM Controller size is if the (very few) DLL modders in the community can figure out how to implement true new networks via DLLs.  If that were to happen, we could shift the override networks from using massive quantities of RUL2 code, to much smaller quantities of INRUL and RUL1 code.  Rather than millions of lines, we'd be talking about (at the most) tens of thousands of lines.

To answer a couple other questions:

gaoting, I can confirm Tyberius' statement that those features won't be in the finalized NAM 37.  While at various points, they were planned to be on the release track, they were ultimately pulled.  They're still planned to be included in some future release--which one, I can't say at this point, however.

JAndrewJ86, I've seen similar issues with textures showing up white on reports from macOS users (and even noticed it myself the 2-3 times I've gotten to run the game on a Mac).  The textures aren't missing, and the suspicion is that it's a rendering engine issue.  The Mac version has historically been using OpenGL, and the game's implementation of OpenGL is not up to par with its DirectX implementation (which the Windows version defaults to using).  It is possible to at least tell the game to run on OpenGL in Windows, but it's very, very glitchy, and often won't even start (as happened to me just now in attempting to do so).

I do know Apple is trying to push everyone over to using Metal for graphics--I don't know if Aspyr implemented that with either of their updates, and it's also possible that OpenGL's implementation in the later versions of macOS isn't quite the same as it was in the past.

Wiimeiser, thanks for your report as well--the FlexSPUI should be a relatively easy fix.  We're looking at the Type D1-Dual Inside Shift FLEXRamp texture situation--our further investigation of it has shown it has some oddities across the board (particularly with wealth textures), but also shouldn't be terribly difficult in the end to address.

-Alex

Wiimeiser

Thanks for looking into that. In the meantime I found some more bugs:
-The ARD-3 to RHW-3 transition is missing
-The 6C-8C Type D1 is glitched
-The OWR slip lane setup is still missing its paths (might not be fixable?)
-The EU texture for the OWR-1 to MIS transition is missing
-Not shown due to attachment restrictions, but I can't seem to find the draggable setup for the RHW-8S Type E1 ramp, and the static version is marked "deprecated" meaning it's been superseded. However, no such piece or setup exists. The one where it transitions to RHW-6 and MIS does, though.
-Related to the above, the old Type D1-Dual Inside Shift hasn't been marked as deprecated yet, when it probably should be as soon as the FLEXRamp version is fixed.
Pink horse, pink horse, she rides across the nation...

Tarkus

Catching up on those reports . . .

The ARD-3/RHW-3 transition was there . . . but had the wrong EU textures (right textures in US version), and also had broken paths.  Both are fixed with the attachments below.

I haven't been able to replicate any issues with the RHW-8C Type D1 ramp, so no idea what's going on there.

The OWR Slip Lane issues are due to the ever-capricious "Tidal Flow" system that Maxis programmed into the OWR network.  I tried applying the same fix I did to address some similar Tidal Flow issues with the OWR Viaducts that were reported in testing, and it appears things should work now.  There are some broken LHD-specific Slip Lane RULs, however, which is going to take some time to fix.

The EU texture for the OWR-1/MIS transition is not missing . . . but for some reason, the REW's code changed the IID on it from 0x5103E300 (which has EU textures) to 0x5702F280 (which does not).  Attached below are EU textures for the IID specified in the REW's code.  I'd propose we switch it back to 0x5103E300 going forward.

As far as the RHW-8S Type E1 ramp, the pattern needs to be initiated from the inner tile, not the outer.  The outer tile of the RHW-8S should stop right before the pattern starts, similar to what's done with the D2/E2 patterns.  D1 works the same way (though the D1 actually is a bit glitchy).

LTEXT issues tend to be very low priority, but an easy fix.  Probably won't address that one now, since it doesn't affect the functionality (or appearance) of the piece.

The LHD FlexSPUI issues appear to be more involved than previously thought, and are probably going to require a RUL-based solution (similar to how the FTLs have separate LHD RULs, such that we don't have to do any actual path/T21 modification).

-Alex

Wiimeiser

#17
Okay, thanks, I'll try the attachments.

For the RHW-8C Type D1 I wonder if the problem is just a stability thing that will fix itself if I click around a bit, though it could still have a bug.

For the RHW-8S Type E1 ramp, I'm having trouble following. Could you please provide a picture for reference?

EDIT: All the attachments work fine, but clicking around didn't fix the RHW-8C Type D1 issues. In fact, 1. The preview (when it's yellow) actually shows up correctly, and 2. The other direction is even worse, displaying not only the wrong texture, but displaying it rotated 180 degrees. Though it might be orientation-specific, I'll check again.

EDIT2: Here's what it looks like from all angles: The "off" variation, where the traffic leaves, displays a rotated tile, the "on" variation displays the wrong tile in the correct position. Paths and previews are normal. This could be another case of the Capitol Records/Max's Grill conflict for all we know. I'll need to test with US textures, RHD, and an empty plugins folder, and all the combinations thereof, to know for sure, though...
Pink horse, pink horse, she rides across the nation...

Tarkus

McDuell and I investigated the D1 issue further . . . turns out it's actually tied in with the issues with the new Type D1 Dual Inside Shift ramp, and I had an older copy of the Euro .dat file in my test, which wasn't afflicted.

The regular Type D1 is fixed for EU textures with the files below (one for RHD, one for LHD).

And the 8S D1 pattern start off looking something like this . . . it's still not always the most stable thing in draggable form, though is more so with the FLEXRamp.



-Alex

Wiimeiser

Thanks, that fixed the problem. But while messing around I found two more texture issues with OWR, specifically crossing TLA-7 and transitioning to RHW-4.

Also, I'm still not following on the RHW-8 pic. I did start it that way, (and that's how I start the D2), I made a MIS come off diagonally, but I can't figure out how to get it to turn into RHW-4, when I tried it just messed up the whole thing as seen below. I must be doing something completely wrong...
Pink horse, pink horse, she rides across the nation...