No mod.  Make sure that Alloy is enabled.  The easiest way to make this happen is play a game using ICO for a little while (might as well just play out a good 2v2 just to get your system going).  Once the game is done, play another game in ICO (without restarting the game and as quickly as possible).  Seems to be the trigger.  If that doesn't trigger it, just quit and remake a game.  Repeat until you get the dump, it will eventually come.

My gut says that there is a variable that needs to be reset when you finish game.  This would explain why it doesn't happen when you start the game fresh.

I fixed one of the causes. Of course there could be more. Thx for the help!

Sure. Buffs that activate on the "OnFinished" condition were being applied during shutdown of the game instance. So when you started a new game, there were buffs in the master buff list which were referencing things that no longer existed. The chance of this happening was pretty rare.

Probably mostly C++ - majority of windows software is, which makes it very hard platform to develop for if you hate pseudo-OO programming like yours truly

hehe...pseudocode object oriented?  or fake object oriented?

Pseudo as in its not real OOP.

Real OOP is SmallTalk: everything is an object and you communicate with objects exclusively via messages.

If parts of the language are in procedural programming with implied object messaging, you have pseudo-OOP.

Since many people find true OOP confusing - in SmallTalk, there is no operator precedence, its a simple left-to-right thing, because algebraic operations are just more objects messaging each other, so why shoudl they have separate rules? - OO languages after SmallTalk use procedural algebra, multiple object inheritance models, and Greenspun's tenth rule instead.

This makes them (generally) lose on power/information density, and gain on flexiblity.

It is ok How....it is just a fancy way of explaining that he meant "fake".  Aaaah....good old Jack O'Neil.

Soor,

Luckily you future programmers will get the benefit of extraordinarily powerful CPU's and massive storage capacities to use with the inefficient but flexible languages of the future.  Considering I taught myself to program in Pascal as a kid, I was not amused when I had to write some programs in Cobol for a college class.  It didn't even seem like a programming language to me.  You should try Cobol...C++ will start to look sexah.

Anyhow, until that future day, I will marvel at how efficiently some games (cough Sins cough) run on an economy computer. 

I kinda liked BASIC...back in the day.  At least it was easy to for my feeble brain to understand.....not that I'm making any statements about its overall value as a programming language.

I think higher level programming languages that abstract away details like garbage collection and other things are still useful.  If you need to write something quickly, do a mockup of a GUI, or need some easy OS neutral code, then a high level language is an OK choice.  Obviously if you need fast system performance you'll want to use something lower level like C to get all the performance you can out of it.  Higher level languages open up programming to more people which is usually a good thing.  I think there are two big issues for programmers in the future.  First, as programming languages begin to build on top of one another and we get even more stuff abstracted away, it becomes increasingly difficult to maintain the language.  It's like building a tower out of blocks, if there's something wrong in C at the lower level this could have a trickle up effect to the higher level languages that are built on top of it.  The other issue which I think is even bigger is the fact that multi-core CPUs will become more popular.  We'll go from 4 to maybe 64 in a fairly short amount of time.  It becomes increasingly difficult for programmers to take both legacy code and even new stuff and get out of the current sequential programming paradigm into some new paradigm where there are tons of cores.  You can't just hardcode support for 2 cores or 4 cores, it has to be a larger change in programming.  New compiler tools and other things should be able to help although I think it's still unclear if they can do everything for us.

Actually, I think strcmp(x, "\0") is wrong.. shouldn't it be ('\0' == x[0]) instead? Fundamentally, x is an array of chars, hence strcmp(x, "\0") implies:

((x[0] == '\\') && (x[1] == '0') && (x[2] == '\0'))

whereas (x == null) is more likely a null (empty) string, meaning ('\0' == x[0])..

See, well, this is what I mean.. Please don't misunderstand me, I'm not trying to run you down or anything.. Simply that an array (a series of bytes one after another) is fundamentally a basic building block of a string, even if it is a vector/class or other dynamic construct of some kind. The difference is that in higher level languages, someone has taken care of the array handling work for you so while it is easier to write/program, it means that the knowldge of the lower fundamentals are "obscured".

Probably the day will come when programmers forget how a buffer overun happens. And maybe one day, if/when that happens, that will be the source of a really big security hole.

I HAVE coded in C before. Skipped C++ (thank goodness) and now play with C# and other languages.

Its may have been 10+ years since Uni, but I believe strcmp checks the two strings (char arrays) char by char

http://www.cplusplus.com/reference/clibrary/cstring/strcmp.html

So if strcmp (x, "\0") ==0 would work (wouldn't it???) - since you are asking to determine if string x is equal to a null terminated empty string.

You are assuming that a string OBJECT in C# (or other .NET language) or Java is the same as how they are done in C or C++. Since they are objects, they have methods etc... In C#, a string is immutable (but has compiler optimisations to allow str1 = str2 + str3 by converting the code to something like

StringBuilder stringbuilder = new StringBuilder ();

stringbuilder.Append(str2);

stringbuilder.Append(str3);

str1  = stringbuilder.ToString();

Maybe - but if the langauge won't allow it (e.g. .NET managed code - cannot overrun buffer) - how can you get a security hole?

Something else to note - unless you REALLY need tight efficent code, higher level languages are easier to develop and are ALMOST as good when compiled. Try writing sockets programming in C# with built in framework support vs C or C++)

Hmm, maybe we are misunderstanding each other here. I mean that "\0" is a string, which is entirely different from the null character '\0'. "\0" as a string takes at least two bytes but '\0' as a null character is only one byte long. The null character ('\0') is therefore used as a string terminator, but the string "\0" just means a '\' character followed by the number '0' and does not have any special meaning to a string. Hence strcmp/strncmp string compare (and such string routines) would look at it differently. Perhaps you can try strcmp(x, "") instead, although I think ('\0' == x[0]) is much faster/lighter.

Look at it another way, in your C# example above, what is the difference between (x == null) and (x == "\0") ?

I don't dispute the object-ness + methods idea of OO. But let me ask a question (pls excuse the high simplification, extrapolate to your fav OO-methods/etc):

str1 = "Hello";

str2 = "World";

str3 = str1 + str2; // which == "HelloWorld"

How did the language/compiler/etc concatenate/join/append/etc the two strings? Chances are they malloc/realloc-ed etc new/more space on str1 then copied the bytes from str1 and/or str2 etc etc. Bottom line is, the strings are still represented as an array at a low level. So the fundamental difference of the string "\0" vs the character '\0' is still there.

That assumes that the guy who wrote the .Net APIs, DLLs, compilers, etc etc all did not make a big mistake. And clearly, those guys needs to understand buffer overruns eh? For example, try writing a Windows Device Driver or Linux Kernel Module in anything but C (not even C++).

I fully agree with you. As I said in my earlier post, such advancements are really useful. For example, I thank God I don't need to write ASM.. But IMHO some fundamental understanding should be learned by programmers at least, even if they write higher level code exclusively.