Crash on resized lots at 7PM -- any ideas?

[Zazazu]

All this focus on roofs being on the edge being the issue feels wrong. The only lot of mine I've gotten to crash consistently is my 1x1 brownstone, unreleased. It doesn't have a roof in the traditional sense. I never used the roofing tool. It's a multi-level floored surface.

If anyone wants to test it, here's the link: http://www.4shared.com/file/28206022/94ab3616/Corner_A.html  (requires all EP)

[Inge]

All this focus on roofs being on the edge being the issue feels wrong. The only lot of mine I've gotten to crash consistently is my 1x1 brownstone, unreleased. It doesn't have a roof in the traditional sense. I never used the roofing tool. It's a multi-level floored surface.

Well that's pretty much how I feel about the wall issue.  Usually once a computer-related problem is tracked down there is a Eureka moment when you realise that it is totally reproducible once it's properly defined.  The walls on edge of lot is not a repeatable cause of a crash in isolation, even related to EP.  Else I would be able to run all row houses without problem, while someone without whichever EP would be able to run none of them.

My bets so far are on the deleted object idea being a better trail to follow.  Maybe in BV the core objects and controllers are not put in the same location as they were in earlier games so they're not getting deleted to the same extent.

[Mootilda]

All this focus on roofs being on the edge being the issue feels wrong.

Well that's pretty much how I feel about the wall issue.

I don't believe that roofs are the *only* issue.  However, the roofs seem to be *one* issue.

There are several possibilities:

1) There is one issue which is causing all crashes - unlikely, but it would be wonderful if we could find such an thing.
2) There are a finite number of issues which are causing all of the crashes - I'm still hopeful that there are a finite number of fixable issues, but we just don't know yet.
3) This is a black hole.  All energy put into the issue will be sucked into the void, and in the end there will be nothingness.  If so, then we are wasting our time.

The question is: which of the above is true.  I'm reasonably sure that there isn't just one issue.  I'm willing to spend some finite amount of time on trying to resolve multiple potential issues.  But, at some point - if we haven't found the answer - it just won't seem worth the effort.

I took a quick look at the roofs and I now know that I don't understand roofs well enough to do anything yet.  The Roof record type for a shrunken lot doesn't contain any coordinates which are off of the lot.  If someone had some idea of what to try, it would be helpful.  Record types, instances, etc would be the most helpful information for me.

If you have other suggestions as to (relatively) quick things that I can change in the LotExpander to help narrow down the problems, I'm very open to doing them.  My main criteria are that I don't spend too much time and energy on something really nebulous.

I hope that this doesn't sound too harsh.  I'd love to be able to provide this feature, but I have very little experience with modding - just my work on the LotExpander.  That's why I was hoping that testing might shed some light on areas of interest.

[Inge]

If you have other suggestions as to (relatively) quick things that I can change in the LotExpander to help narrow down the problems, I'm very open to doing them.  My main criteria are that I don't spend too much time and energy on something really nebulous.

You already came up with the idea that seemed good to me - not deleting objects that are on the shrunk bits.  Obviously I don't know how well that fits in with your idea of relatively quick, as I am not aware of your implementation process.  I have already given a concrete reason why I think this is a good idea, earlier in the thread.

Now this could result in actual visible objects like wall segments and windows being plopped into weird looking places, but the instructions to the user were to make sure no visible objects were on the deleted part of the lot first.   If instructions have been followed, that *should* just leave a few invisible objects and controllers being moved onto the part of the lot that is remaining - which I think is a good thing because of the resources these things can contain.

[nil]

I can say what I've seen so far on the visible elements of a roof.:

known from Materials:
1. RoofTop
2. RoofUnder
3. RoofEdges
known from wall.txt
4. attic walls

From my experiences and observations, attic walls is added by the roof tool only at the perimeter loci of a roof product and is not added for those sides where the roof edges reach down to the grid layer the roof is on.  The latter observed condition is the reason why rooms by the roof tool alone are not a closed room to be considered as "inside" although graphically it appears so.

Note, a build tool can add >1 components into a lot for a given use.

As for whether Mootilda can utilise her first approach to reach the goal to trim off the over-hangs depends on whether the over-hangs are a part of the mesh group that occupy grids at the in-roof side or the out-roof side (the extra one grid outside the roof body predefined by the roof tool and user's drag).  If it's the former, I think, the trimming may be completely unnecessary when no other settings is actually affected.  If it's the latter, we're likely to see a hole gap but we can add the attic walls to fill those gaps in advance.

But at least, such optional trimming may help analyse the roof.


There're different types of roofs.  Some have attic walls at some of its edges while some have no attic walls at all.
If one doesn't count this, it's harder to draw a conclusion if any is deducible.

Please forgive me for my still learning some programming things and my wondering about different "crazy talks". I didn't major in that field, nor I learn them enough to tell.


I'm looking forwards to the new LE version that may ensure all objects to be in-lot to see if that is a factor.

But shrunk lots for row houses are still much more stable and tolerated by the game than wall-at-the-edge lots by means of the fence-based default replacement on Wall1.  The latter crashed at lot-loading.


After all, to say the least, should all fail, we can share lots before shrinking, and let those who want row houses to shrink the lots by themselves for uses in their own testing neighbourhood(s) or even custom folder or game copy to set aside from those they expect to be relatively safer.  In such given cases, the users know the risk that their neighbourhoods can absolutely go bonker corrupted, but they're willing to use them in such a way.

[Mootilda]

I can say what I've seen so far on the visible elements of a roof.:
[...]
But shrunk lots for row houses are still much more stable and tolerated by the game than wall-at-the-edge lots by means of the fence-based default replacement on Wall1.  The latter crashed at lot-loading.

Thanks for the list of roof elements.

I agree with you about the stability.  In spite of the problems that we've been seeing, these shrunken lots are working a lot better than I originally feared.

[baratron]

Inge,

I'm not up to date with the portal stuff -- this:

tried to place a pedestroan portal 1 level up, on the top of the stairs. Not good. Made the game crash every time I tried to save. Moved portal to ground level, saved fine. 

is something that's already known? I believe there was some talk about z levels of portals on R+D .. not sure though. Is this a new thing that Mootilda should know about, or is it old hat?

Yes, this is Not News. How the hell could pedestrians walk into the lot one level up? That doesn't make any sense!

[baratron]

The only link I made was that the times I had a crash, the lots were placed adjoining another lot which had wall on the boundary- but just placing the lot next to a boundary wall didn't guarantee a crash. Confusing!

Ah. This does actually make some sort of sense. The game is confused about where the lot ends due to the "overlapping" wall (called a party wall in British English), and so is attempting to write to the wrong lot based on that? Yeah, I'd always thought that could be the problem... But damn, that's really annoying . I'd been hoping we could manage semi-detached houses even if we couldn't manage terraces, and that's disappointing. I live in London - detached houses barely exist here! >90% of the houses in my town (Kingston) are either semis or terrace.

The "inbuilt defences" might vary with the game version you're running (and possibly other parameters; RAM?) .. which might explain how some users *see* less or no errors, even though they would still *exist* just the same.

I have believed the amount of RAM and/or graphics memory is an issue from the beginning. Did you see the videos I made when the game went completely screwy while I was testing the lots? At the time, I ascribed this to the fact both Sims 2 and Windows tend to leak memory like a sieve; and having booted up the game and quit/let it crash more than 15 times in one session, the memory was a mess.

I am also certain that a game patched with Awesome Fixes (a.k.a. "third-party patches") is far more stable than one without. Prior to testing these lots, the only times I'd ever experienced crashes to desktop were pre-Critical Fixes from Pescado or TwoJeffs, or if I had old versions of hacks after an EP.

In any event, I'm afraid that no crashes don't prove anything. I don't mean to scare you, but only because it doesn't crash it doesn't mean there's no data corruption going on in your hood. I'm going to take down my uploaded lots from mts2 as soon as it's back up, so if anyone still wants them you'll have to be quick =). Please do not redistribute any of my shrunk lots without a dire warning that using them may corrupt neighbourhood data. I don't want people to fuck up their games just because they think the house looks cool.

My primary concern since the beginning has been that the lot package is actually corrupted (based on the game code) and that this corruption may spread to the rest of the neighborhood. 
...
I don't believe that you understand.  An access violation occurs because the game became so confused that the corruption was completely out of control.  An access violation is the operating system's way of stopping a program which has become "insane" and is trying to change memory which doesn't even belong to the program.  IE, the Sims 2 is trying to write into your open Word document and Windows won't let it.

I'm not bothered about the lot package corruption spreading to the rest of the Neighbourhood as I've been testing everything in a throwaway 'hood. What worries me is the example of The Sims 2 trying to write into a Word document. Could someone who understands the way the game works please confirm whether it is possible for it to be confused enough to randomly open another Neighbourhood and write into that? I'm under the impression that it only opens one 'hood at a time, while the others remain unchanged on disc, but I now want to confirm that is the case.

[Inge]

Yes, this is Not News. How the hell could pedestrians walk into the lot one level up? That doesn't make any sense!

Well they don't walk into the lot.  They are instantiated out of world (ie not on a grid coordinate) and then the game tries to find a spot in a position relative to a pedestrian portal to locate them so they can begin their fade-in.  There is some flexibility in where exactly they appear relative to a portal.   Any level where there is floor grid present is considered a valid place for the purposes of "find location for".   So when I had my pedestrian portal in the roof space, the sims happily appeared in the attic.    I didn't provide any stairs to this area, so after they had wandered about a bit they either found another pedestrian portal up there to walk over to in order to start their fade-out process, or if I had already stolen it, they poofed out of existence after they got a bit fed up.

[Inge]

Ah. This does actually make some sort of sense. The game is confused about where the lot ends due to the "overlapping" wall (called a party wall in British English), and so is attempting to write to the wrong lot based on that? Yeah, I'd always thought that could be the problem... But damn, that's really annoying . I'd been hoping we could manage semi-detached houses even if we couldn't manage terraces, and that's disappointing. I live in London - detached houses barely exist here! >90% of the houses in my town (Kingston) are either semis or terrace.

I have terraced housing populated by families in my game.  Overlapping walls and all.  Why don't you try the lot I made in a row of several and play it?

I think there has been so much information and speculation about which situations are causing crashes and why that it's impossible to keep sight of everything.   At the moment for every person who reports a crash in one situation there is another person or another time when that situation didn't cause a crash!   Maybe we need a chart for every situation saying with columns for always, sometimes and never

[Simsample]

The only link I made was that the times I had a crash, the lots were placed adjoining another lot which had wall on the boundary- but just placing the lot next to a boundary wall didn't guarantee a crash. Confusing!

Ah. This does actually make some sort of sense. The game is confused about where the lot ends due to the "overlapping" wall (called a party wall in British English), and so is attempting to write to the wrong lot based on that? Yeah, I'd always thought that could be the problem... But damn, that's really annoying . I'd been hoping we could manage

Please bear in mind though, that I only tested each of PBox's lots about five or six times- so it isn't conclusive. If I played some more it's always possible I could find crashing on lots with no adjoining boundary walls.

[pbox]

During all of my testing on 2007-11-02, all lots had 1 unit free space in between. I had crashes left and right. I see no correlation there.

Could someone who understands the way the game works please confirm whether it is possible for it to be confused enough to randomly open another Neighbourhood and write into that? I'm under the impression that it only opens one 'hood at a time, while the others remain unchanged on disc, but I now want to confirm that is the case.

Dunno .. look at the file timestamps, perhaps? I have absolutely no clue about memory management under windows, but that's what I would do .. assuming that if it writes into a file, the timestamp *will* change.

[baratron]

I have terraced housing populated by families in my game.  Overlapping walls and all.  Why don't you try the lot I made in a row of several and play it?

I'm not trying out any more terraced houses until someone can confirm whether or not the game can get confused enough to randomly write into another Neighbourhood file. Also, having hunted through the 9 pages of the thread for the link (Search on the top of the thread for "Inge" didn't find it), I see it requires BV which I don't have & don't plan to get for some time. (I prefer to obtain EPs only after they have been thoroughly patched.)

I don't have noticeable problems with Plasticbox's original Backdoor Lot 42 as long as I have all my hacks in place, but I'm worried by the potential for corruption to other lots/families within the Neighbourhood. For all I know at the moment, I could play this lot a dozen times without observing anything bad, and then I could open up some other lot to find it full of garbage?

[Inge]

You're surely not playing these in your real game yet are you?   I'm still in my test hood so if it craps on another lot I just vape the hood and make another test hood.   I don't advise anyone to play these for real yet!

[Zazazu]

You're surely not playing these in your real game yet are you?   I'm still in my test hood so if it craps on another lot I just vape the hood and make another test hood.   I don't advise anyone to play these for real yet!

I am playing them in my main 'hood, but if everything bombs out it bombs out. I knew that was a risk when I first plopped one of Plasticbox's down in Queen's Cove. I have two sims in Backdoor Lane 42, and three + dog in one of my 2x2 brownstones, plus have plopped down a good 10 of the gray townhomes I first made and the entirety of the brownstone complex. I think that's 13 lots in that complex. If I end up having to recreate the 'hood from scratch, no biggie. I have plenty of pictures for reference and I don't give a rat's about memories, so a simple sim cloning works for me. But for now, I have the pretty.
 

[Inge]

Well that's ok for someone for whom every hood is potentially a fun experiment, but some people are *really* involved with their sims and would be devastated if anything happened to them.  So it was worth giving a reminder.

[Zazazu]

Well that's ok for someone for whom every hood is potentially a fun experiment, but some people are *really* involved with their sims and would be devastated if anything happened to them.  So it was worth giving a reminder.

Considering the multitude of warnings given, that type of person would be a bonafide idiot if they were playing these in their main 'hood, and most likely are old hat at losing 'hoods in BFBVS. 

[baratron]

You're surely not playing these in your real game yet are you?   I'm still in my test hood so if it craps on another lot I just vape the hood and make another test hood.   I don't advise anyone to play these for real yet!

Depends what you mean by "real game". I only have one Sims 2 game, because I don't have enough hard drive space to create dummy Windows XP accounts to make multiple, separate copies of the game.

I am testing the lots in a throwaway Neighbourhood, as I said 6 posts up from yours. However, I've just looked at the files within Neighborhoods/N00whatever, and it seems that every single Neighbourhood.package, University.package, Downtown.package and Suburb.package get rewritten each time you boot up the game . In fact, the file stamps on those packages correspond to when I quit the game last night, not when I last chose a 'hood to play.

So I'm really quite worried about the potential for bugginess from the game writing to the wrong part of memory getting into the wrong Neighbourhood file, and corrupting one that I actually care about. Anything can happen to N005, but I've worked hard on N004 and don't want it corrupted.

[ingeli]

You dont have to make another windows xp  account- just rename the sims2 folder in documents - for example to sims2-realgame - and then restart the game - voila, game created new sims2 folder, and that one can be used for testing. When I want to play my real game, i change the name of the new folder to sims2test, change sims2-realgame back to sims2 and go play. Very easy, just a few letters to type, no extra programs - only thing needed is the extra space for a sims2 folder in my documents. My absolute vanilla-game folder takes up 512MB (I have all expansions and I use the Clean Templates, so I dont get any extra hoods/character files and such.) The test one has the needed downloads added, atm building stuff.

[Doc Doofus]

Did you try to see what happens when you modify the freshly re-plopped-down lot *again*? Does it work then?

Yes, I did try.  It works.  In fact, this is the most consistent thing I have found in this whole experience.  Making a lot crash is dependent upon several variables:

1. CAS-made Sim or non-CAS sim.
2. Which EP was used to make the lot.
3. Packaged or hand-built lot.

Yet, CONSISTENTLY, if I tweak the lot in build-mode from the neighborhood BEFORE moving in a Sim, ANY sim, I have experienced no problem.  Not me.  I'm using unpatched BV.  I have only experimented with your Backdoor 42 lot and with my own designed shrunken lots.

I like consistency.  Of course, your results may vary, but I hope not.

I'm not bothered about the lot package corruption spreading to the rest of the Neighbourhood as I've been testing everything in a throwaway 'hood. What worries me is the example of The Sims 2 trying to write into a Word document. Could someone who understands the way the game works please confirm whether it is possible for it to be confused enough to randomly open another Neighbourhood and write into that? I'm under the impression that it only opens one 'hood at a time, while the...

I'm reluctant to say never, but it is EXTREMELY unlikely to ever happen that a document in another program could be corrupted by an array index problem.  Those kinds of problems were actually commonplace before virtual memory architecture, which was, uh, years ago.  Since the Word program has a separate memory space, it would take something far, far more catastrophic than a Sims 2 crash to do that.  (Sez Doof who once used to T.A. college Operating Systems)

If you're nervous dancing with the devil in the pale moonlight, maybe you should find something safer to do.  I hear Minesweeper is fun.

[pbox]

CONSISTENTLY, if I tweak the lot in build-mode from the neighborhood BEFORE moving in a Sim, ANY sim, I have experienced no problem.  Not me.  I'm using unpatched BV.  I have only experimented with your Backdoor 42 lot and with my own designed shrunken lots.

I like consistency.  Of course, your results may vary, but I hope not.

I don't have BV, so I can't test this myself .. however, other BV users (namely ladykatsim) do crash with their own lots, so I wouldn't think this can be used as a general recipe.

It seems to work like you say for Simsample:

(..) And if I save the game, it doesn't crash (..) I can consistently reproduce a 7PM crash in the Pbox lots with or without hacks/ mods/ custom content, but only with CAS sims and unsaved lots.

and in a similar fashion for baratron, only that she has up to Pets only (no BV).

Rascal also does not have BV (up to Seasons), and for her it does *not* work:

The very first crash I had was on Plasticbox's Backdoor 42.  I didn't install the invisible driveway or the staircase as I have different versions of both these things already in my game.  Before I moved any sims in I entered the lot in buildmode, changed the staircase and recoloured the driveway and saved the lot.  So I have managed to get a crash on a lot that was altered and saved in buildmode prior to moving in sims.

So, yeah. I for one can't conclude anything from that. I just hope that for you it's really as consistent as it looks like.

Could someone who understands the way the game works please confirm whether it is possible for it to be confused enough to randomly open another Neighbourhood and write into that?

I'm reluctant to say never, but it is EXTREMELY unlikely to ever happen that a document in another program could be corrupted by an array index problem.  (..)  Since the Word program has a separate memory space, it would take something far, far more catastrophic than a Sims 2 crash to do that.

baratron isn't asking about Word, but about other TS2 hoods. (Like anyone here would care about Word files ..)

[ladykat]

All this focus on roofs being on the edge being the issue feels wrong. The only lot of mine I've gotten to crash consistently is my 1x1 brownstone, unreleased. It doesn't have a roof in the traditional sense. I never used the roofing tool. It's a multi-level floored surface.

If anyone wants to test it, here's the link: http://www.4shared.com/file/28206022/94ab3616/Corner_A.html  (requires all EP)

I got it, but I haven't looked at it yet.

I tried something out to see if roofs could make a difference.  I built a house on a 3x3 lot but didn't put any roof on it at all. atthat point I saved and put it onto the lot bin.  I then made 4 versions, one with no roof, one with a floor for a roof, one with gables at the sides, one with gables at the front.  I shrunk all versions to 1x2.

I made 4 blocks, each with 3 houses of the same roof type.  I put CAS sims in the left hand and middle of each sort, with no crashes, and finally I put CAS sims in the other end of each sort and played them through several days.  Not one of those 12 houses crashed.  I can't see that the roof can be causing the crashes, certainly not alone anyway.

A couple of days ago just about every house I did crashed, now they aren't, and the only difference I can see is that right now I don't have even the few downloads I had before!

kat

[Doc Doofus]

(pbox quoting rascal):Before I moved any sims in I entered the lot in buildmode, changed the staircase and recoloured the driveway and saved the lot.

Well, as I said, I changed the roof pattern (and the color of the roof sides)  That might be a significant difference.

Rascal, if you're up to it, please try it again: Backdoor 42.  Repaint and change the roof tile pattern in build mode, save, then move in a CAS Sim and wait for 7pm.

[pbox]

So I'm really quite worried about the potential for bugginess from the game writing to the wrong part of memory getting into the wrong Neighbourhood file, and corrupting one that I actually care about. Anything can happen to N005, but I've worked hard on N004 and don't want it corrupted.

Actually, I think the easiest thing you can do to make sure your other hood is safe in situations like this, would be to simply move the entire N004 folder to the desktop before starting the game.

Rascal, if you're up to it, please try it again: Backdoor 42.  Repaint and change the roof tile pattern in build mode, save, then move in a CAS Sim and wait for 7pm.

Unless I am totally misunderstanding what dizzy said: the problem we're facing is not that it's crashing. The problem is that the game is trying to write stuff where it shouldn't, or read stuff that doesn't exist, and the only thing stopping it at the moment is the OS. This is REGARDLESS of whether or not you see any crashes.

To reiterate:

I'm saying it's probably unsafe. If the index (-192 in my case) is coming from the lot data itself, you may be able to do something about it, but this value changes in different instances of the crashing. In some cases, it's the multiplier (81 in this instance) overflowing (the value 19496 in one of pbox's logs). In either case, it's the same EIP, so this suggests to me that the errant value is being calculated. In other words, the bad offset is probably not coming straight out of the lot file, but rather as a result of a miscalculation because of the walls and their situation.

If you are not getting the error, it is not safe to assume that this miscalculation isn't occurring. In fact, you may well be corrupting valuable data (highly likely, considering the visible corruption of shadows and such at the outset).

Right now, I don't see what we could learn from more in-game testing. Because if he's right, the goal is not to prevent crashes -- the goal is to prevent things going wrong like this in the first place. And you can't see that from within the game.

Maybe there'll be an updated version of the LotExpander that handles off-lot objects differently, or does something else in a different way, or someone writes a fix: then it makes sense to make some new lots and test them, in order to see how it all behaves in-game. Until then, in my opinion the entire shrinking business is ONLY for people who do this in a throwaway neighbourhood that they're prepared to see blow up at any point.

The whole thing is a bit like moving sims between hoods, in my eyes, or deleting all characters: there is no indication that anything's wrong, until it goes all pear-shaped.

[dizzy]

In my opinion, it would be far better if we could determine a way to overlap lots rather than put walls right up to the edge (given the flakiness of build mode).