Game Development Community

SceneGraph::rezoneObject(..) wierdness

by Badguy · in Torque Game Engine · 04/16/2002 (6:34 am) · 10 replies

while playing around in this function

SceneGraph::rezoneObject(..)

trying to find out why the zone isnt working client side on my door (which I fixed)

I notice that it uses this function call

mZoneManagers[i].obj->getOverlappingZones(obj, zoneBuffer, &numZones);

to resolve the outsideInclude variable

the wierd thing is that It should be calling this for the SceneObject in hand but the code for InteriorInstance

bool InteriorInstance::getOverlappingZones(..)

never gets processed here .. (I cant figure out why)
so therefore never happens and this is sad as there is so much code behind this for the zoning between
Interior::scanZones(..)
and
Interior::scanZoneNew(..)
(I cant get the debugger into any of these)
as this is the only place that calls getOverlappingZones in the whole engine.

I did debug and watch it process the

bool SceneRoot::getOverlappingZones(..)

for the InteriorInstance which is wierd as this is when its code should go..

am I wrong about this?
my new InteriorMoving is suffering from this as well :)

.. since noone is here yet .. ill just keep going.

so Now im trying to ask the SceneObject its type
getType() but for some reason it only match's my type on the client????
so in this function ive replaced the mZoneManager object manipulation to pass it into a InteriorInstance pointer
and then make the call if the type match's ..
and this only seems to happen on the client?
this is wierd cause its the contructor for this class that sets the type .. so how come it is not always available?

#1
04/18/2002 (4:57 pm)
hmm Maybe someone could check this out?
#2
04/19/2002 (10:19 am)
This is not code many people are familiar with (including me), so you may be on your own for a while :)
#3
04/19/2002 (9:09 pm)
Ok Tim thanks for the response :)

im just about done doors ..
then maybe I can spend some time with these
#4
04/20/2002 (8:35 am)
Just curious about your doors :) How are you doing the paths for the doors? (where are you getting or building path information). How is door position transmitted to the clients? and how are you interfacing the doors to the scripting language? are door shapes TS or Interior shapes?
#5
04/20/2002 (5:02 pm)
Hey! cool interest :)

1) Path's for doors are defined in the *.map
its setup tho so you can change the path id at any time

2) I get the path information now from the PathManager
which needs alot more work before im happy :)
Edit :
to be more specific, for the rotating object I use the
path nodes to calculate angles, I also have sliding pathfollow setup
now what is left will be using a heading and pathfollow

3) ive defined the PathedInterior class ,using all the code provided in InteriorResource
(addChildren(), and other methods for handling Interior)
this object is a GameBase and I have a mask I made to keep the client up to date

4) the datablock defined by the script will be used for attitude on the door.. I havent really payed that much attention yet(I hope to make the connection to the trigger here for best processing)

5) as of now they are Interior objects as ive fixed the export via map2diff (and a couple issues with paths)
I do plan to extend them into using either type (like Mark suggested)
but ive not spent any time there yet

I have some changes planned to make the PathManager more versatile. (I need rotation ie: for when I dont want the heading) and I would like a Realtime path ... Like the one just sitting there in memory .. maybe I will just yank it and use it(serverside)
Plus it seems to have a problem with the transmitPath
ModifyPath .. when adding more than one path via the InteriorInstance::addChildren() I need to figure this one out.

what do you think about these PathManager changes?
#6
04/21/2002 (11:51 am)
Badguy, thats pretty much the approach I was taking to do the moving interiors when I was taking a look.

The Pathmanager class needs spline paths adding to the paths, as well as rotation (preferably quaternion).

I'm adding these alterations right now for some other code, (pathable gamebase objects).

Basically, get it working for linear paths and the spline and rotation paths are easy as.

Phil.
#7
04/23/2002 (10:40 am)
Sounds pretty good to me. It will be awesome to have the path manager running again. Doors, and elevators, are sorely needed.

Tribes 1 had a similar path arrangement, then a basic "pathedObject" class with a simple scripting interface. The object just took care of moving from one path node to another and the scripts did all the logic. I think the methods were something like:

gotoWaypiont(n)
stop()
onCollision(); // Normal collision callback
onWaypoint(); // Called when object reaches node

Travel speed was a datablock property, etc.
#8
04/23/2002 (6:22 pm)
Cool :)
Ok so ill just mention what is left to do before I post what I have,

Displace Displacables.
Rotations in editor are breaking my door angles
(im not considering rotation when calculating angles yet)
Sound (start, end, idle, impact, ?)
Trigger's
.. which for the most part I will leave alone and they can all be handled in the script.
need only then create a PathedInterior::onTrigger(..)
method for your object.
I will handle a variable in the datablock that this function will operate.

then im gonna put some of the more usefull variables into the datablock

Edit:
I dont think itll be a problem to stick in the callbacks you mention .. so far tho ive not considered them :)
#9
04/24/2002 (9:23 am)
@BadGuy, on the zone issue, are you placing a portal brush where the door is?
#10
04/24/2002 (4:09 pm)
Actually no.
but the zone issue was becuase my SceneObject 's bounding box ws not setup proper on the client :)
so it never made it into the Scene.

so therefore it would complain no zones found! :)

fixed that long ago :)
now with sound and a basic displacement out of the way..
only left to tackle calculating the degree properly based on the interior's editor rotations