Ok, read your other post, yes I had read that before, I think it answers my question but I'm not sure--I have to assume .

The lot I looked at had a U11 value of 0x00, the Orientation value was 'Left'--I'm going to assume (again! ) that what SimPE reports as Orientaion is simply an interpertation of the U11 value.

Well that wouldn't be surprising since a freshly placed lot template is moulded to the terrain. Blue-line problems must be more likely when you've got a lot with different ideas from the land it was placed on, ie one you sculpted after placing or one that had previously been saved with the contours of a completely different location imprinted on it.




I'd be worried about the ethics of this. I think on the whole reputable creators try to avoid doing work which is about making things available to earlier EPs that EA intended, as it could translate into lost sales for them.

Delphy asked me to get together an initial group of people. We have 5 definites and some people that I'd like to check up on a bit. Since it sounds like I don't actually have control over the user list, but instead have to rely on Delphy for all changes, I thought that it would be better to get together a good list before submitting my request.

So, I'm waiting for a few more responses - I know that there are more people out there who are interested in this testing, so I'm hoping that word will get out (but not *too* far).

There's no hurry, since I have nothing to upload at the moment.

Hey, I see on MATY that you consider the shrinking feature to be complete!

It's certainly complete for me! It's doing everything I wanted and without causing any problems. Edge smoothing (between each 10th vertex) would be a nice optional extra (as it kills the blue gaps) but I wouldn't want it compulsory because one time I wanted to make a river that ran along the backs of a row of houses. Smoothing would have ruined that :D

Smoothing is even more important to offer for expanded lots since the user can do nothing about the edges before expanding.

BTW I did test the smoothing hypothesis, and have found that yes, no matter that the game allows gentle curves in the middle of the lot; around the edges where lot meets hood, the line is dead straight between each 10th vertex (that is of course when you place a lot that has not been tweaked by an external program). The fact this doesn't happen on the main body of the lot would indicate that the terrain is actually masked out by the lot's presence. If that were not the case, you would not see blue sky where there is a gash, you would see the hood terrain dipping underneath - and you would see the hood terrain grinning through if you made a small but deep pit that was in an area between major vertices. If the LA doesn't offer straight-line smoothing at edges there is a high chance of any lot having gashes no matter whether or not the player picks it up and replaces it.

Actually, Orientation is a separate thing from U11 (I really need to update the U10 and U11 thread with the Orientation information). U11 is the rotation of the lot within the lot package. Orientation is the rotation of the lot within the neighborhood.

When you first place an empty template, the Orientation will match the lot rotation, although I believe that the two fields use different values for the same rotation (sigh). However, if you ever pick up the lot in the game and rotate it before placing it back down into the neighborhood, then these values diverge. The same holds for any lot put into the lot bin, then rotated during placement.

The lot package will retain its rotation value (U11) throughout its life, since this tells the game how to interpret the collection of bytes in each record - for example as a 2 or 3 dimensional array. The only exception to this is when we trick the game by changing the U10 and U11 values to rotate the lot (aelflaed's lot rotation tutorial).

The Orientation value is more ephemeral, since it lasts only until the lot is moved again. The Orientation value is more closely related to the Top, Left, and Z values in the Lot Description of the neighborhood package, since they all describe the current state of the lot in the neighborhood.

Actually, I haven't ruled out the cross-reference to OBJDs being via the NREF rather than GUID. NREF is hashed to form the group ID of the object as a whole (internally the game translates our FFFFFFFF groups to another number apparently - Peter told me this) Now if that is the case, then there may not be one record per tile of a multi-tile object in your lot files. There will be one per whole "thing", which will (I guess) line up with the subindex 0000 tile of the item. I might be able to work this out by looking at the - is it the OBJT file holds the objects and their coords?

Thank you for the explanation. I understand a bit better now.

Shrinking the lot with SimPE that way did not work.The lots (tried three) appeared as they should in the hood view, but were not enter-able. Without that intial enter and save, they could not be moved to bin. Failure

Do you think that doing the edits in SimPE on both the hood and lot packages would yeild any different results than it does with the LA?

OK, so now that I understand the concept... At this time, I don't know of any way to specify anything other than numeric coordinates... However, I need to do more research. I'll certainly keep a lookout.

I agree. I feel very fortunate to be a part of this team. Without all of your help (of course, I mean the plural "you" - everyone who's been posting), there is no way that I could have accomplished this much.

And I'm having a great time! I've been learning so much from everyone. It's a very stimulating group.

I remember seeing this in one of the simple records - oh yeah, the Fence Post Layer. I'll try to keep an eye out for this in the MOBJT, XOBJ, and OBJT records.

With the portals, I had to change coordinates in both the XOBJ and OBJT records. However, I believe that the majority of information about objects is in the OBJT record.

I could try to give you a summary of how the LE / LA translates the information, if that would be helpful. Alternatively, I could post a test version of the LA with debugging information enabled - it won't be pretty but it would tell you the strings that are found and which values the LA considers to be X, Y coordinates, if you would prefer your information pre-digested.

Of the two options, the debugging information is easier for me.

Just so I understand: The game would not let you enter the beach lot, after editing the neighborhood package and before putting the beach lot into the lot bin?

I think that it's very difficult to edit the lot package correctly by hand.

Back from a short trip and just wanted to say that I really really want to help in tests too, if possible :D

Yes: The game would not let me enter the beach lot, after editing the neighborhood package, and therefor it would not let me put the beach lot into the lot bin.

So editng the lot package is difficult or tedious? If it's tedious I can probably do it ok. If it's difficult to understand/deciper I can't more than likely--so we may be up that proverbial creek, I think, on 1x beach lots. Just to recap: the 1xs I made in mytest hood were fine until moved to a new hood. I thought, wrongly, I could simply make a 1x for each hood but I tried to make a 1x5 in my second hood (which I've been using for placement only) It had the tear. Maybe it's this one hood? I'll try another and I'll keep trying when I think of a new angle to hit from....

However, the 2xs are playing great so far. I have two made into comms and one made into a res with a sim and a cat in it. All build actions and day one sim actions are fine so far.

My row template has a flaw: we can not remove a foundation square on the outer edge or it leaves a 'hole' in the foundation wall. On a regular placement foundation when one hits the foundation with the hammer, the immediate square is removed, but it automatically 'builds' the foundation walls 'behind where the square was, where it needs to. (hard thing to describe.) I'll play with it some....

This was something that niol suggested; I'm sorry that it didn't work at all. niol, any ideas? Perhaps beach lots are different enough from the empty lot templates that this just won't work?

I've never done this, myself. I think that niol and Inge have, so again I should defer to them.

However, I believe that it's impossible to add new elements to, or delete old elements from, a record using SimPE. If I'm correct, then you would need to get yourself a proper hex editing program, or else leave the arrays intact. Now, I believe that niol has had good luck leaving the arrays alone and just modifying the sizes, but that was with flat empty lots... it probably won't work with beach lots.

The game interprets some records, which are just collections of bytes, as 2D and 3D arrays. If you change the height or width of the arrays, then things which used to be side by side in a virtual array will no longer be interpreted as being side by side... so you'll get very poor results.

This is further complicated by the fact that the record structures are not well documented. In general, I determine the record structure by reading the C# source code for the LotAdjuster. Eventually, I'd like to get this information into a reasonable format and get it into the Sims2Wiki, but it's not there yet.

Sounds like the current shrinking feature just isn't up to the task, yet. You might have better luck once I get the lot edge smoothing feature implemented.

You described it perfectly. Perhaps if we get some logic into the LA to move objects back onto the lot, this problem will disappear. For now, you should definitely avoid having anything on the area to be deleted.

Remember, the lot shrinking feature is still fundamentally broken. While some people have had some luck creating lots for themselves, many shrunken lots crash. They really aren't safe to share yet. I was hoping that empty beach lots would be safe, but we don't even know that for sure.

I've been playing a 2x3 beach lot all day-for about a sim week. No problems at all. I have sent her to comm lots wlaking, her cat is supporting her (wish my cat would learn that...) and the car comes and goes just fine. I willcountinue on with ordering pizza and maybe adopting a kid to see how that all goes and how the school bus does.

Inge had wondered if the off lot wave effect portal would create off lot waves: no it doesn't. The 2x3 has two effect portals and one wave from each is visible, but that's it.

One odd thing: the 2x3 lot was made by 'cutting off' the green area at the front of the lot, basically. The result is 10 squares of sandy colored build area, 10 of sand only--sandcastle building/sunbathing area, and 10 squares of water. The od thing is the surrounding hood is seen asall sand--all grass is turned to sand throughout the hood except for the small strip at road side. On the 2x4 there of course was 10 squares of orginal grassy area left plus the 10 sandy area, resulting in a total of 20 squares for building, 10 for sunbathing and the 10 water. On these lots, with a grassy area still in the lot, the hood view is grassy, as it should be, all over the hood. Odd, yes?

I have had the same effects (sand) when working on my lots near water, shrinking them. Both beach lots, and "ordinary" sloped water lots. I think its due to being too low and close to water line.

After some looking around in the Hex for some of my lot packages, it seems possible to break the 6 x 6 lot size limit. This could all be fruitless if it turns out that the limit is also hardcoded into the source and not just database-related, but...

As was mentioned several pages back, the current database is set up for at most a 63 x 63 tile lot (60 x 60 for neighborhood-friendly lots). Unfortunately with Maxis's current package structure, it is not possible to completely remove the limit, increasing the limit looks feasible. After trying a 500 x 500 lot just because I wanted a huge lot, I realized that the Hex-ness might limit the size to 255. After some more messing around, I noticed a lot of 64s and values that could be derived from function inputs of 64 in the 3D & 2D Arrays.

An unfortunate result of passing the number 64 through a function leads me to estimate that 84 x 84 (80 x 80 for neighborhood-friendly) is the largest lot that would work. Perhaps 64 was chosen because it's both a perfect square and a power of 2, making some of the math I'm about to bring up a bit simpler.

EC44BDDC - 00005129
Offset 77, 93
f(x) = 2x
Offset 78, 94
f(x) = x - 1

6C589723 - 00000000
Offset 101, 129, 157, 185, 213, 241
f(x) = x
Offset 102
f(x) = 3x - 1

* It's this handy 3x and more to come that means we can't break 85 (85 x 3 = 255).

Offset 130, 158, 186, 214, 242
f(x) = 3x - 2
Actually f(x) = 3(x - 1) + 1, but let's keep it simple.

3D Array (2A51171B) - 00000001
Just start scrolling down and looking for pairs


2D Array AKA Lot Terrain Geometry - 00003B76
Look for 191... that would modify to f(x) = 3x - 1.
Then we have 96: f(x) = 3x/2
And 48: f(x) = 3x/4

Since I don't have the patience to start modifying thousands of Hex values, I have been unable to test increasing all the aforementioned values to be based on 84 (although 85 is possible, we need to divide by 4 at some points).

If anyone knows of a nice Find/Replace plugin for SimPE that can search the binary values, let me know!

I just noticed an oddity in one of my shrunken lots. I have a wall on the very edge of the lot. Along this edge are (front to back) the living room, the bathroom, and the bedroom. I decided that she needed a mirror and was considering a large mirror that takes 4 squares along the wall (Fancy Synchophancy). Even though I have moveobjects turned off, the game is very happy for me to place the mirror on the edge wall and through the wall between the bathroom and the bedroom or (even worse) so that 1 tile is in the bedroom, 2 in the bathroom, and 1 in the living room. It just doesn't seem to recognize the walls which separate the 3 rooms as barriers. As far as I can tell, the walls still function as privacy and sound barriers.

Has anyone else noticed anything odd about the walls which intersect the new edge walls?

I haven't, but maybe I'll go have a look-see.

EDIT - Same thing for my shrunk lot, using a double-wide curtain. Two-tile coffee table and paintings did not work - maybe your mirror was cloned from a curtain? However, I did reproduce this in a Maxis-built lot too, using the curtain, so it's a curtain thing not a shrinking thing. I think.

Not with base game. You build the lot in the terrain you want, or use terrain paints to make it look different. The automatic terrain detection for me came with an EP, probably NL I think.

Thankyou! This is something I've been puzzling over since I started doing the rotations, but hadn't managed to ask. I might possibly understand it now.

The LotExpander doesn't do anything with 0xEC44BDDC - NHVW - Neighborhood view, so it's definitely not required to change the size of a lot.

The LotExpander changes the height and width values at offsets 66=0x42 and 70=0x46 in 0x6C589723 - LOT, but doesn't change any other value in this record. Again, if the LotExpander doesn't change the value, then it probably doesn't help to define the size of the lot.

I'm assuming that the second number is the instance? The LotExpander changes the height and width values at offsets 81=0x51 and 85=0x55 in 0x2A51171B - 3ARY - 3D Arrray Instance 1. Depth is stored at offset 89 = 0x59. Most of the rest of the record is a 3D array (depth x width x height) of floats defining the relative z-value of the lot above or below its 0 point, which we believe translates into an absolute value based on the Z-value defined in the Lot Description of the neighborhood package.

The LotExpander changes the height and width values at offsets 81=0x51 and 85=0x55 in 0x6B943B43 - 2ARY - 2D Arrray Instance 0x3B76. Most of the rest of the record is a 2D array (height x width) of floats defining the z-value of the water level for the lot.

Interesting. The mirror is maxis-made and I tried another maxis-made multi-tile mirror with the same result.

I'll go check it with a maxis-made house.

[Update:]

Yup, it happens with the unplayed Grunt house in Strangetown. I can't believe that I've never noticed this before. OK, false alarm. (Phew!)

Oh. I'd completely forgotten that this doesn't happen with the base game. Thanks.

So, I guess that you can ignore what I said about the terrain, niol.

Was my explanation good enough to just add to the U10 / U11 post as is? Or, do I need to explain what the Orientation values are and what they mean? Do I also need to add an explanation about the rotation of the neighborhood?

Every time that I think about all of these rotations (neighborhood rotation, lot rotation in the neighborhood, rotation of the lot in the lot package), I think about the ElectroDance Sphere. It makes me dizzy.

I tried your mirror trick - see post edited above.
Need to digest a bit before responding. Does this type of orientation show in the neighbourhood shadows, on lots seen in hood view? That's what I think it means, but you never know.

From post 1032:
This is a bit much programmer-speak for me. I believe it means that the U10 / 11 values dictate where the road is in relation to the house, and that remains constant regardless of shifting the finished lot around in the hood.

If the Orientation recorded does NOT relate to the neighbourhood shadows, I have no idea what it means. I've tried to observe those records when modifying lots, but have never come to any conclusions on my own. It certainly doesn't match the left/right/front/back that you had in your U10 and U11 notes, because I did think that at first and was quickly proven wrong.

I was told by someone - maybe on the 2x North and South mini-lots thread? - that the neighborhood sun direction was exactly opposite the lot sun direction. If this is true, then the neighborhood sun direction is also controlled by the U11 value and not by the Orientation.

So, sounds like we need to do some research on this. If you look at the neighborhood sun direction for a lot and then rotate the lot in the neighborhood, does the sun remain in the same place on the lot (in the neighborhood view)? If so, then it's controlled by U11. If not, then it may be controlled by Orientation.

Sorry about the programmer-speak. I just don't know how to describe the U11 value without referring to the internals of the lot package, since that's what it affects. I suppose sun-direction works. The roads are actually controlled by U10.

Unfortunately, I defined the U10 and U11 values based on the location of a road and the front of the lot relative to the rest of the lot, while SimPE defines the Orientation value based on the location of the lot relative to the front of the lot (above or below, left or right). In other words, the definition that I've been using is almost the exact opposite of the one that SimPE uses.

I've been wondering whether I should change my definition to match the SimPE definition?

Well, that was easily checked. I looked at one Maxis lot and my Modern Terrace lot. Both have the internal sun opposite to the hood sun, and the hood sun doesn't change when the lot is placed different ways in the hood.

Which means I still don't understand what the Orientation is telling me.

When you pick up a lot in the neighborhood view and rotate it, then you have just changed the Orientation of the lot.

No problem, just mentioning it - If I'm being the general everybodies with regard to understanding explanations, I'm going to report whatever I don't follow (that might matter to me - obviously I'm ignoring a lot of what Inge and Niol talk about, since it's way over my head, but things that I might actually be expected to do something with, that's different)

I did understand about the difference between U10 and U11 when I read up about it ages ago, but for my purposes, remembering that they had to be used as a pair to make the rotations work was sufficient.

I found using the idea of sun direction made far more sense to me than your left/right etc directions. I even used Andi's sketch in preference to your version of the same, so we were not on the same wavelength there at all. Your explanations worked much better though. I don't know if the SimPE definitions would be any better, since I have no idea what that Orientation means now. Maybe it would be best to be consistent with SimPE anyway.

I seriously don't understand what you mean by the front of the lot "relative to the rest of the lot". Yes, fair enough, but so what? What does it affect in-game? Obviously not the shadows.