NAM: Development

[Tarkus]

- 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).

The ANT network is the Real Highway and has been like that for a decade or more. If you want some slope making network pieces for right of way construction the best way would be to make some Flex Pieces based on network slope parameters and with the [#4]  Flag, bulldozing one tile would remove the whole segment across a few tiles. That is one of the advantages of using flex Pieces, Once one tile is bulldozed it will remove the whole piece thus making way for cut and fill segments.

Additionally, it should be possible to just install the L0 RHW-2 network, which is what the former ANT Tool officially became back with NAM 22/RHW 2.0 in January 2008.

-Alex

[cogeo]

Alex,

My project about the consistent (and persistent) streetlights for roads, streets, tram-in-road and tram-on-street networks is almost complete. It displays wealth-dependent streetlights while the even/odd pattern as well as the random props are preserved (for tram-in-road and tram-on-street no props other than streetlights are displayed, due to lack of space). Here is a pic:



The modding I have done is as I described in my previous post, ie split the 0xA0000060 prop-family needs to be to 3 wealth-level-specific props, each displaying the streetlight prop directly, with the requester satisfaction bit cleared - this is what causes all the trouble.

I think it would be nice to include this into the upcoming NAM version, or alternatively post it as an add-on later. What I need now is the ID range I asked in my previous post - I will have to re-IID them. Please also check the issues I mentioned (streetlight props 0x9F9BBC47 and 0xB48B3B43 included in the 0xA0000060 and 0xA0000063 families respectively, and the pattern flip of East-West roads only).



Another little addition I would like to make is a GLRxAve T-intersection with a road connection, just like the existing GLRxAve T-intersection/GLRxRoad puzzle piece, only this one will be a road connection instead of GLRxRoad. See the pic below:



The pic of course is photoshopped and the texture is not yet made. I need an ID range for this (in the GLRxAve range of course - I think 2x2 would be OK because as far as I can remember no tile is needed for the road).

I would like to make and release these asap.

[mgb204]

I think it would be nice to include this into the upcoming NAM version, or alternatively post it as an add-on later. What I need now is the ID range I asked in my previous post - I will have to re-IID them.

ID Ranges for Prop Families are not really handled by the NAM Team. I'm sure we have some ranges, but honestly any ID is fine here. If you don't have some Prop Family IDs to use, let me know how many you need and I can pass you some from my personal range.

Pretty much all your observations re: Maxis T21s / Streetlights are spot on. I happened to be digging through this all myself not so long ago and came to the same conclusions. Like you, I also realised new IDs would be needed and the Wealth property simply isn't working as one might expect. Presumably another long-standing bug?

Please also check the issues I mentioned (streetlight props 0x9F9BBC47 and 0xB48B3B43 included in the 0xA0000060 and 0xA0000063 families respectively, and the pattern flip of East-West roads only).

I'm pretty sure a similar issue was affecting the NAM T21s for FA-Roads. Marteen (Mandelsoft) included a fix for that problem as part of the LRM mod, file: zLRMv5_Patch_NAM_FAR_Lights_FamilyBlocker.dat. it's only two replacement Prop Exemplars, but might be worth comparing.

The pic of course is photoshopped and the texture is not yet made. I need an ID range for this (in the GLRxAve range of course - I think 2x2 would be OK because as far as I can remember no tile is needed for the road).

I'd say that's a good idea for an additional piece. As for ID ranges, don't quote me, but in recent times simply requesting IDs doesn't tend to get a response. Better to "find" a spare ID or group thereof to squeeze such pieces into. I'm no expert on Puzzle Pieces, but you could certainly re-use the textures from the original TiA T-piece, so you'd only need one ID for the new texture with the Road connection. I believe you can re-use the S3D's too, but will need new IDs for the Preview, Paths and Transit Exemplar. Many such legacy components were built only using the 0 through 4 (5 for preview) ID groupings. But we can use 5-9 and A-E also, usually that's an easy way to find an ID gap. In this case, I'd use the same IDs as the current T, but with A-E + F (preview). That should be pretty sure not to conflict with anything.

[cogeo]

ID Ranges for Prop Families are not really handled by the NAM Team. I'm sure we have some ranges, but honestly any ID is fine here. If you don't have some Prop Family IDs to use, let me know how many you need and I can pass you some from my personal range.

I do have ID ranges for prop-families and textures (for lots), but here I'm talking about network IDs for street and road T21s. It can be an unused (and unlikely to ever be used) "hole", anywhere in the NAM range. A range like 0x5-----## would suffice (no more than 256 IDs are needed). The tram-in-road and tram-on-street T21a use the same ID-range as their corresponding puzzle pieces, of course.

I also realised new IDs would be needed and the Wealth property simply isn't working as one might expect. Presumably another long-standing bug?

Yup, a Maxis bug (I would rather call it a poor implementation) actually.

Please also check the issues I mentioned (streetlight props 0x9F9BBC47 and 0xB48B3B43 included in the 0xA0000060 and 0xA0000063 families respectively, and the pattern flip of East-West roads only).

I'm pretty sure a similar issue was affecting the NAM T21s for FA-Roads. Marteen (Mandelsoft) included a fix for that problem as part of the LRM mod, file: zLRMv5_Patch_NAM_FAR_Lights_FamilyBlocker.dat. it's only two replacement Prop Exemplars, but might be worth comparing.

Well, it would be easy to just remove the aforementioned props from the prop-families for my personal use (and that's what I'm  doing for now), but the point here is if these props should have been included in the prop-families at all. Which networks are using them, bridges, idk. If they are referenced by prop IID they don't need to be included in the families, whether my streetlights fix is included into NAM or not. The 0xA0000060 and 0xA0000063 prop-families already include same-looking props anyway. It's about NAM, not me.

As for ID ranges, don't quote me, but in recent times simply requesting IDs doesn't tend to get a response. Better to "find" a spare ID or group thereof to squeeze such pieces into.

These are puzzle-pieces, and the IDs conform to certain rules, eg an additional tile in the verical axis requires an additional hex digit too. I could look into the GLRxAve ID-range and try to find some available range in there, but I think it would be best to ask for it, if someone manages these ID ranges. Btw, what's the (whole) ID-range for GLRxAve puzzle-pieces?

[mgb204]

I do have ID ranges for prop-families and textures (for lots), but here I'm talking about network IDs for street and road T21s. It can be an unused (and unlikely to ever be used) "hole", anywhere in the NAM range. A range like 0x5-----## would suffice (no more than 256 IDs are needed). The tram-in-road and tram-on-street T21a use the same ID-range as their corresponding puzzle pieces, of course.

Apologies, I got mixed up, but see your plan is to fix it the other way round. When I found this problem, I copied the three affected Props and gave the Prop Exemplars unique IDs and removed any Prop Families. Of course then you'd need to update every affected T21 to the correct Prop Exemplar. Wouldn't that be simpler than making new T21s?

As for ID Ranges, I don't think you need worry too much with T21s. Just find a gap that's not in use. Sticking with using the ID of the Texture or S3D has always worked for me. Since you can increment the last digit all the way to F. I've yet to come across a situation where so many T21s previously existed, that this didn't leave enough room on the 8th digit alone for my needs. Maxis didn't even use such a system, for example the base Road Straight (0x00004B04) range is unused. For fully wealthed texture sets like this, you have at least 128 IDs spare. Since the 7th Digit covers the 0-7 wealth textures, they can all be used for corresponding T21s. I.e. 0x00004B0# through 0x00004B7#.

Well, it would be easy to just remove the aforementioned props from the prop-families for my personal use (and that's what I'm  doing for now), but the point here is if these props should have been included in the prop-families at all. Which networks are using them, bridges, idk. If they are referenced by prop IID they don't need to be included in the families, whether my streetlights fix is included into NAM or not. The 0xA0000060 and 0xA0000063 prop-families already include same-looking props anyway. It's about NAM, not me.

Understanding that probably requires having been part of their development. Otherwise all the rest of us can do is try to see what's going on and unravel it. Like with the Prop changes above, I would think the safest thing is to make duplicate versions of the Props, with unique IDs. This way anything that relies on the original setup, that we might not be seeing, is unaffected by any changes.

That's pretty much why I mentioned the LRM file, because that's exactly the approach Marteen also went for. Then he just updated the affected T21s to link to the fixed Props.

These are puzzle-pieces, and the IDs conform to certain rules, eg an additional tile in the verical axis requires an additional hex digit too. I could look into the GLRxAve ID-range and try to find some available range in there, but I think it would be best to ask for it, if someone manages these ID ranges. Btw, what's the (whole) ID-range for GLRxAve puzzle-pieces?

That was really my point, I don't think there's master lists or one person managing all this. So the best solution is to be pro-active in finding gaps inside current ranges.

I've no idea where to find any central lists of such ID schemes, I always just track them through. I'd hazard somewhere deep in the development threads, when these were made, ID's schemes were planned out. But these days, the methodologies I'm outlining here are the best ways to find a small number of spare IDs for minor additions. Obviously, making new networks and/or much larger additions, would need the IDs to be scrutinised. But for the odd piece here and there, this system is just more practical.

I've never needed more than a handful, my biggest project to date, SAM11, had IDs already allocated. Even when I started out with implementing SAM support for El-Rail/Monorail/GLR crossings, I found IDs pretty easily. Luckily in that case, two GLR crossings had reserved IDs from planning. I was able to expand these 2 IDs into 6 working ones, by utilising the 5-9 and A-E sets, giving me the 6 per-network I needed.

Based on the textures and a quick peek in the files, the TiA range is:

     0x584*####

*with 0-3 being used for the 4th digit. Given all that, I'm sure there's bound to be some IDs left somewhere in these, since it's a pretty big range.

If I look at the last pieces added, I can see the range 0x5840 was used, with A through F for the 5th digit. These were part of the Draggable TiA to intersect with RHW interchanges.

The standard T, of which this would be a variant uses 5840DE and 5840DF (Preview 0x5840DFF0). Space exists between 5840E1 and 5840EF here, which should be sufficient. Otherwise since only IDs 0-4 for the 8th digit exist, use the same scheme but ending from 5-9 or A-E instead. The game supports such IDs fine, but this information was not widely known. But it basically means we were previously not utilising 2/3rds of the available IDs in a given space. For most legacy content, you can be very confident using such, will not cause conflicts. Note too that RHW, RRW and newer content is typically planned to make better use of the full ID range, since the number of free IDs is always getting tighter.

Again, I think you can re-use both existing textures and possibly 3 out of the 4 S3D files from the normal T-Crossing. Because those parts of your new piece would remain identical. You just need IDs for the single new texture and it's various parts, everything else can link back to the existing pieces. The only potential issue I see is if the paths for the other three pieces needed to be different, then they too would need to be duplicated and given unique IDs.

Having found some seemingly free IDs, it's best to quickly cross-check that with a DAT-Packed NAM. Just to be sure they were not used in an obscure place you aren't expecting to find them.

[Jack_wilds]

hello nam...

hoping for idea of when to look for teh release of name 37... will it be released or has this also fallen by teh wayside of real life...

how much maybe needed to have a finished package... sure hoping progress is being made and sitting in all these lockdowns perhaps projects are getting done... guess looking for progress update and any plans concerning its release...

and then further if this likely teh last update will there be a finishing up of features or some sort of finished projects... just hope this also does not languish like too many projects have...

[Tyberius06]

Jack_wilds:

We are working on it. Unfurtonatelly, the current lockdowns actually don't really have affects on the two main active developers, since their RL jobs fall under the "essentials jobs" more or less (so as mine). It will be ready, when it will be ready, sooner or later, but it's coming.

- Tyberius

[Tarkus]

The big holdup, as always, is the bloody crosslinks, which need to die in a fire already. 

Due to how the new installer works, we no longer have a z___NAM folder.  Everything now needs to be contained within the main Network Addon Mod folder.  As has been already announced, we've pulled some cosmetic/reskin stuff (Alternate El-Rail and Bullet Train), partially to simplify things (and also, we're not really able to support those all that well, anyway). 

The two big things that were in z___NAM that we aren't pulling out of the main mod itself, however, are the RRW (which is becoming the default and only option in the main mod itself--Maxis Rail is getting jettisoned to a separate-download "legacy" plugin) and the Maxis Highway Override AKA Project Symphony, which is still having to co-exist in the core part of the mod with the vanilla Maxis Highways, since each have about a 50% user share.

And that's proven to be a MASSIVE pain, because it means pulling everything Rail or MHW-related from any non-Rail or non-MHW plugin that intersects either network (which is pretty much all of them), and there's just so many cases of it.  It's literally 90% of what we've been fighting for the past several alpha builds. 

-Alex

[Wiimeiser]

Sounds like it'd just be easier to go the override network route (Though doesn't the RRW already kinda do that?)

[Tyberius06]

As far as I know, RRW is not being an override network for a long time now, since most of its recent and currently under development features are way ahead of anything what maxis rail (RAM) could ever offer. And since Maxis rail stuffs won't be developed anymore the RRW has to stands on its own feet in the future. And MHO is somehow in the same shoes. But MHW likely won't get any new stuffs, while MHO still can get new features considering it's fairly close relationship with the RHW.
So this is a very much necessary, although really painfull process.

- Tyberius

[Tarkus]

The term "override network" is also not quite being used correctly here . . . generally, it refers to one of the NAM's "new networks", which uses RUL overrides (RUL2 code) and starter pieces in order to change one of the game's base networks into something else on the fly, while still allowing that base network to co-exist.

MHO really ought to be called "Maxis Highway Replacement" or "Re-Skin" rather than "Maxis Highway Override", because it is replacing the base network (you can't build stock Maxis Highways with it installed).  The same is true for the RRW. 

As Tibi mentioned, the fact that we're effectively having to "purge" the NAM of Maxis Rail is a huge part of this.  And since we're ditching all the other re-skins save for MHO, because of the crosslink complications, and the fact that MHO has its own RULs, we're having to get it to stand on its own two feet, without using legacy content as a crutch.

If we can actually get these bloody things to behave . . . then it's going to make things a TON easier for NAM 38 and beyond.  But it's meant NAM 37 is a huge, huge pain in the butt on our end.

-Alex

[Wiimeiser]

The reason I used "override network" to refer to the RRW is because after installing it any existing rail will need to be clicked to update it.

[Tarkus]

Actually being able to develop new content again, no longer being wracked by "NAM 37 isn't released" guilt . . . #FeelsNice.





-Alex

[Tarkus]

And there's more . . .





I'm methodically working through L1 Road, and going from there.  The OxD situations are largely worked out, and I'm now in the process of getting the DxO setups together.  I've done a few DxDs already as well.

-Alex

[matias93]

Really great and much needed! Just to know: is there some chance to add a centre pylon on those long-span overpasses?

[Wiimeiser]

Personally, I think we shouldn't start anything new for NAM 38. Now that the NAM Team should be back on the development track, now would be a good time for catchup on half-finished projects. This does include the diagonal stability Tarkus is currently showcasing. Just my two cents, though.

[roadgeek]

And there's more . . .





I'm methodically working through L1 Road, and going from there.  The OxD situations are largely worked out, and I'm now in the process of getting the DxO setups together.  I've done a few DxDs already as well.

-Alex

Got some drool to clean up! Looking forward to some of that FAR development too!

[Gugu3]

That's some exciting news Alex!

[dyoungyn]

Finally something over those pesky 3 tiled RHW6C diaganol.  Great job and great heaps and bounds

[Tarkus]

Back in the saddle again . . .



-Alex