I cheated. I asked a friend.

When I knew that you couldn't install .NET 2.0, I asked a friend who knows more about Vista. He said that there was a special version for Vista 64bit and searched google for:
.net runtime 64 bit vista site:microsoft.com

Not completely intuitive.

I have no idea what that means... ? Oh, I see... you searched again and got lots of results. I thought that you meant that you ran the LotExpander and got lots of results... silly me!

Yes, it looks like google's search engine is significantly better than microsoft's search engine on their own site. Pretty sad, really.

Plasticbox, I've been playing your row house again, this time as the centre lot of three, to see how they mesh. Only change I notice is that the streetlamp for the centre lot vanishes.

No crashes thus far, after several days' play with a couple in the house, and up to four visitors at once.

Also, the taxi in the moving-in video parks in the front yard, but I've been noticing that on other lots too. The portals are right, so I don't know how that could be fixed.

I reckon 7 or 8 tiles would be about the perfect width for a single row house - these are just a bit narrow to see what is happening on the ground floor. (In case the marvellous Mootilda is going to enable non-standard widths sometime.)

Remember, our tests have shown that the portal display location is not necessarily the same as the portal function location. Perhaps there is still a problem with the portals, even thought they look OK. Try picking up the portals and then putting them down again in the same (correct) place. If this fixes things, then we know that there was a problem with them.

No, no change. I put the markers back again, and moved sims in and out of all three of the rowhouse lots. Each video placed the taxi in the yard, although the portals function correctly while playing. Didn't Niol say something here once, about the video graphics not using the same info as the real portals?

In that process, I moved a sim briefly into one of my own shrunken lots, where the video taxi did keep to the road.

More possible glitches from Plasticbox's lot - the bed pillows go funny colours when sleeping sims turn over, and the newspaper goes lurid green when they are reading it. I've seen the pillow thing before, in pre-shrinking days, so that might have nothing to do with the lot or the shrinking. The newspaper I haven't noticed previously.

I'd really like rowhouses to be just one to a lot - it would save a lot of fuss. However, having them right to the edges of the lot is grand, and much more realistic with the increased view of the neighbours.

If I remember correctly, changing the XOBJ works for the vehicle portals, but the pedestrian portals also need their location changed in the OBJT. I changed the LotExpander to change both, just in case. My belief is that moving the flamingo moves both locations.

[lot templates]

I've done a pilot experiment on switching the lot templates.
I've modified a 50x60 lot template into a 10x60 lot template and then replace the default 30x30 lot template with the modded.
Note I didn't alter the portal xobj and so their positional infos remain unchanged.

Then, I went into an exp. neighbourhood and make 3x2 lot. The biggest "obvious" mess-up I see is the portal.
Some are missing.
So, it looks good!


[neighbourhood - terrain & +roads][Rotations: all 3]


PS:
I just realised that moving a lot to yet another location of the neighbourhood affects the neighbourhood terrain quite differently from adding a lot from the lot bin.

Lots from the lot bins can be added to twisting neighbourhood terrain easier while reshaping the neighbourhood terrain at the same time. Lots by lot-moving can't even be added the twisted neighbourhood terrain.

Has that to do with the z-value?


[roads & portals]



The move-in cinematic camera appears to be parallel to the mailbox direction, and that's why I thought the mailbox were related to the portals. But then in further tests, the mailbox is actually the first spot for entering sims to pass by.

Probably, the move-in action only add the sims right in the lot rather than through the portals, so the first place becomes the mailbox, and so its direction only affects the move-in cinematic view. That is just a guess but I don't care about it as much to prove further on this.


[Lots (non-10x)]

but currently, there's no way to convince the neighbourhood file to accept 0.5 as a value in the plugin view or use singles 0.5 in the hex view.

I assume it's gonna take too much an effort to archive that and we can't afford such effort. But, we may add this to a wish list for the TS3 .

Sounds like if I move the mailbox back to the edge of the road, the move-in movie will be right - plasticbox has the mailboxes up against the house. I'll give it a go.

The bushes in the front yard are not accessible (there's a low fence), so sims won't trim them.

I've played the house through about ten days now, moving in and out included, without any crashing. The glitches reported are pretty minor, really.

EDIT - yes, putting the mailbox back at the roadside did fix the move-in video. I only moved one of the two. (is one of them dominant, or are they just the same? In which case, it wouldn't matter which was moved.)

So, an odd movie is the price we pay for having the mailbox somewhere other than beside the footpath. Easy to either fix or ignore.

I tested my dipped-road lot with family life. The one with the gentle slope not the one with the gashed trough.

Pedestrians - no problem
Service vehicles - pizza had a problem until I moved the service-start portal so that there was one more square of flat land behind the car. After that services were working fine.
Car/bus/taxi were operational, but always stayed the full hour. It seemed they had to rely on being vaped rather than driving away. I suspect further fiddling with the portal positions could have solved that too.

My position on this is that some things don't work *the same* with a sloped road, but they still work, and some players may wish to sacrifice realism of vehicle animation for aesthetics of landscaping. So I partly disagree with Aelflaed.

On a slightly different topic, I have changed my mind from when I said I didn't think the nhood terrain got reshaped when the lots were placed or reshaped. I now think it does at every 10th lot vertex, I think even the changes you see when bulldozing are only a sort of levelling out happening, rather than the land being restored to original heights. I think there is a clue here as to why lots that are not multiples of 10 would have graphical problems - my current theory is that blue gashes are only prevented by ensuring a lot is smoothly graduated along its edge between each 10th point - and it's each 10th point that is "stitched" to the terrain. If you had an edge with no stitched points along it, I feel you might see a rough edge.

And on a finally different topic, I now have NO idea what the reference point for height is. I had thought it was center front, but the experiment designed to prove that - the trough-shaped lot - didn't. I had expected the wings of the trough to be raised while the lower part lined up with the existing road, but it didn't do that, it lowered the road instead. I may do some further experiments with making the trough occupy the extreme left or extreme right to see if the reference point is for a corner.

[roads & portals]

The grocery or the pizza delivers have to go to the vehicles backs to gather the accessory objects, grocery basket and pizza box here.

so, a plain grid of the same height for the back of the vehicles is necessary.

After all, this proves that certain parts of the road can be uneven.
yet, we have to check out all the sizes of all vehicles to know the limits for working uneven roads.

But you know this could probably be overcome by some code hacking. There is a routing syntax that says whether to allow different levels between sim and object or not. It could be simply a case of allowing the pizza man to be standing at any level performing the animation.

Inge,

now, I see why you said that... so, you feel like to try that out?


PS:
Shall we solve how walls are built at the level of lot-modding, upper-level-based bridge can be made plain for the portals while connecting the edges of the road in a given lot. The road remains uneven.

Or, one even move the portals in the plain buildable area for a "TS2-natural" illusion. :D

Lol!!! I just lost a lot! I was trying to lower it all over then shrinking on every edge. Now it's under the ground and I can't click on it at all, so I can't even get it into the bin - bah!

Inge,
lol, calm down...
just simpe-open the neighbourhood package file, and browse to the lot description.
Then, recover the z value of the lost lot.

If you don't know it, just check a nearby one, or even copy it to the lost lot. commit and save, and reload the game.

Surely, you may wanna check if U10 and U11 are matching by the way.

That rather defeats the object though, I wanted to see if it would take the road down with it after I placed it again from the bin. Still, I think I can guess it would have.

I am currently desperately trying to find a rule about how the game decides whether to level the road up to match the highest point when you place a flat lot, or down to the lowest point, or whether it always matches the level the road is at on a certain point of the lot. For the life of me it looks just random, and I have tried it hundreds of times now on hilly ground. I know computers don't do things at just random and there must be a pattern to observe if only I could spot it!

All you need to do this test is a flat lot that is already saved and put in the bin, and some hilly terrain. See if you can predict whether the road will flatten to its highest, lowest, or mid point each time you place the lot.

Sure, if people want to fiddle they can have sloped roads. But the point of LotExpander for many people is that it allows us to alter lot sizes to our desire, without having to understand how to modify things - the lowest common denominator. Maybe this is another thing to be put into Advanced Features, while the general everybodies get a flat road - for simplicity's sake, and the best chance of a functional, easy-use lot.

In other news, I've successfully rotated a 1x1 built lot, putting the road to one side rather than to the opposite end of the block.

The end result has only one tile of locked space on the left edge (probably wouldn't let me rebuild there though, if I deleted the walls that I started with). Two tiles as usual on the other sides. Having turned the house, I could now add another strip of building at the new front.

I deleted the old road tiles before shrinking the lot - don't know if this was necessary, but Mootilda said "nothing on the tiles to be deleted", so I figured I had better. The lot played fine, went in and out of the catalogue fine and played again. I have pictures.

There is a balcony on the house - all the posts disappeared, as Plasticbox reported with the row house. Easily fixed by replacing the fence, as the balcony is in the buildable area. Something to mention under 'issues' perhaps.

Since the lot didn't crash, there's nothing else to report.

Cool... :D
As for the partitions's buildability,

1. fences can be built basically anywhere in a lot.
2. Season-Greenhouse fence can be built on up to the last second lining to the lot edges. Shadowing can be disabled. They can be set to support upper levels.
3. Half-walls consists of both the "fence" part and the "wall" part, and so it follows the limitations on both.
4. Fence-arch can be built on up to the last second lining to the lot edges. A grid far is reserved when it meets walls. It can also overlap fences and greenhouse fences. The only default has no diagonal mesh and so it's disabled to work diagonally. Surely, custom ones can have diagonal meshes and diagonal buildability.

You mean: you put three lots next to each other, this one in the middle, and when you enter the lot the streetlight in front has .. disappeared? As in, poof?

That would be very very odd .. You mean this street light here, yes?:



This is the lot I playtested. I'll check this out next time I can play(test) .. this would definitely be something to keep in mind when building lots.


About the mailbox: the second box is from frillen's collection (229 ingame objects) here on mts2 -- it's 100% a maxis mailbox, not a deco object --; yes the paperboys and mailmen always pick one to use, the other one/s are purely decorative as far as the game is concerned (I often put more than one mailbox on multi-household lots). Thanks for the tip about the in-game movies, I never watch them so I didn't know that. I'll add a note next time I upload somehting.

(I move the boxes around because that's more realistic to me -- the only time I've seen mailboxes on the curbside was in a U.S. suburb. And in the countryside, where they're often on the next street corner, nowhere near your actual house. My actual mailbox is downstairs in the hallway, *not* on the street. Same goes for trash cans .. it's not even allowed to put your stinking trashcans on the sidewalk, here. They belong in the backyard where they belong.)



This is somehting else I think, not my lot -- I seem to recall this bug got reported quite often after some EP came out. Might be a NL bug? And now with the BGS we get to enjoy those old bugs all over again? I did not see this, in any case, and my testers were reading the paper quite a bit. (Is your NL game patched?)


Also, thanks for the reminder about the bushes (untrimmable when behind a low fence) .. I keep forgetting that.

We're not even allowed trashcans, we have to use plastic bags, which we have to leave on the sidewalk.

Anyway, here is a patch so that your pizza dude can get his pizza out no matter where the portal is on a slope

Well, I believe that I now know the answer. It came to me last night. No idea why I didn't think of this before...

When a lot is placed into the neighborhood, the neighborhood package is updated with the Top, Left, and Z-value of the lot. The Z-value is the height value of every point in the lot file which has a relative height value of zero. So, the heights stored in the lot terrain array are all relative to 0 (or Z in the neighborhood), and the game adjusts the Z-value of the lot in the neighborhood file as whenever the lot is placed or moved.

What does this mean?

Well, I would guess that a brand new lot always has the road at height 0. However, when you use the terrain-modification tools in the lot view, you can change the height of the road, etc. When you place a lot with a funny road into a neighborhood, the game goes through its calculations to try to place the lot "appropriately".

This explains why your dip in the lot road creates a dip in the neighborhood road. You took a piece of the road which was normally at relative height 0 and changed it to relative height -x (negative some value).

It might be interesting for me to try flattening the road to relative height 0, and then try again with relative height -10 and see how this affects the placement of the lot.

Sorry about being away yesterday. I'm trying to catch up now.


I believe that this is far too dangerous. Anything that requires some special data (ie, the entire lot) to be stored somewhere safe between two consecutive runs of the LotExpander is probably a bad idea.

I have been considering something very similar, but less dangerous. The LotExpander could allow the user to supply a second lot which the LE would use as a template to get the new edge vertices for the lot being expanded / shrunken. This would obviously be an advanced feature and would require the user to have the knowledge of how to create such a secondary lot (backup, delete the original lot, place the new lot in the correct location, modify and save the lot to generate the terrain array, move the new lot away somewhere safe, restore from backup).

The advantage to this method over your suggestion is that the user knows their system and will be less likely to accidently delete the real lot.

However, I am still hopeful for getting each 10th vertex from the neighborhood array and then coming up with some formula (probably not a straight line) to mimic EA's unknown smoothing formula.

So, until I have exhausted all research into using the neighborhood terrain, this idea will remain on the back burner.

That makes sense! (Heh - you already posted again before I sent this, so I have to explain I was talking about your definition of the Z value for the lot) However that leads to another question: when the nhood terrain is already sloping before you try to place your lot, how does the game decide which vertex of the terrain will form the baseline height for your lot's zero height offsets? I don't think this knowledge is important to the LE, but guessing in advance what effect placing a lot could have one your terrain landscaping could save some frustration, as there is no "undo" once you've the reshaping has happened.

I had an idea for an algorithm for shrinking a lot at the road edge, though I don't know how possible this is. With the new front edge, work out which vertex is nearest to 0 height offset. If its height offset is -20, then add 20 to all vertices on the entire lot - but this is only valid if you know how to also raise the height of all the other objects and walls. Or would adding 20 to the Z value for the lot work? Then if the user has asked for road flattening, just set all the front 10 rows to 0 height offset.

I believe that this is unnecessary. For the average user, flattening the road and moving the portals (X, Y, and Z) is appropriate. For the advanced user, the user knows what they want and the LE should avoid doing anything to compromise that... ie, no flattening and no moving of portals, mailboxes, etc.

A straight line is better than a blue gash, to start off with, while you come up with a curve formula. I wonder if the curved smoothing of the terrain is handled by a runtime display formula rather than height measurements stored in files?

Edge stitching/smoothing needs to be optional, just like the road flattening. In some circumstances when I shrink a lot in order to place it elsewhere, it's important that the remaining area is exactly the shape I chose for it - the surrounding terrain then moulds to it.

I believe that the game has an algorithm that it uses to allow placement of the lot, based on the resulting angles between the neighborhood vertices.

If I were coding this algorithm, I might allow the game to choose between various Z-values at every location, and then see whether the angles are OK for any of them. In general, I assume that the game prefers to place a lot with both edges of the road at 0, but that's obviously not always possible.

Since the LE doesn't really need to know the answer, I'll leave research into the actual EA algorithm to others...

Yes, this is my original option #2:

http://www.modthesims2.com/showthread.php?p=1798684

If changing the neighborhood Z value is inadequate, then I believe that this option is probably not feasible, at least in the short term: lots of coding and lots of possibility of error.

[Update:]
Oh, there was one other thing that I wanted to get down, before I forget. Once we understand the roads better, it should be a fairly simple matter to allow the user to specify two Z values for the two edges of the road... providing the ability to have truly sloped roads. Note that this is just a thought that I wanted to get down, for future reference. I haven't thought this through.

Yes, it's too bad that you deleted the lot... it might have been informative to examine the lot, to try to determine what went wrong.

Random crashes while playing a shrunken lot are going to be very difficult to debug. It's much easier for me to try to solve problems like the missing fence posts.

I wonder whether it would be useful to suggest putting shrunken lots into the lot catalog? My impression is that this can help to point out corrupted lots, which could be a useful thing.