Do either of you have MoveObjects on? You need it to grab the portal markers.

I don't know that we're going to be able to fix this. It seems to be a defect in the game, rather than a defect in the lots. So, unless we can figure out a way to convince the game to do the right thing, I can't imagine how the LA can solve this. I wonder whether this is why EA decided to ship only the huge beach lots?

I think this and the hard to place smaller lot is why EA went with the larger ones. However: the smaller ones aren't that hard to place. The 2x3s and above are great and great fun.

I'm having a problem--not sure why: for a few days now I can't get the 'force 12 hour clock' to stay on, and now it won't even click on. I haven't been reading posts much so this may be and most likely is a BV problem, but I thought I should mention it.

I play with moveobjects on.

But I don't think grabbing the portals is the problem here. It is missing and/or too many portals.

Oh is this the dip in the beach lots? If you look at the edges of a normal beach lot that has just been placed, you will see that at the water end of the sides, the difference between the corner major vertex and the next one up towards the road is exactly 3 metres (16 clicks). The edge between them is straight. Then the very next column of minor vertices in towards the centre, the slope completely changes to make the shape the sims need to get into the water. When you are preparing a beach lot for shrinking, you have to get that edge just right. If the LA is handling that, it needs to respect the 3metre difference, or else the portals will probably try to change the level of the land and that might be why there is a gash still in spite of the smoothing.

Moveobjects doesn't make any difference, except that it allows me to place new beach portals over the area where I think that the old beach portals are sunk under the ground.

[Update:]I finally got them. Moveobjects did help, but the portals were only accessible at one tiny point at the intersection of 4 tiles. Thanks, aelflaed!

The blue gap occurs at the water end of the lot, parallel to the water line, not along the edge. However, the LA doesn't change the primary vertices (yet), it just smooths the minor vertices between the primary ones.

Inge, if you want to see it, DL my 1xs and place them in a couple of hoods (sometimes they are ok and sometimes they aren't so try them in at least two different terrains.)


Mootilda--do you think the portals could have all been deleted, not sunk? I ask since I was missing that one.....

Well, since I finally managed to grab them, obviously not. However, I suspected that they were sunk because the game wouldn't allow me to put new beach portals in, saying that the space was already occupied. I also suspected because the space that the game said was occupied was exactly the right location and size for the beach portals.

Anyway, the moveobjects trick worked, but I had to be very precise.

Sorry, I didn't see this before. Is anyone finding lots with smoothed edges (LA 0.1.3 or .4) easier to place than lots shrunk with previous test versions?

Oh. I missed that, I didn't know you finally grabbed them. Well good--that's better than just gone! My missing portal was 'just gone' period, but it has ionly happened once.

As for the 'easier to place' yes and no: yesterday when the lots were fresh made, they did seem easier to place. However, today, after a few starts and stops, they did not appear to be any easier to place on the same terrain as I tried yesterday. I can't account for the difference.

The littler or rather less deep lots are of course going to be harder to place because of their slope and depth requirements.

With the out-of-the-box beaches, the edge at the sea end of the lot (the edge opposite the road) is dead horizontal all the way along. Unlike normal virgin lots, it never seems to follow the terrain geometry. I am just offering this as an observation, I can't yet come up with an idea for how the LA should deal with this. For shrinking, I have found that scrupulous attention to manual levelling before shrinking gives good results, so beach shrinking is workable but troublesome let's say.

Not that I have noticed. Sometimes they are tricky, sometimes it doesn't seem to matter. However, I wasn't aware of it as a big issue previously either.

Glad MoveObjects helped with your beach portals.

I've been testing on my Lumpy Shrinker lot.

- The Next button has returned to the Restart screen - thanks.
- Distorted houses are visible when re-entering the game after shrinking with LA 015.
- Windows built on the edge walls are present, but if moved, must be put back with ESC button, and are then blanked out.
- Portals are excellently placed.
- Terrain paints are sometimes odd, sometimes not. The tower version today had malfunctioning terrain paints, the copy from yesterday did not.
- The distorted buildings of yesterday are history - the terrain edges are smoothed, and the built levels remain flat.

I tested with a fresh copy of yesterday's house (lattice foundation plus one storey), and with today's version, which I altered to have a livable basement and a little tower, so three storeys in all. No distortion on any of those levels.

I have not tested with inhabited versions.
Pics attached
- yesterday's distorted lot, mainly so you know what the base house is like.
- today's tower version, after shrinking.
- the base house after shrinking, showing the blanked-out rear window.

I'm sorry, but I don't understand what this sentence means. Are you talking about the picture of the lot that you see in the neighborhood view after shrinking and before editing the lot? If so, are you just expanding on our previous discussion about this view, or are you stating that there is a problem which needs to be resolved?

I also wanted to say that this is excellent testing feedback. Except for my one confusion above, it was very easy for me to tell what you had tested and the results of the tests, and how things had changed from previous test versions.

The original smoothing algorithm (LA 0.1.3) was to create a straight line slope between major vertices for the entire 3DArray Instance 1 table (Depth X Width X Height), as well as the entire 2DArray Instance 0x3B76 (Height X Width). This was too aggressive.

The new smoothing algorithm (LA 0.1.5) is to create a straight line slope between major vertices for 3DArray Instance 1 Depth = 0 only (terrain), as well as the entire 2DArray Instance 0x3B76 (water).

It's possible that we still need to refine where the smoothing occurs. There may be other layers (Depth) of the 3DArray Instance 1 which require smoothing. My lack of knowledge about what is stored in each layer of the 3DArray Instance 1 means that the logic may not be agressive enough. As well, there may be other record types or other 3DArray instances which require smoothing.

Am I reading this right? Are you smoothing between major vertices *all over the lot*? If so I think that's a huge mistake - only the edges where the lot meets the neighborhood terrain want smoothing, otherwise you will ruin people's landscaping. I don't think you should touch a single vertex anywhere else, apart from the road area where that option has been selected.

No, this is an "edge smoothing" algorithm, which means that it is only smoothing the edges of the lot. To be precise: smooth all width for height = 0, all width for height = lot size, all height for width = 0, all height for width = lot size. Sorry for the confusion.

When I implement the neighborhood terrain (in progress), it will also be an "edge only" feature.

I haven't yet decided on the road levelling algorithm, although it will clearly need to affect more than just the front edge of the road.

Argh!!!!!!! I was really struggling with that, but now I see when you say "height" you just mean the other dimension from "width". Another terminology clash - as we're dealing with a three-dimensional lot I was reserving height for - well what height usually means.

When I am just translating the source code, I'm afraid that I tend to use the current LA source code terminology, since it's staring me in the face.

Unfortunately, it would be too hard for me to use the terms "height" (above terrain), "width" (frontage) and "depth" (measurement from front to back) as we are using them in the LA UI, since those terms require additional translation based on the U11 value and those terms conflict with the current source code terminology. I would find it too confusing and would therefore make errors, which would just add to the general confusion.

However, I could easily change to using the more obvious ? x Rows x Columns terminology, if you would prefer. "Rows" is the outer 2D loop as well as the middle 3D loop; "Columns" is the inner loop. What's the term for the outer 3D loop? I tend to think "Depth", but then we run into the same confusion as above. "Layers" is the only other term that comes to mind.

Of course, I could always use the standard C notation: i x j x k, but I suspect that would be even more confusing to the average simmer.

If you have a different way to refer to a 3D array, let me know and I'll try.

I honestly want to be understood and I will attempt to make any adjustments to my terminology that will help.

width, height, depth--x axis, z axis and y axis respectively?

Mootilda you don't need to change anything. I have learned how you use the terms now so will be primed to understand them in future Will you use "depth" to mean height as in "towards the sky"?

Not a bad idea. However, I think that I'm still confused about whether x refers to the inner loop, or the source code "width", or whether people expect it to refer to frontage of the lot? It should be relatively easy for me to translate the source code in one of the following ways:
1) x = inner loop, y = middle loop, z = outer loop (but what does this mean when there's no loop?)
2) x = width, y = height, z = depth, where width, height, and depth have the source code definition and are determined by the U11 value (note that this is NOT the same as #1).

It's much harder for me to translate:
3) x = frontage, y = front to back, z = height above terrain

Are people content with me using X, Y, and Z to define three arbitrary dimensions?

In general, the source code uses depth to mean "the outer loop" or "the 3rd dimension".

Trouble is, the game uses Z to mean the axis that points from the ground to the sky. Not sure how that started but SimPE uses it that way and I have always heard it said the game uses it that way, which is unusual. So we have tended to use it that way when we're talking about things to do with the game.

lo!. I wasn't suggesting you make the change--so sorry for that!--but if you want to use those go ahead. They are very standard, yes? I was just asking if I had the correct definitions down as you are using them for the width, depth and height.

And yes, to me width = x axis = along front of lot.