• Welcome to SC4 Devotion Forum Archives.

NAM Issues Thread - PLEASE POST YOUR NAM QUESTIONS AND PROBLEMS HERE

Started by jahu, June 03, 2007, 10:15:49 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

noahclem

It's not possible to plop the puzzle pieces directly over the el-rail stubs at the ends of the bridges. You will need to use a trick to get rid of those stubs. Drag the el-rail one additional tile on each side of the bridge, drag a road under that el-rail, immediately adjacent to the bridge, and then bulldoze the outside el-rail tiles. You may then bulldoze the roads and you will have only the bridge left, with no el-rail stubs.

You can find better instructions with pictures in the NAM readme.

lostwizard

I have an interesting problem though it causes no particular problems for
game play. When installed on Windows, the road cul-de-sacs appear as
expected (with the option enabled during NAM install of course). However,
the exact same version of Simcity 4 Deluxe installed under Wine and using
the exact same plugins folder (duplication of the folder from Windows to the
Wine install) does not show the cul-de-sacs on roads. They do, however, show
for streets.

It is interesting to note that drawpaths shows the paths for the
cul-de-sacs, as can be seen in the attached images.

Guzz


NCGAIO

Quote from: noahclem on August 26, 2013, 09:04:46 AM

You can find better instructions with pictures in the NAM readme.



I searched for these instructions throughout the documentation but unfortunately found nothing.


It would be somewhere else?

noahclem

Quote from: Guzz on August 26, 2013, 11:46:10 AM
Thanks noahclem. It works.

You're very welcome!

@ NCGAIO: Are you sure there wasn't anything in the NAM readme? If not than checking Xannepan's original bridge LEX uploads should help. If nothing else works let me know and I'll explain the situation with pictures. :)

TWAK

getting pretty bad lag when I do anything involved plopping, dragging, or interacting the TLA5, but my one way/road pieces are fine.  I looked at google but didn't see any results

memo

Quote from: lostwizard on August 26, 2013, 09:52:45 AM
I have an interesting problem though it causes no particular problems for
game play. When installed on Windows, the road cul-de-sacs appear as
expected (with the option enabled during NAM install of course). However,
the exact same version of Simcity 4 Deluxe installed under Wine and using
the exact same plugins folder (duplication of the folder from Windows to the
Wine install) does not show the cul-de-sacs on roads. They do, however, show
for streets.

It is interesting to note that drawpaths shows the paths for the
cul-de-sacs, as can be seen in the attached images.

Apparently, the cul-de-sac file is loaded, but the textures get overwritten by another file that is loaded afterwards. The only reason for this I can think of is that the loading order of plugin files is determined by the file system. While Windows does not distinguish between upper and lower case letters, *nix usually does. Perhaps you can solve the issue by renaming the file "zzzNAM_Retexture_and_Cosmetic_Mod_Culdesac_Plugin_Superhands.dat" such that it loads after the other retexturing files, possibly by switching to upper case letters or so.

Quote from: TWAK on August 27, 2013, 12:59:00 AM
getting pretty bad lag when I do anything involved plopping, dragging, or interacting the TLA5, but my one way/road pieces are fine.  I looked at google but didn't see any results

Usually, missing SC4Path files can cause a lag like this. However, since the path files for TLA5 are contained in the NetworkWideningMod.dat, just like the TLA5 textures, I guess it is not the cause of your problem...

spot


lostwizard

#2828
Quote from: memo on August 29, 2013, 02:53:46 PM
Apparently, the cul-de-sac file is loaded, but the textures get overwritten by another file that is loaded afterwards. The only reason for this I can think of is that the loading order of plugin files is determined by the file system. While Windows does not distinguish between upper and lower case letters, *nix usually does. Perhaps you can solve the issue by renaming the file "zzzNAM_Retexture_and_Cosmetic_Mod_Culdesac_Plugin_Superhands.dat" such that it loads after the other retexturing files, possibly by switching to upper case letters or so.

That had not occurred to me. It looks like the conflict is with NAM_Retexture_and_Cosmetic_Mod_Road.dat.

The thing about unix (at least Linux) file systems is that the file system itself does not sort directories at all. If it did, then the file naming would be fine (upper case would sort before lower case). I see that while the order appears deterministic on at least my system, it is apparently random and certainly not alphabetical. Some basic research suggests that on Windows NTFS might sort the files but FAT32 does not. It is apparent that the game itself does not sort the files before opening them (which makes sense - why would it need to?).

I wonder if there's something I can do to force ordering, like maybe a shared library I can LD_PRELOAD to force ordering on readdir() (which does the directory reading).

Edit: Yes, it was definitely file load order. I lashed up a FUSE file system that sorts directories and redirected my plugins folder through that. Cul-de-sacs are showing up as they should now.

APSMS

Well, when it comes to sorting, I am not sure what you mean by that, but I think (am pretty sure) that there is a predetermined loading order for SC4 that can be seen easily if you use the DATPacker by wounagaine. The files & folders are arranged in the same order in which SC4 loads them, and since the last file loaded overwrites all conflicting files that might have been loaded previously (in the startup process) the zzzFileFolder naming practice becomes clear.

In fact, the NAM makes use of the fact that ~ loads first and _ loads last (according to the game anyway) to make sure that critical files are never overwritten. You could also try putting the texture plugin in this folder (the "Z___NAM" folder) to see if it helps solve the problem, since I know for a fact that it takes effort to make a folder that loads after this one due to all the underscores.

I am pretty sure that the only thing ordering files on your explorer windows would do would be to make it easier to see the file overrides properly. I don't think that it has anything to do with the way the game reads the files, however.
Experience is something you don't get until just after you need it.

My Mayor Diary San Diego: A Reinterpretation

lostwizard

Quote from: APSMS on August 29, 2013, 08:28:05 PM
Well, when it comes to sorting, I am not sure what you mean by that, but I think (am pretty sure) that there is a predetermined loading order for SC4 that can be seen easily if you use the DATPacker by wounagaine. The files & folders are arranged in the same order in which SC4 loads them, and since the last file loaded overwrites all conflicting files that might have been loaded previously (in the startup process) the zzzFileFolder naming practice becomes clear.

In fact, the NAM makes use of the fact that ~ loads first and _ loads last (according to the game anyway) to make sure that critical files are never overwritten. You could also try putting the texture plugin in this folder (the "Z___NAM" folder) to see if it helps solve the problem, since I know for a fact that it takes effort to make a folder that loads after this one due to all the underscores.

I am pretty sure that the only thing ordering files on your explorer windows would do would be to make it easier to see the file overrides properly. I don't think that it has anything to do with the way the game reads the files, however.

I wasn't going to respond on this because I solved my problem, but here's a more complete explanation for others that might have the same problem.

I wasn't talking about explorer windows or any confusion related to the reason for the file names. In fact the texture file in this case was already in the z___NAM folder.

It turns out you are, in fact, mistaken when it comes to there being a "predetermined" order the game uses. The game itself doesn't sort anything at all when it is loading the files in the plugins folder. Datpacker might sort the files before making its dat files, but I'm not using it because I have no need of it and it just adds more complexity when messing with plugins. (Besides, it's recommended not to use it with the NAM.)

It turns out that the file name ordering behaviour being exploited in this case is a feature of the NTFS file system on Windows rather than the SC4D exe itself. Because I'm using Wine on a Linux machine instead of Windows, the underlying file system is not NTFS and, thus, does not have the file name ordering behaviour. Note that I'm referring to the low level operating system stuff here, not the explorer window or what have you. If you look at the low level system calls that are used to read a directory, the order you receive the file names may be any random order, and may not even be related to the order you created the files in a particular directory.

I have been able to conclusively demonstrate that the exe itself does not sort the files. The cul-de-sac textures were missing when I just left the files alone on the file system, just as they stored when they were installed. Then, when I installed a shim file system that sorts directories before returning the list of files to the application, the textures started appearing correctly. That means with absolute certainty that the exe file itself is not sorting the file names. Thus, SC4D itself has no predetermined order in which it loads the files. Instead, the fact that the file naming convention for controlling such loading works at all is an accident of the way Windows implements NTFS. (Obviously, if you've datpacked the files, the order they appear in the dat file would matter instead. Odds are datpacker itself relies on the same feature of NTFS and Windows rather than doing any sorting on its own but since I haven't studied its implementation, I don't know.)

The upshot of all this is that if one is going to use Wine to run SC4D with the NAM or any other order-sensitive addon, one needs to use a file system that sorts the file names in a directory before passing the list to the application.

whatevermind

First off, I have to say the new NAM (312) works beautifully so far. There was some of the usual rebuilding of things broken by the update, but it was overall a very smooth transition, which is good for the plugin-picky! I also love the manuals that go along with it, they're really well done and quite helpful.

One thing I noticed though is that the info on the updated Maxis stations doesn't mention that you have to bulldoze and rebuild existing ones to get the new, higher values, which might be useful to mention, especially since I think a lot of people place stations and forget about them.

I don't love the new implementation of the road turning lanes. They're incredibly unstable, and while I can get used to them not being automatic anymore, it would be nice to not need to rebuild them anytime changes are made to the road. But again, that's minor.

I'm currently trying out the North American textures, which are overall pretty nice, particularly some of the diagonal intersection handling, but there's two minor complaints. First, the road/street transition:

This used to be a lot smoother, where you barely saw any of the road at all, and I think that looked a lot better - now the road portion takes up most of the square, and the transition seems a lot sharper than before.

Secondly, the obstacle course traffic control devices in the street intersections in residential zones:

I don't really get why these are included in a standard texture set. They're incredibly rare in the real world. A better implementation of them would be similar to the road turning lanes, where you have to purposely place them if you really want them.

You can also see in that second texture a bit of a bug with the streets, namely the signs in the roadway. It's a lot more pronounced at diagonal intersections, but it seems that with the wider curves in the North American textures, the street signs weren't moved to match.

I remember seeing somewhere that the Norwegian textures were similar to the American, but I noticed in the installer that they are listed under RHW2 options. Does that mean they only change the RHW2 textures, or are they a full texture set?

z

Quote from: whatevermind on August 30, 2013, 05:15:05 PM
I remember seeing somewhere that the Norwegian textures were similar to the American, but I noticed in the installer that they are listed under RHW2 options. Does that mean they only change the RHW2 textures, or are they a full texture set?

The Norwegian texture set uses the standard RHW Euro textures, with the exception of the RHW-2 and RHW-3; instead of white median lines, they have yellow median lines.  The installer documentation will be fixed (right now) to include RHW-3 in the description.  For now, the Norwegian texture set affects only these two RHW networks.

irwinkevincarpio

#2833
Hi, guys!

To the NAM team, thank you so much for doing all of this stuff for us. We truly are lucky that developers like you continue to give this game a lot of love.

Anyway, prior to installing the 31.2 update, I installed the no-cd patch for 1.1.640. I also cleared up my plugins folder of my transport related mods dated prior to 2013. I have the US version of the game but I converted it to LHD via the UKEnglsh folder renaming and the hex digit alteration in the registry. I also selected the LHD option in the new NAM.

I now that Mandelsoft patched the SPUI some hundred pages back, but will it also work for the Euro textures?

In any case, here are the bugs I found:

The TuLEP pieces for the TLA-7 or the AVE-6 have some redundant arrows, the texture for the ave-6 - Ave -4 intersection seems incomplete, the SPUI is stuck in RHD and is non-functional for both elevated Maxis Highway override and Elevated RHW-4, and the diverging diamond has some blocky transitions.

If it's any help, I noticed the bugs with the TuLEP pieces in my copy of NAM30 and just thought that they'd be fixed in a later patch but it seems only I'm getting this bug.

Thanks again for this awesome mod. It's definitely what completes Simcity 4.

P.S. how do you make images display on a post without going over the limit? Also, what does it mean if I can't use any cheats? I try using the draw paths cheat with the extra cheats plugin but nothing happens when I press enter.

memo

@lostwizard: Thanks for the detailed explanation. I was not aware of the unsortedness of Linux file systems, at all. As I have just worked on something that requires the exact loading order, this is valuable information. In particular, this means that the order is different for Windows and Mac users. I have done some quick tests and suppose that on the (case-insensitive) standard Mac file system HFS+ filenames are ordered by their lower-case variants, whereas on (semi-case-insensitive) NTFS they are ordered by their upper-case variants. In particular, the annoying underscore character '_' comes after any alpha-numeric characters in Windows, but before alphabetic characters and after numeric characters in OS X.

As I neither have the Aspyr port nor have Wine installed, I cannot check whether this really is the case, though.

Quote from: irwinkevincarpio on August 31, 2013, 07:46:49 AM
P.S. how do you make images display on a post without going over the limit? Also, what does it mean if I can't use any cheats? I try using the draw paths cheat with the extra cheats plugin but nothing happens when I press enter.

There is a bug in the extra cheats DLL, so that it is loaded by the game only by a chance of about 50%. Restarting the game usually fixes this.

sidestab

mine keeps saying simcity4.exe is not found any help guys??

APSMS

Thanks, lostwizard. It seems I stand corrected, but at least I learned something. This is valuable information in case I ever make the jump to Linux. I guess being stuck in Windows leaves a bit to be desired concerning other OSes.

Also, concerning whatevermind's issues concerning textures, if we open up the DAT file with the modified textures and simply delete them, will the game revert to the default, or would it cause potential conflicts elsewhere that I'm not aware of (e.g. other lots/RULs that rely on these textures to display properly)? Because I, too, find those street islands highly unrealistic. I don't thing I've ever seen them implemented quite like that anywhere, and it'd be nice to know if I can do the fix myself.
Experience is something you don't get until just after you need it.

My Mayor Diary San Diego: A Reinterpretation

z

Quote from: memo on August 31, 2013, 11:04:03 AM
There is a bug in the extra cheats DLL, so that it is loaded by the game only by a chance of about 50%. Restarting the game usually fixes this.

I have never noticed this.  Do you have the DLL in your root Plugins folder?

memo

Steve, I don't think the order displayed in the Finder is representative here. After all, the Windows file explorer does not display files in the order used by the game, either. I rather based my assumption on this:



Quote from: z on August 31, 2013, 02:26:29 PM
I have never noticed this.  Do you have the DLL in your root Plugins folder?

Yes, I do. I have mentioned it in [this post], but to be honest, I still don't know whether my assumption is correct.

Quote from: APSMS on August 31, 2013, 02:19:41 PM
Also, concerning whatevermind's issues concerning textures, if we open up the DAT file with the modified textures and simply delete them, will the game revert to the default, or would it cause potential conflicts elsewhere that I'm not aware of (e.g. other lots/RULs that rely on these textures to display properly)? Because I, too, find those street islands highly unrealistic. I don't thing I've ever seen them implemented quite like that anywhere, and it'd be nice to know if I can do the fix myself.

Indeed, you can safely delete the textures.

z

Quote from: memo on August 31, 2013, 04:11:31 PM
Steve, I don't think the order displayed in the Finder is representative here. After all, the Windows file explorer does not display files in the order used by the game, either. I rather based my assumption on this:


You're quite right.  In the post from which I got the picture (entitled "Mac directory order"), it says, "This is the order the Mac sorts characters (in Mountain Lion): space, underscore, dash, exclamation, question, at, star, accent, hat, plus sign, open bracket, equal, close bracket, pipe, tilde, numbers, letters, µ, π, Ω, and ".  However, this clearly applies only to the Finder display - not to the underlying filesystem.  So I've removed the misleading part of my post.