• Welcome to SC4 Devotion Forum Archives.

NAM: Development

Started by memo, April 29, 2007, 06:33:33 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

druidlove

Here's an interesting reference that would answer the railroad height clearance:
http://www.michigan.gov/documents/rcbook_55515_7.pdf

According to the State of Michigan, the height would be 22' 6" from the top of the rail to the top for available clearance space. While this is one state's representation, this is a standard that can be used to compare to the game. The 22' 6" clearance space given could hypothetically fit in the 24' 7" number (7.5m). Realistically, this must include factors such as height of rail from base to rail top, and overhead width concerns. However, I don't see how the L1 rail/L2 RHW could not be possible.

b22rian

#1601
Nam Discord Chat Announcement :  "$Deal"$

Recently we have decided , to open up the former NAM discord chat room to non NAM members  ;D
We will be keeping # NAM as a private room for NAM discussions only still...
However you are welcome to attend any of our other 3 channels which include the main channel-

# General,  -which mostly focuses on NAM content / transit /traffic/ other sc4 chatter , but also has a general topic theme to it also..

# Pictures - focuses on either presenting pics for demonstration of NAM content and transit  (issues + bugs)
                         - but also has pics of peoples recent work in there CJ's and cities..

# Help Desk - an area to post issues and bugs, ( not only with the NAM Mod but in any aspect of the sc-4 - the game) in order to take advantage of "live help" for these.. in the chat room..

# How to NAM- A newly created channel , and will feature NAM and transit related tutorials

Our membership currently stands at 31 members. But we are (hoping for), and would like to welcome all Devotion community supporters..

Here is the Discord Invite Link - https://discordapp.com/invite/NsNZHEC

Looking forward to seeing new members soon !  :thumbsup:

Thanks, Brian

Wiimeiser

So, there's been no real activity on the NAM front lately. Does that mean NAM 37 is close? Or is it just RL issues?
Pink horse, pink horse, she rides across the nation...

Seaman

#1603
Quote from: Wiimeiser on October 16, 2018, 10:03:22 PM
So, there's been no real activity on the NAM front lately. Does that mean NAM 37 is close? Or is it just RL issues?

Based on similar questions in the past, I assume Tarkus will say that NAM 37 release is "imminent"  :D

(jokes away, I believe most dev work for NAM37 is done and they are in testing and installer building now)

mgb204

As of this moment, there is no build for NAM 37 internally, but discussions are underway regarding a new version. The three main developers (Tarkus, Eggman and myself), have all had really hectic RL the past year, but behind the scenes have been continually working on new content. As for when that can be finalised and collated into a release, honestly throw a dart at a calendar, we couldn't give you a better answer at this point. *cough*, I mean a new release is imminent  :P

eggman121

To echo mgb204's Comments, The NAM 37 Dev cycle has been strained by the RL of the main developers this year.

There is only a few of us working on content and the installer is one of our bottlenecks.

Regarding content, there will probably be a whittle down of the content to just add on some new functionality to existing projects.

It is no easy feat pulling a large package together.

At the moment I am focusing on the NWM MRCs



As you can see I am adding wealth textures to the set.

So realistically speaking from my side RRW Flexpiece and NWM MRCs will probably be my content for NAM 37.

-eggman121

Wiimeiser

Still no REW for NAM 37, then? That's a shame...

If only I could help some way... All I can do is offer ideas...
Pink horse, pink horse, she rides across the nation...

j-dub

Of course the side that has all the traffic is only one lane, while the opposing lanes sit open unscathed.

Tarkus

The types of projects in the works have also complicated things with NAM 37.  I'd say at this point, we're mostly looking to clear out a few smaller projects with this release, in order to give the community some new content to enjoy, while we work out the roadmap going forward.  There is at least one long-awaited surprise coming from yours truly that is currently almost a given for NAM 37, however.

As my NAM colleagues have mentioned, RL's been a complication, and some of the larger projects that have been in the works--namely, the REW and P57-Mark IV--in addition to being quite extensive, pose some significant packaging and file architecture issues.  The installer has gradually been getting more and more broken each release, in part due to all the complications from the likes of "Maxis Rail vs. RRW", "(default) Maxis Highway vs. MHO", the cross-linkage between such options, as well as the numerous cosmetic options on top of that.  The potential for "Maxis OWR vs. REW" adds yet another similar complication to the mix. 

P57-Mark IV is a HUGE improvement in RHW stability over the current Mark III code, though it has steep technical requirements.  There's been discussing of whether or not it even makes sense to include it in the NAM proper because of that, though given how much of an improvement it is, I don't think any of us want to continue fielding Mark III-related bug reports and issuing patches for essentially dead code, either.

-Alex

paddy0174

Is there somewhere a list or kind of a thread, where one (like me) could take a look, what would be to do, or where one can get involved to help? What I'm looking for is a list of tasks that could be outsourced to others, to take a little of the work load from you three...

Just like with a lot of open source projects of all kind, where a github repository exists and others can get involved for just one thing, or as they like for more.

I have no idea, if this has been discussed, or is even possible or wanted (copyright and the will to give out code), but a lot of projects benefit from this kind of sharing and placing it in the community.

Is there something like that anywhere? :) I would really love to help in some way, but tbh I have no idea, what is even needed.
Back to the game after nine years - and everyday I find something totally new! :)

mattb325

Is it worth exploring the option of drawing a line in the sand with backwards compatibility with each release and possibly splitting the two systems between the stuff you are making and the old Maxis stuff?
Those of you left developing obviously have a much keener interest in the items you are making RRW/REW/RHW and so on without the drag of trying to make something that can install all of the old Maxis stuff which really won't have any future changes.
Purely from a process point of view you could just leave one version of the NAM (say, V36 or V37) for the folks who simply "have to have" the clunky old Maxis rail, highway (etc) and and leave the future updates for the stuff that you enjoy making which may just ease the burden of installer work. It becomes an either/or selection for the user rather than you trying to be all things for everyone (which is impossible). If they insist on Maxis stuff, then they can't have the new stuff and vice/versa. Ultimately your dev time is more important and more valuable to the community than the loud protests from some (very small, but noisy) parts of the community

Anyway, that's just my thoughts that I'm putting out there...I don't need a response  :D

Regardless, the new NAM-37 looks to be a real treat  :thumbsup:  :bnn:

Andreas

#1611
Quote from: paddy0174 on October 18, 2018, 01:39:48 PM
Is there something like that anywhere? :) I would really love to help in some way, but tbh I have no idea, what is even needed.
The NAM Team is always looking for volunteers, but that means you must be skilled in transit modding, or having the will to learn these things. There are various tutorials and guidelines, but it's certainly not something for the faint-hearted, as it involves a steep learning curve, and most likely, it will take you months to get a good grasp of what is needed to be done.

Many "easy" things are outsourced to excellent tools like texture batch processors and such already, and since the number of active developers is very small these days, you're pretty much on your own when it comes to learning. Naturally, there's always a place where you can ask things, but don't expect anybody to take your hand and teach you the basics. ;)

Some items that are stalling the current development have been named already, such as building a better installer that is easier to use, and "crosslinking" all the various NAM items. This means making one item working together with another, such as, say, a FAR oneway road intersecting with a diagonal railway line. There are so many possible intersections in various angles and rotations, and for each of them, special code is needed.

Personally, I got lost a long time ago, and since programming was never my cup of tea, my active time in the NAM Team was over once it got the advanced installer that we have now. Maintaining the readme and publishing a German NAM was mainly a chore, so if you don't have any modding skills, maybe that would be a job for you? I'd certainly introduce you to this task, such as updating the German language file, and translating all the new and updated readme stuff, but beware, it's long and boring work alright. :-\
Andreas

mgb204

Quote from: paddy0174 on October 18, 2018, 01:39:48 PM
...Is there something like that anywhere? :) I would really love to help in some way, but tbh I have no idea, what is even needed.

Yes and no really, whilst we do have a GitHub account for NAM development, its not really necessary from the perspective of those outside the NAM team. We use it internally to fork and recombine code, but it doesn't handle everything.

The process for making NAM content is based on some key tasks, each of which requires different skills, but the reality is that a combination of them are necessary to make anything functional. RUL coding (RUL0, RUL1, RUL2 and INRUL), Pathing, Texture making, Transit Modelling (S3Ds) and Exemplars are the key components of making things work. When you install the NAM, all the RUL code is output into the following location; \Documents\SimCity 4\NAM Auxiliary Files\Tools\Controller Compiler\Network Addon Mod\Controller. All the RUL code is in separated .txt files, there is nothing to stop anyone from contributing, by creating their code in a new .txt file and passing it to the team. However, depending on what you are creating, you will need other components for it to work. There is no repository of these, outside of the DAT files contained with the NAM itself. That said, those same files contain a lot of parts, which will typically be invaluable as part of any development work. But you need to find and extract them for modifying somehow, it's something all the main developers found their way to doing at some point. There is rarely, if ever, a list of things to do, because that's not really how we work.

For example, right now I'm going through the process of adding further RHW support for both the cosmetic El-Rail and BTM (Monorail) mods by Moonlight. So I start by digging into the RHW files, taking template S3D models (The El-Rail / Monorail x RHW ones). I then remove the original El-Rail/Monorail parts of those models manually using Reader. Next I combine them in Model Tweaker with similar templates containing the updated El-Rail/BTM models. It's not as simple as it sounds, because once more I've had to find and in many cases adapt those template models. Lastly, since it's an override, there are no new textures, paths or RUL code needed, but I do have a lot of T21s to make for the sake of completeness. So again, I have to find and adapt other T21s, in order to fit these modified pieces. Of course, it's always an option to make new things from scratch, but usually it's just easier to take what exists and adapt it to your needs, where possible of course.

All in, it's quite the involved process, but whilst obviously it was an outstanding task, ultimately I've made these pieces, because that's what I wanted to contribute at this time. All of us work this way, we find something we want to improve, add or support, then work on making it happen. At a team level, we come together when we've sufficient contributions to make a release and by and large Tarkus handles the process of the installer/release from there. We don't have a list of tasks or assign them, because this is not our job, but our hobby and if we are to all stay motivated, it helps to be free to work on those things we're interested in. We don't take applications for new team members, but anyone who proves themselves to be a capable transit modder, will surely catch our attention in the process. But if you want to get involved, the best first step is to decide on what it is you want to achieve and start working on it. It's a great idea to start a thread somewhere to both show your progress and ask for help where necessary. We always have time to help those who committed to learning and creating content.

Quote from: mattb325 on October 18, 2018, 01:58:47 PM
Is it worth exploring the option of drawing a line in the sand with backwards compatibility with each release and possibly splitting the two systems between the stuff you are making and the old Maxis stuff?

It's an interesting idea, although personally I'm ideologically opposed to it. The problem there is that as a modular mod, doing this restricts the ability to pick and choose between those things a user might want or not. That said, RRW development has taken this tract, if you don't use RRW, you're left with Rail as it was when RAM was last updated. Cross linking can be an uphill battle installer wise, but that's really the main issue at play here.

Quote from: mattb325 on October 18, 2018, 01:58:47 PM
Ultimately your dev time is more important and more valuable to the community than the loud protests from some (very small, but noisy) parts of the community

It's one way of looking at things, but I don't think protests are really the problem here, neither are those members such a minority either IMHO. Plenty of players simply don't want or like the style of certain aspects of the NAM, RRW once more being a key example. So whilst those users won't get new rail content, should they also be forced to never get RHW updates, purely because they didn't want RRW?, especially when little of those updates are likely to pertain to RRW in any way? This is really my concern, that we might leave many people out of the loop by forcing such a change in philosophy. With an ever-dwindling community, splitting the NAM this way seems like it might have unintended consequences. It's rare to get complaints about these things, once again at the core of the issue, is simply making it work from an installer perspective. The developer who made that is no longer around and as someone who's dabbling in NSIS coding myself, I can tell you it's really a complex mess beyond a certain point. Sans the resources to test every change, unexpected errors creep in as a result of changing something which wouldn't obviously affect other parts. It's not a simple issue that's going away, because there is no good solution for moving the installer code to another platform or rewritting it. In fact both these options are almost unthinkable from a sheer workload perspective. Even without the cross-linking, those problems are inherent to the installer as you continually update it. I think I'd sum it up by saying, it's gotten so big and complex, that it's becoming very difficult to properly test. An issue exacerbated by the small dev team and limited time to devote to testing it. There is no quick fix to that, but certainly it's something we're all aware needs addressing before it gets out of hand.

mattb325

^^ All valid points of course, but having led and managed many organisations through difficult changes over the years, as a small team I would simply look at what is most important to yourselves and play to your core strengths - is it the installer that's more important or the files therein? Or perhaps both have equal importance? It's something that only the three of you can determine.

Sometimes, we get attached to a process that made perfect sense once, but may no longer makes as much sense today or tomorrow. Maintaining that process just because it is a 'nice to have' for users who might miss out on a whole new version because they don't want or use one part of an upgrade, can act as an ever tightening noose around your neck.
When push comes to shove, as in when the developer numbers dwindle; it the users who should adapt, not the other way around. Because the inevitable (ie the possibility of no more NAM releases) will also force users to adapt. It is that simple.
But again, that should be a discussion for yourselves: however as an outsider who is familiar with maintaining the status quo of teams' processes within the SC4 community (BSC were also obliged to use simplistic installers, and believe me, there was little unanimous consensus at the time despite the united front) it is worth having the discussion amongst yourselves, particularly, if as you have all mentioned, it is the complex installer that is as much of the bottleneck as the development itself. Certainly as an outsider, the first thing that springs to my mind when I think about the NAM team is the amazing and varied content....the installer, is way, way down the list of things that first come to mind.

Again, just my thoughts.....

Wiimeiser

All I can do is offer suggestions. For example, I still think cutting the FlexSPUI in half would make it more modular.
Pink horse, pink horse, she rides across the nation...

Tarkus

Quote from: mattb325 on October 18, 2018, 03:39:03 PM
^^ All valid points of course, but having led and managed many organisations through difficult changes over the years, as a small team I would simply look at what is most important to yourselves and play to your core strengths - is it the installer that's more important or the files therein? Or perhaps both have equal importance? It's something that only the three of you can determine.

. . .

Certainly as an outsider, the first thing that springs to my mind when I think about the NAM team is the amazing and varied content....the installer, is way, way down the list of things that first come to mind.

First off, Matt, thanks for the encouraging and thought-provoking comments! :thumbsup:

The content in the mod is indeed the foremost aspect of the mod for me as well.  That's the real passion part of being a NAM developer--expanding the array of transportation options available, for both ourselves and our fellow SC4 enthusiasts.  The whole underlying philosophy behind the NAM and the NAM Team is that we're essentially the Department of Transportation for the SC4 custom content world, a key portion of which entails managing RUL-bound transportation content for the benefit of the community, ensuring maximum intercompatibility between items.

If you're thinking about the content, and not the installer, that's a good sign.  Our intent with having the installer is to do the heavy lifting for the end user, such that they (hopefully) don't really have to think about the whole process of installing the mod, or having to get dirty with the file architecture.  When the installer fails to work its magic properly, however, that's when the problems arise, which is the case right now. 

The alternative--a manual installation--is fiendishly complex with the mod in its present configuration, and it would pretty much require that the end user be a NAM developer with intimate knowledge of each component, and how they're all supposed to fit together.  There's also the fact that a full installation requires the game's executable be switched to Large Access Aware via a "4GB Patch" (which the installer handles) in order to avoid CTDs (something we found out the hard way with NAM 31), and the issues of the mod being installed on versions of the game that do not actually support it (versions lower than 1.1.638, including the infamous Origin retail edition), which the installer's version check prevents.

Our "Mac version" up through NAM 30--the last before we went "Monolithic"--was, in fact, just a loose .zip, and the users on that platform were expected to perform a manual install.  At that point, we also had most of the other larger components--the RHW, SAM, RAM, etc.--as separate downloads, and also packaged those as loose .zips for manual installation for the Mac users.  A decent percentage of the Mac userbase had technical issues with this process, and that was when "The NAM" proper was a mere fraction of what it is now, with everything rolled into a complete, all-in-one package.

While NAM 30 does seem to still have its supporters :troutslap:, the general sense I've gotten talking to various segments of the community over the years (including those not particularly active in the SC4D/ST forum side) is that the "Monolithic" concept is quite appreciated, especially in the context of some of the broader distribution/packaging discussions from the past couple years.  I don't believe the "Monolithic" packaging is the problem, but rather, what we're looking at is really an execution issue.

Regarding the "legacy components"--i.e. the Maxis Rail stuff--some of it could be mitigated with some improvements to the file architecture.  I don't think completely dropping the support would be a tenable solution, but one possibility I have considered is that of offloading it to a separate-download "as-is"/"no support" legacy file.  We also have a number of other cosmetic options that with our current staffing, we are no longer able to consistently support, either.  Those could potentially given the same treatment.

I'm definitely curious to hear more feedback on this side of things.

Quote from: Wiimeiser on October 21, 2018, 01:33:16 AM
For example, I still think cutting the FlexSPUI in half would make it more modular.

FlexSPUI is already a half-SPUI.  If you talking about (drawing and) quartering it, that might be something down the line, though it does complicate things considerably to have asymmetrical setups with only onramps or only offramps (especially once one gets into LHD support).  The priority right now is getting the broken NAM 30-era version retired at long last.

If I can figure out what is up with the QuickChange Xpress issues (they're not going into NAM 37, barring a miracle), there will be SPUI QCXs, too.

-Alex

jeffryfisher

Quote from: Tarkus on October 23, 2018, 08:06:31 AM
Regarding the "legacy components"--i.e. the Maxis Rail stuff--some of it could be mitigated with some improvements to the file architecture.  I don't think completely dropping the support would be a tenable solution, but one possibility I have considered is that of offloading it to a separate-download "as-is"/"no support" legacy file.  We also have a number of other cosmetic options that with our current staffing, we are no longer able to consistently support, either.  Those could potentially given the same treatment.

I'm definitely curious to hear more feedback on this side of things.
-Alex
I've been puttering around in the same rather large region since 2013. My early work was mostly wiring all the city-sectors together using rail and highway -- all Maxis highway -- and avenues with plopped interchanges. There are now dozens of densely populated towns / cities built up around some of those Maxis highways and their compact interchanges. I have continued to use such because I have never gotten the hang of RHW's free-form interchange construction (the difference between plopping a ready-made interchange versus spending all day fighting ramps is monumental, at least to me).

Ripping out my Maxis highways from 300+ sectors and laying RHW highways and interchanges in their place, including dozens embedded within existing towns would be a nightmare that might take months, so obsolescing Maxis highways would be a drop-dead show-stopper preventing me from upgrading the NAM, probably forever.
[Note: I am looking forward to ploppable interchanges. I hope to add some RHW to my region for the first time when those interchanges appear.]
Modding PC games since 1993 (back when we needed hex-editors)

eggman121

QuoteRipping out my Maxis highways from 300+ sectors and laying RHW highways and interchanges in their place, including dozens embedded within existing towns would be a nightmare that might take months, so obsolescing Maxis highways would be a drop-dead show-stopper preventing me from upgrading the NAM, probably forever.
[Note: I am looking forward to ploppable interchanges. I hope to add some RHW to my region for the first time when those interchanges appear.]

I don't think making the Maxis Highway obsolete will happen for the aforementioned outline but we have to come up with a solution for both end user and developer.

Holding onto projects that will not be worked on can be a challenge of the developer end and since the NAM has gone in so many directions it may well be the case that we need to tidy up some things in the way things are packaged.

Now ploppable large interchanges won't happen for complex setups due to the sheer amount of work involved but we are open to the idea of making subset parts either through new models or existing model for the RHW. Lucky the Maxis Highway is a standalone network and I have contemplated using  "Flex cores" linked with the RHW ramp system to make pseudo Pre Made interchanges that to a large extent can be made to specification. They would need to use the Maxis Highway override however.

I think this is a healthy discussion since there is only a small team working on the NAM so our direction has to be focused on projects that are viable.

-eggman121

mattb325

#1618
What I'm suggesting is not to make certain elements completely obsolete; it's just to leave them as is and when new elements are created (that align with the remaining developer's  interests), these old pieces do not receive backwards compatibility prior to releasing the updated NAM. At a certain point all legacy systems are no longer feasible to support. Case in point is Microsoft with XP/Vista etc. They still work, and people & businesses still use the operating systems but they and the systems which depend on these operating systems, become less desirable to use as time goes on.

As I see it, when developer numbers plummet, those remaining have a number of options available and they relate to issues of succession planning and processes if they wish to see the development continue in the public sphere.

1) Business as usual: time will take care of the details. One of you will get married, move to a big city, get a better job, or just get tired of trying to make the updates. No more NAM releases.

2) Up-skill someone else in the team. That's a lot of work, and there's no guarantee that the new trainee will stick around or even be any good.

3) Write a how-to-manual. Also a lot of work and a brave step: you completely divest yourself of everything you've worked hard for over the years.

4) Look at partitioning certain aspects of the build; leaving them as is and concentrating on things that are likely to keep you developing new content

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?

6) Anything else you care to think of....

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.

I could be completely off-piste in that line of thinking: but it hinges on the question of how the installer benefits you three, and you three only. Does it ultimately make your lives easier? Does it reduce support issues after a NAM release (bearing in mind that support issues will have decreased anyway based on fewer community members)? Is having that installer important for transferable skills in the real-world? Etc, etc.

As long as functionality remains the end-users can adapt to the packaging (saying something is no longer supported or expanded upon is completely different from making it cease to function; and I know the NAM team would ever deliberately trash the Maxis rail or Maxis highways just to move users to the new stuff). While I am in awe of the achievement of the NAM installer, I am in more awe of the goodies inside it and I don't mind if I do a half auto installation and a half manual installation if it makes it easier for the team to get new content out  :thumbsup:

It will always boil down to what you guys decide upon. In the end it just has to work for you.

Wiimeiser

Quote from: Tarkus on October 23, 2018, 08:06:31 AM
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...