I've been over this subject so many times; I almost don't even feel like commenting on it anymore. (Along with this post now, I have made other posts/comments on the GS forums, IX forums and YouTube supporting IX, saying what a great product it is (and GS too).) I will say that when I purchased GS (Extra version first and then quickly upgraded to Commercial because it supported decals and Intense X needed that for its blood decals.) last year back in May, I had already done research and comparisons of all the game engines and decided that GS was the best choice due to its cost, simple licensing, documentation, relatively good performance, stability, fast results (for prototyping/simple games), and most importantly, THIS COMMUNITY. Afterwards, I decided to take another chance on another product, Intense X. And let me tell you, in my opinion it is one of the best purchases I have made. I have learned so much more, so much faster because of IX. It gives you this great base to build off of and it is very flexible. I started off just using the basic features, of course, but after a while I inevitably wanted to do more. And with a little persistence, the help of this community and the flexibility of IX, I have been able to add and do just about everything I have wanted to so far. IX Copper is designed specifically to create first person shooters. But right now I am using it to make a third person/isometric game. After some tweaking of the camera code (and a few other things), it works great, and I have, what I feel is a pretty solid, decent looking little game that I can easily expand on and tweak/perfect when I have time after (sometimes before ) work/college/home. So if this issue with IX is really due to a memory problem with GS, exposed because of IX’s heavy use and reliance on structs, I feel that Conitec should do everything they can to help correct the problem, because IX is really a great asset to GS (and vice versa) and because it is a problem that effects GS as a whole (viability, users, projects, etc...). Also, I do not feel that the decision to correct the memory problem is JCLs. I am sure that JCL has a boss and is told what to do, what is important to spend time, money and resources on and what is not. I am sure JCL has a voice/input on decisions made, but it is not his alone. So we shouldn’t attack JCL, who may be on our side and just as adamant about this as we are.

If JCL doesn’t fix the problem he is missing out on the best Add On ever developed for 3DGS, if completed the sales for 3DGS will go over the top.

I cannot understand why this project seems to be going the way of all the others. IntenseX makes 3DGS the easiest AI to implement of all game makers.

Please don't turn this thread into another engine discussion as then it will only be moved to another forum and completely ignored!

Thanks.

Feel free to open another thread for another engine discussion.

I wouldn't have purchsed GS if not for IntenseX. I'm not a programer and I suspect a lot of people that purchsed GS aren't either.

Quoting Rondidon.

Where is the explicit definition of this "memory bug"?
Almost certainly, it must be in plain sight.

If there would be an expicit definition the crash wouldn`t exist. IntenseX crashes unreproducable by E1513 and E1514 errors after some gameplay. Just read yourself a bit into the IntenseX forums. http://www.intense-i.com/forum/showthread.php?t=447&page=2 (post number #15)
JCL knows about this bug since a few months and it`s caused by the Acnex Engine and not IntenseX if Aris is right.

That doesn't sound like an engine bug, it sounds more like an bug inside Intense X... =/

reading the IX-Forum, Looks like a problem with handeling very big scripts.
(the Example script in the discussion is huge - 12.000 lines of
code, and its just a part of IX.)

Anyhow, lets see how this will resolve, and what the
problem was in the end.

Hmm, "waiting for you to fix the bug" is a strange strategy for a developer.

Please understand that we can certainly fix engine bugs, but normally just don't have the time and resources to fix other people's scripts. IntenseX was an exception here because it's a really excellent software.

We were asked by its author some time ago for help, and could reproduce a crash bug. I remember that it was a handle issue, causing a pointer crash. It's supposed to be fixed in the latest IntenseX version - but I'm not fully sure. The version I got still had that bug, and crashed when the player died.

According to IX`s developers the engine still produces those E1514s that are not caused by IX`s code itself. It has to do with the Acknex Engine (handling big scripts) and can`t be resolved without Conitec`s help because Acknex is closed-source. That`s what we`re waiting for. Are you still in contact with them or did you quit support?