Quote: "Also, it works perfectly fine if I test the terrain as a mesh in a separate program. So, DP bug or an organic error? "
I'm siding with organic and/or a context anomaly.
This might sound "DUH, that's what I did already" but I'm guessing its relatedto something else you have going on with DP. First off, I too have had reasonable success with the DP + Terrain as static mesh. In fact, in my DarkGDKOOP Lib, I have a demo that does this very technique for a USGS satelite generated terrain - multiple "Memblock" created meshes, with verts adjusted to USGS height data. (Tiled so multiple terrain objects = one ground cover).
This worked fine - but too awhile for the "make static mesh calls" (I never did implement that save/load physics info - my code was a moving target to much at the time but yours seems to have some pieces starting to solidify which is why I mentioned it in last post)
Ok - my long winded suggestion is simply to comment out - or conditionally define (I forget if DBPro lets ya) Any and all Physics aside from that which is necessary to do a basic test of your code - where you can either raycast using DP and get a valid ground hit - or drop one item onto the ground and it reacts to the mesh.
If this works, Then its a matter of iteratively testing as you bring each little "DP" using code back into the mix - and seeing where it chokes. This should enlighten you to what is really going on.. though time consuming - could preserve a lot of code you have written already.
I'm really convinced some new "action" or "line of code" is effecting the values your terrain is relying on - perhaps using the same ID twice some how - or something similiar where the terrain is FINE - then it gets.. well... made "inert" somehow - or something like the controller DP thingy is not honoring it. Note that Dynamic Mesh doesn't work great - you need to use convex for other DP stuff.. basically make a simplified mesh - that is "invisible" but used for the physics environment - and move your "visual" models with the invisible "covex" models movement as DP adjusts it through its course.
Hope this sparks an idea, or something. This is a very cool project - I'm a usually silent fan. But the thought of you ripping a ton of code before a THOROUGH "combing" of your existing (proven to work recently) code... just made me cringe. (I appreciate what is involved with rewrites!)
--Jason
