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.
