If that crashing is to do with having lights on the lot before shrinking, have you tried the same lot without lights on (add the lights after shrinking) ? If the crash doesn't happen then, at least we've narrowed it down. If it can't be tracked down why it happens, at least users can be advised to get rid of lights before shrinking.

Well, I still can't produce a crash. I have just run all three houses, one after another, as fresh placements in a fresh neighbourhood, with a new CAS sim. Some on fast forward, one on slow speed all day. All without saving during that first day. Plenty of people in the house, shadows and such all on.

By the way, the pizza deliverer was not confused by the double row house after I removed one of the front doors. She did stand by the car for a few moments (maybe considering the back gates?), but then proceeded to the remaining front door as normal.

And I'm seeing the disappearing front yard syndrome someone reported. On both the single house and one of the row houses. Pics attached.

Inge, didn't we clear up the streetlamp thing, or are you thinking that's something to do with the crash becasue it is lighting on the edge of the shrink zone?

Oh - if we did, maybe I missed that. The thread is quite a challenge to keep on top of :D

"Over the road" = checked allows you to have a road in the middle of your lot; it will move the lot to ensure that the road remains correctly placed in its original location on the lot, and then expand the lot forward past the road.

"Align to road" = checked works for lots which have the road in the normal location; it will move your lot to ensure that the road remains correctly placed in its new location on the lot.

"Align to road" = unchecked will not attempt to move the lot at all, but will instead allow the game to determine the placement of the lot. Sometimes the lot will appear to move with respect to the road, sometimes it will not. The lot's Orientation value is the determining factor.

The "align to road" = unchecked option merely restores Andi's original logic, as you requested. Personally, I don't think that it's a useful option. However, if you find it useful, I'm quite willing to leave it in.

I believe that you want to change the Top and Left values for the lot to move the lot away from the road.

Based on my understanding of what you are trying to accomplish, I believe that Andi's original logic may be useful for some lot orientations, but not others. It's also possible that the "over the road" logic may work for some lot orientations.

However, I still think that the correct way to achieve your goal is to just change the Top and Left values (and possibly the Z-value, depending upon the height difference between the old and new coordinates) and the U10 (road) value.

I am going to try it out now, and see if it produces useful aesthetic results. I'll let you know either way. Obviously even I am not gonna want to use something in my proper game that leaves the lot with a blue gash all round - though of course in future releases you were hoping to fix that up with gradient smoothing?

Thank you for the pictures. Has anyone been able to reproduce this problem on a non-shrunken lot?

I believe that the reason that we are associating this crash with lighting is that the only thing which obviously occurs in the game at 7PM is the change from day to night.

If anyone know of anything else which occurs at 7PM, please let us know.

Just to set people's expectations realistically:

I doubt that there is anything that we can do about this crash. After all, we are using the LotExpander to attempt to get around a known limitation in the game; I am not changing anything about the way that the game handles the lot file... Unless we can narrow this down to a specific change in a specific record type within the lot package, we may just have to learn to live with the intermittent crash.

Those pictures of the disappearing yards - those are on the imposters not the loaded lot. Yes I do get things like that occasionally, on lots that were never touched by the LE. It seems to happen on lots where the lot geometry was very different to the underlying terrain geometry, for instance where I have placed a deeply sculped lot on flatter land. It's fine when you're in the lot but sometimes the lot can look very odd when you're viewing it from the hood or another lot. Actually if you look carefull the yard has not disappeared, or you would see the blue gash syndrome. It's just being drawn sloped.

Thank you so much for this explanation. I suspected something like that.

I now consider this issue to be closed on this thread. There's no use cluttering up this research thread.

If I can just add one thing, MaxoidTom did say that he wasn't all that satisfied with the way the lot imposters were created, but we reassured him it was better than nothing - than just seeing wilderness around your current lot. So I think the problem happens at imposter creation time, not when you go in to play the next door lot. Presumably there is a GMDC for the imposter, so the adventurous player can try fixing it after saving the lot but before taking to bin.

This new advanced option has exceeded my expectations and I bet it exceeds yours, Mootilda

I placed a nominal 3x5 lot template, shrank it at the front unticking all advanced options. I laid it out as a small park with fish pond, placing pedestrian portals only - at opposite corners, not in the usual straight line.

I placed a 2x3 lot template along the freed-up road space, and a 5x3 lot template each side.

I moved the Ramaswamis into the middle lot (some people really appreciate Maxis making premade families as they're quick to use for tests lol) and made them walk to the park. The pictures show this functioned perfectly well. I consider this another enormous breakthrough for gameplay.

Next I want to test if I can move the lot further away from the road step-wise by expanding and shrinking alternately.

Wouldn't be difficult to exceed my expectations

I'm really glad that this worked for you. What orientation does your lot have in the neighborhood package? Did you change the U10 value? If not, have you had any problem with the road space locking up?

Please let me know how that goes.

I suppose you wouldn't consider turning this tool into the Lot Expander/Mover? It would save a lot of fiddling about for the user who wants stranded lots, if there is a feature for moving the lot backwards/forwards/sideways by however many. Specially since it looks like these lots are gonna be perfectly usable.

Surely, you mean the Lot Resizer / Mover? I'm not sure that the term "Expander" is appropriate any more. Lot Modder? There's got to be a more appropriate name... How about Lot Adjuster?

Yes, I would consider either changing the LotExpander or making a separate utility, depending upon how well the interface fits in with the existing LE interface. Can you give me an idea of what you'd like the interface to look like?

Should be a very easy thing to implement. I assume that it would supercede the "Align ..." feature?

The UI needs some time to consider, cos obviously lot moving isn't gonna work with some of the settings in the Advanced tab not set. It may be that the moving tab should only pop up after a visit to the Advanced tab to turn off lock to road. Or moving would automatically turn off the road locking. Yes it needs careful thought. I shall be thinking

Later: my attempt to move the lot backwards in steps failed, because after step 1, which was expanding it backwards, what actually happened is it grew to 3x6, but grew forwards so it was using the road again. I am certain I unticked the lock to road box. However, I don't think that is something that will affect any proposed move function on the LE, because I think the problem was probably with the LE not really understanding what I was asking it to do.

I have realised that if you have the move option, you really don't need the lock to road box as well, since that was only added as a convenience to those (me) who wanted to move their lot in this indirect way. With a direct move feature, locking to road or not locking to road is something the tool can handle transparently depending if it's a resize or a move activity.

In fact it could more or less do away with the over-the-road box too, since the user can grow the lot at the front with one pass, then move forwards with the next pass. So it becomes a more modular set of actions.

So there could be a tab for resizing, a tab for moving, and a tab for rotating. The user would have to complete and save each action before moving on to the next tab.

How about we keep the "Align to road" advanced option. If unchecked, then the user would be given two new numeric up-down controls for "move lot back from the road" and "move lot to the left". Both controls could allow both positive and negative numbers, so that the user could move lot forward or right, as well.

No, the problem is that I haven't added code to the LotExpander to do what you want. The "align ... unchecked" option is just telling the LE not to modify the Top and Left values, which means that the lot will stay in the exact same position in the neighborhood. The position after both expanding and shrinking is chosen by the game, based on the lot Orientation. As expected, if the top left of the lot never changes, then a lot expanded then shrunk (or vice versa) will remain in the exact same place in the neighborhood.

What you want is for the LotExpander to modify the Top and Left values by a specified amount. This is very different than asking the LE to leave the values alone.

No, your proposal wouldn't work to replace the "over the road" option. If you grow the lot at the front with the first pass, it will change the location of the road, which is not what that option does.

Not a bad idea, but this would require multiple passes on a lot, which is a lot more work than I was expecting to do for now.

Let me try my first suggestion and you can play with it a bit. We'll keep the tab idea on hold for now and I'll look at it later.

You still haven't told me whether you need the U10 (road) value changed...

Ok but I had imagined it would make the coding simpler if the user was expected to do it in seperate stages, since your code only has to handle one activity at a time? Doesn't this make less chance of a mess-up?

I am going to have to read back in this thread a bit to find out if I want U10 changed, since I haven't taken on board properly what it does. For the purposes of having the landlocked lot, the shrinking worked fine, the expanding not so fine. That's all I can say for certain at this moment.

Later: well it just looks like U10 says yes or no does the lot have a road? That should presumably have been already set to 0 by not ticking the lock to road box? Reading back, it looks to me more like the Top and Left value were not being changed as I needed for this purpose. The lot stayed anchored to its back edge, not the front edge. In fact the lot *did* expand at the back, because the back portion was empty. The stuff I had placed on the lot was on the old bit which had been pushed forwards by the expansion at the back.

Oh sorry I meant to tell you the details of the lot, it was U11=02, and Above.

Yes, I'm sorry. That was stupid of me. I've fixed it now -- I hope it's clear enough now (if not, please do complain =). I didn't mean to make people post all over the place, merely point them at places where they can find more information (*instead* of asking questions the umpteenth time .. but I was being a bit optimistic there, it seems).

Mootilda, should I repost my test row houses in the tutorial thread perhaps? So that we can discuss the build mode trivia over there, and keep this thread for the hardcore stuff? Let me know. You need to tell me where the 7PM crash discussion goes, in your opinion -- right now we don't know whether or not it's a build mode thing (apart from the question whether or not it can be solved at all) .. I was assuming it goes here, but maybe that was silly.

Since you were mentioning the LE interface, I have a quick suggestion: on the resizing screen, the old size should be listed first, and the new size below it (We read top-down). Also, "LotResizer" is an excellent name =).

Stupid? No. Optimistic? Yes.

It's OK. I didn't realize how much response you would get from your two threads. You've obviously made this research much more accessible to the average simmer, which is wonderful.

Last night I started to feel very overwhelmed by Doc Doofus telling everyone that the LotExpander was broken... especially when he started posting on other websites! Ouch! I pride myself on the work that I'm doing with this tool and it hurts to have people criticising it without giving me a chance to respond (I finally managed to catch up with him over at MATY) - who knows how many people now have a poor opinion of the LE because of this?

I think that makes a lot of sense. This should make it easier for people to keep up.

I'd prefer to keep this discussion in your row house download thread until we can get a better handle on what's wrong.

Ah, but perhaps out-of-date as soon as I write the code in to move the lot in the neighborhood, as Inge has requested.

Oh, by the way, I removed the 1.2.7.10 version. It wasn't really what Inge wanted. Working on 1.2.7.11 now, but it won't contain anything new for lot shrinking.

Erk! I feel embarrassed now (and I can't even find an embarrassed smiley)

Anyway, I used SimPE to change Top and Left (and make U10 = 0 again, it was set to 10 I think) and my lot moved back off the road into a new position. Looks fine though and the portals are still there. Even though this was a simple move for me, I suspect it would not have been if I had all different orientations to consider, so it's still worth being in the LE.



There seems to be a general thing that people report problems (or perceived problems) with other people's work at MATY. Goes with the general "relaxed" ethos of the site, maybe. I have had a problem with one of my downloads reported there first too, and that was by someone who is supposed to be actually a friend. MATY is good in small doses - spend too much time there and your judgement starts getting skewed.

No problem. It was a very very simple thing for me to implement, so it seemed worth doing - on the off chance that it would solve your problem. However, my expectations for this working were quite low. It was actually easier to implement your suggestion than to think the issue through and document why it wouldn't work.

I agree. The hardest part of this is just getting the logic right... doing the actual coding should be easy. Remember, the LotExpander is already moving the lot, so this isn't much additional work.

As far as the U10 value goes, I'm not going to change it for now. My hope is that the road tiles will remain unlocked unless you try snapping the lot to a road. If you find that we need it changed, it's pretty simple to implement.

Thanks for that. It wasn't actually MATY that got me, though. It was when he said that he had posted on yet another website, but didn't give the name of the site or a link to the thread. I started to feel that I'd never catch up with him.

I think he said S2C? I've been looking for that too, didn't find anything, but seeing as I've got 24 tabs open already I'm happily leaving it for later. I'll PM you the link if I find it.

[Lot -shrinking] - trouble-shooting

1. Plasticbox rowhouse crash mystery:
I'll divide it in the following ways here:
a. if it is caused by trimmed invisible objects in a lot, then we can go investigate the objT listing to trace for evidence esp. for time controller or something like that?, then it can be an issue for LE. Then, we may need some fix on the LE to move all the other invisible objects to a location of a lot where will stay regardless of expansion or shrinking. The safest point to store these invisible objects is the origin (0,0) coz whichever way the lot is rotated, this point will stay as always as it's the only mutual point.
b. if it's caused by the light being placed crossing the kept and the trimmed, that's obviously solvable by not doing so. Problem solved for this possiblity.
c. unmatched terrains between a lot and a neighbourhood, simply move the the lot to else where, right? Problem solved for this possiblity.
d. Problem solved for this possiblity.
All the other latter 3 can be solved or avoided with supposed precautions to warn makers and/or users.
Only the first possibility can be relevant enough to stay.


[record formats (lots and neighbourhood)]


we may go dig it...


[chit-chat]


As long as you're doing things all right and stay calmly doing things in the silence of your mind, rumours or other unhelpful things will pass by coz not all people are the same.
Some are very "sensitive" and /or "hard to be pleased".



Guess what I intimidated in the rant thread I made and linked before to you all here...
That was a fun thread tho .

Niol, yes I found the GMDC, it's in the lot file. Do not try to preview it, as it crashes SimPE.

Mootilda, I tried the flag for beach you suggested, but it doesn't seem that the beach portal is happy to accept that as sufficient to make it a beach.

[record formats (lots and neighbourhood)]



I went a step further the another day...
http://simpeforum.ambertation.de/si...e-file-in-simpe

Hopefully, there may be a fix for that. :cross-fingers:

The cres can't be opened properly for the SimPE version I've, 0.62.


[chit-chat]

As for yellers, in his SimPE site forum Quaxi also got hit verbally.
http://simpeforum.ambertation.de/si...ything-simmilar
So, a reaction thread.
http://simpeforum.ambertation.de/si...-appreciate-you

Lousy reports are still the lousy ones, and they'll be gone like a storm. As long as we stay calm, open-minded and confident, they'll be gone fast, too as the way in real life.

What was the original value? What did you change it to?