Here are the final two in that set

Are you saying that the blue disconnects always disappear if the lot is moved in the neighborhood? Does anyone have a lot which has retained the blue disconnect, even after moving the lot in the neighborhood? It's a less serious issue if the game can be convinced to resolve the disconnects (even though I understand that some people may not be able to move the lot to resolve the issue).

I apologize if I wasn't completely clear. I am only considering smoothing the 9 lot vertices between each pair of neighborhood vertices, around the very edge of the lot. This might decrease the blue disconnect without seriously impacting the lot itself.

Imagine trying to translate a neighborhood terrain into a lot terrain. You know the absolute height of the terrain at every 10th point, since you have that information from the neighborhood terrain. But, what do you do with the 9 points in between? In my brief work with the neighborhood terrain, I noticed that every 10th point around the edge of the lot was "attached" to the neighborhood, but the other 9 points "floated", which created a blue disconnect.

My thought is to try to minimize the difference between the lot edges and the (imaginary) neighborhood edges, which are defined by some unknown (to us) mathematical formula that EA/Maxis is using to extrapolate the neighborhood vertices into lot vertices. It is my belief that this will minimize the blue disconnect, especially for lots which are not moved to convince the game to resolve the issue.

Ah, I now see where the confusion lies.

You are assuming that the height-above-terrain values stored for each vertex of the lot are relative to the corresponding neighborhood vertices. This could certainly result in some very odd behavior.

I am assuming that the height-above-terrain values stored for each vertex of the lot are relative to the base height of the lot, as defined inside the lot package. Thus, the terrain of a lot is internally consistent, so matter what the underlying neighborhood terrain may look like. When a lot is moved within a neighborhood, the game correlates the base height of the lot with the corresponding height in the neighborhood via the Z-value stored in the Lot Description (LTXT) in the neighborhood package.

At this point in time, we believe that the base height of the lot is defined by the height of the road. This would explain why the lot "snaps" to the road as the neighborhood decides that it can accept the lot terrain at this point in the neighborhood:

As you move a lot within the neighborhood, the game is probably attempting to adjust the neighborhood terrain to match every 10th lot vertex around the very edge of the lot. If the angle of any slope between vertices in the neighborhood becomes greater than the one specified in the .ini file, then the game refuses to place the lot. However, if all of the angles are within the specified range, and especially if the road doesn't cause problems, then the game "snaps" the lot to the road to show that the angles are all acceptable and the lot can be placed at this location.

If people could verify this, especially with the base game and / or hilly terrain, it would really help me. I hate to flatten the road if the game doesn't require it.

I believe that this is another area where there is a conflict between the average user and the advanced user. I think that the LotExpander should default to flattening the road, but allow the advanced user to opt-out.

We are definitely pushing the limits of what the LotExpander can be expected to do. However, I still need to come up with some base value for the lot, if the LotExpander is going to flatten the roads.

Not a problem. I'm just glad that you didn't find some horrible bug in the LE!

I was also strangely excited with my first row houses. In the back of my mind, I guess that I never really expected it to work. I was just thrilled when I saw Inge's picture. Yesterday was an exciting day for all of us.

I remember you mentioning this before. It's hard to believe that EA/Maxis missed this, no matter how busy they are.

However, if the hotel templates are actually able to take on the neighborhood terrain, then we may be able to glean some information about allowing the lot edges to "float"... that would be wonderful.

Alternatively, the game may just be willing to compensate for any lots in the template directory and there may be no magic at all.

Are you thinking about testing this yourself, niol? If not, is there someone else who would like to fool around with the hotel templates?

My guess is that the game will only adjust a maximum of one (or many two) neighborhood vertex at each point around the edge of the lot. However, once a vertex has been adjusted, it remains adjusted because the game has nowhere to store the original value.

This would explain why you need to do multiple adjustments to completely flatten the land.

Ouch! This is the first problem that I've seen which may not be fixable (although your workaround seems acceptable). Remember folks, we're doing something that EA/Maxis does not allow. This may explain why. I suppose that we should all try playing our row houses through the 7pm change from day to night, to see whether everyone is having this problem.

Other than that, I don't know what to suggest. This is certainly a disappointing turn of events.

Well, it looks like I've finally caught up on this thread. So, I'm left with one major question:

Is the lot shrinking code ready for release?

In general, lot shrinking seems to be a pretty risky venture... it's easy to end up with a lot which crashes the game. Has anyone managed to play a lot to the point where they feel confident that it is not corrupted?

The issue which seems like a potential show-stopper is the crash at 7pm (and potentially at sunrise, as well). I think that this needs to be investigated. However, there may be a workaround, so I might be able to release this version with a warning about turning off shadows on any lot with a wall at the lot edge.

Other potential show-shoppers are the other miscellaneous crashes that people have seen. Has anyone managed to reproduce a crash which is definitely not related to deleting non-empty terrain? I know that the LE needs a stern warning that the user cannot shrink terrain which has anything on it. But, is that sufficient to prevent crashing?

My biggest non-crashing concern is the road not being level, which can cause the portals to fail. However, the LE has never tried to keep the road level, so it doesn't seem any worse than the existing release version. And, the portal revealer gives the user a way to resolve the issue. I certainly intend to try to resolve this issue soon, but I'm not sure that it needs to be done before the release.

"[...] it doesn't seem any worse than the existing release version"... I may have to retract that statement. When a lot is expanded, the LE currently expands the lot out from the existing terrain. This means that the new road should maintain the level of the old road. However, the lot shrinking code just uses the existing lot terrain. Therefore, the road can become much less level. Perhaps this is OK, with a warning about what will happen if the user attempts to shrink a bumpy lot at the front.

As well, there is the blue disconnect issue. Can anyone verify that these disconnects disappear if the lot is moved in the neighborhood? The final solution to this issue would be to use the neighborhood terrain. An intermediate solution may be to "smooth" the edges of the lot. But, can I release the existing code - is it "good enough"?

These are the known issues that I can remember. Is there anything that I've forgotten?

i did a test of a 1x1 lot with walls on 3 edges. No crash at 7pm, with or without shadows on. I did put the house into the lot bin, then take it out again, before moving anyone into the house... don't know whether that step might have stablized things a bit.

Has anyone else been able to repro the crash with shadows on?

[lot-neighbourhood terrain sync.]



does that implicate the followings?
1. LE store away all the data except those for the lot terrains.
2. LE then delete all data from the given lot package file.
3. users have to enter the lot, make at least a build change, save the lot and quit the game.
4. LE incorporate the saved data except the one(s) for the terrain morphic data to overwrite the lot package file without erasing the new terrain data.

Or, the LE will only keep the edgy vertice height values for the "re-born" lots while erasing the others from the "before-reborn" lot backup data?




so,
1. the N x 10 + 1 can be for the linings of a lot grid page.
2. the N x 10 - 1 can be for internal float points in-between the edge borders of a given lot.
3. the N x 10 x 4 + 1 can be just like 1. above for float data.
4. the N x 10 can be for the gird block areas.


[neighbourhood - terrain & +roads]


the attached pix show a lot I placed on a slope.
http://www.modthesims2.com/showpost...6&postcount=422


agreed...


Either way should work as long as there must be the option to choose. That little bit of user-dependent convenience doesn't matter to me.


[roads & portals]


lol, regardless of lot expansion or shrinking, the levelled road only matters the process when there is no lot relocation in the neighbourhood to regenerate or fix the road by the game.


[LA/LE - UI & versions tests]


obviously, it's much better than the previous one in my opinion.
as usual, precautions and extra instructions are necessary.



but, a possible error may be the in-lot timer gets messed up during the LE process or other processes?

It can be also the memory remains in the RAMs or system memories
you know the scene, sometimes it just takes a longer time to let the temporary memories to die off before using functions to call for the related data again, or even a restart to avoid the olde ones to interfere with the new process.

I *was* saying it might - but when I went to test that was shown to be not true. The lot vertices remain unstitched no matter where you move them. If you look at the pictures I uploaded last night, you can see the game has made an attempt to stitch the edges but has given up in the corners.

Are you referring to what we talked about some days ago - getting the values from the terrain geometry and applying them to the lot edges only? If so I was in wholehearted agreement with that and remain so. Or do you mean calculating an incline so that if main lot vertex A is at +10 and main lot vertex B is at +20, you will arbitrarily make the in-between minor vertices have values of +11, +12, +13 and so on? That might work too, though the outside terrain you can see from within a lot is not usually completely flat between each 10th point, the graphics engine gives it undulations. But still this will give the lot a very good chance of being assimilated into the terrain when it is moved even if there is still a thin blue line in situ.



I was speculating such - but I quickly realised it was a stupid idea because of the results it could bring!


It's apparently not that simple, as the images from my tests show. I have proven myself wrong about the roads always being flat, because as you can see in my pictures, if you deform the road using cheats, and move the lot, it takes the deformed road with it, and *actually deforms the neighbourhood road*!! Even after removing the lot again, the cars in nhood view still go up and down the dip you made.
Therefore I think the flat road you get when you place a virgin lot is because that flat road is actually stored in the template lot. Then when you build on a lot normally and move it, the road is still flat because most people don't edit the road.
I have shown that the flattening of the road is not something that is arbitrarily done at lot placement time by the game engine. Instead the game adjusts the hood road taking into account the road it finds in the lot you are placing.



Please don't flatten the road, I think that was a red herring. If people find their portals don't work on non-flat roads they must stick to making lots with flat roads - which is the default anyway. You have to work hard and cheat heavily to make non-flat roads Anyone doing highly weird lots like me will have to realise the LE won't be holding their hand all the way while they do it. 99.99999% of people will automatically have a flat road on their lot without the LE having to worry. The .000001% of people without a flat road wanted it that way for some reason.

So, if we (collectively) have identified there is a reference Z value for the lot, and all other vertices on the lot are plus or minus that height, then what point on the target terrain is considered the place to level the Z value of the lot with? Is it the front left corner looking from the road or something? Is this known, or shall I experiment (by placing lots created on dead flat ground onto terrain with hills and seeing what direction the terrain flattens from)

Can we just move the portals up to a built foundation while keeping ground terrain for the road inclined...
Can that work out?

The people with sloping roads will have made them on purpose, and so they will be able to flatten the road in places where necessary to make the portals work. I don't think the LE needs to handle this situation at all. Even advanced users probably won't want to make sloping roads once the novelty of experimenting wears off. They look quite ugly as the rendering of the road tiles is poor.

So... that "unknown list" in the LTXT seems to correspond to the major vertices in the lot (the ones that represent the hood-sized grid)? I wonder if those values simply override the underlying terrain values while the lot resides in that position?

I'm coming in late today, so pardon me if my remarks are already out of date.


This is what I have observed too.

I'll add some pics of my lots from yesterday. The first two are of the second odd lot, from neighbourhood and inside views. The third photo is of my initial reported lot, with the uneven road tiles and a sim halfway through the mailbox.


My husband has some good stories along these lines. I'll keep bumbling.


So far, I've done one lot each way that has come out odd, and two that have worked - one shrunk from the rear, one from the front. Of course, I can do more.



I don't think I have ever laid a lot that retained a sloped n'hood road, and I'm only used to playing basegame - I now have EP's, but I have barely played them. Too busy here!

Placing a lot on a sloped section of road (assuming the game allows you to place it, which it sometimes has) results in sharply flattening that section of road, creating a steep hill just beside the lot.



My lot with the blue bits has now been deleted, since it started crashing, but the blue was there as soon as I entered the lot after shrinking and moving it to a new position. I think it started crashing after I put it into the lot catalogue.


I'm not sure I agree on that - my original non-flat road appeared just as a result of shrinking the lot from the front, no other modification or cheats used. And I couldn't fix it without 'cheating heavily', and then the fix was only partial.


I think my uneven-road lot counts - it began crashing without any further shrinking or expanding having happened. But it was pretty messed up anyway.

Does Plasticbox or anyone else still want me to test a rowhouse? I'm not paticularly interested in building my own at this point.

I realise matters have possibly passed beyond these notes, but I thought I'd comment just in case.

I'm working on that tutorial still.

Doh! Yes of course I had completely forgotten about shrinking at the front! Then yes road flattening needs to be an option.

Anyway back to my ongoing tests. I created 4 lots on 100% flat land, one with each orientation. Upon placing many of each of them on the wobbly terrain I made, in various directions, it looks like they snap to road at the centre of their road edge, and the hood road (as well as the rest of the perimeter rise and fall to meet the lot contours) all takes place with reference to that point. In fact, as you go to place them, you see the bright green that follows the existing terrain countours, then a darker green shadow that represents the height and contours of the lot after placement. This darker shadow lines up with the white arrow, which in turn lines up with the centre of the road edge of the lot.

To finish testing this theory I need to make a dip that starts at the road, and extends to the back of the lot. Then I need to shrink from the road edge and try placing the lot elsewhere. The lot *sides* should be raised if the game is reading the value from the lot's leading edge. If not, the nominal value of the road edge height is stored on the lot independently at the time of lot creation and the actual edge level is not read at the time of placement.

Update for me too - I've played Plasticbox's rowhouse three times now, without any crashing. Shadows on high, Reflections on, neighbours on. Each time until Wednesday morning at least, with a single fresh-made sim living in the house. They didn't leave the lot except for work.

The pedestrian portal on the right-hand side seems to be facing the wrong way perhaps? People entering on that side appeared facing out of the lot, but otherwise behaved normally. I don't have the flamingo in the NL game, so didn't check the marker myself.

The lot is very stylish, plasticbox - it's funny watching them cook in one house and eat in the other, though, since I don't have any special doors.

Is there anything else I should try changing to test the crash problem?

Thank you for testing this. Which game configuration/s did you use? This may have an influence -- the light/shadow business has somewhat changed with Seasons, as far as I'm aware. And do you have any lighting mods?

Yes the pedestrian portals are a wee little bit odd, I've noticed that too -- not sure what direction the walkbys face (I'm very certain that I did place both portals with arrows facing in, not out), but I saw that they appear one tile in from the lot edge, i.e. on the exact tile the portal is on, and not directly *at* the lot edge like normal. But that's really a minor issue .. most people won't even notice, I think.

I just found a screenshot, attached below: this is how I placed the portals. This is correct, yes? You're the portal expert =) ..


Anyway -- I haven't been able to reproduce the crashing issue myself, not sure what caused it .. shadow/lighting was just my best guess based on the time it occurred at. Again, there is nothing else happening at 19:00 is there? Still, it's possible that my crash was for a totally unrelated reason.

If nobody else has any rowhouse problems, maybe I should just inflict this on the general public (labeled *experimental* of course) and see what they say .. the more people test this, the better. Or what do you think, is this safe for consumption? Should I wait until 1.2.7.7 is officially released?



Mootilda,

two more things I noticed (using 1.2.7.7):

* After shrinking or extending a lot, all fences and halfwalls on the lot lose their posts -- they stay lost even after putting the lot in the bin+back. The only thing that makes them reappear is rebuilding the fence/halfwall. Not an issue with fences, but with halfwalls one should keep that in mind, since they can't be rebuilt when on a lot edge (if you look at my house screenshots: the one on the right has a post-less halfwall around the covered entrance, this is why).

* The LE interface still says that the lot will appear empty when returning to the neighbourhood, but last time I tested it didn't appear empty (but shifted instead). Might want to change that accordingly .. also because the "shifted" appearance can be quite frightening to the unsuspecting user.

We definitely need lot-tile increment shrinking too - I see you're having to put two row houses per lot even now. I was just planning to make mine larger-than-real scale as they're easier to play like that too.

More results from my bumbling method:

Using the NL verison, since I had that CD in, I have laid five maxis lots in different orientations and shrunk them. I haven't used the flamingo yet to check portals, since it wasn't installed.

I'm attaching a pic of the n'hood after shrinking the lots, but before editing, in case that is helpful. Blue bits and flashing bits galore.

Lot 1 - 3x2, hilllside lot, flattened (steep at right edge). F -1, B 0, L 0, R -2.
Kept the level side. All good.

Lot 2 - flat 3x2. F -1, b 0, L -2, R 0.
All good.

Lot 3 - hilly 3x2. f -1, B 0, L -1, R 0.
Road moderately bumpy, blue edges, buried mailbox and bin. Photos available - attached are the before and after shots.

Lot 4 - 3x2, flattened (rise to landscape at rear, remainder at road level)
F -1, B 0, L -1, R -1.
The dip at the rear is maintained, with blue triangles between the lot and the landscape. Otherwise good.

Lot 5 - hilly 6x6, for a change. F -2, B -2, L -2, R -2.
Blue edges, floating mailbox, bumpy road. Heavily distorted n'hood roads.
Photos available - see below.

As an aside, while I was shrinking these, LE shut down when I was selecting the fourth of my lots. I think I may have doubleclicked on the lot name.

Sorry the photos are all out of order, but I'm too sleepy to fix them.

Now it's late, so that's it until tomorrow.

I'm using Up2NL in the BGS. No lighting mods.

Your portals look fine to me.

Did you know the paperboy delivers the paper to either of the two mailboxes? Only saw the postie using the right hand one, which was the closest when she entered the lot.



Yes, not much of an issue.

There was nothing much happening in my game at 19:00. Sometimes there was a visitor, sometimes not. I couldn't see anything strange, apart from the pedestrian oddities.

Now I'm really going to bed -it's stupid o'clock here by now.

[Row-houses]



is that how Maxis made fences like this? http://www.modthesims2.com/showthread.php?t=193824


[Lots (non-10x)]


5x20 lot ?
but, can we have 0.5x1 i the neighbourhood? :D
omg, no, the plugin view will turn 0.5 into 0 while the hex interface the singles doesn't work in this case.


[Rotations: all 3]

The attached... I used a 10x60 lot and sink down to z = 300 from 313.5. After a neighbourhood reload, the sea water flooded in!

I don't get it... I thought the z value in the lot description file of the neighbourhood package file is already lot base height. The change in the road or other buildable areas are relative to this point as shown in the pix posted along the way. I think I'm really lost...

Anyway, I'm gonna make my undersea lots...

I made a lot with a sharp trough in it for the middle 10 lot tiles, which extended onto the road. I shrank the lot at the front, loaded the game, did a token edit to it, then took it to the lot bin.

Picture 1 shows what the lot looks like placed one next to the other. There is the blue gash, interestingly shown in one side of the road on the live lot, and the other side on the lot imposter next door.

Interestingly, notice the leg of the deck foundation goes on into space below for eternity!

I then made another lot with a dip in it for the middle 10 lot tiles, but this time I made an even slope by lowering the vertices 1 click each time. Again shrank the lot from the front and took to bin after performing a token build action.

Picture 2 shows two of these lots adjacent to each other, and this time the game has been able to do a very good job of stitching them into the terrain.

Neither of these lots allowed me to place another lot - even an identically shaped one - opposite them. Nor could I place a lot template opposite. However, what *could* be done is place the blank lot templates on the other side of the road and *do not* load them. Then place the deformed lots opposite, and the blank lots the other side deform to fit. See Picture 3

If you load the blank lots and save them first with just their mailbox and bin on, you can still place the deformed lots opposite, but this time you get a blue gash instead of a dipped road.

In summary, I would say there is a place for a road straightening option, and for an edge smoothing option, but make them tickboxes perhaps. In which case a button for "reset defaults" would be handy as people always forget what boxes are usually meant to be ticked.

Being able to build in dipped roads is a marvellous way to add character to a hood, if you don't mind it being a bit fiddly, so it definitely wants to remain an option IMHO

Is anyone using the LE on a Vista 64bit system?

Try installing the Vista 64bit version of the .NET runtime 2.0:

http://www.microsoft.com/downloads/...&displaylang=en

Yet more shrinking remarks:

Plasticbox, before I forget, the invisible driveway is not included with your lot.

I've been experimenting with 6x6 lot which I shrank to a 2x1 size. It's the one with the greatest distortions of road and terrain.

I've been trying to see how much road needs to be flat in order for things to work. Initially, the pedestrian portals worked - the slope at those points was minimal. Sims walk quite nicely up and down the incline to the edge of the lot. Mail and paper deliveries also worked okay, but no vehicles.

I flattened just the squares for the road portals. No change.
I flattened along the median line, so that the markers were on flat land with a flat strip between them. No good.
I flattened along the exit edges at left and right of the block, no good.
I flattened from the car stop marker to the edge, and the taxi appeared. However, the same method didn't work for the service portal.

The only thing that worked was a major flattening of the road area, using CFE of course. The edges are still unstitched, and there's an exciting ravine at one edge. It really does look as though the road has to be kept flat.

not me - just so you know someone noticed your question.

Moontilda--how'd you find that?? I had been there and searched and came up empty handed! I searched on 'framework 2' from the framework 1 page!

yes--that will probably solve my problem. Thanks so much!!.....for leading the dumb by the hand.....

edit: well damn! I just tried it again and cameup with lots of results.