Crash on resized lots at 7PM -- any ideas?
Inge:
Well it depends on your main reason for wanting lot shrinking. If you dearly wanted to do the Other Factor on your lots, then you'd need to avoid the walls on the boundary (IF and only IF it turned out to be implicated). However for many of us, the idea of proper joined up row houses was the main reason we ever asked for shrinking in the first place. We are obviously therefore very interested in tracking down the Other Factor. What we do know without any doubt at all is that walls and/or roofs and/or floors on boundaries are not a no-go by themselves.
Doc Doofus:
I seem to have a reliable way of avoiding the crash on my lots.
1. Plop down the lot.
2. Go into build mode and modify it. (Repainting it and changing roof color is a good idea if you're setting up a little colony of row houses).
3. Move in your sim whether CAS or other.
I tried to repackage one of the crash-y lots (Backdoor 42) immediately after step (2). I plopped the packaged copy of the fixed lot down and moved in a CAS sim. It crashed. Apparently the packaging process undoes whatever tidying-up and housecleaning that first build-mode edit does.
Whatever. The lots looks really cool and the crashes haven't borked my neighborhood yet, so I'm happy.
You know, I've been playing this game for years now, since the first release, and I've never messed up a neighborhood so badly that I had to stop playing it or couldn't use it. EA really improved on the lousy QA they had with Sims 1, which was not robust at all.
Simsample:
Quote from: pbox on 2007 November 02, 23:33:41
in order to disprove the theory that previously played, "pre-crashed" lots are safe, someone could play those and see if they can get them to crash. I have attached all of my test lots to my post in the R+D thread at mts2 (link see above) -- could somebody download "lot03+04+05+05_post-play.zip" and test lot 3, 4 and 6 to see if you can get them to crash?
Plasticbox, I'm getting inconsistent results with these lots. I could make none of them crash at 7PM or by day/ night toggle, but I did have lots 3, 4 and 5 (but not 6) crash upon loading.
I placed each lot several times and in several situations in the hood, and they didn't crash all of the time- so these results aren't really conclusive. One of the placements of lot 3, I tried 4 different CAS sims to move into it- but each time it crashed. Then I moved the Ramaswamis in with no trouble. However, placing a fresh instance of that lot elsewhere in the hood allowed me to move in and play a CAS sim with no troubles. 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!
I've attached to logs for different lots that crashed upon loading (lots 5 and 3), and here is an image of the graphical glitches I have with the boundary walls:
That's lot 6, which I couldn't make crash!
pbox:
Dizzy:
Can you see any significant difference in the error logs depending on what lot the error occurred on? Or can you point me at where to look in the logs, so that I can see that for myself? (it's probably not very interesting reading, going through 25 logs all over again) This could be interesting in order to see whether there's any difference in what is *on* the lots (walls, roofs, foundations) .. you said
Quote from: dizzy on 2007 November 03, 08:40:21
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.
I can see where it say's "EIP" in the logs but I have no idea where/how to look for an index or overflowing multiplyers, if you'll forgive my ignorance =).
Also:
Quote from: Inge on 2007 November 03, 09:52:28
As soon as the game detects the data is attempting to write to space it's not meant to, it crashes with an access violation. If it was allowing corrupt data to overwrite other parts of the file, you'd be more likely to get your errors or crashes when you loaded another lot, not while you were updating or saving the faulty one. So I think there are inbuilt defences.
I think it's not impossible that this is *exactly* what happened during my test run yesterday. I have never seen so many crashes on load/save before.
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.
(Also, could someone explain "red herring"? Wikipedia says "In literature, a red herring is a plot device intended to distract the reader from a more important event in the plot, usually a twist ending" .. this what you mean? (Non-english person here))
Quote from: Doc Doofus on 2007 November 03, 12:56:36
1. Plop down the lot.
2. Go into build mode and modify it. (Repainting it and changing roof color is a good idea if you're setting up a little colony of row houses).
3. Move in your sim whether CAS or other.
I tried to repackage one of the crash-y lots (Backdoor 42) immediately after step (2). I plopped the packaged copy of the fixed lot down and moved in a CAS sim. It crashed. Apparently the packaging process undoes whatever tidying-up and housecleaning that first build-mode edit does.
Did you try to see what happens when you modify the freshly re-plopped-down lot *again*? Does it work then?
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.
Simsample (and Zazazu and baratron), thanks for your testing. There's no need in trying to make *all* of the lots crash -- one single crash is enough to prove that we can't assume a lot is "safe" just because it did or did not crash during building/playtesting: There is no correlation. This is what I wanted to know. Thank you.
(Simsample, your screenshot doesn't show up for me, but I think I know what you mean -- vertical lines on the border walls?)
Also:
Quote from: Inge on 2007 November 03, 10:19:36
No, but unless you think elimination processes are meaningless we have eliminated walls on the edge of the lot as being the culprit.
How so?
In case you're referring to my test run: only because the wall lots didn't crash for me 3 times in a row, it does not mean there's nothing wrong with them. Again, no crash proves nothing.
The only thing this test run really showed is that there's definitely something wrong with the roofs -- but right now, we have no way of knowing whether the crash on the wall lot (lot 6, phase 5) occurred because of general data corruption of the lot/sim/neighbourhood due to the borken roof lots, because of the walls, because of the moon phase .. all I can see is that it did crash. Simsample crashed with lot 5 (walls), Zazazu with lot 3 (foundations) .. they didn't even download a roof lot; how are the walls "not the culprit" then?
pbox:
Inge,
I'm not up to date with the portal stuff -- this:
Quote from: ingeli on 2007 November 03, 09:47:14
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page