Strange Runtime issue/bug with addObject...

Hey guys… I’ve run into a strange issue with the addObject actuator.

In the game I’m working on, I’m using the addObject actuator (calling it from a python script) to add trees to my level. The trees are contained within a separate bounding box mesh that’s supposed to keep the character from walking through them. The actual tree meshes are set to not collide with the character, just the bounding box.

Now, if I run the game from within Blender, the bounding boxes properly keep the character from walking through them as is supposed to happen, no problem there… but if I compile a runtime and play my game from there, only 2 trees (one of each tree type) will behave properly and the rest I can walk right through.
Stranger still, if I add more trees in the runtime manually one at a time (it’s actually part of a level editor for my game, the problem trees occur when I’m loading a level), the bounding boxes will work. It’s almost as though I’m adding the trees too quickly. I’ve tried different things, from adding a delay, to adding the trees and having them add the bounding box to themselves after. It’s crazy. The reason I thought it might be timing based is because if I manually add trees too fast, they’ll show the same behavior as the one’s I add during the loading process. Is this a known bug with compiled runtimes? Is there a workaround for this?
Any help would be appreciated!
I’m not willing to post a blend file right now, only when I’m finished or close to it (I’ve put so much work into this so far). I will however post a video if need be, to show you the behavior. It’d really suck if the only way to play the game is through Blender itself, as it cuts my frame rate in half.

parent your trees to a simplified collision hull mesh, and add the collision hull.
hope that helps, I have moved on to Crystal Space because of such nonsense.

Yeah, that’s what I was originally doing, with the trees parented to the collision hull and adding it (The trees are alpha planes). Switched that up to adding the trees and each one adding the collision hull to themselves after they appeared. Neither one works in the compiled exe, only in Blender itself. Thanks though.
One way I’ve considered was having a ton of collision hulls already on the main layer and having the tree relocate the next available one to the trees location, but that could get messy trying to track the hulls already in use, plus performance issues that might cause.
I think I may have to switch to a different form of motion to fix this. Thankfully I already store which squares are walkable in a grid array, so I’ll just have to set up my movement script to stop movement onto a square that is not walkable. It’ll be more staggered in movement, but at least I’d have full control, and not have to worry about iffy walls that might still be walked through if the character is moving too fast.