Hello, I am having a problem that is severely hindering my game.

When I use level_load in the middle of a game to load the next level, the collision system seems to error severely and strange thing happen. Sometimes the player is unable to move while other times the player falls through the floor.

I have had this problem with other games also, so could someone please help me and tell me why the collisions could possibly be acting strange after using level_load in the middle of the game?

I've had this problem as well, but it was only when switching to one level, all the others were fine...

I'll be monitering this thread for results.

There are a lot of things that can go wrong when you load new geometry. If your player starts the new level inside a solid wall, they'll either stick or fall through.

yeah... but the player does not start the new level inside a solid wall in this case. So, can anything else go wrong?

Also, I'm not using the templates at all. So could it be some problem occurring because of a script error? I never encountered this problem before I last updated. I think I had 6.4-something before.

maybe recalculate colision detection via c_setminmax or c_updatehull will solve the problem?
Just idea.

It's not that, and it's a unique problem I've only had with loading certain levels. It's as if the BSP tree was "shifted" over. I can still walk around, but the collision is shifted...

Hope you understand. If not, then i can post a FRAPS vid...


Now that I think about it, it might )somehow) be the player action? It's custom, and does not close when "my" handle is terminated. Since it uses the same "player" handle, could the function still be running?

the c_update hull didn't seem to do anything. is there a way to make sure that the level's hull is updated? The odd thing is that the problem still occurs even when I load the same level over again.

Anyone have an idea? How does everyone else change levels? What Im doing is just using level_load(levelstring) to open a new level, this should work, shouldn't it?

I think the problem might be in custom scripts. The actions (shouldn't), but may still be running if the while loop doesn't check to make sure that "my != null"...

I tried that before though, and there wasnt a difference.