Crashing

#1 The only TGE crashes I ever have repeatedly (in 10+ months of working with it) are due to mistakes I have made. It sounds like you have errors with your objects most likely that you haven't found yet.

Have you run your executable under a debugger to find out why and where it is crashing? Most IDE's have a built in debugger, and of course GDB under MinSys/MingW is free.

#2 Hi STEPHEN,

When u say erors with objects what do u mean? Standard objects that are loaded, or scripted objects.

I am gonna do a debug build now to find out
Cheers

Steve

#3 It's hard to tell what types of errors without debugging info :) You mentioned that it is crashing, especiall when colliding with an object or dif. That implies there there are issues with the object or dif, since most implementations don't commonly have crashes like this. Other than that, I can't really give additional info, since we don't have any debugging information at all.

#4 Looks like someone need to learn how to use a debugger, instead of accusing Torque of being unstable

#5 Anthony please dont start an argument - i am sick of arguments on these forumns. I do now how to use a debugger .... okay.... i was just asking had any had similar problem. Please dont jump down my throat.....

#6 Stevie, we've gone over this time and again, and quite honestly, I had the exact same feeling as Anthony. In many, almost all in fact, of your posts, the tone and content of your posts is "TGE is broken" or "TGE can't do this" or along those lines, and seriously...until you can figure out how to get your questions/issues across without alienating the community, you're going to get fewer and fewer helpful answers.

I bit my tongue and went ahead and pointed you in the right direction, simply because I know you mean well, but seriously man, posting questions in a community with the expectation of receiving helpful answers can be an art--and one of the big factors is the apparent attitude that comes across.

The attitude that almost always comes across (and again, I know you don't mean to come across this way...but you do) from you is "TGE is broken, and I want someone to fix it for me", when most of the time, it's something you have done that is causing the issue.

A much better approach to questions would be:


Summary: "Recently I've been having some issues with TGE crashing with my modified/new objects and difs, and I'm trying to figure out how to fix it. I'm using "model app XXX" to create these objects. I've looked through the console logs and not seen anything that looks wrong (although I'm not sure about some of these lines ).

I went ahead and did a DEBUG build, and the crash occurs in "class::method", with . I searched the forums for similar errors, and didn't find anything specific, but I am new to this part of the engine, so I'm not sure if I simply misunderstood something".

Yes, it has the same general content (in some ways) as what you posted...but the huge advantage is that this type of post brings out assistance from the community, instead of the resposes you routinely get.

#7 Listen then all of u - i am fed up to my high teeth of getting into these situations - i wrok hard - very hard at what i do - but it seems u have to think had before posting on these blasted forumns and if u say something that comes across n a wrong way ur blasted for it. I have had more than enough.... more than enough - so stephen if u feel this way, please dont post to me anymore. I have had it up to here...

#8 I have the Tim Aste environment pack. When run torque exits when it trys to loads the pack with the following error:


error, ran over the shapebase assumptions about convex hulls

but there are no .difs in there? strange how this happened with dts objects in that pack


i ran the level and tried to break it, and it was fine - so far

#9 Ok, that is an assert that happens when loading .dts shapes for sure, not positive about .dif, but I've run into it with dts shapes that weren't fully convex, and/or had bad collision nodes/meshes.

Assuming that there are no .dts shapes in Tim's pack, I would start looking at your other models and see if you can further refine the error (crash, not the assert). A possible way of doing this would be to start removing .dts shapes one by one from your mission and see if the assert goes away.

#10 Stephen thanks for just answering my question - apreciated.

No there are dts models in Tim's pack - and that is what are not convex according to the error. In the environment pack - there are tree and rock dts objects. These are what are have the convex error.

Anyways - taken them out - i then had no more errors - and in debug mode the game didnt crash - probs cos movement was that slow - but in release did.

Thanks

Steve

#11 Ok, see if you can figure out exactly which one of the .dts objects is an issue--if it does turn out to be one of Tim's, I',m sure he would like to hear about it!

#12 That should be easy since you know how to use a debugger. When the break happens, check out the contents of the TSShape, or TSShapeInstance that it is bombing on and look for the shape file variable.

#13 In debug mode - torque runs really slow, and no matter what i try to do it wont crash! - maybe its something to do with the speed at which the player hits the objects - i really dont know. In release mode the game just clams up at very unspecific points. To be honest i have had this problem for a while, and tried to find out through out way or another why the problem is so - and i just cannot fathomit.

#14 I have found the problem. Believe it or not, its the water block. After 8 hours today of debugging, and trying different things - one last try was the water. I removed it, and torque does not crash now.

As i remember it is scaled huge, and i do mean huge... so maybe this has some baring on it - because in affect the water lies underneath the terrain, maybe when the player is on part of the terrain , that has the water close underneath, the ray cast methods go nuts... i am gonna try and rescale it now

#15 Good to hear you've tracked down the root cause! Sometimes that happens when you try to modify something to do what it wasn't intended to do--IIRC, you are using a horizontal mirror technique to have reflective water "the poor man's way" (not an insult, just a term!)...it's possible that could be part of the issue as well.

#16 No mate - i am not using the mirror - it was eating too much fps - it is just a standard water block. I even deleted it, and remade one, but the problenm still remains. When i remove the water, the game never crashes,after testing to no end, coliding into objets etc - its very very odd.

#17 Hmm..what's your mission squareSize? If it's not the value 8, there are some hard coded aspects of waterblocks that will cause problems...

#18 Do u mean the terrain sq size? It is 8. Also i for test reasons i have tried with and without the terrain - still happens with the water

#19 Hmm...quite honestly, I'm stumped. Waterblocks aren't an area I've dabbled in too much, so I haven't run across this myself.

A DEBUG build shouldn't be an extreme slow down (not enough I'd think to keep you from duplicating single player testing scenarios) unless the IDE you are using is causing it. Does your IDE allow for "after the crash" exploration of the call stack, or can you only monitor directly as you step through the code?

#20 Stephen, there are a lot of things that would cause something to crash in release and not debug, it's all memory related.

Firstly, the Torque Memory Manager does a lot of clean-up for you in debug mode, and the debug-heap that the compiler runs also wipes your butt for you, so to speak. Stevie, if this truely is totally unmodified Torque than what you are talking about shouldn't happen. (Debug build should be way slower than release, though, that is normal.)

What have you changed in the engine, there has got to be something that changed that the water assumed and is no longer true. This has memory bug written all over it.