Menu

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

Author Topic: NAM: Development  (Read 493169 times)

0 Members and 2 Guests are viewing this topic.

Offline eggman121

  • Moderator
  • Forums Parliamentarian
  • *
  • Posts: 1587
  • Total likes: 2811
  • Reputation: 27
  • CL:
    Mr. Smth
Re: NAM: Development
« Reply #1640 on: October 15, 2019, 05:38:30 PM »
I am working with T21s as well for an undocumented project on a couple of networks. My thoughts are that once we have a public release a T21 mod for the Road network could come to fruition. I have done some experiment with T21 road markings that change based on slopes... (An auto line marking project for rural areas). That could be coupled with some overrides to make a new Linemarking mod.

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.

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.

I will have more to say later.

-eggman121

Offline Tarkus

  • Administrator
  • Forums Legend
  • *
  • Posts: 11360
  • Total likes: 4263
  • Reputation: 71
  • NAM Team Tankadillo
    • NAM HQ
  • CL: Dr. PuzzlePiece
Re: NAM: Development
« Reply #1641 on: October 15, 2019, 07:25:00 PM »
- 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

Offline cogeo

  • NAM Team
  • Forums Parliamentarian
  • *
  • Posts: 1163
  • Total likes: 33
  • Reputation: 18
  • CL:
    SC4 Station Master
Re: NAM: Development
« Reply #1642 on: November 27, 2019, 04:31:56 PM »
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.

Offline mgb204

Re: NAM: Development
« Reply #1643 on: November 28, 2019, 06:27:56 AM »
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?

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

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

Offline cogeo

  • NAM Team
  • Forums Parliamentarian
  • *
  • Posts: 1163
  • Total likes: 33
  • Reputation: 18
  • CL:
    SC4 Station Master
Re: NAM: Development
« Reply #1644 on: November 28, 2019, 07:47:56 AM »

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.

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

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

Quote
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?

Offline mgb204

Re: NAM: Development
« Reply #1645 on: November 28, 2019, 08:00:38 PM »
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#.

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

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