Menu

LEX File Exchange
EA Support Files
SC4 Wikipedia
Network Addon Mod
Dependencies
Chat

Author Topic: NAM: Development  (Read 492894 times)

0 Members and 1 Guest are viewing this topic.

Offline Wiimeiser

  • Forums Senator
  • *
  • Posts: 624
  • Total likes: 90
  • Reputation: 0
  • Pink horse, pink horse
Re: NAM: Development
« Reply #1620 on: October 23, 2018, 05:18:55 PM »
If I can figure out what is up with the QuickChange Xpress issues
What seems to be the problem? Not plopping properly?
Pink horse, pink horse, she rides across the nation...

Offline paddy0174

Re: NAM: Development
« Reply #1621 on: October 24, 2018, 06:51:16 AM »
I have to agree with mattb325, if the number of active developers go down, the system behind needs to be more focused. And from my point of view, it wouldn't be to harsh on users, to simply leave things as they are, especially for some outdated content like the Maxis Highways. I do see the point, that some doesn't want or can change to the RHW, but that really doesn't mean, they need to get new features or updates behind the already existing version(s). I think of this is an alternative, you simply cannot invent new things, if you always have the pit fall not to only cover backwards compatibility but to release new features. At some point, there is simply no way to make everyone happy....

What brings me to my second point. I do know and understand, that it is always some kind of a hard dicission, to "open up" things. But as I said before, I would love to see at least a discussion about making all these things "open source" and make use of collaborating and developing tools, the internet gave us in the last few years.

Let me just describe my thoughts, how this can go further:
  • make the code and ways to work the code public
    Why? A lot of people are able to help, but only a few are willing to go that deep. But right now, nearly all tasks are stuck upon you three, even the easiest and frustrating tasks with a lot of repeated steps... That can be outsourced.
    If there is somewhat like a repository, everyone can see, what is going on, and where a step in can be made. But, if handled via github/gitlab or any other collaborating software, you still would have the control. PullRequest is the key phrase here.
  • make the development strictly bound to what you like
    Sure, if you ask ten people, you will get twenty opinions, what is needed, and what can't be left out. Nope, sorry, that's not the way it works. As of this moment, everything in NAM should be considered as a starting place at zero. Whatever is in there right now, it stays. But only the things you decide will get new development or just bug fixes.
    The good ol' three:
    1.) nothing is done, no new features, no bug fixes (if a user wants to use it, fine, if he wants to improve it, sure, go ahead, make yourself comfortable with github and make a pull request)
    2.) bug fixes (strictly bound to things, where a new version has broken something)
    3.) new feautures
    => what mattb325 said
  • a healthy discussion about the financing for the work on the NAM
    what I would really like to discuss, would be the financial aspect of this. My "vision" would be, to make something like a non profit found, that takes care of the financing. I know, I know, everyone tells you the same, not needed, the costs for the site are already hard to get and so on.
    I wouldn't have thought about such a way, if I hadn't the perfect example for: Contao (formerly TypoLight). They did it this way, right now the main developer is a paid employee, and a lot of projects get paid for by the non profit foundation.

And for the end of that long post, I just want to go a bit deeper into the last point. I do know, that working on things, you don't like totally, can be a PITA. Getting some money for the hard work you do, doesn't make it less frustrating, but it makes up for it on another edge: go have a big and tasty dinner with your gf, wife, mother whatever. Buy the new keyboard or mouse from this money, whatever. At least it gives you one thing: you have something in return, it is more like "the community shows you respect and aknowledges your work", then the big money, but hey... :D :D :D If we are lucky, in a few years or months the foundation could support ST and SC4D for their monthly costs.

I for one would love to get one larger summ to a foundation, knowing that this helps not only on one corner, but over time can asure a still runnning system.

And btw, I don't find it offensive, to pay for things I want to have. Right now, I would be looking for someone to make a diagonal ERRW crossing over a diagonal road, and I would be willing to pay for that extra. Sure, I cannot pay hundreds of dollars for that, but a few bucks... If this pushes something forward, I want to have... And if the project is something, more people want, why not letting them pay for the fast track?

Just my two cents, and at the end one personal note: I am not a native english speaker. I try my best, but if something in this text is wrong (wrong use of words or grammar) or if there is something that comes down offensive, please let me know. It isn't meant that way, so please bare with my english and correct me! :)

Back to the game after nine years - and everyday I find something totally new! :)

Online Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11359
  • Total likes: 4261
  • Reputation: 71
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: NAM: Development
« Reply #1622 on: October 25, 2018, 09:55:48 AM »
Just want to put in a few quick words while I have a down moment (just completed the third day of a four-day span of 12-hour work days--5:30pm to 5:30am--and about to call it a night/morning).

No one has to worry about the base Maxis Highway features going anywhere.  They pretty much require zero technical support from our end--the NAM features that exist for them are ancient and heavily battle-tested--and the only component that bumps elbows with them is the Maxis Highway Override.  It's highly unlikely they'll get any updates in their default form--there's been none in the past 7 years, and maybe two in the past 13 years--but we're not going to completely push them out of the NAM ecosystem. 

In fact, the only things that have been fully pushed out are (a) things that have been found to be seriously broken--i.e. the original attempt at Draggable FAR in NAM 28 (May 2010), which caused a CTD whenever one plopped a Car Ferry, or (b) are designed in such a way that they actively prevent future development.  The original "automatic" version of the Road Turning Lanes Plugin, is the only such case.  It was pulled in NAM 31, after being largely responsible for the initial NWM release having a development cycle of 4 years, and then threatening to take Draggable FAR for an especially long detour.  The faction of the team that had been most adamant about keeping it ended up joining the removal chorus after that.  (Had it been limped along to the present-day, it would have also impacted the Draggable Road Viaducts, and--in an ironic twist--the FLEX Turn Lanes.)

As far as the QCXs go, there's still a lot of internal fact-finding needed there, but suffice to say, the plopping side of things (aside from the lack of proper preview models at present) is not the problem, and works exactly as intended.

I'll have more on Matt's and paddy's thoughts tomorrow.

-Alex

Offline paddy0174

Re: NAM: Development
« Reply #1623 on: October 25, 2018, 12:45:47 PM »
Thanks for your always detailed answers! :)

And take your time, no quick answers needed (at least on my side) :D
Back to the game after nine years - and everyday I find something totally new! :)

Online Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11359
  • Total likes: 4261
  • Reputation: 71
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: NAM: Development
« Reply #1624 on: October 27, 2018, 01:20:54 AM »
As promised, I'm back.

5) Simplify or split the installer: is it possible to leave the last known built installer that worked really easily for you as is and then add a second/third installer for new stuff added?

. . .

If the issue is around the monolithic installer which, to my eye as an outsider, seems to be a series of either/or selections related to content and interchangeability of such choices,  surely the end user can run a few separate installers based on their choices? EG: one for LHD; another for RHW; another for RRW; another for legacy, etc,  over and above a "base installer" of content that you as the developers determine to be a standard or ideal set up.

With that first process, that does actually fit with something that has been periodically discussed internally--the notion of having a "frozen core", coupled with a series of more frequent update packages, containing new/improved features, fixes, etc. that would be applied to it.  The "core" would be briefly "thawed" out once enough updates had been issued, with those updates being rolled in, and the core "re-frozen", starting the process again.

The result of the latter process would likely result in something that looks more akin to the NAM 30 paradigm.  While that didn't require quite the level of installer complexity, were readily maintainable, and didn't really cause any of our more experienced users to sweat during installation, it did cause some issues for the general user population.  In the 6 years during which the NAM existed in that configuration, our consistent #1 tech support issue was the infamous Red Arrow Bug, which resulted from people messing up the process of updating versions, or trying to mix-and-match incompatible versions of the various separate download components (i.e. trying to run RHW 5.0/0.50 with NAM 29, or RHW 4.1/0.41 with NAM 30). 

NAM 31, for all its issues (there was a reason people called it "NAM Vista"), did end up completely eliminating the Red Arrow Bug.  That said, some of the modern conveniences in the present installer could theoretically be ported over to smaller installers without much issue (save for the occasional user who has a sticking point about installing Java, since the TSCT and Controller Compiler require it), and could potentially introduce some new improvements to a refined version of the old approach.

I think there's quite a few potential ways out of the current situation (including also writing a new Monolithic script, taking what worked from the current version, and working it into a steroid-infused version of the NAM 30 script), though they're pretty much all going to require some dedicated time working on packaging and logistics, rather than development.  If they end up making it such that we don't have to spend much time on those tasks later on, however, I'd consider it a worthwhile investment.

  • make the code and ways to work the code public
    Why? A lot of people are able to help, but only a few are willing to go that deep. But right now, nearly all tasks are stuck upon you three, even the easiest and frustrating tasks with a lot of repeated steps... That can be outsourced.
    If there is somewhat like a repository, everyone can see, what is going on, and where a step in can be made. But, if handled via github/gitlab or any other collaborating software, you still would have the control. PullRequest is the key phrase here.
  • make the development strictly bound to what you like
    Sure, if you ask ten people, you will get twenty opinions, what is needed, and what can't be left out. Nope, sorry, that's not the way it works. As of this moment, everything in NAM should be considered as a starting place at zero. Whatever is in there right now, it stays. But only the things you decide will get new development or just bug fixes.
    The good ol' three:
    1.) nothing is done, no new features, no bug fixes (if a user wants to use it, fine, if he wants to improve it, sure, go ahead, make yourself comfortable with github and make a pull request)
    2.) bug fixes (strictly bound to things, where a new version has broken something)
    3.) new feautures
    => what mattb325 said
  • a healthy discussion about the financing for the work on the NAM
    what I would really like to discuss, would be the financial aspect of this. My "vision" would be, to make something like a non profit found, that takes care of the financing. I know, I know, everyone tells you the same, not needed, the costs for the site are already hard to get and so on.
    I wouldn't have thought about such a way, if I hadn't the perfect example for: Contao (formerly TypoLight). They did it this way, right now the main developer is a paid employee, and a lot of projects get paid for by the non profit foundation.

And for the end of that long post, I just want to go a bit deeper into the last point. I do know, that working on things, you don't like totally, can be a PITA. Getting some money for the hard work you do, doesn't make it less frustrating, but it makes up for it on another edge: go have a big and tasty dinner with your gf, wife, mother whatever. Buy the new keyboard or mouse from this money, whatever. At least it gives you one thing: you have something in return, it is more like "the community shows you respect and aknowledges your work", then the big money, but hey... :D :D :D If we are lucky, in a few years or months the foundation could support ST and SC4D for their monthly costs.

With respect to #1, everything technically is already out in the open in some way or another.  The current version of the RUL code is on a publicly-visible GitHub account with an easy to remember URL (https://www.github.com/NAMTeam).  There was once an internal Gitlab for the non-RUL stuff (.dat files), but the server for it crashed and it has not been brought back.  That said, as long as one has a tool like ilive's Reader or Tropod's SC4Reader, it's quite easy to peer inside any of the mods files.  Granted, the contents may not make much sense if one isn't familiar with how the game's transit network implementation operates, but there are tutorials and spec guides around for much of it, either on the NAM How-Tos and Tutorials board, or the old Wiki.  We're also still around to help out with any questions. 

Most of us learned how to do all this stuff by sheer determination.  Back in 2006, when I started, I really wanted to be able to cross an Avenue Viaduct over an RHW--something which the initial RHW release (1.2/0.12) couldn't do.  At that time, there were hardly any NAMites around at all (2006 was surprisingly rough for SC4), and it took me a couple months of studying the documents that were out there (which were far more convoluted than what is available now) in order to start being able to do things.

#2 is actually pretty close to how we approach things.  We do generally try to work on the projects that will bring things we want to see come to the game, and that we will enjoy making.  This does sometimes result in a rather freewheeling developmental process, in which projects get started, shelved, and then brought back (sometimes multiple times) before seeing the light of day, but it's helped us stick around for almost 15 years now.  I would say that "taskmaster" types would probably go insane being on the inside of the project, because our approach often borders mild chaos.  We only start to tidy things up and bring order once we think we have enough stuff ready to release.  The elusive "golden ticket" would be the ability to do that on smaller batches with a quicker release cadence, without it causing issues on the end user side.

As far as #3 goes, the response to anyone who has offered to monetarily contribute to development has indeed been to direct them to give to SC4D and ST, for fostering our continued existence.  While I don't think anyone would really say it out loud in the past, beyond the previously oft-cited angles of wanting to "do it for fun" and "not turn a hobby into a job", I think that is in part due to concern for the logistical and interpersonal issues that could potentially result from money entering the equation. 

If one looks at the credits and acknowledgements list for the NAM, as of NAM 36, there's about 120 unique names on that list, whose contributions vary considerably in type and scope.  The list of those actively and regularly contributing to development was around 30 people at one point in 2010.  Particularly with some of the internal politics that happened in those heady times, there was no way that the introduction of money into the development process would have produced a good end result.

Would it be nice to make a little extra cash?  Sure.  And I take it as a significant compliment for what we've built, that people would be willing to pay for it.  The idea of an SC4 non-profit is also intriguing.  But even with a smaller team in a smaller community, I would still have some pause about some form of the same issues happening. 

-Alex

Offline mattb325

  • BSC Team
  • Forums Parliamentarian
  • *
  • Posts: 1616
  • Total likes: 5271
  • Reputation: 25
  • CL:
    SC4D Housing Authority
Re: NAM: Development
« Reply #1625 on: October 27, 2018, 06:19:56 PM »
Thanks for the info....it would always tricky to balance the perceived needs of newbies vs. seasoned players.

I know when I've had requests for BATs where the person has offered to pay (it happens a lot more than one might think) I have always directed them to make a donation here at this site if I end up batting it....taking money for bats feels like I should be wearing prophylactics  ::)

Offline Wiimeiser

  • Forums Senator
  • *
  • Posts: 624
  • Total likes: 90
  • Reputation: 0
  • Pink horse, pink horse
Re: NAM: Development
« Reply #1626 on: March 05, 2019, 04:09:56 AM »
(Continued from this post)

I really wish there was some way the community could help speed things up... All I can really do is give ideas and bug reports... I have a lot of spare time, but I lack the required skills and attention span to be of any real help myself...

If other active community members could share their thoughts, maybe we could get an idea of what needs to be done...
Pink horse, pink horse, she rides across the nation...

Online Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11359
  • Total likes: 4261
  • Reputation: 71
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: NAM: Development
« Reply #1627 on: March 31, 2019, 10:32:10 PM »
It's still March 31st here in Oregon, so I can assure you this is very much real (and just went out for internal testing).



This is likely one of the last times you'll see this installer/configuration.  We've been having a rather productive discussion internally about the plans for the installer/packaging/file architecture over the past couple weeks, and will be sharing some proposals and soliciting feedback on those fairly soon.

-Alex

Offline Jack_wilds

Re: NAM: Development
« Reply #1628 on: April 01, 2019, 04:16:28 PM »
is it okay to get excited?...  :thumbsup:

here is hoping for Easter release...  &apls

Offline Wiimeiser

  • Forums Senator
  • *
  • Posts: 624
  • Total likes: 90
  • Reputation: 0
  • Pink horse, pink horse
Re: NAM: Development
« Reply #1629 on: April 01, 2019, 09:15:31 PM »
Hopefully we'll get a release soon, 2018 was the year of no releases for me (Terraria, Starbound, other things...)
Pink horse, pink horse, she rides across the nation...

Offline owlsinger

Re: NAM: Development
« Reply #1630 on: April 03, 2019, 05:33:34 PM »
Here's hoping you have kept the DRIs for the MHO  ;D
'Luminous beings are we..'  - Yoda

'Hints of Gold'
by Jasmine Becket-Griffith

Online Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11359
  • Total likes: 4261
  • Reputation: 71
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: NAM: Development
« Reply #1631 on: April 03, 2019, 06:04:46 PM »
Thanks for all the support, everyone! 

Usually, Alpha 01 is a sign (barring anything crazy happening) that we're getting close, though not to the "i-word" stage.  It's generally the first time we've assembled everything together (and owlsinger, you'll be pleased to know that the MHO DRIs made the cut), so it's rather rough around the edges.  We've already started fixing up some of the messiness with Alpha 01, and I suspect we'll be onto Alpha 02 before too long.

NAM 36 was released after Alpha 04, for reference.  That's about average these days.  The record number of alpha builds before release, IIRC, was with RHW 2.0 (concurrent with NAM 22), which took something like 13 or 14 (I think I actually still have them somewhere on an old laptop).

-Alex

Offline Wiimeiser

  • Forums Senator
  • *
  • Posts: 624
  • Total likes: 90
  • Reputation: 0
  • Pink horse, pink horse
Re: NAM: Development
« Reply #1632 on: May 15, 2019, 06:02:31 AM »
To those who haven't been keeping up on Simtropolis, there's a new installer in the works.

And I'm a bit concerned at the lack of talk lately...
Pink horse, pink horse, she rides across the nation...

Offline mgb204

Re: NAM: Development
« Reply #1633 on: May 15, 2019, 06:22:34 AM »
And I'm a bit concerned at the lack of talk lately...

Define lately? Sure, it's been a few weeks and generally speaking, I can state publicly how the original plans for NAM 37 had a bit of a spanner thrown into the works. In short, problems with the old installer have prompted us to reconsider using it one more time and driven development of a new installer for the next release. However, that does mean getting to grips with a new system and re-making the whole before we can get a release out of the door. This will require much internal testing, perhaps even with a public pre-release to get on top of any potential issues there. Combined with real life hitting us developers much harder than anticipated, it means things are taking longer than we had hoped. But it's only been a few weeks since the last public announcement and we would kindly ask everyone to be patient.

There is no need for anyone to be concerned about NAM development, it's still very much alive. As usual we won't be drawn on specific time-scales regarding releases. It'll be ready when it's ready as always.

Offline LucarioBoricua

Re: NAM: Development
« Reply #1634 on: May 22, 2019, 09:49:39 PM »
Here we go...  :)



I was thinking to myself the other day how there would pretty much never be a W 12-2 sign, let alone a "Low Clearance" plaque, in SC4 since even 7.5 m translates to roughly 24' 7" in imperial units.  That number would look absurd on a W 12-2 sign.  From a BATters point of view, however, it might just seem low because of the game's perspective — an effect akin to the BAT squash which implores BATters to upscale BATs to 133% of source height.  It's just the game's isometric perspective.  Adjusted for "inflation," you really have 5.6 m or 18' 6" in RL terms, even though the overpass will be 7.5 m in-game.  This number is much more reasonable in my mind for highway overpasses IMO.

It begs to question.  If these signs were in fact made, should they use the game's nominal measurements or the adjusted ones?  ;D


Let's do some quick math with both measurements. For reference, I'll be using AASHTO's 6th edition Interstate Highway Standards and pre-stressed concrete beam sections.


Based on the original measurements with no scaling:

* 7.5 meters translates to the 24' 7" clearance, if we somehow assume that the bridge superstructure (deck, beams and railings) is as thick as a paper.

* A real bridge superstructure, we're looking at 8" / 0.2m of bridge deck thickness

* AASHTO's nine pre-stressed concrete beam designs come in all sorts of section heights, the smallest being AASHTO I with a section height of 28" / 0.7m, the largest being AASHTO VI and AASHTO Bulb Tee 72, which have a section height of 72" / 1.8m. Taller sections can span larger gaps below.

* This means that the minimum bridge thickness will range from 36" (3 ft, 0.9m) to 80" (6' 4", 2.0m). Which leaves a gap ranging from 5.5m (thickest bridge) to 6.6m (thinnest bridge). The smallest of these gaps translates to 18 feet, the larger of the gaps translates to 21' 8". AASHTO requires interstate highway bridges to have a minimum clearance of 14 feet in urban areas and 16 feet in rural areas. 18 feet is actually a common typical clearance in many jurisdictions, which means that the 7.5m bridge is fully compliant for AASHTO if we assume SimCity 4's vertical scale to be the same as in real life, and thus wouldn't require warning signs.


If we adjust for the exaggeration of the vertical scale by 33%, equivalent to reducing the game scale by 25% to get real life value equivalents:

* The equivalent bridge height would be 5.625 m, the same as 18' 5".

* Using the thickest and thinnest bridge superstructures would result in gaps of 3.625m / 11' 10" (thickest bridge) to 4.725m / 15' 6" (thinnest bridge). This means that only a very thin bridge superstructure would be compliant with the Interstate Highway Standards, and only for urban areas.

* If I were to suggest a gap to use as a reference for the clearance sign, I'd go with the AASHTO IV section (one of the most common ones), which is 54" (1.37m, round up to 1.4m). This results in a bridge superstructure height of 1.6 m and a downscaled gap of 4.225m / 13' 10". This would just barely miss the Interstate Highway Standard for urban areas and could be simplified to a 14' 0" clearance sign.

Offline Jack_wilds

Re: NAM: Development
« Reply #1635 on: October 13, 2019, 07:13:58 PM »
just wondering about the NAM status, and release... if it can ever be released sooner than later... is the new installer gonna work for this update... hoping things can happen soon...   :popcorn:

Online Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11359
  • Total likes: 4261
  • Reputation: 71
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: NAM: Development
« Reply #1636 on: October 13, 2019, 10:07:41 PM »
Just to give a heads up on status, we've been testing Alpha Build 03a of NAM 37 for the past 5 weeks--mostly because I'm still having to wrestle with tedious, annoying file architecture issues that need to be solved for Alpha Build 04, on top of more normal sorts of things that need to be addressed.

The file architecture issues, as you might guess, are the result of Maxis Rail vs. RRW and Maxis Highway vs. MHO crosslink issues.  I'm literally having to rip almost anything Rail or Maxis Highway-related out of non-Rail and non-Maxis Highway plugins, and put them into separate files, to try to contain everything.  We're going all in on RRW (Maxis Rail functionality is being spun off into a separate download "legacy" plugin), but because the polls showed an almost even 50-50 split in our userbase between stock MHW and MHO, both of those options will remain as part of the main download.

Additionally, because of the new installer setup (yes, we are indeed going to the new installer), we can't do Controller Compiler routines, Station Updating (SLURP) or automatic 4GB patching anymore--the latter being the most problematic, since we're having to install a full-blast Controller (essentially requiring the user have 4GB+ of RAM, and the patch). 

It was the price we had to pay for creating what (once settled) will be a much quicker release engineering process for future NAM releases, with cross-compatibility for non-Windows OSes (critical, since Aspyr is indeed going to update the Mac port to 64-bit).  The option to run the Controller Compiler after initial install will still exist, and the tool itself will remain in the NAM package, however, and we're looking at a stripped down version of the existing installer to handle SLURP.

Since it has been a record-long development cycle (we're now at 2 years and 1 month--eclipsing NAM 33's 1 year and 10 months), we are still planning on offering a public "release candidate" of NAM 37 before the "official" release (similar to the old "pre-releases" we used to do).  There is, of course, no date or timeline we can announce for either, because we honestly don't know. 

Trust me, I'd love to have this interminable release cycle off my back (I haven't been able to make new content for several months), as would everyone else, but we're trying to do it right--at least to the greatest extent possible.

-Alex

Offline owlsinger

Re: NAM: Development
« Reply #1637 on: October 14, 2019, 03:25:47 AM »
I appreciate all the hard work the team is putting into this, it certainly sounds like a monumental (and somewhat thankless) task to do this new installer. I'd rather wait than get an early release that's buggy.

Deep breath......'Patience, Grasshopper'   ;D
'Luminous beings are we..'  - Yoda

'Hints of Gold'
by Jasmine Becket-Griffith

Offline matias93

Re: NAM: Development
« Reply #1638 on: October 14, 2019, 10:59:36 AM »
At first it doesn't sound like that, but this is great news, you are getting an arrangement that works!  &apls

About the MHW vs. MHO thing, what about doing separate installers for both options? Would that ease the crosslinking 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

Offline cogeo

  • NAM Team
  • Forums Parliamentarian
  • *
  • Posts: 1163
  • Total likes: 33
  • Reputation: 18
  • CL:
    SC4 Station Master
Re: NAM: Development
« Reply #1639 on: October 15, 2019, 11:44:09 AM »
Hi NAM Team,

I have checked the T21 exemplars for SC4 roads and streets, trying to find out why the streetlight props are mostly not shown after some development takes place. If you try plopping a 1-tile road or street on top of an existing one, the streetlights around may disappear or reappear and the props on the sidewalks (trashcans, mailboxes, flowers etc) may be changed as well. My conclusion is that the reason is the 0xA0000060 prop-family, which includes streetlights of all three wealth-levels, and the prop is selected by "requester satisfaction" (bit 0 in the 2nd LotConfig set), which in this case is wealth. It is "OK" as an approach, but it doesn't always work well, with the effect being that no streetlight may appear.

Analyzed the T21 exemplars and found that it's quite easy, and not actually much work to fix this, resulting in consistent streetlight props. More specifically, T21s with the 0xA0000060 prop-family needs to be split to 3 wealth-level-specific ones, each displaying the streetlight prop directly (the $$$ streetlights are a prop-family as well - 0xA0000075 - but if the requester satisfaction bit is cleared, the game will always display a member of the family). The R- and C-specific T21s are organized this way already, and the I ones use the $$ streetlight only, so no changes are needed here. Changes are needed for the exemplars with the extra sidewalk props (15 in total), which do use the 0xA0000060 family. Also, the two "AllStreet" (AllStreetEven and AllStreetOdd) T21s must be disabled, as the rest ones cover all cases. Maybe these were a last-minute and not-well-studied addition, supposed to fix problems, but actually cause even more. Made a quick test-fix (disabled the "AllStreet" and "Prop" T21s), and this worked splendidly for R and C streets.

So I think it would be nice to include this fix in the upcoming NAM release. I have already found, separated and reordered these exemplars. What is still needed to be done is split the "Prop" exemplars to 3, or sometimes 2, wealth-level-specific ones). The civic ones need to be fixed as well, either split to 3 or just use the $$ streetlight. So, the "mod" I'm suggesting will contain only the (disabled) "AllStreet" exemplars, and the split civic and "Prop" ones. Maybe some few additional fixes, to make the pattern more consistent, but these are really few.

Therefore I'm requesting a range of unused IDs (it can very well be a "hole" in an existing network range). Some 100-120 IDs would suffice, with a two-hex-digit range (256) being comfortable.



Another streetlights pack, made T21s for the tram-in-road puzzle-pieces, using the technique I described above. And these ones are quite more complicated, due to rotations, as the alternating pattern must be preserved, thus requiring a large number of exemplars. But it works wery well, with the streetlights always being displayed, and changed if the wealth of the adjacent lot changes. The pack contains T21s for most, but not all puzzle-pieces, eg didn't make the TramxRoad-under highway one and the likes. I believe it should be covering more than 90% of the cases, omitting only the weirdest and rarest ones; if some certain interchanges are deemed important, I could make them as well. So I think it would be OK for testing and addition into NAM.

Actually, I had made it many years ago, but it was never put into NAM, partly due to lack of time and partly due to a problem (pattern flip of East-West roads) of NAM itself. My pack was made to the original/standard streetlight pattern of roads and streets. But at some NAM version the pattern for E-W roads (but not N-S ones, or streets) was flipped, and it looks weird. I had reported the problem (and what needed to be checked/fixed) by the time (here is the post), but apparently no fixing action has been taken yet.



Another problem I'm facing with streetlights is with two NAM props. More specifically, streetlight props 0x9F9BBC47 and 0xB48B3B43 are included in the 0xA0000060 and 0xA0000063 families respectively. Didn't check details, but they use the original 69AD model ($$). Btw the 0x69AD0000 prop exemplar is correctly included in the NAM props, as a fix was required (wrong mirror model). These props interfere with my streetlight color pack (getting both in roads and streets). I would like to ask why these were included at all (on which networks), and also why they were included into the families. If some T21s use them directly, this was not needed, and additionally, the families already contain such streetlights, so this wouldn't be needed even if some T21s use them through the families. The 2nd one doesn't even have the Wealth property defined. Please consider removing them from the families.



Finally two questions:
- Is the old "ANT" network still available in draggable form? Don't want to make something with NAM, just want to make a custom slope mod for it (to prepare the roadbed for other networks).
- Is it possible to make tunnels for El/GLR and street networks? SC4 doesn't have "Tunnel Entrance" models for these networks, but I could easily make them. However the problem isn't this, while it is possible to modify the "Tunnel" properties and drag the tunnels (albeit missing the entrance prop), they are not functional. Even tried adding SC4Path files, but this didn't help. Don't know if adding/modifying some RULs could make this work. I know, RULs are needed for bridges, for example.

« Last Edit: October 15, 2019, 04:22:24 PM by cogeo »