The only experience that I've had with XOBJ rotations was trying to ensure that the portals are placed and rotated correctly. I know that the posts are in this thread somewhere... my memory is that the portals did not work correctly without additional modding of the OBJT record. As it is, the visible rotation (noted by the arrow on the box) can still be incorrect, even with both of these records changed.

No worry. I'm aware of the fact it takes modifications on at least these 2 files for the objects to work out when without user intervention.

Unlike other unvisualised objects, portal objects in lots are interesting because they have a modelnull mesh which, if I remember correctly, is an "underground" simple 2D trigonal planar morph. In the pictures I attached in the previous post, I used nutcracker-based mesh-override to visualise them out. They're more like other visualised objects.

Upon your saying, so the part for the rotation embedded in xobj file is not on the way, but others in other files be?
If so, I'll move on those.

Oh, it appears, the rotation value seems to appear consistently to be the BYTE before a string pattern like "00 00 00 FF FF" in xobj files under the few conditions I've checked..

The LotAdjuster logic seems to find the XOBJ rotation byte consistently. Looks like I haven't transferred any of that knowledge to the wiki, although it's in the source code, so it's somewhat available. I guess I should document what the LA knows and we should add whatever you've figured out.

by the way, the third value in the wiki is right about that it's the level value, but the ground starts from "1" instead of "0". I've yet to confirm if the only underground level is "0" instead of "-1".

I confirmed that none of the pre-made lots have level = -1. It seems more likely that EA is using the array index, which would imply that the underground level is 0, if it exists, and the ground level is either 0 or 1, depending upon whether an underground level exists.

Ouch, that shows a defect in my memory while I was analysing the file.
I forgot this switch in numeric value we had sorted out before.

I need to do more research to confirm this. Probably the best thing is to look at specific items on lots with and without an underground level.

I do wish that EA were more consistent with field values.

Probably they don't want people to mess with those parts, so they choose to be inconsistent (Just kidding...)
Alright, me too, have to get some more empirical instances out to solidate this.

I've done a few empirical tests.

1. I've checked out the xobj obj level value before and after addition of swim pool under TS2EP0, no change in value was found.

2. upon alteration to 0x00 from 0x01 or 0x02, the resultant object hplaceholder were eventually located at 0x01 graphically after the undo trick.

3. oxFF as "-1" makes the object disappear.

Conclusions:

1. under TS2EP0 (base game), the value was altered upon addition of swim-pool.

2. 0x00 or 0xff are ineffective under TS2EP0.


Trials:

1. will try newr game versions to see if any change.





Updated:

Note the prefixes (t2-, t3-, t4-, ...) of the pictures are for the corresponding test series.


Series t2:

It demonstrates that 0x00 based on xobj file does work for objects under TS2EP0.


Series 3:

Note the addition or removal of extra swimpool have nothing to do with the series but simply trapped in the process for my laziness to re-do the whole demonstration or testing.

1. It shows that the presence of the swim-pool product inhibits objects to be placed at level 0x00 based on xobj file. By means of in-game undo scripting, objects can get placed at level 0x00 based on xobj file before formation of swim-pool product. That's how objects can get placed at such level currently through object placeholder modding at xobj file.


t4:

1. it shows the absense of the level 0x00 based on xobj file caused objects dumped to the lot dump location upon object placeholder modding at xobj file.


Current conclusions:

1. Previously occured swim-pool products can block object-placement underground. So, the workaround can be to delete the pool before object placement or to place objects by means of SimPE and in-game undo-scripting.

2. 0x00 is really the underground value for the Level value in xobj file at least under TS2EP0.

3. Before addition of the underground level, objects can't be located at the pre-defined 0x00 level geometry. Instead, objects may be placed the lot dump region as depicted in series t4 graphics.

From: http://www.modthesims.info/download...089#post3205089
(Post #94 in the LotAdjuster 3.2 download thread)
Actually, yes I have. Completely unintentional, in fact, although that doesn't make it less useful.

Because I love modern homes, I've been looking into double-sided floor tiles to be used on sloping roofs. As a part of that research, I've been thinking about a new program ConvertiFloor, which will change floor tiles in the same way that ConvertiWall changes wall styles. This would allow people to replace the default (Maxis) single-sided floor tiles with custom double-sided floor tiles on the roof level(s), even if there are no flat tiles on the roof.

As a part of that research, I've learned a lot more about how floor tiles are made and stored within the lot package. I may have enough information now to do a proper job of regenerating the roads, excluding correctly-formatted intersections. From my previous research about regenerating roads, this may be enough to make the game more willing to place LotAdjusted lots on difficult terrain. (The only other thing that I've found which may help is to update the local hood terrain in the lot description within the neighborhood package).

Here's what I know so far:
- Road tile references are stored in 3ARY instance 0 (by quarter tiles).
- Road file references can be mapped to string values via SMAP.
- SMAP contains only the road tile patterns actually used on the lot.
- SMAP contains a count of the number of times each road tile pattern is used on a lot; usually (front road only) width * 10 (depth of road) * 4 (number of quarter tiles in a tile) * number of times pattern is used on a road cross-section.
- String values are the various road tile patterns (ie, sidewalk, road_asphalt, road_crosswalk_00).
- The road tile patterns used on a lot are most likely dependent upon the U10 (roads) value.
- As far as I can tell, intersections with neighborhood roads show up in both the hood and lot views, but are not reflected in the road tile patterns in the lot package. This is good news.

Here's what I don't know yet:
- Where do the road tile string values come from? [Update: Possibly TSData\Res\Catalog\Scripts\FloorPatterns.txt, which maps to a material definition.]
- If I want to add a new road tile pattern, is it enough to add a new entry in the SMAP? If not, what else do I need? [Update: adding a new entry to SMAP seems to work, at least for the pre-defined road tiles]
- Is it important to keep an accurate count of the number of times that a floor or road tile is used on a lot? [Update: so far, I have had no problems with road tiles with inconsistent counts.]
- I notice that in FloorPatterns.txt, there is a set of european roads available immediately after the standard roads. Does the game use these as the default road patterns in some countries?

A standard straight front road pattern is:
1) sidewalk
2) blank
3) road_sidelines_xx (xx = 00 for U11 of 1 or 3, 01 for U11 of 0 or 2)
4) road_asphalt
5) road_whiltelines_xx (xx = 00 for U11 of 1 or 3, 01 for U11 of 0 or 2)
6) road_whiltelines_xx (xx = 02 for U11 of 1 or 3, 03 for U11 of 0 or 2)
7) road_asphalt
8) road_sidelines_xx (xx = 02 for U11 of 1 or 3, 03 for U11 of 0 or 2)
9) blank
10) sidewalk
This is repeated for each cross-section of the road across the width of the lot. All four quarter tiles within a tile are identical.

I believe that the road tile sets are identical for U11 = 1 and 3, and also for U11 = 0 and 2, because the roads are placed on opposite sides of the ground level of the floor tiles array. This means that the road tiles are actually reversed when looked at from the edge of the lot, which makes sense. Luckily, the fact that they are identical makes the logic simpler for straight roads.

I can probably translate the above for all roads (not just the front), based on the U10 value, but I haven't done that yet. For now, it's reasonable to assume that:
U11 = 0 => U10 = 1
U11 = 1 => U10 = 2
U11 = 2 => U10 = 4
U11 = 3 => U10 = 8

Corners are more difficult. I have only looked at the corner for 55 Woodland Drive in Pleasantview, which has U10 = 3, but I assume that there are four different sets of patterns for the four corners and that the cross-section patterns vary depending upon the location of the cross-section within the corner 10x10 area. For example, I have identified the following road tiles used for the corner on this lot:
sidewalk
road_corner_00
road_corner_01
road_crosswalk_00
road-crosswalkend_00
road-crosswalkend_01
road-crosswalkend_02
road_asphalt
road_sidelines_00
road_sidelines_01
road_sidelines_02
road_whitelines_01

Luckily, it still appears that all quarter tiles within a tile have the same pattern.

Ooo, wonderful! Even though it isn`t yet ready for public consumption, I think I might like to try a test-version on some of my problematic lots to see if the results are LESS problematic than with the current version.

...if you`re willing to cobble something together, that is.

I'm currently testing the straight roads, but haven't done anything about the corners yet. In the process of working on this, I found a couple of bugs (did you know that a road-only lot will crash the game?), so I may be putting out a new release soon.

Interestingly, the corners seem to auto-generate for some lot rotations (at least, with all EPs and SPs) if the straight roads have been added by the LotAdjuster.

Now for the bad news: So far, regenerating the roads isn't helping me to place a corner lot back onto its highly sloped terrain. However, I was still able to move the lot somewhere else in the neighborhood (completely inappropriate terrain, but at a corner) and then move it back without any problem.

---------------------------------------------------------------

I'd like to step back for a moment and examine what we're trying to accomplish. The LotAdjuster relies on the game to "fix" the lot after an adjustment. At this time, I only know of the following things that the game does:

Build change:

1) Regenerate the lot impostor. Without this change, the lot cannot be picked up and moved within the neighborhood.

Place the lot in the neighborhood:

2) Generate appropriate roads on the lot. Sometimes this is a bad thing; for example, for "over the road" lots, lots which have been expanded into the water, or lots which use custom road tiles.

3) Update the neighborhood terrain, including roads, to take the new lot size into account. These changes can ripple through fairly large portions of the neighborhood.

4) Update the local hood terrain stored in the lot description in the neighborhood package. The function of this array is unknown.

There may be other things that are affected; these are just the ones that I know. Of these, the lot impostor and roads are the most obvious to the user.

Note: the following is speculation, based on testing.

My current theory is that lots which are difficult to place have the top left corner vertex of the lot at a non-zero (relative) elevation. This corner is associated with the Top and Left values in the Lot Description and is based on the Orientation of the lot in the neighborhood.

If this is true, it may be possible to resolve this problem by adjusting every elevation on the lot, so that the top left vertex is at a relative elevation of zero, then adjusting the associated lot elevation in the opposite direction.

From observation, here's what I believe that the game is doing, when I move the lot away and back:

A) Adjust the hood terrain near the edges of the lot to match the lot elevation. If the edge of the lot is not at a relative elevation of zero, this results in hills and valleys next to the lot.

B) Adjust the hood terrain at the edges of the lot to match the lot elevation + the relation elevation of each lot vertex. Since the local hood terrain has already been deformed, this results in a further deformation of the hood terrain, making the hills and valleys sharper.

What the game should do instead:
- Attempt to place the zero-points on the lot, then adjust the rest of the neighborhood terrain according to the relative elevations inside the lot.

It's also possible that the game cannot adjust the hood elevation underneath existing lots, including the lot being moved. This may explain why particular lots cannot be placed in their original locations unless they have been moved away first.

Please note: all of the above speculation requires further research.

If my speculation proves correct, then there may be no way to resolve the problems moving these lots, since the logic is embedded in the game executable.

The only "solution" would be to avoid moving these lots. If so, the LotAdjuster may be able to do enough to make moving lots unnecessary, such as regenerating the roads on the lot and updating the local hood terrain for the lot.

My current advice for this type of lot is to adjust the lot in several stages: First, adjust the width of the lot, so that the roads can be properly regenerated. Then, adjust the depth of the lot, to get the slope. An intermediate solution may be for the user to place the appropriate road tiles.

It's possible that neither of these workarounds will work for a lot which is expanded to include a new non-flat side road.

The new test version of the LotAdjuster, which attempts to regenerate the roads, is now available in the Moo Test social group. If you are interested in testing, but are not yet a member of the group, please let me know.

Update: This almost worked. My lot has uneven roads on two sides. By adjusting the entire lot down, the top left corner of the lot was now in sync with the neighborhood terrain and no valley was created on this side of the lot. However, the other side of the lot was still lower than zero, so a hill was created on that side. Because of this, it was impossible to place the lot in the same location without moving it first.

Just to help people visualize what's happening, I've attached some screenshots.

1) The LotAdjuster creates the lot terrain to match the neighborhood terrain, so the roads blend smoothly from the lot into the neighborhood.

2) If I pick up the lot in-game and move it somewhere else, so that the roads and local hood terrain are correctly regenerated, then move the lot back to its original location, the game lowers the neighborhood terrain near the upper road, and raises the neighborhood terrain near the lower road. This basically destroys the neighborhood terrain, so that the roads no longer mesh smoothly; instead, there are (unnecessary) hills and valleys.

3) If I use the GridAdjuster to change every elevation on the lot, so that the top left corner of the lot is now at a 0 relative elevation, the lot looks the same as it did in picture #1. However, if I move the lot away and then back again, the game now places the top left corner of the lot correctly, so that the top road now flows smoothly into the neighborhood. Unfortunately, the game now creates an even larger hill next to the lower road.

This distortion of the neighborhood terrain is being done by the game itself and has nothing to do with the LotAdjuster. The only way to resolve this problem is to avoid moving the lot in-game.

The new version is now available. There is now an option to pave roads, as well as several other new features and bug fixes.

Hooray! LA 3.3 won't download for me at present, but I'll keep trying. Sorry I missed the call for testing - things are a bit wild here at present, and I'm online less than usual.

I did a lot of testing myself, but I'm hoping that people will still let me know if there are any problems.

Just did a bunch of testing and wanted to document the results...

Wall coverings on partial walls are either aligned at the top or the bottom, based on which EPs are installed. All EPs align wall coverings at the top on foundation walls. For normal walls...

Wall coverings are aligned at the bottom in the following EPs:
Base Game
University
Nightlife
Open for Business
Apartment Life

Wall coverings are aligned at the top in the following EPs:
Pets
Seasons
Bon Voyage
FreeTime
Mansion and Garden

Therefore, for early EPs and AL, a diagonally-split wall can sometime appear to be a standard wall through the use of normal and foundation walls. However, the later EPs and especially M&G destroy this ability.

The pictures are of the exact same house, in the exact same neighborhood. The only difference is which EPs are used to edit the house. By using a normal wall (aligned bottom) on the lower level and a foundation wall (aligned top) on the upper level, the wall coverings hide the diagonal split. However, when both normal walls and foundation walls align at the top, there's no way to hide the diagonal split.

Neighborhood water will flood lots which have relative elevations which are below zero, when the lot is placed near the neighborhood water level. Basements can be forced to be dry by raising the major vertices (every 10th grid point) to a relative elevation of at least zero.

Raising the major vertices will keep basements dry for these EPs:
Base Game
University
Bon Voyage
FreeTime
Apartment Life
Mansion and Garden

Unfortunately, this trick will not work for the following EPs:
Nightlife
Open for Business
Pets
Seasons

The pictures are of the exact same house, in the exact same neighborhood. The only difference is which EPs are used to edit the house. Note the raised grid point at each major vertex, surrounded by basement walls.

When a lot has a basement, the lot imposter will sometimes show the basement extending out into the yard. This problem can sometimes be solved by raising the major vertices on the lot to a relative elevation of zero or higher.

This solution works for the following EPs:
Base Game
University
Nightlife
Open for Business
Pets
Bon Voyage
FreeTime

This solution will not work for the following EPs:
Seasons
Apartment Life
Mansion and Garden

The pictures are of the exact same house, in the exact same neighborhood. The only difference is which EPs are used to save the house. When the major vertex workaround fails, the game interpolates the neighborhood water incorrectly.

MAB-2000 created a journal entry today about the underground level (level=-1):
http://www.modthesims.info/journal....howentry&e=5669

We've already done some research on this and found it less than useful:
http://www.modthesims.info/showthre...152#post1929152 (Post # 1578)
http://www.modthesims.info/showthre...185#post1929185 (Post # 1581)
http://www.modthesims.info/showthre...438#post1932438 (Post # 1651)

Since I had never shared my original underground test lot, and since I seem to have lost it, and since at least one person has requested it, I decided to create a new test lot. Note that it is still impossible to access the underground level.

How this lot was made:

1) Create a new base game lot.
2) Add a pool, to quickly add a new level=-1 to the lot.
3) Remove the pool, since it's no longer needed.
4) Save the lot, to ensure that saved lot has new level.
5) Add some walls on the ground level.
6) Save and quit the game.
7) Subtract 1 from the level of every wall in every WGRA. See Note 1.
8) Add invisible tiles on the ground level so that we can see the underground level. See Note 2.
9) Drop the water on the lot by 20 clicks. See Note 3.

* Notes:
1) Using a special version of ConvertiWall V1.2.1.
2) Eventually, this step could be replaced with the invisible flags in the 3ARY instance 0x15.
3) Using an unreleased version of the GridAdjuster V1.2.3.3.

This discussion has been moved to its own thread (which should be in research, but is in building by accident):
http://www.modthesims.info/showthread.php?t=453069

From: http://www.modthesims.info/showthread.php?t=297782

Looks like I found the lot price in the SIMI record. And only 3 years late!

It's been difficult to find because the price is split into 4 (!!!) separate DWORDs, and one of those DWORDs requires an adjustment before it's added to the total lot price.

I'm trying to work out what the different DWORDs represent. The first DWORD is the empty lot price. I suspect that the last DWORD is the price of walls, floors, etc.; basically anything that isn't object based. The last DWORD is the one that requires the 80% adjustment, which may match the difference in price when you build a wall and then immediately delete it (can anyone verify that?)

Expect a new SIMI wiki entry soon.

[Update:]

Has anyone heard of a problem where Nightlife lots have the wrong lot value? I added a vase to a Nightlife lot then deleted it, but the lot value (both in-game and in-file) still includes the price of the vase.

[Update:]

Here's the article: SIMI^wiki. I hope that this is understandable. The record seems to contain a variable-sized array of WORDs. Rather than count the number of WORDs for each version of the record, I just tell you the location in the record where the interesting stuff starts. I specified the location in hex, to make the fields easier to find in SimPE.

So far: cash, price of empty lot, price of objects which will be sold when a family moves out, price of objects which will remain on the lot when a family moves out, and the price of all architectural elements, plus the calculation of the Lot Price shown in game.

Interesting observations:

- Inge Jone's stay-things shrub probably causes problems with the lot value because the game assumes that all sellable objects have been sold and sets the "sellable" price to zero.
- The LotAdjuster doesn't adjust the price of the empty lot when the lot size changes, which is why the lot price is incorrect until you make a build change and the values are recalculated.

I hate to necro, but I have a question about wall paint alignment discovered here:
http://www.modthesims.info/showthre...998#post3025998

Would it be possible to mod so wall paints align to the bottom of walls, for those that are using an EP that aligns paint to the top? OR vice versa? I would assume there must be a variable in code somewhere that shows notable change per EP as to why this happens, so it could be modded? Or is this hard coded and unreachable?

I'm afraid that I don't know where this information is stored. It seems entirely possible that it's in the game executable, which would mean that it can't be modded. However, I'd be very happy to learn otherwise.

Sorry to have dropped out at about the time when the new Lot Adjuster that I effectively requested became available, but I had a lot go VERY bad on me [crash-the-game-when-loading-the-lot bad!], and I suffered *severe* burnout whilst trying to work on my tool in an attempt to detect and repair the damaged lot.

I eventually determined that my tool had a pair of errors in the record-decompression routine such that one error caused insane records to be returned when one rarely-used opcode appeared in the compressed data while the second error masked the existance of the first.

Unfortunately, I discovered this *much* too late to do much good, and still have no clue what went wrong in that lot. I`m glad to see that you have continued research in my absence, and appear to have made significant progress, as well.