Correcting maxis' T21s

[vil]

I have been sidetracked from trying to make pavement for WRC work like normal game road pavement - textures, props and flora.

My T21s were not doing what i expected so i looked a little closer at Maxis orthogonal road T21s. They are broken in quite a few ways.

1. Road light models are bad
The model for streetlight 2B290000 has a bad LOD shape. Its used in prop families and also plays a part in problem 2.
This also means prop family A0000075 is useless, but families generally die of problem 5. anyway.
I have dropped this model from all the T21s, keeping only the three other high wealth lights 2A5A0000, 2A5B0000, 2A5C0000.

2. Road light exemplars are bad
The Resource Key Type 4 and Resource Key Type 4xm lines of the above mentioned high wealth lights (2A5A0000, 2A5B0000, 2A5C0000) contain references to streetlight 2B290000 by mistake or oversight, causing wrong models to appear at certain times of day.
I have corrected the 3 exemplars within the attached file.

3. The 2nd rep of LotConfigPropertyLotObject has strange values
Values of 11 or 21 - does anyone know why? All i could make of this is they sometimes work and sometimes not.
I took the liberty of changing these to 10 and 20, making light placement reliable.

4. One T21 has a wrong kPropertyID_NetworkPlacementPattern value
The exemplar CAADA9B6 is the only one of 74 exemplars that has a kPropertyID_NetworkPlacementPattern of 1,2,4,C.
Using 1,2,4,8 works better IMHO.

5. Prop families containing different wealth level dependant props dont work on T21s
They just dont. For example if you have a road on which a high wealth prop is expected from a variable wealth family, it is equally likely for the game to pick a low or mid wealth prop from the family, and display nothing.
So i got rid of all the affected families, namely A0000039, A000003F, A0000058 and A0000060 (and A0000075 from problem 1.) and replaced them by listing all the appropriate models in the LotConfigPropertyLotObject lines.

And i attach the result for your pleasure and comments. These are corrections for Maxis road T21s so they may conflict with any other road T21s out there.

Orthogonal roads only. Works with Euro.

Hopefully i will get around to diagonals and then, just maybe, the curves. 

edit: outdated attachment removed

[xannepan]

Hi Vil,

Great work. Does this also mean that the lightpoles are now placed on a more regular distance (ie each tile).

Maybe it's worthwhile to look at the USL thread, where there is also a discussion going on about this. (http://sc4devotion.com/forums/index.php?topic=11937.20)

I'm not sure kodlovag eventually solved the problem... Here is part of the discussion. Perhaps you can team up (at the least to make sure we don't end up with conflicting MODs  )

Just few hour before I read this topic first time I started thinking on the displacing streetlights. At that moment I worked on the lights for the road turning lanes, and I was unable to display the lights correctly. They seemed appearing randomly when clicked the tile, some tiles always got the light, others never. I was really confused, because I inherited working avenue turning lane support from Maarten's LRM, and I did everything in the same way, except that I started to build all the T21s from a Maxis road T21. At first I guessed the problem is that I'm using prop families because I'm lazy to make T21s for each wealth level independently. I thinked this because $$ lights are never appeared, others only randomly, worst places were mixed $/$$$ zones. Finally I found the solution in a totally different point. I don't shot it now. But I was really happy.
Then I read this topic. And I started to think more about the displacing streetlights. Because I started to build my T21 from a Maxis T21, I inherited a problem from it. Or a feature? I don't know what would it be good for. But if this bug caused the same displacing streetlights syndrome, and I started from the T21s responsible for streetlights, this might cause the same problem in the vailla game too. I've looked for all the road T21s (what I already collected earlier to make light support for roads), and I realized, that for every zone, density and wealth level roads have at least one T21 with light prop, which should result in exactly one light pole in every second road tile. A very well defined grid. What was screwed up by Maxis programmers.

I'm sure you are now curious to know what caused the problem. In about half of the T21s the prop line what gives the light pole had the LOD value of 0x00000011. What is not a valid value. Valid values are 00, 10 and 20. Or 11 (also 21) is also valid, and means randomly appearing prop at the defined level of detail? But why is that applied on streetlights? So, its a one bit error. Only one bit. Everything is corrected now, see the image in my previous post. The vertical road has streetlight at every second tile. On a $$$ medium density commercial area. These roads have almost no streetlights earlier.

[Lowkee33]

Xannepan beat me to it.  I even saw him over at that thread 

Prop wealth is something I was having a problem with too.  The reason different wealths would be in the same family is for lots who's props change when the building dilapidated.  I never saw no props appear though, so perhaps T21s work differently.  It might be worth getting the $$ T21s to show for a R$$ and then cut their job access to see if the props change. 

[kodlovag]

Hy vil,
I'm working on a uniform street light mod (USL) since November, and wrote and modified about 1500 T21s and 50 light poles for it. So I'm familiar with T21s and streetlights.

1. Road light models are bad
The model for streetlight 2B290000 has a bad LOD shape. Its used in prop families and also plays a part in problem 2.
This also means prop family A0000075 is useless, but families generally die of problem 5. anyway.
I have dropped this model from all the T21s, keeping only the three other high wealth lights 2A5A0000, 2A5B0000, 2A5C0000.

You are right, that road T21s are broken, but your first statement is bad. Streetlight 2B29 has only bad name. It should be 2A59. I think there is no problem with the model at all. 2B29 is the mirrored model for all of the $$$ streetlights. Mirrored models are required for mirrored network pieces. Typically for ortho-diag intersections, when it is not possible to get every shape just by rotating the piece. But streetlights are only appear at rotationally symmetric straight pieces, so mirrored model 2B29 never appears in game. But stoplights placed at intesections also has mirrored models, and they are used in many cases.

2. Road light exemplars are bad
The Resource Key Type 4 and Resource Key Type 4xm lines of the above mentioned high wealth lights (2A5A0000, 2A5B0000, 2A5C0000) contain references to streetlight 2B290000 by mistake or oversight, causing wrong models to appear at certain times of day.
I have corrected the 3 exemplars within the attached file.

Resource Key Type 4xm line contains the mirrored model. This line only exists in T21 lots. 2B29 is the mirrored piece for all the $$$ streetlights, and these lines are correct.

3. The 2nd rep of LotConfigPropertyLotObject has strange values
Values of 11 or 21 - does anyone know why? All i could make of this is they sometimes work and sometimes not.
I took the liberty of changing these to 10 and 20, making light placement reliable.

I discovered the real meaning of value 11 and 21 just two hours ago during the beta testing of USL. I assumed it is just a bug, but not. 00, 10 and 20 are the level of detail, mean appear always, medium or high detail only. The last bit can be 0 or 1, and it means wealth dependent prop selection from prop families. But it works in a very strange way. The prop is selected randomly from all entries of the family. If this value is 0, it will appear in the game. That means a prop with any wealth level can appear. If this value is 1, prop will only appear, if the randomly selected prop has the correct wealth. If not, nothing will appear. That means, only a wealth matched prop can appear or nothing. A0000060 and A0000063 families for roads are works in this way. Notice, that streetlights are always correct by wealth (if appear), while other families, which use value of 0, are always appear, but many times are incorrect by wealth. If a streetlight uses the 0 value, it always points to a specific prop, and not to the family.

4. One T21 has a wrong kPropertyID_NetworkPlacementPattern value
The exemplar CAADA9B6 is the only one of 74 exemplars that has a kPropertyID_NetworkPlacementPattern of 1,2,4,C.
Using 1,2,4,8 works better IMHO.

Correct

5. Prop families containing different wealth level dependant props dont work on T21s
They just dont. For example if you have a road on which a high wealth prop is expected from a variable wealth family, it is equally likely for the game to pick a low or mid wealth prop from the family, and display nothing.
So i got rid of all the affected families, namely A0000039, A000003F, A0000058 and A0000060 (and A0000075 from problem 1.) and replaced them by listing all the appropriate models in the LotConfigPropertyLotObject lines.

Correct, but see point 3.

Hopefully i will get around to diagonals and then, just maybe, the curves. 

Diagonals, streets and one-ways are all suffered from the same "bug".
In the last two hours I made the absolute same work on replicating the road T21s for each wealth level, as I must keep the correct streetlights by wealth, while I can't allow disappearing streetlights. That lighting won't be too uniform.

[Lowkee33]

3)... That means, only a wealth matched prop can appear or nothing.

So you would use 1 LotConfigProperty per wealth, and be able to have a ton of possibilities per tile.  I imagine this could work for other prop requesters too.  Maybe "0" would be used if the game was looking for a certain type of crime to show or just any crime at all.

This is happy news for me and regular lotting potentials.  If you cut the network to a Maxis Lot you will see the props going crazy.  I have been trying to replicate this, and I believe you have figured it out.

[sithlrd98]

Great job Vil..and of course kodlovag ..both of you have done a lot to try and get some kind of consistency and conformity with these T-21's! all I can say is that I knew something was causing me to have even more issues with the curves than just my inexperience! Anybody who has downloaded those curve mods I did will notice one issue (well a few since I could have done a better job). I can't remember the piece(s) but I think it was the Avenue pieces , if you plop the T-21 curve just the right way, if memory serves, half of the props dissapear. It was an issue that did not always happen, and since I opted to not make them "wealth dependent" , partly because of  the fact that the sidewalks were not "wealth dependent", I never fully figured it out.  I can't wait to see your different fixed T-21's, kodlovags' USL mod , and your Road/WRC  curve mod Vil!

Jayson

[vil]

Oh woderful news kodlovag, i was really hoping i didnt mess things up by dropping those 11s and 21s. 

I am not at this moment trying to mod anything, just make the game work like it was intended to, and in the process get to understand how it works.

So yes, ALL Maxis ortho road T21s have either lamps or palm trees on them, in an interlocking checkerboard pattern, lamps alternating sides every 2 tiles, and thats what you should get, reliably, with the previously attached file.

So you would use 1 LotConfigProperty per wealth

If 2nd rep LotConfigPropertyLotObject values of 11 and 21 work the way kodlovag says T21s can have a LotConfigPropertyLotObject line for each wealth, of which only the correct ones would appear, reducing the number of T21s required by half. I like that because i can fit all necessary T21s into the original ID range that way.

Should not xm models generally point to the same model, and only point to a different model if the model actually is meant to be different when the base texture is mirrored?
Im in a little deep just there. I actually use two different models to make my WRC sidewalk T21s, but my brain hurts when i rotate and mirror.
In any case 2A59 and 2B29 are both identically wrong models (down to using the same FSH and same bad LOD shape).
My conclusion is that the mirrored $$$ road lights should not all have yellow banners cut off by bad LODs but instead the xm lines should point to the same models as the regular lines.

2B29 doesnt appear in the vanilla game but it made me quit working on WRC curve sidewalks for a couple of months (to let off steam) because i could not get rid of it on mirrored tiles So i had to start over from correcting normal road T21s to make my T21s work.

[kodlovag]

Quote from: Lowkee33 on Yesterday at 07:04:33 PM
So you would use 1 LotConfigProperty per wealth

If 2nd rep LotConfigPropertyLotObject values of 11 and 21 work the way kodlovag says T21s can have a LotConfigPropertyLotObject line for each wealth, of which only the correct ones would appear, reducing the number of T21s required by half. I like that because i can fit all necessary T21s into the original ID range that way.

Eh, I understand how the system works, and I couldn't find this easy way to keep the number of T21s low. It's much easier to add new LotObjectData lines than replicating two new T21s for splitting the wealth levels.

About 2A59 and 2B29: I don't know too much about 3D models and LODs. Well I don't know what LOD actually is. Maybee you're right. If I remember correctly, 2B29 is a rotated version of 2A59, and therefore not a mirrored piece, because 2A59 is mirror symmetric. So your correction on 2A59-2A5C xm models is very OK. But for diagonal lights the rotated piece is equal to the mirrored piece, and the mirrored diagonal lights are used in the game and correct.


Vil, would you like to work together with me? I think (hope) USL will be popular, and your corrected T21s will conflict with it. But your work can be included in the USL mod to keep them compatible and fix the game. I already collected and modified all of the T21s for road/one-way ortho/diag separately. I will do the replicated LotObjectData lines for the light poles, because I'm using modified pole props and renewed placement pattern for the diagonals to achive the same 32 meters pole period like in ortho roads, measured diagonally. And you should replace the other prop families by listing all the appropriate models in the LotConfigPropertyLotObjectData lines. You can do it much easier than me, because you already collected the prop list for the families. The process is already in your hand.
What do you think?

[RippleJet]

I discovered the real meaning of value 11 and 21 just two hours ago during the beta testing of USL.

  Karma point coming your way!

[vil]

Lines with 11 and 21 in the 2nd rep dont work. Sometimes nothing appears even if all props are the correct wealth.

kodlovag I cant promise anything but i do want to correct all the original T21s to work the way they should, so i will do diagonals next, and if it helps i can do the streets and one-ways.

Obviously your mod is an alternative to what im doing, so they will not work together, but feel free to use my files if they help you in any way Basically if i understand correctly you would just either change the light cone models or add some light-spill flat props? Then you can use my files and put your props on them, i try to change only what must be changed and if i had to split an exemplar for different wealths they all keep the old name (if the name says its a bench, its a bench) so they should be relatively easy to use. They overwrite all the original Maxis T21s and 5 additional exemplars are used.

I am not too sure what the numbering conventions are for T21s so i used my usual range expecting to be held reponsible if $&*# happens, is an ID range assignment service for T21s operational somewhere?

[kodlovag]

Lines with 11 and 21 in the 2nd rep dont work. Sometimes nothing appears even if all props are the correct wealth. 

How did you tested it? If the prop don't have ResKeyxm line, and it should be applied on a mirrored T21, nothing will appear.
Is there any other property of a prop that should match to display? Like nightlighted, ground model, etc...
Can you try other values, like 12,13... Maybe they work differently, however never used in the whole simcity dat files.

T21 numbering conventions
- Randomly grouped for Maxis
- new T21s added by for example NAM team uses the texture ID or S3D IID (if exists for that piece) for the T21 exemplar IID. So straight road piece range starts from 0x00004B00 to at least 4BFF. I'm adding new T21 in this way. Sometimes there are much more possible numbers for an S3D based piece, as they usually use 0xNNNN0000 style IID. I think it is not necessary to take into account what ranges are used by others. T21s applied on the same network piece will conflict anyway. Except, if they are carefully designed from the beginnings. But that requires cooperation between the modders, and it is still possible, that the two mods cannot coexist in the game.

[vil]

I tested it by running it in the game 

The best way for me is adding a line to the palm tree T21 - so it should appear every other tile - then i just find an $$$ stretch of road and click on it a couple of times and watch. Using 11 or 21 in the 2nd rep of the added line makes a mess regardless of there being one prop, several props or a prop family in the added line. Sometimes nothing shows, sometimes it appears two or more available props are placed at the same time.

Ive got the diagonal placement sorted, i think 

Thanks for the ID info

[Lowkee33]

Could it be that you change the even/odd count when you re-make the road?

[vil]

No im absolutely sure. 

In fact there is more about those 11s and 21s to come, i think.

I tried placing high wealth props (a family) in lines with 11s.

On long stretches of high wealth road with high wealth lots all around they appear fairly reliably.

On short stretches they hardly ever appear at all (like one orthogonal tile between two intersections or between different wealth tiles)

In some places its one click you see it, next click you dont.

Also the line 11 props appear (after a click with the road tool nearby) with a slight delay (compared to other props on the tile), as if it takes the game a little time to decide if something should be there or not.

To me it appears line 11 or 21 means the game checks if some conditions are met but it is not a simple case of testing the tile that the prop is placed on (or the whole thing is just broken).

So if someone wants to figure this out, youre welcome

I need to spend time correcting maxis $$$ diagonal light models, and because mirroring is involved i may not be back for a while 

[vil]

diagonal light spacing   

[kodlovag]

My solution differs from yours. How many new T21s did you add? My solution required doubling, because other diagonal direction required different light placement. However I accidentaly did the task on T21s without lights too.

[Lowkee33]

I have to say, I prefer the lightposts on the middle of the tile and not the corner.  T21's are important to me because it is a good way to "prop" the steps.  The props on the corner of the lot could be done on the Res Lot. 

[vil]

My approach is im trying not to change anything at this moment unless its broken.

So i kept the maxis light placement and worked with rotations and placement grids only.

The original T21s with lights become three identical T21s with:
Rotations 3 (1+2)   Placement 1,1,1
Rotation 4             Placement 4,4,4
Rotation 8             Placement 2,2,2

The original T21s without lights remain unchanged and keep their placement. They fill the remaining rotations:
Placement 1,1,1    Rotation 0x0C
or
Placement 4,4,4    Rotation 0x0B

If there were any diagonal T21s without lights with placement 2,2,2 they would be R 0x07 

[vil]

Soo... attached you can find the results of trying to get road T21s to work properly.

Problems encountered along the way and solved or swept under the carpet:

1. All lights appear in reasonable places reliably (orthogonal and diagonal roads for now).

2. At the same time all original game T21s work properly (correct wealth of props, correct placement on diagonal roads so light placement is not messed up)

3. Orthogonal $$$ lights have better night models and work in all rotations and flips.

4. Diagonal $$$ lights have working models (day, night, all maxis colors, all rotations and flips).

5. Optional additional green $$$ lights thrown in as proof of concept.

6. Some bugs squashed, no exemplars get overwritten. Delete previous version.

This is all working up towards those wide radius curves. Im considering first doing transitional pieces, one-ways and streets to prolong the agony. In the process i have realized that wealth dependant sidewalk textures and lights are actually not what i want. I want density dependant sidewalks. Mmmm...

Ive also been skiing the last couple of days and my son turns 10 tomorrow prompting several days of celebration and a new joystick in the house, so progress will probably not be fast.

A picture...