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

[pixiejuice]

Nope - no crash even with shrunk-off groundpaint.     I feel as if I don't fit in!  Everyone else has managed to make at least *one* crashing lot

Not me.  I haven't had any crashing at all.  Not with my lots or anyone else's.

[nil]

lol, I could only make a crashing case with ambiguous result for the half gable wall in the base game with LE. 127B.  But then the rest are fine.

only with LE1277 did I get some crashing cases.

I guess I've already stated the procedures of my approaches in the testings, so I can't think of reasons other than the HW and OS.

I personally still think there's at least a conflict with the shadowing... probably the arrays for it may not be not interpretted as the way LE/LA treats them or it's interpretted in more than that way..

My standing points are:
1. day/night toggle is related to the sun lighting and shadowing: the direction and coloration (RBG ; more yellowish during daytime while bluish at night) are simply switched
2. 1900 is the time when these switch.  If we can start a lot before 0600 to check out the 0700 change, we may further confirm it something in the day/nioght switch that caused a crash.
3. out of tests for the roof crossing the trimmed and the reserved, it shows the shadowing has problems.


I'm making a 20x20 in a 1x1 lot to see if any additional array added will follow the manual preset values.

[Inge]

But one person said they had a mod to make nighttime start at 6pm, and they still got their crashing at 7pm.  That's how the 7pm walkby rumour started (I think)

[nil]

so, what's the mechanism to get the game to switch to the night around 1800?
Does it affect other settings?

If that reported case is true, then my suspected cause is false or that can be an another factor for a crash.

Pretty unfortunately, it can have more than 1 factor. 

1. Shadowing,
2. nighttime sounding,
3. what else happens around 1900?  Maybe, we need a list of that...

[dizzy]

Many things like vampires awakening happens at 7pm, plus there are range checks that will come up like IIRC exterminators stop showing up if you call after 7pm.

[J. M. Pescado]

Yes, but all those things are softcode. It is extremely unlikely that they are the things causing the crash given how isolated they are. Codes like that are all isolated on objects which are not even commonly present on the lot.

[dizzy]

I can quite easily make the game crash with soft code. In fact, it's pretty easy to crash the game with Lua code.

[Mootilda]

It's very unlikely that this condition would corrupt anything, because the game simply crashes and burns spectacularly, preventing the data from saving.

There is only one condition under which this could potentially damage the game saves, and that is if a character was created in that session: I have noticed that the game will write out character files for characters that should not have been committed to disk yet, as can be seen when doing CAS on totally deleted neighborhood, and if the game were to terminate unexpectedly, those files would get left behind, gunking up your data.

I really have to disagree with this.  What JM says is true: if the game crashes, then it won't have time to save the corrupted data.

But, my concern is this:  The game seems to work most of the time.  However, at least one person has experienced increasing numbers of crashes over time.  I'm concerned about what the game is doing with the "corruption" when it doesn't crash.

The access violation means that the game is accessing random memory.  It could easily be corrupting random stuff in its own internal memory without causing an access violation.  The O/S isn't going to stop the game from doing whatever it wants to with memory which belongs to the game - it only really stops programs when they try to access memory which is outside of valid memory space.  So, anything that's loaded into the Sims 2 memory space is in danger of being corrupted.

We know that the game doesn't have strict checks for data corruption.  It could be blindly continuing on, corrupting little bits of stuff as it goes.  If our suspicion about out-of-world objects is correct, the game is only trying to access memory which is "a little bit off" from where it should be.  Given the huge amount of data in a lot file, the most likely thing being corrupted (at least initially), is the lot itself.  So, no crash and the user saves the lot to play another day.  The new bits of corruption are saved with the lot.  The next time it's run, the game corrupts the lot a bit more.  Over time, perhaps it corrupts the neighborhood, or other lots being played, or sims.

I'm not saying that this is happening.  I'm saying that it's a possibility.  That's why someone said that it's better to have a spectactular crash than to have a little bit of corruption which grows and grows.

Some of us have been playing these lots without any sign of corruption or crashes.  Perhaps the shrinking code doesn't corrupt all lots.  Unfortunately, we don't have a LotAnalyzer which will check a lot for corruption and tell us what's corrupted and whether the corruption is spreading.  That's why I consider all of these shrunken lots potentially bad - even if they've never had a crash.

[Zazazu]

so, what's the mechanism to get the game to switch to the night around 1800?
Does it affect other settings?

If that reported case is true, then my suspected cause is false or that can be an another factor for a crash.

Pretty unfortunately, it can have more than 1 factor. 

1. Shadowing,
2. nighttime sounding,
3. what else happens around 1900?  Maybe, we need a list of that...

My suspicion is that the person who has nighttime starting at 6:00 doesn't truly have nighttime then. With Gunmod's Radiance Lighting, dusk falls at 6:00, and true dark doesn't start until 7:00. It's actually a bit darker internally between 6-7. On the couple of lots I could get to crash consistently (oddly, neither of them mine, although I did eventually achieve crashes on my own), I crashed both on day/night toggle from build/buy and on natural progression using the lighting mod - at 7 pm.

Now with my lots that have 1 space on each side, I've still yet to get a crash. Granted, I'm not playtesting at this point with a CAS sim, but I did get crashing around Day 7 on lot load with non-CAS sims on a lot with walls at the edges. The 1-space colonial I'm playing now is at about Day 22.

[pbox]

But one person said they had a mod to make nighttime start at 6pm, and they still got their crashing at 7pm.  That's how the 7pm walkby rumour started (I think)

I just skimmed most of this thread again and can't find any such statement. Inge, are you really sure? Do you have a pointer?

All I've seen seems to indicate the opposite: lots of crashes happening when people (me included) toggle night in build mode, regardless of in-game time. Lots with no lights have been crashing too.

I believe what you're thinking of might be the lights: there are a few fixes that turn on outdoor lights at 7PM (when it gets dark) and not 6PM (as per default) -- people have been talking about this in this thread. (Or, as Zazazu said, a lighting mod that makes use of the dusk and dawn stuff)

[dizzy]

It just occurred to me that maybe CAS sims tend to crash the game because they tend to be at the edge of a contiguous memory pool (I'm assuming that the way they allocate memory is using a pool technique). If this is the case, then maybe the errant pointer is corrupting the sim character file (or nearly so).

[Zazazu]

Baratron, the lights come on at 18:00 in my game, so this isn't a factor in the 18:59 crashes. And if I save the game, it doesn't crash- so surely that means specs/ lighting isn't to blame? Or is my logic wrong?! I don't have any lighting mods in currently (I clean reinstalled a few weeks back), but in case this is relevant here are my specs:

It was that his lights come on at 6, not that it gets dark at 6.

[pbox]

It just occurred to me that maybe CAS sims tend to crash the game because they tend to be at the edge of a contiguous memory pool

Correct me if I'm wrong, but wouldn't this:

And if I save the game, it doesn't crash

(snipped from Zazazu's Simsample quote above)

support that theory? As in, if the game gets to write those corruption-prone sim files to disk, they don't get smashed (or: get in the way) when the light/shadow change occurs (because they're safely out of reach)?

If this is so, or perhaps even if it *might be* so, the cas sim issue would be perhaps be reduced to a side problem .. they suffer the results from a problem with redrawing the night scene, but they aren't the cause of it.

Does this make sense?

(I have seen crashes with no sims involved -- in a completely empty hood, clean templates and all -- which in my eyes also means the sim files aren't causing anything)

[dizzy]

This tells me that if what I surmise is the case, then saving the game does some memory-juggling which causes the said character data to plunged into the middle of random allocations, thus rendering the errant pointer harmless with respect to generating CPU-interrupting exceptions.

All of which is to say that indeed CAS sims are merely a possible correlation to The Problem Factor rather than part of the causation.

[Doc Doofus]

My own suspicion is that there is some field (a square, a field, an index variable, a whatever) that would be normally initialized by the game is sometimes NOT being initialized because walls are on the edges.  However, the flawlessness of the gameplay once you achieve 7:01pm makes me think that when the game gets the opportunity to do some normal housekeeping procedure, things get cleaned up.  That is why I find it interesting that tweaks to the house in build mode so often fix the problem.

Mootilda, I'm not as worried as you are about the corrupted data from the hanging pointer.  Until we know what the problem is, there's no way to know for sure, but nobody has had that kind of corruption yet.  I'm much more worried about the kind of corruption that could be caused by a half-written file interrupted by a crash, or a character file out of sync because of interruption by a crash, as J.M alluded to.

The game's Simantic code interpreter is a virtual machine, written in C++.  Interpreters tend to be more robust than native-code programs when it comes to things like hanging pointers and uninitialized variables.  They do crash, but usually with more grace and little damage. 

[nil]

So, new CAS sims are more advised to run on empty blank lots and get saved first to be older sims before getting evacuated out of the blank lot and moved into a built lot, especially a shrunken lot?

Just wonder.


2 years ago, I downloaded a set of custom windows which crashed my game copy completely dead including both the custom folder and the game files.  I lost my favourite sims at the time and lots.  (No, they don't work any more even with a new game copy or a new custom folder.)

Since then, I don't download windows from those I can't know a bit from.


As for whether walls at the edge is a major cause, I think we need shrunken blank lots and wall at various different locations to help make a point on it.
But in my base game copy, all lots of plainly "wall at the edges" by LE/LA127B didn't get a crash at all. So, I conclude it's at least not a sufficient cause itself.

[dizzy]

The game's Simantic code interpreter is a virtual machine, written in C++.  Interpreters tend to be more robust than native-code programs when it comes to things like hanging pointers and uninitialized variables.  They do crash, but usually with more grace and little damage.

Simantics is not your average interpreter. There is almost no type checking done (outside of an Expression primitive), scope and privacy are completely user implemented, and your only clue to when you pass a bad Id to something like GSC or a Dialog is the Windows Error dialog.

[Inge]

Ooh Dizzy, I see you're sporting a proud pair of bonfires there

[Doc Doofus]

Well, none of us can really know how well or poorly Simantics was implemented, because we don't have source and neither of us worked on it.  I'm simply making a general observation about interpreters and virtual machines.  I've implemented a lot of interpreters, mostly for AI friendly languages like Lisp and Prolog and Logo, which are all very similar, and more basic procedural languages like Basic in its many flavors, and a couple of new languages of my own weird design that were used for proprietary in-house systems.  One of the unique things about interpreters is that they (generally) never have direct access to any machine memory, even through a pointer, because all pointers and variable bindings are managed by the machine.  The machine usually has its own memory management and garbage collection system.  That's why, for instance, when you crash a Java program, you will get a nasty message from the Java machine, but not from the OS.  I take you at you word that Simantics doesn't have the quality robust error-checking that a language like Java has, but they still (VERY likely) have the similarity that memory addressing is indirect and layered.

This is all just to make a bullshit speculative argument that if the virtual machine itself is crashing, it's probably TOO catastrophic to do much damage.

[dizzy]

It pretty much goes without saying, and even in Lua (which is pretty low-level for a script language) you do not access memory directly. I can make Lua crash also, but only the Sims 2 implementation. You see, that's the common element.