Falling Through Terrain Bug
by Prairie Games · in Torque Game Engine · 06/23/2005 (9:43 am) · 20 replies
The player falls thru the terrain if they get any sort of velocity going at all. This has been a problem for some time.
I am going to look at it today... has anyone fixed this? Maybe for 1.4? I did try clamping z velocity at -70 and this didn't help...
-Josh Ritter
Prairie Games
I am going to look at it today... has anyone fixed this? Maybe for 1.4? I did try clamping z velocity at -70 and this didn't help...
-Josh Ritter
Prairie Games
#2
-70 z axis velocity is actually pretty slow... and still causes the problem...
-Josh Ritter
Prairie Games
06/23/2005 (10:31 am)
Yes, this is a big issue... our players are constantly falling through the world... I did a forum search to no avail.... Quote: particularly for high-velocity objects.
-70 z axis velocity is actually pretty slow... and still causes the problem...
-Josh Ritter
Prairie Games
#3
06/23/2005 (10:51 am)
I can drop the orc from several hundred meters in the air and land solidly on the terrain (both Atlas and legacy) with no problem. :(
#4
is it something that's easily repeatable for you? like you can go to the same place each time and fall through? or is it more random?
06/23/2005 (10:53 am)
I haven't seen this problem yet, except when my character was scaled down to a tiny level.is it something that's easily repeatable for you? like you can go to the same place each time and fall through? or is it more random?
#5
-Josh Ritter
Prairie Games
06/23/2005 (10:54 am)
Do it 100 times in different spots... I'll load up stock TGE today... I remember it being an issue... -Josh Ritter
Prairie Games
#6
1) Remember last position
2) if "last position" was above the ground, and "current position" is below then you've kissed mama earth, and should react accordingly.
Step 2 could instead involve a raycast from "last" to "current" looking for terrain.
I understand that many physics systems don't maintain an actual velocity at all... they just remember where you were last, are now, and how long ago that was (probably kept system-wide rather than per object). That information, plus any and all forces acting on a given Thing can be used to compute the Thing's new location.
Interiors could cause problems with either of the above solutions. In a "cave mouth" situation, you might get a false positive with the above pseudo-pseudo-code with their method.
EDIT: Another thing: I don't remember ever having Kork drop through the ground when doing a "drop at camera" from On High... Does anyone else run into that with a stock TGE?
--Mark
06/23/2005 (10:57 am)
I suspect you could hack hour way around it thusly:1) Remember last position
2) if "last position" was above the ground, and "current position" is below then you've kissed mama earth, and should react accordingly.
Step 2 could instead involve a raycast from "last" to "current" looking for terrain.
I understand that many physics systems don't maintain an actual velocity at all... they just remember where you were last, are now, and how long ago that was (probably kept system-wide rather than per object). That information, plus any and all forces acting on a given Thing can be used to compute the Thing's new location.
Interiors could cause problems with either of the above solutions. In a "cave mouth" situation, you might get a false positive with the above pseudo-pseudo-code with their method.
EDIT: Another thing: I don't remember ever having Kork drop through the ground when doing a "drop at camera" from On High... Does anyone else run into that with a stock TGE?
--Mark
#7
06/23/2005 (11:03 am)
@Josh it would be interesting to hear what framerate you are running at? that could definitely be a factor.
#8
-Josh Ritter
Prairie Games
06/23/2005 (11:13 am)
I can barely get any falling velocity going in the demo... I haven't been able to fall thru the terrain at a scale of 1 1 1 (though I do remember this happening)... after scaling the player (which our game does), I fell through... -Josh Ritter
Prairie Games
#9
-Josh Ritter
Prairie Games
06/23/2005 (11:52 am)
Alright, I buffed up the mScaledBox z axis some for normal and scaled players... I then leaped off some towers and so far so good... -Josh Ritter
Prairie Games
#10
1) Put a spawn sphere High In The Air
2) At ground level, have a trigger that will kill anything inside it if it stays for longer than one second. (onEnter, schedule a kill in one second, onExit, remove the scheduled command)
3) UNDER GROUND, build a "capture trigger/zone"... a physical zone at 0g, and a "vel = 0" onEnter trigger.
Start it and walk away. Come back later... if your avatar is still in its eternal lemming plunge, you can be reasonably sure no one will fall through the ground.
Instant respawning would be good too.
--Mark
06/23/2005 (1:24 pm)
Testing Suggestion:1) Put a spawn sphere High In The Air
2) At ground level, have a trigger that will kill anything inside it if it stays for longer than one second. (onEnter, schedule a kill in one second, onExit, remove the scheduled command)
3) UNDER GROUND, build a "capture trigger/zone"... a physical zone at 0g, and a "vel = 0" onEnter trigger.
Start it and walk away. Come back later... if your avatar is still in its eternal lemming plunge, you can be reasonably sure no one will fall through the ground.
Instant respawning would be good too.
--Mark
#11
06/27/2005 (6:45 am)
Josh--as you seem to have realized, I'm betting that your player object scaling (which I read from your .plan) is what is causing this. I'm guessing here that scaling the player object down isn't properly scaling your collision with the terrain. It sounds like you've figured out a fix, so it would be great if you could describe briefly the why and how of the fix!
#12
Not sure if you are allowing your players to customize their character height or not via bones but we ran into this as an issue with Adellion. The character height increased uniformly and it pushed the players feet below the terrain. As soon as the character hit an edged slope they could fall through.
We also ran into this problem when we were scaling. If the scale goes below .5 .5 .5 and the character can run fast enough, it can pass through objects like walls. If the character is dropped from a height, it can fall through the terrain in some cases.
We elected to keep the character scale above .5 .5 .5 and to raise the entire model up a bit if the legs got longer. It's a bit tricky since the player can adjust height and you need to compensate and still keep their feet on the ground. We are still playing with it but I can put you in touch with someone on our team who is working on it if that seems to be your problem - email me.
06/29/2005 (8:30 am)
Josh,Not sure if you are allowing your players to customize their character height or not via bones but we ran into this as an issue with Adellion. The character height increased uniformly and it pushed the players feet below the terrain. As soon as the character hit an edged slope they could fall through.
We also ran into this problem when we were scaling. If the scale goes below .5 .5 .5 and the character can run fast enough, it can pass through objects like walls. If the character is dropped from a height, it can fall through the terrain in some cases.
We elected to keep the character scale above .5 .5 .5 and to raise the entire model up a bit if the legs got longer. It's a bit tricky since the player can adjust height and you need to compensate and still keep their feet on the ground. We are still playing with it but I can put you in touch with someone on our team who is working on it if that seems to be your problem - email me.
#13
offset = (scaleNew - 1) / 2
scaleOriginal = 1
scaleNew = 1.5
offset = .25 * height
scaleOriginal = 1
scaleNew = 0.75
offset = -0.125 *height
06/29/2005 (8:50 am)
Hmmm... since the player scales uniformly up and down. The following equation would keep the players feet on the ground at all times. If it only scales down then remove the "/ 2".offset = (scaleNew - 1) / 2
scaleOriginal = 1
scaleNew = 1.5
offset = .25 * height
scaleOriginal = 1
scaleNew = 0.75
offset = -0.125 *height
#14
It not happens on every position only on some so its was hard to find out. It also doesnt matter which height i used to drop the player.
Strange is this only happens when i use the dedicated server on my bsd box.
Edit: i use TGE 1.5
07/21/2007 (7:19 am)
I also have this problem when i change the player boundingBox from "1.2 1.2 2.3" to "1 1 2".It not happens on every position only on some so its was hard to find out. It also doesnt matter which height i used to drop the player.
Strange is this only happens when i use the dedicated server on my bsd box.
Edit: i use TGE 1.5
#15
Anyone have an idea how to prevent this or is there a patch or bugfix in a newer version than 1.50. I did read that in 1.52 was some changes to the unix code. The bad is its nearly unimpossible for me to reproduce the problem. I got several positions on terrain and if i go there it dont happen to me.
If all fails i've to add some code to player.cc which catch the position (maybe < -50) on update move and "beam" the player back to terrain which i not really like.
Edit: i'll try http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=12174 crossing fingers that this solve it.
08/05/2007 (6:17 am)
I still have the problem :( I'am running my game as a Open Beta and sometimes player fall through Terrain on random places. I think its a rounding problem or something only on x86/unix server. Anyone have an idea how to prevent this or is there a patch or bugfix in a newer version than 1.50. I did read that in 1.52 was some changes to the unix code. The bad is its nearly unimpossible for me to reproduce the problem. I got several positions on terrain and if i go there it dont happen to me.
If all fails i've to add some code to player.cc which catch the position (maybe < -50) on update move and "beam" the player back to terrain which i not really like.
Edit: i'll try http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=12174 crossing fingers that this solve it.
#16
This is the approach I usually take for difficult-to-repro/difficult-to-catch-in-the-debugger type bugs like this.
08/05/2007 (11:44 am)
It doesn't seem like it would be very hard to add positional recording baskets/lists to player objects (or something higher in the class tree) so that when you did detect that the position was "under the world", you could dump the last 50 simulation positions to the log file and figure out what exactly happened over the last second and a half or so of the simulation. Basically, at every tick when an object moves, record the current position on the end of a linked list ('std::list' is your friend :) and keep a maximum of 50 or 100 positions. You may even want to keep other stuff like collision data and acceleration data.This is the approach I usually take for difficult-to-repro/difficult-to-catch-in-the-debugger type bugs like this.
#17
Torque does however provide a vector helper class that is very similar to std:list.
08/05/2007 (12:10 pm)
Tim's idea is a good one, but keep in mind that Torque doesn't play well with std unless you make some adjustments (long discussion, but the short answer is that it just doesn't).Torque does however provide a vector helper class that is very similar to std:list.
#18
I'm using it (STL, I mean) quite prolifically, now.
Get Visual Studio 2005 (you can't survive trying to use STL with anything earlier) to be able to see into STL's data structures in the debugger, and you'll be very happy.
08/06/2007 (3:51 pm)
Actually, just removing/disabling Torque's internal memory manager was all that I found necessary to get STL to play nicely with Torque.I'm using it (STL, I mean) quite prolifically, now.
Get Visual Studio 2005 (you can't survive trying to use STL with anything earlier) to be able to see into STL's data structures in the debugger, and you'll be very happy.
#19
08/07/2007 (6:15 am)
The "Fix for ExtrudedPolyList" resource (http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=12174) seams to fix the problem :) I saw it is also integrated into 1.51 so only needed for <1.51.
#20
Any ideas why only one machine would have this problem??
Thanks.
02/13/2008 (7:00 am)
I'm having this problem with TGE 1.5.2 on a Fedora Core 8 machine running a dedicated server. It only happens on this one machine though. I also have Fedora Core 8 running on another machine and there are no problems. Same with a Windows dedicated server - no problems.Any ideas why only one machine would have this problem??
Thanks.
Torque Owner Kirby Webber
There have been issues like this for some time, particularly for high-velocity objects.
If you search the forums, you'll see this has been prominant with hovers and flyers.
I believe that it has been attributed to the integration rate, which can be increased in script, but often doesn't fully alleviate the issue.
Personally, I think that the time/step is getting out of sync between client and server i.e. the object is placed in it's next position before the collision can be registered.
Please please share your findings with the community. =)