Lift platforms?
by Tim "Zear" Hammock · in Technical Issues · 11/14/2001 (5:27 pm) · 29 replies
Not sure if this is the right place for this, but danged if I can see a better place...
Hey GarageGames:
What about lifts? I know there were problems in T1 and there were no lifts in T2 (but there were places for them in the interiors - mebbe dropped due to time constraints or tech problems?).
Any chance TGE will get lifts? I know they present problems, but they would sure improve the engine. Ideally a lift would be a separate interior object with pathing nodes to follow and triggers to set it off, so we could make elevator cars, etc., but even simple platforms would be nice.
Well? Just asking... (with fingers crossed)
Hey GarageGames:
What about lifts? I know there were problems in T1 and there were no lifts in T2 (but there were places for them in the interiors - mebbe dropped due to time constraints or tech problems?).
Any chance TGE will get lifts? I know they present problems, but they would sure improve the engine. Ideally a lift would be a separate interior object with pathing nodes to follow and triggers to set it off, so we could make elevator cars, etc., but even simple platforms would be nice.
Well? Just asking... (with fingers crossed)
#2
Along with rotating/sliding doors, breakable objects(glas), pathnodes, etc....
Because without all this the TGE will very quickly render it self useless.
You cannot make a gmae here in 2001/2002 without any off these things.
The only reason Tribes 2 could do without, would be cos of that damn jetpack.
If we made a game without the option to open door or break windows the gamers communities would laugh at our game and go "wth is this, even Halflife could do that".
// Clocks out
www.flashthunder.com
11/17/2001 (1:31 am)
But you (I & we) should expect the lift entities in TGE.Along with rotating/sliding doors, breakable objects(glas), pathnodes, etc....
Because without all this the TGE will very quickly render it self useless.
You cannot make a gmae here in 2001/2002 without any off these things.
The only reason Tribes 2 could do without, would be cos of that damn jetpack.
If we made a game without the option to open door or break windows the gamers communities would laugh at our game and go "wth is this, even Halflife could do that".
// Clocks out
www.flashthunder.com
#3
Someone do me a simple building, with an opening and a door.dts to go in it, and I'll do you a door. Make me a lift and I'll see if that will work too.
Phil.
11/17/2001 (5:42 am)
Ok, you asked for it....Someone do me a simple building, with an opening and a door.dts to go in it, and I'll do you a door. Make me a lift and I'll see if that will work too.
Phil.
#4
Phil.
11/17/2001 (6:06 am)
Oh, forgot to mention.. if you do the door/lift, make sure its got collision info :))Phil.
#5
I would think it would be best to have the lift/door/etc... to be Worldcraft entities (instead of .dts), as it would really speed up the mapping process.
Mail me the things you'll need, like should the building be a .dts or .dif what triggers/dummies do you need, and I'll make it ASAP.
clocks@flashthunder.com
or ICQ 74050405
// Clocks out
11/17/2001 (7:45 am)
Ok then Phil, I'll do it.I would think it would be best to have the lift/door/etc... to be Worldcraft entities (instead of .dts), as it would really speed up the mapping process.
Mail me the things you'll need, like should the building be a .dts or .dif what triggers/dummies do you need, and I'll make it ASAP.
clocks@flashthunder.com
or ICQ 74050405
// Clocks out
#6
The Torque engine initially had support for doors and platforms created in Worldcraft - but the functionality was never completed, as we ended up cutting those features from Tribes 2 and replacing them with simple force fields.
If you look in interiorInstance.cc, there is a commented out addChildren function that loops through the platform/doors and door paths, constructing them and placing them in groups.
Also, the morian files entityTypes.* and exportGeometry.* describe how door and path nodes are exported into the interior file.
At one point we had doors working entirely except for collision - which is the hard part (especially with the network). This is certainly an area we need to address at some point.
11/17/2001 (10:11 am)
Sorry for chiming in so late on this thread...The Torque engine initially had support for doors and platforms created in Worldcraft - but the functionality was never completed, as we ended up cutting those features from Tribes 2 and replacing them with simple force fields.
If you look in interiorInstance.cc, there is a commented out addChildren function that loops through the platform/doors and door paths, constructing them and placing them in groups.
Also, the morian files entityTypes.* and exportGeometry.* describe how door and path nodes are exported into the interior file.
At one point we had doors working entirely except for collision - which is the hard part (especially with the network). This is certainly an area we need to address at some point.
#7
I'll take a look over the code Mark mentioned and see whats needed to complete it.
Basically Karsten, just do a wall with a door in in worldcraft and get it to export to dif, then send me the map and rmf files and I'll take it from there.
Phil.
11/18/2001 (12:41 pm)
Its going to be harder for me to take them from the entities in worldcraft, but it does seem like the best idea. I'll take a look over the code Mark mentioned and see whats needed to complete it.
Basically Karsten, just do a wall with a door in in worldcraft and get it to export to dif, then send me the map and rmf files and I'll take it from there.
Phil.
#10
Phil.
11/23/2001 (5:19 am)
Havent been able to get to it yet, but we've gone gold, so I'm free on the weekend to take a proper look.Phil.
#11
Over here in denmark 500 copies would probably be gold :)
// Clocks out
www.flashthunder.com
11/23/2001 (5:46 am)
Cool, have many copies is gold in the US.Over here in denmark 500 copies would probably be gold :)
// Clocks out
www.flashthunder.com
#12
11/23/2001 (9:19 am)
Doing collision on the doors is pretty easy, as long as the doors don't try to push people out of the way. Elevators definitely get tricky, mainly because of network prediction. Tribes 1 had elevators (as well as doors), and those of you who player T1 would know how well the elevators behaved :)
#13
12/11/2001 (1:33 pm)
Umm.. let me think... *crush*... vgo. :)
#14
Truth be told, I agree with what was said earlier. Different types of doors are necessary...shattering glass is necessary...lifts are necessary. The list could go on, but if I could just have those three things working perfectly (or at least near it), the creative noose would get a lot more loose.
Scott
12/11/2001 (2:22 pm)
To be quite honest, I think the elevators in Tribes 1 functioned just fine. I'm speaking specifically of the lifts in the base maps, not some of the more wierd player-made maps. The main lift in Scarabrae was fine, as was the lift in Broadside/Blastside. The ONLY time I ever had problems with it were back when I was on dial-up and lagged out for one reason or the other. That would be in line with the aforementioned problems with lifts and network. Truth be told, I agree with what was said earlier. Different types of doors are necessary...shattering glass is necessary...lifts are necessary. The list could go on, but if I could just have those three things working perfectly (or at least near it), the creative noose would get a lot more loose.
Scott
#15
Wolfenstien 3D even had them.
04/06/2002 (5:20 pm)
I'm kind of surprised that GG didn't give this a higher priority. Tribes 2 is the only first person game that I can think of that doesn't have working doors and/or lifts.Wolfenstien 3D even had them.
#16
Elevators are basically useless in T2. There IS a script out there that makes one of a sort (Mr. Zear's Fountains of Paridise map, I believe) and another for some doors but really I don't think either are vital needs for Tribes2.
04/06/2002 (6:47 pm)
Yeah, but they didn't have jetpacks. ;-)Elevators are basically useless in T2. There IS a script out there that makes one of a sort (Mr. Zear's Fountains of Paridise map, I believe) and another for some doors but really I don't think either are vital needs for Tribes2.
#17
04/06/2002 (6:55 pm)
Delta Force 1 & 2 had no working doors or lifts. Delta Force: Landwarrior has one functioning door object, and no working lifts.
#18
im having some major issues regarding the actual use of the pivot point..
ok picture this its all working fine
you can set a pivot point on the door. have the door follow the path and even resolve the angle the door should move to the path node if it is a rotating door
my troubles are
when in editor if you apply angle to the building ..
i need to be able to recreate an offset for the door that matches that angle need some help there...
second
when you put a door on a rotation in the bsp editor seems to mess up my pivot point for rotation
there are other smaller factors ..
but ive done it without too many hacks ..
and used all of the code that is in place
basically I need help at this point or it will take me forever to finish it
anyone wanna help me fix these couple things?
Edit :
I just realized where I posted this :)
for the topic I agree with the precedence of doors as they are very much required in my design .. seeing how close to completion they are is good
I plan to use them extensively and im going to make them fairly versatile
just need to pass these hurdles here then I will make them available
04/06/2002 (7:35 pm)
Ive got doors really close to complete ..im having some major issues regarding the actual use of the pivot point..
ok picture this its all working fine
you can set a pivot point on the door. have the door follow the path and even resolve the angle the door should move to the path node if it is a rotating door
my troubles are
when in editor if you apply angle to the building ..
i need to be able to recreate an offset for the door that matches that angle need some help there...
second
when you put a door on a rotation in the bsp editor seems to mess up my pivot point for rotation
there are other smaller factors ..
but ive done it without too many hacks ..
and used all of the code that is in place
basically I need help at this point or it will take me forever to finish it
anyone wanna help me fix these couple things?
Edit :
I just realized where I posted this :)
for the topic I agree with the precedence of doors as they are very much required in my design .. seeing how close to completion they are
I plan to use them extensively and im going to make them fairly versatile
just need to pass these hurdles here then I will make them available
#19
I've made a little progress on lifts, but I'm to the point where I need a little guidance on implementation.
For the lift, would it be preferable to have parameters that indicate floor levels?
Here's an example of what a mission script might look like:
// %lift is the DataBlock of the lift.
%lift.setFloorCount(3);
%lift.setZOffset(0, 0);
%lift.setZOffset(1, 20);
%lift.setZOffset(2, 30);
%lift.setText(0, "Basement");
%lift.setText(1, "First Floor");
%lift.setText(2, "Second Floor");
// -1 will mean stay where last used
%lift.setDefaultFloor(1);
// code for linking the "up/down elevator buttons"
// %fc1 - %fc3 are DataBlocks of triggers / objects.
%lift.setTrigger(0, %fc1.getTrigger());
%lift.setTrigger(1, %fc2.getTrigger());
%lift.setTrigger(2, %fc3.getTrigger());
// The following will probably be done in setTrigger
// instead of explicitly performed in the script...
%fc1.setLift(%lift);
%fc2.setLift(%lift);
%fc3.setLeft(%lift);
I want to do as much as possible in script because I want to expose the lift behavior to script writers.
Does this look like a decent script interface?
04/15/2002 (2:00 pm)
Any progress made on lifts / doors yet?I've made a little progress on lifts, but I'm to the point where I need a little guidance on implementation.
For the lift, would it be preferable to have parameters that indicate floor levels?
Here's an example of what a mission script might look like:
// %lift is the DataBlock of the lift.
%lift.setFloorCount(3);
%lift.setZOffset(0, 0);
%lift.setZOffset(1, 20);
%lift.setZOffset(2, 30);
%lift.setText(0, "Basement");
%lift.setText(1, "First Floor");
%lift.setText(2, "Second Floor");
// -1 will mean stay where last used
%lift.setDefaultFloor(1);
// code for linking the "up/down elevator buttons"
// %fc1 - %fc3 are DataBlocks of triggers / objects.
%lift.setTrigger(0, %fc1.getTrigger());
%lift.setTrigger(1, %fc2.getTrigger());
%lift.setTrigger(2, %fc3.getTrigger());
// The following will probably be done in setTrigger
// instead of explicitly performed in the script...
%fc1.setLift(%lift);
%fc2.setLift(%lift);
%fc3.setLeft(%lift);
I want to do as much as possible in script because I want to expose the lift behavior to script writers.
Does this look like a decent script interface?
#20
Torque has support for paths, defined for the purpose of moving platforms/doors, which never made it in for T2.
The Path class (engine/sim/simPath.*) is used to define a single path. The Path exists in the mission as a group, whose subobjects are Marker objects defining position and rotation of the path nodes.
The paths are packed and sent to each client after the ghost always objects by the path manager. This way, any object using a path can pack its current position/path state in as few bits as possible.
The interior system at one point had support for doors/elevators via the PathedInterior object. This source was removed and needs to be reconstructed... if you look at the function InteriorInstance::addChildren() (currently commented out), you can see how pathed objects worked at one point.
Ideally an elevator/door should be able to be use an interior sub object or a dts shape as its render source.
04/15/2002 (3:05 pm)
So, let me chime in, a little late :)Torque has support for paths, defined for the purpose of moving platforms/doors, which never made it in for T2.
The Path class (engine/sim/simPath.*) is used to define a single path. The Path exists in the mission as a group, whose subobjects are Marker objects defining position and rotation of the path nodes.
The paths are packed and sent to each client after the ghost always objects by the path manager. This way, any object using a path can pack its current position/path state in as few bits as possible.
The interior system at one point had support for doors/elevators via the PathedInterior object. This source was removed and needs to be reconstructed... if you look at the function InteriorInstance::addChildren() (currently commented out), you can see how pathed objects worked at one point.
Ideally an elevator/door should be able to be use an interior sub object or a dts shape as its render source.
Torque Owner Tim "Zear" Hammock
I would attempt this myself, but based on recent experiences, I am sad to report the conclusion that I am not prepared skillwise to make more than (what basically amounts to) cosmetic changes to the engine itself (and this appears to be somewhat more than cosmetic). Sigh. I follow 3D rendering in concept, but regrettably find myself hopelessly mired when I attempt any useful changes. Sigh again.
I don't expect lifts overnight (I don't expect them at all), I just wondered if it was under consideration, etc.