Game Development Community

Waterblock error?

by Chris "Dark" Evans · in Torque Game Engine · 11/30/2001 (5:07 am) · 6 replies

I've noticed that the waterblocks extend farther than they're supposed to. In scorched planet, if I walk away from the water and go down a hill below the water level my player acts like he's in the water. I don't believe this is my bug either. I replaced my engine's terrain directory (the one with the actual code in it, *.cc, *.h, etc.) with the one from 1.1, cleaned out the .obj files, and ran it. It still does the same thing.

Can someone experiment with this? Add an echo in Player::onEnterLiquid() to see if it does the same.

I haven't done anything to the code that would cause this.


Dark
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine


Torque Owner Chris "Dark" Evans
#1
12/01/2001 (7:51 pm)
Yep, just did a complete rebuild right out of the cvs. The waterblock extends farther than it is rendered.

Kind of hard to explain, but if you add an echo in player::onEnterLiquid() and player::onleaveLiquid() you'll see it.

If you walk down a hill that is lower than the waterblock then you will act like you're in water, when you really aren't.


Dark

Torque Owner Tim Gift
#2
12/02/2001 (2:31 pm)
Sonds like a bug with the water container test. Let me know if you confirm it, but I've added it to our bug list.

Torque Owner Chris "Dark" Evans
#3
12/06/2001 (4:48 pm)
It's still doing it. When you walk down a hill that is below the waterblock it thinks you're in the water. It's like there is no container around the sides of the waterblock.


Dark

Torque Owner Chris "Dark" Evans
#4
12/21/2001 (6:19 pm)
Box3f::isOverlapped() and Box3F::isOverlapped() look broken. They look like they only check if the object is on one side, and if the object is on the other side then it says it's overlapped.

Since there's two if statements:

inline bool Box3D::isOverlapped(const Box3D& in_rOverlap) const
{
   if (in_rOverlap.min.x > max.x ||
       in_rOverlap.min.y > max.y ||
       in_rOverlap.min.z > max.z)
      return false;
   if (in_rOverlap.max.x < min.x ||
       in_rOverlap.max.y < min.y ||
       in_rOverlap.max.z < min.z)
      return false;
   return true;
}

It checks if the blayer is on one side, then it checks the other. Which is off.

That's my theory anyway. I'm still testing it, I've got to go now so I'll post my findings when I return.


Dark

Torque Owner Chris "Dark" Evans
#5
12/21/2001 (8:45 pm)
Doh, I was looking at that, and I was reading it wrong.

It looks fine to me now. Really odd bug... :(


Dark

Torque Owner Chris "Dark" Evans
#6
12/21/2001 (10:47 pm)
Ok, I figured it out, I was way off. It has something to do with the removeWetEdges boolean. If you set it to 1 in the .mis file then the water works fine, but when it's 0, it screws up.

In WaterBlock::onAdd():

if(!mRemoveWetEdges)
{
   mObjBox.min.set(-1e4, -1e4, 0);
   mObjBox.max.set( 1e4,  1e4, 1);
}


Then it calls resetWorldBox(). Which doesn't seem to be working in this case.

You can see that it's trying to set x's and y's min/max extremely high/low. I'm assuming so it covers the whole map? It isn't rendering the changes, but it IS computing the size. So the water's there, but you can't see it. I commented the above if statement out for now, and instead added a check in two other if statements:

In WaterBlock::onSceneAdd():

// Attempt to get the terrain.
if( (mpTerrain == NULL) && (mContainer != NULL)  && !mRemoveWetEdges)
{
   mContainer->findObjects( mWorldBox, (U32)TerrainObjectType, SnagTerrain, (S32)this );
   if( mpTerrain )
      mFluid.SetTerrainData( mpTerrain->heightMap );
}

I added " && !mRemoveWetEdges". Do the same thing in WaterBlock::prepRenderImage().

This way it won't look for the terrain, it will render anywhere, even in the air.

Kind of a crappy hack, but I'm new at this. I'm still looking for a real fix.


Dark