... sort've. Ever have CC crash on you, telling you that it couldn't write to a point in memory? Kinda like this:

"The instruction at 0x730656c0 referenced memory at 0x43df0b60. The memory could not be written."

Well, I managed to get this bug to happen consistently by accident, when doing some stuff. Basically, I had a script that'd spawn a MOSParticle, and then continuously do things to it. For some reason, despite some initial efforts, the MOSParticle would disappear after a certain time (despite it being LifeTime = 0). And as soon as it disappeared, the game crashed. Well, I messed around trying to figure out why, and I realized that when the MOSParticle arbitrarily disappeared, my code was still trying to reference and change variables on it, which is clearly a problem since its kinda hard to reference something that doesn't exist.

The bug here, really, is that the game crashes rather than just giving some kind of Lua console error. Also, I'm sort've wondering if this info might shed some light on the more general problem of the game randomly crashing as it often does. Something is trying to reference something else that isn't there.

This does tend to happen alot.
But then again...... This did happen to me in B22. And even less in B21.

This has happened since Lua was around with CC. I guess there's just no error catching for reading values that don't exist

thats not a problem with cortex command, thats a windows Memory read error, its a problem with your ram.

Its the equivilant of a bad sector on your harddrive, but for ram. that or something you did in CC is trying to read something it didn't write. I've never had this happen with CC, unless I go past 255 MOIDs AND 30K+ particles.

I suggest you re-boot, check your hardware, make sure everything is working correctly, before you play again. (I used to have this problem a lot because my comp had been on for 3 weeks, so I reboot more, and set my VR Mem way up just in case my ram was going.)

MILES, THIS HAS NOTHING TO DO WITH RAM! What is it with you and deciding there is a problem with RAM?
This happens to ANYBODY who tries to get data from an object that no longer exists in CC, and he and everyone else who has pointed has made this unequivocally clear.

"The instruction at 0x730656c0 referenced memory at 0x43df0b60. The memory could not be written." is a windows memory read error, Memory, IE Random Access Memory, or RAM, is what it refers to.

In this case, an Instance that does not exist, attempting to be read, is your computer trying to find something in RAM that is nolonger there. This type of error is caused by several things, A defect in ram is ONE, but there are also memory leaks (software issue) as well as simple problems in code of deleting something and then referring to it.

In this situation it is a problem with RAM (as per the windows ram error "The instruction at 0x730656c0 referenced memory at 0x43df0b60. The memory could not be written." 0xNumbers is a location in RAM, my dad works with computers and I had this error a lot taught me what it is, and fixed it. I know what I'm talking about, this is one of those random things I learned from experience, sorry)

Yes it is a RAM issue, in this instance it is a ram issue, caused by software,

CTRL ALT DEL, end CC's process, you might have it running multiple times from the crash, then start the game again. This error happens a lot when a program is running twice as well (been there done that) the error is sort of a fluke, but its tied to how on a crash CC's process is still in ram. the more that happens, the more often it will crash.

My GOD MAN, how do you go about telling someone who is a Dev for the game how it works? I'm pretty sure he's seen a lot more than you have!

Assume makes an ass out of you and me, Lambda.
"Its the equivilant of a bad sector on your harddrive, but for ram."
Mmm not really. It's more like a segfault. xkcd described it well

yeah, thats the thing, its a different cause, but its the same result.
"The instruction at 0x######## referenced memory at 0x########. The memory could not be written." is the result for both right? can not read RAM. its trying to get something that isn't there. (And yes, I know the #s are in in Hex)

and yes that is actually a question, I'm curious about the differences between bad ram, Segfault, and the rest of those types of errors.



its an issue with the game yes, he is right,

But the issue with the game results in a Memory Read Error, AKA a RAM error, I am right.

We are both right, and you all need to deal with it.

Data forgot to handle some pointer failures. It will very likely be fixed eventually. End of story.

IT'S LEARNING TIME WITH THELASTBANANA EVERYONE!
All righty. First off, let's go take a look at a look at a page on pointers!
All C++ programs with any decent level of complexity are going to use them at one point or another. CC most definitely falls under this category. Pointers are a variable that points to a spot in the computer's memory so it can be used later. In Lua, all the variables are pointers. So, let's say you have an MOSParticle stored as the variable "foo". To get the MOSParticle's position in Vector, we go to "foo.Pos". This gives us a pointer to foo's position so we can read or write to it.
But what happens when foo gets deleted?
foo.Pos is now pointing to somewhere in memory that is no longer foo.Pos! This can cause problems when trying to read or write to that piece of memory, because a different variable (or no variable at all) is now occupying its space, as we could now be writing to a space that is halfway between two bytes that make up a variable. This means that a variable somewhere will be corrupted. If you try to read there, chances are you will arrive at the same problem: you are reading halfway through a variable, not starting at the beginning. To put it metaphorically, it's like attempting to read a book, but starting in the middle. It doesn't make any sense. To a computer, which takes all directives literally, this is even worse. Of course, this is going to result in the computer giving you an error complaining that RAM is not being read or written to properly.
Now, let's take a look at Darlos' problem:

And here's the error:

Given the information you have just been taught, is this a problem with RAM being broken or Darlos having to reboot? I'll let you smart little kiddies figure that one out
As much as you are right that it is a problem with RAM not being accessed properly, you jumped and said, after I had explained the problem, and I quote:

Does that not make it look just a wee bit like you are, once again, telling me that I don't know what I'm talking about? This is now the third thread where I have tried to answer a question about the game and you have shut me down with logic that either doesn't make sense or is just repeating what I said in a way that nobody else can understand.

That makes sense, thank you. I was partially wrong at first, and my secondary argument was misinterpreting your post, as saying that it has nothing to do with ram at all. My apologies.

Now as for his problem I have a question,

If a script creates particles, and the first of the particles expires, how does that remove the code for the particle from being created? thats like removing a single instance already placed makes it unplacable, or in english, if you load a gun with bullets, after you shoot the first bullet, it doesn't know what a bullet is and the entire clip disappears.

Its not the result you came to i'm having a problem with, Its the problem itself. How does the removal of an instance created from a source, remove the source as well? My apologies for not understanding the problem.

Segfaults are exactly what TLB described. It's trying to find something that isn't there.

Miles, it's not so much the code being removed as the source of the variable. When a particle is removed, the program follows the pointer to where the object's memory and variables lies, and replaces them with zeroes.

Uh... what? Where do you get this crap? I don't even know what you're talking about. The source doesn't go anywhere. If anything the problem lies in the fact that when the object disappears, the source is still there trying to call it, which results in a memory read/write error.

Honestly, no more discussion on this issue is necessary. I'm satisfied that Banana clearly knows what the problem is, and that he'll communicate it to the proper folks. That's all I really care about. Everyone else can argue with Miles. I have modding to do.