plasticbox, if you don't want to add another general upload, you could just send an unshrunk lot to Rascal for testing. Just to be sure. She did offer to take test lots earlier in this trhead. I'd offer, but it seems pointless - haven't crashed one yet!

But of course, I agree that it isn't likely to work, as my shrunk lots crashed too.

Boy, this thread quietened down as suddenly as it blew up!

I've had crashes with aelflaed's lots and my own as well as yours plasticbox so I really really don't think there's any chance it's something peculiar to your lot. I will happily test but don't really see the point.

And you always use the BSG thingy to make lots? Just trying to make sure the *only* thing different was that you shrank these.

Have you uploaded the exception files?

Rascal has just tested a new basegame lot I made today. Still no 7pm crash, but she did get it to crash THREE times on save. The lot is shrunk at two sides, but NOT built to the edges.

I can post the lot here if Mootilda or anyone else wants to examine it - I was trying to get the test done without clogging any threads, but it looks like it needs clogging!



Also, I uploaded the rotation tutorial on this thread again, since the other one is still pending after three days. The link from the start comments should now access the tutorial message for anyone who wants it.

Looks like we can't reasonably share shrunk lots yet.

Are the crashes "this application has crashed the application will now terminate" types?

Don't know, probably - Rascal?

No - I didn't get the little text box - just crashed to black and restarted the computer. So yeah - didn't just crash the game but crashed the pc as well. Sorry for not saying that before. I was so frustrated with getting a different crash I didn't actually think about it. My 7pm crashes just crashed the game, not the pc.

Well I have tested backdoor42 for the first time just now, I am ashamed to say..

Placed in hood, immediately moved in freshly created CAS sim, crash at 18.59 (Sound error logs populated with gobbledygook, graphic error logs empty)

Placed in hood, saved after replacing front steps, moved in new CAS sim, no crash.

Anyone had a crash *in spite of* saving after a build action before moving a sim in?

Yes Inge - I did. My very first crash with backdoor42 I changed the staircase and recoloured the driveway then saved before moving in a CAS sim.

I don't have BV.

The second backdoor42 placed in the same neighbourhood did not crash despite not having altered anything in buildmode before moving in sims.

Well probably the advice for sharing shrunk lots will be to have a small cooperative testing team who will help the creator come up with advice to downloaders as to whether the lot is likely to crash and under what circumstances. A bit tedious but if we haven't come up with the reasons yet, it could be a long long way off being solved properly. Or just a general list of guidelines and warnings for the downloader about possible adverse events on shrunk lots - maybe start a public thread for support and advice with shrunk lots and lot sharers point to that thread so people know what they might expect. It's probably going to be more practical to "handle" it rather than either avoid it or fix it.

For what its worth I agree. Maybe we'll come up with something definative eventually but everytime I think we've narrowed it down something new comes up. Im off to bed now but I'll check in tomorrow night. I'm of no use on the technical side of things but am happy to test more if anyone wants me to.

This sounds reasonable to me too - it's a pain to fill every upload with dire warnings and pages of suggestions.

A central help thread to point to would be nice. And, hopefully, would mean more than one person will be able to offer advice on problems too.

Of course, now I don't know whether to share my house or not. I should rebuild it without shrinking, really, since it isn't going to the edges, and I have no reason to expect it to mess up on a 'normal' 1x1. Or I could build something new...

Wonder if plasticbox is getting anywhere with those experiments?

I'd say hold back on sharing shrunk lots (other than very clearly marked for experimental purposes) until the shrinking is a part of the LE release version. I would like to be sure Mootilda is comfortable with the decision.

Now... for when we are ready, where is the best place to start a shrunk lot support thread? The tools discussion forum? Building discussion forum?

A cross-reference in one, pointing to the other? I suggest that the Tool is the LE, and that already has a support thread, so perhaps the building forum is the place.
I wish they'd process the tutorial file. I feel all half-finished.
Going to bed now.

With the roofs? Not yet, sorry, had to work yesterday. Hopefully tonight or tomorrow.

My crashes were all "Application was terminated", and in the crash logs (yes I did post them, see MATY thread post #1, there's mine and Rascal's -- simsample has posted some further downthreads) it always says "Access Violation".

I think there's two different kinds of crash we see here -- the "7PM" one (triggered by day/night change if there's a CAS sim on the lot), and a crash on save/load that's a bit more mysterious to me.

Not sure how to go about public distribution of those shrunk lots -- the 7PM crash wouldn't be such a big deal anymore now, since it can apparently be circumvented by not moving in CAS sims, but what about the save/load crash? I for one do not plan to upload any shrunk lots before this isn't a bit clearer -- I've too much on my hands with this stuff even so, no desire to play helpdesk on top of that.

In any case, for uploads on this site we should check back with the moderators again .. they're the ones who have to provide most of the support, after all (not for our lots perhaps -- by people who have been involved in all this --, but for everyone else's).

ETA: also, perhaps there's a way to support this on a technical level -- new "experimental" subcategory, support groups, or something -- so whatever we do we should talk to the admins before doing it)


Need to run off now, again ..


quick ETA for Inge:


I've been using the BGS for quite a while now. Been uploading a few base game/NL lots in the recent past, no problems whatsoever. There is a Base+NL one in the queue right now, as well (nonshrunk).

If you look here: http://www.modthesims2.com/member/d...Type=1&u=178282
everything on the first 2-3 pages that's NOT all three EPs (NL+OfB+Seasons) is a product of the BGS.

plasticbox,

have you tried some shrunk "blank" lot as test subjects? If it crashes, it means the shrinking process itself has at least a significant error.

Then, this will narrow down the potential factors a big bit.

May also try the following lots built with different components when s.the above works well in your case.
http://www.modthesims2.com/showpost...2&postcount=761

BTW, anyone has used modded wall.txt?
I do. Anyone else?

Yes I have all manner of custom walls, but obviously I don't use them in the lots for sharing.

If it is the case, only the used wall type(s) matter(s).

I asked it's because I've been using modded wall1, modded attic walls and modded foundation walls and modded screen walls. They can be placed without wall support, placed in a terrain water, placed on uneven terrains etc... in all game copies.

Lol, never mind, I've tested both cases for to have or not to have the modifications, the shrunk lots done by LE1277 still crashed the base game @ build mode to switch to the night mode anytime but not necessarily @ 1900.

Blank lot won't crash after a new CAS sin moved in when night mode is selected in the build mode,

I've noticed that several people are still using LE 1.2.7.7.

Just to rule out off-the-lot fence posts as a cause for the crash, I would recommend that everyone upgrade to 1.2.7.8. I really doubt that the fence posts have anything to do with a 7PM crash, but it can't hurt for everyone to be using the same test version.

There is one additional bug fix included in 1.2.8. The LE was not correctly handling strings which are long enough to require two or more 7-bit bytes for the string length. I need to go through the entire LE code base and ensure that this bug does not occur in other places; my guess is that this bug occurs fairly frequently - whenever strings are used. Because of this, I wasn't planning to put out a new test version until I have the entire code base fixed.

However, since this string-too-long bug should crash the LE, I don't believe that there's any need to update the test version at this time. If anyone experiences an LE crash, I'll get you a fixed test version immediately.

As you may remember, I've been putting debug code into the LE as I come to understand the structure of various records. This code helps me to find new record formats for new EPs and SPs. It can also help to find lot corruption and other bugs.

So, I ran my own shrunken lots and the crashing blue terrace lot through this debug code, but no lot corruption was found. Oh well, it was worth a try.

I continue to suspect the portal code in the 7PM crash and am considering changing the portal algorithm again. I am currently setting the portals to an absolute position on the lot, but I think that it might be better to use the existing relative position logic instead. I'm not sure yet how difficult it will be to use the relative position logic to set an absolute position, but it should be more robust once completed.

I notice that the MATY thread finally caught Pescado's eye, and that he has the expected concerns about the game just not being able to handle these lots. I continue to hope that we can figure out some way around these problems, even if the game can't handle these lots.

Well for the record I don't agree with Pescado's reasoning. I don't see how it can be the position of the walls or roofs or else the crash would happen again and again until you deleted them. Given that the logs are showing audio errors not graphics errors, and walls don't make special noises, and it happens at official dusk, I would be looking more to things like the cricket sounds kicking in. Maybe the cricket noise generator object got cut off the shrunk lot.

I certainly don't see how it can be a portal problem. I've had anything from no portals to excess portals on my lots - and in all manner of places - and still no crashes. And you'd expect the problem to be manifest when they were used not just cos it was 7pm. Even on the 7pm crashing lots I had successful visits and walkbys earlier in the day leading up to the crash.

But Inge, how can it be the cricket sounds when people are crashing in Build mode, where no audio change happens?

In other news, I'm testing minimal lots (roofs, walls, foundations) right now and I'm seeing *so many* crashes in Build mode (before any sims enter the picture) that I'm wondering whether it's possible that the shrinking (or the crashing?) corrupts the entire neighbourhood somehow?

(Perhaps it's only because I'm still at the stage where I'm testing lots that I have *not* moved or put in the bin+back -- don't mean to scare you =)

Will report later.

Actually there is sound in buildmode - most of the tools come with sound effects.

And bear in mind I haven't had crashes in build mode in shrunk lots either yours or mine other than when I tried to save the lot with the infeasibly long pier

Just remember, the LE is not deleting any objects, it is just moving the objects so that they remain in the same relative position on an expanded or shrunk lot. For expanded lots, this can never cause any problem. For shrunk lots, it may result in an object being off-the-lot (ie, the X and/or Y coordinates of the object either less than 0 or greater than the height or width of the lot).

We don't know whether the game has problems with objects with coordinates which are off-the-lot. It's also possible that the game may only have problems with some types of objects, or with objects with both the X and Y coordinates off-the-lot.

One thing that I can do is to add checks on all object coordinates to ensure that they are on the lot. This is a non-trivial change to the code, but it might help us to find the problem.

Another thing that I can do is to add logic to move all off-the-lot objects back onto the lot. This is a fairly major change to the code, but might completely stop all crashing. Especially if I can find some way to deal with objects which straddle the edge of the lot, such as windows and roofs, without completely destroying them.

Easy. Your lots may not have portals in the exact state that's required to produce the crash. Other lots may meet the conditions required. I do not believe that it is the number of portals which may be at fault. If anything, it would be the location and orientation of the portals, possibly in conjunction with other game elements, such as sounds.

In any case, I am still not completely happy with the portal logic. When I wrote the new code, I decided to allow the old logic to remain for multiple portals of one type. Now, I think that the LE should either move all portals, or none (based on a user-controlled flag). I have also come to believe that moving a portal to an absolute location on the lot is incorrect, and that the relative-movement logic is more correct. My concern is that the absolute logic sets all X, Y coordinates for an object to the same value, but an object may require some of the X, Y coordinates to be off by a bit.

Aside: did I ever mention that the new portal logic found several Maxis-made lots with portals facing in the wrong direction?

In the interim, I have verified that the string-too-long bug occurs in many locations that access strings, but that there is only one other place in the code where this is likely to be an issue. In most of the places where the LE handles strings, the LE expects a particular (short) string, so the old logic should be sufficient. In most of the other (more general) cases, the string length is stored in an integer and so the multi-byte logic is not required.

This might explain why we haven't seen any reports of this problem until recently. Both people who reported the problem had custom content with very long object names.

Portals have no connections with any sound resources and they are totally passive objects that neither spawn nor react with the cars or pedestrians who use them. All they do is suggest a position for the sim or car to appear or disappear at (even that is flexibly coded), after the sim or car has already been spawned out of world. There are various other controllers that are more likely to be upset by a portal being badly placed, but that would be a code error not a CTD.

From previous bugs which were shipped with the game, we know that the game does not do much checking for corruption, and that the game may spread any corruption through the entire neighborhood.

I believe that this is an indication that the development is being done too quickly, and the developers do not have the time to put these additional checks and error handling into the code.

If I am correct and the problem is that some objects are off-the-lot, then the game could easily corrupt other things by just accessing whatever happens to be in these off-the-lot memory locations. I understand that many of you do not understand programming, but let me say that two different lots do not have to be close to each other in the neighborhood to be adacent to each other in the computer's memory.

The one thing that mitigates this somewhat is that I believe that the game only loads one lot at a time. However, if you save multiple lots during one run of the game, then all of those lots can be affected.

I assume that everyone is still using test neighborhoods?