Replies: 2423 (Who?), Viewed: 453574 times.
Page 18 of 97
One horse disagreer of the Apocalypse
#426 Old 19th Oct 2007 at 11:41 PM
Here are the final two in that set
Screenshots

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Advertisement
Site Helper
Original Poster
#427 Old 20th Oct 2007 at 12:27 AM
Quote:
Originally Posted by Inge Jones
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.
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).

Quote:
Originally Posted by Inge Jones
Quote:
Originally Posted by Mootilda
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?
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 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.

Quote:
Originally Posted by Inge Jones
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.
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.

Quote:
Originally Posted by Inge Jones
Quote:
Originally Posted by Mootilda
Are you sure that the road is always completely flat?
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.
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.

Quote:
Originally Posted by Inge Jones
Quote:
Originally Posted by Mootilda
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.
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 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.

Quote:
Originally Posted by Inge Jones
Quote:
Originally Posted by Mootilda
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.
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

Quote:
Originally Posted by Mootilda
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.
And possibly for lots with specially shaped houses, dummy levels, foundations, landscaping etc
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.
Site Helper
Original Poster
#428 Old 20th Oct 2007 at 12:47 AM Last edited by Mootilda : 20th Oct 2007 at 2:16 AM.
Quote:
Originally Posted by niol
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:
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.

Quote:
Originally Posted by niol
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 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.
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?

Quote:
Originally Posted by niol
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.
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.
Site Helper
Original Poster
#429 Old 20th Oct 2007 at 12:55 AM
Quote:
Originally Posted by plasticbox
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.
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.
Site Helper
Original Poster
#430 Old 20th Oct 2007 at 2:14 AM
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?
Site Helper
Original Poster
#431 Old 20th Oct 2007 at 7:12 AM
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?
Mad Poster
#432 Old 20th Oct 2007 at 8:50 AM Last edited by niol : 13th Nov 2007 at 6:26 AM.
Default [lot-neighbourhood terrain sync.], [neighbourhood - terrain & +roads], [roads & portals], [LA/LE - UI & versions tests],
[lot-neighbourhood terrain sync.]

Quote:
...
Originally Posted by Inge
...
it seems to me that the game moulds new virgin lots to the terrain
...
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?
...


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?


Quote:
Originally Posted by Mootilda
...
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.
...


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]

Quote:
Originally Posted by Mootilda
...
Originally Posted by Inge Jones
Quote:
Originally Posted by Mootilda
Are you sure that the road is always completely flat?
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.
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.
...

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

Quote:
Originally Posted by Mootilda
...
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.
...

agreed...

Quote:
Originally Posted by Mootilda
...
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.
...

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]

Quote:
Originally Posted by Mootilda
...
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.
...

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]

Quote:
Originally Posted by Mootilda
...
But, can I release the existing code - is it "good enough"?
...

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

Quote:
Originally Posted by Mootilda
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?


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.
One horse disagreer of the Apocalypse
#433 Old 20th Oct 2007 at 9:16 AM
Quote:
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 *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.
Quote:
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.

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.


Quote:
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 was speculating such - but I quickly realised it was a stupid idea because of the results it could bring!

Quote:
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:

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.


Quote:
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.

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.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
One horse disagreer of the Apocalypse
#434 Old 20th Oct 2007 at 10:46 AM
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)

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Mad Poster
#435 Old 20th Oct 2007 at 11:36 AM Last edited by niol : 13th Nov 2007 at 6:27 AM.
Default [roads non-stand.]
Can we just move the portals up to a built foundation while keeping ground terrain for the road inclined...
Can that work out?
One horse disagreer of the Apocalypse
#436 Old 20th Oct 2007 at 11:41 AM Last edited by Inge Jones : 20th Oct 2007 at 11:55 AM.
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?

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Alchemist
#437 Old 20th Oct 2007 at 12:34 PM Last edited by aelflaed : 14th Nov 2007 at 12:47 AM.
Default testing, shrinking, terrain observations, roads
I'm coming in late today, so pardon me if my remarks are already out of date.

Quote:
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.

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.

Quote:
The best testers spend a large amount of time trying to figure out how to break the code.

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

Quote:
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?

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.

Quote:
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.

Quote:
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 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.

Quote:
Does anyone have a lot which has retained the blue disconnect, even after moving the lot in the neighborhood?


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.

Quote:
Please don't flatten the road, I think that was a red herring.(...) You have to work hard and cheat heavily to make non-flat roads

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.

Quote:
Has anyone managed to reproduce a crash which is definitely not related to deleting non-empty terrain?

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.
Screenshots
One horse disagreer of the Apocalypse
#438 Old 20th Oct 2007 at 1:06 PM Last edited by Inge Jones : 20th Oct 2007 at 2:03 PM.
Quote:
Originally Posted by aelflaed
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.


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.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Alchemist
#439 Old 20th Oct 2007 at 1:56 PM
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?
Pettifogging Legalist!
retired moderator
#440 Old 20th Oct 2007 at 3:09 PM
Quote:
Originally Posted by aelflaed
Update for me too - I've played Plasticbox's rowhouse three times now, without any crashing. Shadows on high, Reflections on, neighbours on.

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.
Screenshots

Stuff for TS2 · TS3 · TS4 | Please do not PM me with technical questions – we have Create forums for that.

In the kingdom of the blind, do as the Romans do.
One horse disagreer of the Apocalypse
#441 Old 20th Oct 2007 at 3:18 PM
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.

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Alchemist
#442 Old 20th Oct 2007 at 3:21 PM Last edited by aelflaed : 20th Oct 2007 at 3:29 PM.
Default Shrinkage tests
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.
Screenshots
Alchemist
#443 Old 20th Oct 2007 at 3:40 PM Last edited by aelflaed : 14th Nov 2007 at 12:54 AM.
Default testing, rowhouses
Quote:
Originally Posted by plasticbox
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?

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.

Quote:
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.


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.
Mad Poster
#444 Old 20th Oct 2007 at 5:23 PM Last edited by niol : 13th Nov 2007 at 6:35 AM.
Default [Row-houses], [Lots (non-10x)], [Rotations: all 3],
[Row-houses]

Quote:
Originally Posted by plasticbox
...
* 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).
...


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


[Lots (non-10x)]

Quote:
Originally Posted by Inge Jones
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.

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...
Screenshots
One horse disagreer of the Apocalypse
#445 Old 20th Oct 2007 at 7:32 PM
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
Screenshots

"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Forum Resident
#446 Old 20th Oct 2007 at 7:52 PM
Is anyone using the LE on a Vista 64bit system?
Site Helper
Original Poster
#447 Old 20th Oct 2007 at 11:49 PM Last edited by Mootilda : 21st Oct 2007 at 1:37 AM.
Quote:
Originally Posted by Mutantbunny
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
Site Helper
DELETED POST
Original Poster
20th Oct 2007 at 11:54 PM
This message has been deleted by Mootilda.
Alchemist
#448 Old 21st Oct 2007 at 1:20 AM Last edited by aelflaed : 14th Nov 2007 at 12:57 AM.
Default shrinking, portals
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.
Screenshots
Alchemist
#449 Old 21st Oct 2007 at 1:27 AM
Quote:
Originally Posted by Mutantbunny
Is anyone using the LE on a Vista 64bit system?


not me - just so you know someone noticed your question.
Forum Resident
#450 Old 21st Oct 2007 at 3:45 AM
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.
Page 18 of 97
Back to top