Aelflaed, I think what you describe is an inevitable result of shrinking a lot, until such time as Mootilda manages to incorporate terrain geometry. What happens if you move the lot to another place in the hood? I think the game should make an attempt to marry the lot to the terrain when you do that.

If not, it means there must be a "height above terrain" value on each vertex - which would be incredibly useful to the lot expander, as they would merely need to be set to 0 at all edge vertices during expansion and shrinking, with no fetching values from the terrain required. :D

[Lots (non-10x)] & [Lots > maxi.size]

This is about the lot 65x65 for other specs while keeping the world database file set as 63 and 63 for stability. The lot is still played as a 64x64 lot.
65x65as64x64.jpg


[Row-houses]

I 've expanded a copy of a10x20 lot I made to 30x40 with LE1276, then I built a 10x8 double-levelled row house in clockwise direction for the walls.
After the shrinking with 1277 with trimming all sides by 10 tiles, I got this for the first entry to the lot and save successfully.


10x20to30x40to10x20.jpg
10x20to30x40to10x20-2.jpg

But strange, the house is on road rather than back, the portals and the mailbox and the garbage can are inside the house properly placed...

I've also made 4 30x40 plain lots with the same house specs for each direction. So far, they all show up well as the same except the lot direction and hence the light and shadow directions. (30x40to10x20-LightFromBottomLeft-2.jpg)


[neighbourhood modding - terrain & +roads]

Lol, to get a plain lot, may use known plain huge (50x50, 60x60) lots to flatten the neighbourhood terrain first before lot expansion or shrinking. lol, sorry to sell my tutorial here, but this ensures the whole testing region is plain before trial.

You can turn the house into a toll station

[LA/LE - UI & versions tests]


true :D, the new 4 from 30x40 are just fine...


Thanks Mootilda..., the LE is working brilliantly for at least these simple tasks...
Now, guess when the row houses will bloom...


[neighbourhood modding - terrain & +roads]


The attached is a leveller I 've used. it's 30x60. I made it from levelling retangular buildable zones of a neighbourhood with small plain lots like 30x30, 20x30, etc.

Moving the lot around distorted the road in new places - the old spot reverted to flat road, except for the last shift, when I put the lot into the catalogue - that piece of road remained distorted. Neighbourhood vehicles followed the distortion. Inside the lot looked flat, except for the big drop at the edge.

I'm thinking my rotated mini lots are rather redundant (already), since anyone can easily get whatever orientation they like, and size they like, with Mootilda's fabulous new LotExpander. Oh well - I couldn't be sure the program would progress so far as quickly as this, and I have at least learnt something.

sounds like a mishap between U10 and U11m too, :D...
A pic may tell more...

Do you mean me? I can post a pic of the lot if wanted.

This sort of thing?

Pretty much, but without the fish.

wow...

I've gone wild with it yet... gonna try :D

aelflaed,
yes... but Inge got it, too

OK, I've read through everyone's posts and am digesting the information. So anything that I say here is very tentative... feedback is very welcome, but I could easily be wrong.

First, let me say that this could be a bug in my code... I wrote a lot of code for this change and these are the first tests of that code. So, the first step is for me to check over the code and see whether I see anything that looks wrong.

However, since the problem only seems to occur at the edges of the lot, it's less likely to be my code, since I'm not doing anything special at the edges of the lot. All that I am doing is deleting elements from the various arrays.

I think that I've mentioned this before, but my guess is that one location in the 3D Array contains the "base" terrain value; perhaps that value is being deleted in the process of shrinking the lot. This would mean that some arbitrary value is being used in the game when it determines the actual Z-value (height) of the lot in the neighborhood.

Why do I believe that such a value exists? Because neighborhood Z-values are absolute, based on a zero value which is deep underground. But, lot Z-values tend to be zero, which implies that they are relative to some "base" value. That "base" value would reasonably be stored in the lot and would be used by the game to determine the absolute height of the lot in the neighborhood.

The purpose of this difference between absolute and relative values is to allow the game to easily move a lot within a neighborhood, even when there is a large height difference between the old and new positions of the lot in the neighborhood. I can explain this concept more fully if anyone is interested.

I have two guesses as to where that "base" terrain value is stored: x=0, y=0 in the array (which is on one corner of the lot, depending upon the U11 value), or some specific point at the front of the house (left-yard corner, right-yard corner, midpoint, at the mailbox, ...), which is a specific x and y value in the array, based on U11.

If my guess is correct, then we might be able to determine which value is being used based on the behavior of various lots with different U11 values. For example, someone mentioned that shrinking at the road tends to have more problems than shrinking in other places. Is there any place on the original (non-shrunken) terrain which has that higher or lower lot value? If so, is it always in the same place, or is it dependent upon the U11 rotation of the lot?

Finally, I can easily set the values all around the edge to zero, but I doubt that this is what we want. The result, if I understand the terrain array correctly, would be to create a "box" of terrain at a specific height around the entire lot. Disastrous for hilly terrain and beach lots.

A more reasonable approach is to try to determine where the "base" value is stored and ensure that the value is set to something "reasonable".

In case people haven't figured it out yet, I put quotes around words that are undefined in my own mind... I have no idea what a "reasonable" value would actually be.

Well, that's all that I can think of for now. Let me look over the posts again, check out the array-handling code and let my brain mull over the problem for a while.

Any and all input is appreciated. Oh, and pictures can be really handy, so please attach pictures of problem lots.

Igne, would it be possible for you to explain this more fully? I'm not quite sure that I understand how changes to the lot terrain affect the underlying neighborhood terrain.

I already noticed that portals on uneven ground don't work, which is why I implemented the small terrain fix at the same time as the portal changes. Looks like I need to do more to ensure that the portals work correctly.

I believe that there are two reasonable approaches to this issue: flatten the land where the portals are, or move the portals to flatter land. Perhaps even a combination of the two.

Then again, I could just let people use the flamingo to fix their portals, if there are problems after expanding or shrinking a lot. I'm going to need to re-do the tutorial anyway.

Just remember, I do this for a living. Some large part of being a developer is being able to find and fix bugs. A good developer needs to be a good tester. And, of course, testing is a profession in itself. The best testers spend a large amount of time trying to figure out how to break the code.

I'm very willing to do the "grunt" testing (ie, testing shrinking in every direction for every U11) and leave you all to do the "creative" testing. We are all different enough that I think that playing with the things that we are interested in should provide some good test cases.

Perhaps I need to ensure that the portal Start / Stop pairs are always offset from center. This should already be true with the new portal logic for all lots except 1-wide lots.

Your test also seems to indicate that the "base" terrain value is at the front of the lot (ie, the side with the road). Do you tend to have more problems on the left or right side, or are they about even?

That's my point really, I don't think they do, other than when you first place the lot. What happens during placement seems to be controlled by this part of neighborhood.ini



Which confusingly contradicts itself by saying if it's less than that it does, and if it's less than that it doesn't - grrrr!

But once you have laid the lot, if you expand it, it doesn't change the underlying terrain, and if you sculpt it (using the level or water tool) it doesn't affect the underlying terrain. And if you shrink it back thinking you have now got rid of the unwanted height differences in the terrain... well you haven't I think all that happens is the faces of the terrain are simply hidden graphically when there is a lot over them.

Now I come to think of it, my suggestion about maybe there is a height-above-terrain value stored on each vertex of the lot was a stupid one. That's can't be right or lots would deform bizarrely all over whenever they were moved to a non-level area, and they don't!

There can't be an absolute height value either, or else they would float when you move them to a lower place.

My next suggestion is that the z-values actually refer to height relative to the road the lot is attached to. The fact the road is always completely flattened by the game when you place a lot would appear to support that idea - as if the game needs to know exactly where it stands in relation to the absolute height of the road at least !

I keep wishing that there were a "magic" value, like 0, that would tell the game to adjust the lot terrain (edges) to match the neighborhood, rather than its usual behavior of matching the neighborhood terrain to the lot. However, I have yet to see any actual evidence of such a value.

Too bad... it really would be nicer if that were the default for lot edges. Why else did EA/Maxis leave a two-tile unbuildable space at the edge of all lots?

I believe (please correct me if I'm wrong... niol?) that a real lot template accomplishes this by having no terrain array, which allows the lot to take its terrain directly from the neighborhood. If I'm right, then this is obviously not feasible for existing lots.

I assume that this occurred because your house was originally built too close to the road for the lot to be shrunk at the front. Am I correct?

I suppose that the more reasonable test is to build the house before expanding. If you expand on all sides, then shrink on all sides, the house should remain in it's original position.

Yes, this is certainly an alternative which could resolve some of the terrain issues. However, I'd prefer not to require pre-processing of the neighborhood terrain before expanding and shrinking lots, if at all possible.

Inge, can you explain the steps which resulted in this picture? Have you got a picture of the original lot, before using the LE?

Lol! Don't panic that is simply another view of an old lot I showed you a while ago, when you were only taking the heights from two points

But I am still getting strange road dips. I shall have to think carefully before I can identify when it happens, though let me reassure you I have had similar without using the Lot Expander. It's largely because of my bizarre configuration in conjunction with some very bizarrely sloped lots. Would it be more useful to you if I tested using default settings? I am not sure you can be expected to write a tool that copes with every possible user experiment!

It's pretty clear what they meant to say, though... the terrain is adjusted if the angle is larger than the one specified in the .ini, and the terrain is left alone if the angle is smaller than the one specified.

Figures that EA/Maxis wouldn't actually check these things for accuracy... They really seem to be trying to do too much in too short a time. I wish that they could slow down, but I know a lot of people are always eager for the newest EP / SP. And, of course, EA is always in need of new money.

OK, I think I understand now. This certainly seems like a reasonable explanation.

However, I was under the impression that moving a lot would also deform the neighborhood terrain. Since the standard procedure is to move the expanded / shrunk lot, doesn't this convince the game to adjust the neighborhood terrain to match the lot terrain, thus removing the odd blue disconnects?

Perhaps the game requires the lot terrain at the edge of a lot to conform to a specific mathematical function? Until we started expanding and shrinking lots, the game could guarantee that all lots would conform, since it created the lot edges itself. If I am correct, the LotExpander suffers because it breaks this requirement, especially noticable on hilly terrain.

This implies that we might want to change the LotExpander to ensure that all lots conform to this "edge function". Since we don't actually know what the function is, we'd just have to fool around until we come up with something which is "close enough".

However, this could break the townhouses unless the terrain is already completely flat. Hmmm... obviously need to think about this some more. Perhaps the LotExpander should usually attempt to smooth the terrain, and provide an advanced feature which turns off this smoothing?

Actually, I believe that there is a (relative) height-above-terrain value stored for each vertex of the lot. If the base value (the value that everything else is relative to) is stored at some location in the array, then the terrain heights within the lot would remain constant with respect to all other areas of the lot.

Can you explain why you think that this would deform the lot when it is moved?

Yes, I agree. As far as I can tell, the terrain heights stored are relative values... we just need to determine "relative to what"? If we can determine where the base value is, then I think that we are on our way to solving this.

Are you sure that the road is always completely flat? I know that you've said this before, but I never realized the implications before.

If so, then I agree that the entire road surface could be the base value for the lot. This would explain:

- Why buildings cannot be built within two lot tiles of the sidewalk.
- Why the problems are only occuring for lots shrunken at the front.
- Why the new terrain logic works better than the old terrain logic.
- Why portals behave so badly on non-level terrain.

It would also point to a defect in the LotExpander code - Neither Andi nor I have made any effort to keep the road level across the entire front of the lot.

OK, this looks like a very fruitful area for research. I think that I should modify the LE to keep the road surface level for all expanded and shrunken lots.

The next question is, where do I get the height value for the road? Here are some possibilities:

1) Use the height value for the existing road. Problem: if a lot slopes down quickly from the existing road, then it will slope even more if we remove the land between the old road and the new one.

2) Use the height value from a specific point along the (new) front of the lot. Probably the mid-point of the new front of the lot would be the most reasonable value. Problem: this would move the terrain for the entire lot up or down from it's original height. This could prove disastrous for beach lots, which (I assume) require a specific height at the back of the lot.

3) An advanced feature which allows the user to choose which method they prefer?

Completely off topic:

Has anyone else noticed that EA/Maxis really mucked up with the Twikkii Island terrain? There's a huge beach area that won't accept beach lots because slope of the water isn't quite right!

Well... this was a very interesting conversation. Let me fool around a bit and see what I can come up with...

Phew!

While I agree that the LotExpander can't be expected to deal with every situation, I believe that testing with extreme situations can help us to understand what the limits are and why they exist. As well, it can be very fruitful for providing information which leads to a full or partial solution to various problems.

In order words, please continue testing as you have been. I may not be able to solve all of your problems, but your tests have been helpful.

Possibly/probably - I would have to verify this. But remember, I particularly wanted the LE *not* to insist on me moving the lot after expansion, because one of uses for it would to expand a short lot backwards into the sea. If I had to move the lot after doing that, the terrain would not accept me putting it down again in the same place.
BTW the "blue disconnects" are sky showing through the cracks. The Sims have a flat earth 


Well, the game hasn't had its hands on the process until or unless the lot is moved elsewhere, so it never had the chance to stitch the lot edge to the terrain. I don't think the game "requires" it so much as actually *does* this for us. The game changes the hood terrain at that time. I don't see how the LE can possibly be expected to do this for us, but maybe the other way round (change the lot edges to fit the terrain) will be possible in time.
To sum up, it seems to me that the game moulds new virgin lots to the terrain, but moulds the terrain to an already-played lot, at the time of placement. It's outside the scope of the LE to do this surely.


If the player wanted a smooth lot they would probably have made it smooth to begin with, and the problem would not arise. If they had a rough lot they would probably be dismayed to find it smoothed. This doesn't seem an intuitive solution.


I will use a very simple illustration. Suppose you had a lot you made on land that had an 8-click deep hollow in the middle of it, and used the levelling tool to level the lot? That would set the height of bit you raised to "terrain + 8 units". Then you moved the lot to an area with an 8-click high hill where the middle of the lot would be. The lot vertices marked "terrain + 8 units would now form a hill 16 clicks high instead of the lot being flat like it was in its old location. A bit disastrous if it already had a house on it. 



Pretty sure. It's been annoying me as it's the main cause of the donkey-leg hills between lots. I feel convinced that in the original pre-EP game you could build a lot on a sloped road, but I could be wrong.




Doing so would not help the breaks in the roads (as per previous attached images), as the expanded road would overlap the terrain road without bringing that road up to meet it. Roads can and do slope between lots, they just get flattened in the area you place the lot. Again this would be addressed perfectly if you can read and apply the hood terrain to the lot - don't bother to create the new section of road, let the player fill it in with floor tiles and shape it to blend with the original road. You can still use the original length of road as your height reference point, hopefully.





I am not sure there is anything the LE can and should do about this. People deleting parts of a steep slope are going to be left with a crevasse. That's just physics



And possibly for lots with specially shaped houses, dummy levels, foundations, landscaping etc

[LA/LE - UI & versions tests] & [Row-houses]



I'm sorry about this. The time I typed this was when I had "memory-leak" probably due to my over-excitement on the row houses I made... that Iforgot I built the house right at the border of the road and so it's reasonably on the road now after shrinking all sides... That's just my mistake, and so LE didn't make a mistake there but me. :red face:


[lot-neighbourhood terrain sync.]



Lol, this we have to build some hotel lots in BV to test out. Why?
The hotel lot templates are some used and built lots with lots of crappy data like 3D arrays, 2D arrays, all that a normal built user lot has. They're "not typical" templates. That's why I worry when it comes to hotel lots... Just imagine if the game engine copies and merges the data from these templates to the newly made lots... Hopefully, that's not the case.


lol from my view point at the time I first read it in the past, it means the numeric values "do not get modified" while the "graphical smoothing" will fix the graphical positions. Surely, that can be wrong, and more interpretations are welcome.



Yet, removal the fixating levellor lots can cause a roll-back of the terrain twisting for some regions but not all... This I think one has to play around with it more especially in N001 neighbourhood with various vertex angles. There seem some smoothening functions that blurs the whole scene. So, there is not a completely absolute change always, and that's why you see i was talking about using some lots to fixate the neighbourhood terrain of the planned plain.

Lol, may use a modified camera script to access those defaultly unreachable regions. I'll attach my own modified version just for those who are curious about what I see in a neighbourhood when the MTS2 allows it. :D

Can't remember all the camera mods... There're a few more, but i just recall them, so google or TS2wiki them.


More options to check can always increase the functionalities of a tool, please do... Thanks..


Actually, that's the last lot row along the lot edges including the all the linings and their areas. Diagonal walls can be built on the last second lot rows.


true... for every newly made lot without a visit ans save, the lot package file is null. so, you want the new virgin lot activated by the LE? :D


Lol, but making it as an advanced option to check if one wants it (as Mootilda suggested) doesn't conflict with the assumptions. BTW, some users may wanna do this on built lots either by themselves or someone else. And this can open up some more possibilities.


[roads & portals]


Portals are just like many objects that they need plain terrain to function.


[beach lots]


Can there be 2 specific heights for beach lots?

Lol, I find your OT is really interesting and may be relevant somehow! :D

If you could do that, that would be very useful I think. The game normally forces the road to be flat -- e.g. if you put an empty lot template on a road that goes uphill --, because non-flat roads simply don't work .. whenever people have tried to deform the roads (within the lot i mean, with the terrain leveling tools), the portals broke and it was all a huge big mess.


In other developments, I could use some playtesting assistance: I built a nice little row house, and while everything else seems to work (portals and stuff), my game crashed with the infamous "The application has crashed" error the first day around at 19:00 (7PM). This might have something to do with the night setting in (I can't think of anything else that's scheduled to happen at 19:00) -- the game being unable to render shadows or something.

On the first try (when it crashed), I had visible neighbours on and shadows set to High. On my second try, I turned neighbours and shadows off: no crash this time, and when I turned the neighbours back on it didn't crash either.

This is with Base+NL, in the "Mini Game" hood that's provided by the Base Game Starter, my testers were the Randoms, I had no hacks installed and no CC apart from frillen's invisible driveway. None of the sims was doing anything out of the ordinary at the time of the crash (I think they were watching TV or reading), and nobody except the two residents was present on the lot.

ETA: Lot is attached + some screenshots. Requires NL; no CC except the aforementioned driveway (included).

Edit: Download removed -- reposted in the Backdoor Lane 42 thread. Please put all further feedback (gameplay issues) there, not here.

I have been experimenting with lots that have been nowhere near LE just to see what happens to roads when you place lots.

I placed a virgin lot, and using constrainfloorelevation and locktiles cheats, I made a huge dip in it that included part of the road. (The road had started out totally horizontal).

I moved and bulldozed the lot several times, and the dip in the road remained each time. However the rest of the space the lot had been on reverted to roughly the level the terrain had been before the lot was ever on it - adjusted slightly to meet up with the road dip.

Putting a virgin lot onto the dipped portion of the road or in fact anywhere within a few tiles of it caused the dip to straighten out, and stay straightened after the new lot was removed. I am now wondering if the straight road that always happens when you place a new lot, is actually part of the lot template itself and is not actually something that "happens" at runtime when you place a lot.

I think I might be able to test this precisely by shrinking a lot after making a dip in its road, otherwise there is no way not to start and end the road at the normal level.

I laid a 5x3(4) template with the long edge along the road. I lowered the entire lot and leveled it apart from a crater in the middle which I made so I could test that remained at the right comparative height.

I shrank the lot at each side, so that the ramps leading to the normal height hood road were deleted. I put the lot in the bin and put 3 of them one side of the road and 3 the other.

The first picture actually belongs to the lot in my previous post, and it shows that if you deform the road on a lot, the real neighbourhood road gets deformed by that action. You can see vehicles following the dip.

The other pictures show the progress of me planting the sunken, shrunken lot in several almost adjacent places. I was not allowed to put them completely adjacent.