Inside3D!
     

How to create rotating doors?
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Mapping
View previous topic :: View next topic  
Author Message
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Thu Nov 01, 2007 6:04 pm    Post subject: Reply with quote

Nash wrote:
1) func_door_rotating is Chris' rotating door code, which I linked to in my first post in this thread.


I was pointed to this thread by Urre, I didn't read the start.

Nash wrote:
2) Where is the QC code for dpmod's rotating entities? I can't find them in your mod's QC folder.


misc.qc
Back to top
View user's profile Send private message Visit poster's website
Nash



Joined: 19 Oct 2007
Posts: 95
Location: Kuala Lumpur, Malaysia

PostPosted: Fri Nov 02, 2007 5:44 am    Post subject: Reply with quote

Thanks LordHavoc.

Having a lot of trouble porting your rotating code into stock QC 1.06... will have another go at it later tonight when I have more time.

EDIT: Decided to use Preach's solution. It's working good so far... except when RT world is turned off, the door BSP is fullbright.

I want to make sure my maps are playable with and withour RT world. How do I get the door to have proper lighting? The door.bsp is just a map with zero lights BTW...
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger
leileilol



Joined: 15 Oct 2004
Posts: 1321

PostPosted: Fri Nov 02, 2007 6:11 am    Post subject: Reply with quote

Nash wrote:
The door.bsp is just a map with zero lights BTW...


Well there you go. The brush aliasmodels never confine themselves to level lighting. You'd have to go MDL for that.


Dunno how HL did it for func_trains though...
_________________
Back to top
View user's profile Send private message
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Fri Nov 02, 2007 6:34 am    Post subject: Reply with quote

I think all HL fixed was dlights on plats. Which must have been pretty straightforward.
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.
Back to top
View user's profile Send private message
Preach



Joined: 25 Nov 2004
Posts: 122

PostPosted: Fri Nov 02, 2007 8:41 am    Post subject: Reply with quote

I didn't put any lights in because I'm lazy, and the fullbright door looked alright in the test map. You can add lights to door.map and compile them in. They're fixed lights, not changing when you rotate the brush, but that would be true whether you made a seperate map or not, and the same happens in any other game prior to realtime lighting. The advantage of having a seperate map is that you can give it fairly generic lighting that fits the level of the whole section of map it rotates in. If you were compiling it in the same map, and there was some geometry that cast a shadow over the door in the closed position, the same shadow would show up when the door was in the open position, but without anything to cast it this time. So it gives you that little edge of control/less to worry about.
Back to top
View user's profile Send private message
Nash



Joined: 19 Oct 2007
Posts: 95
Location: Kuala Lumpur, Malaysia

PostPosted: Fri Nov 02, 2007 8:44 am    Post subject: Reply with quote

I see. Indeed, this whole multi-file hack is kind of messy.

Okay now I have a question. First, I shall post Chris' code here.

Code:

/*
Chris '06 Hinge Door concepting
Swings from both sides, avelocity overshot issue resolved using .ltime.


RSTATE variable:
0 = idle/closed
1 = active

Due to some origin issues to be able to have the door swing in the correct
fashion depending on where the player hits it you will have to use the
setpointdoor float as a key in the func_door_rotating entity in the map editor.

Their names correspond to when looking down from on top of the door (bird's eye view):
Their angle, if the door is the long way from left to right it is HORIZONTAL. If it is
long from top to bottom it is VERTICAL. The next bit corresponds to which side of the door
has the origin brush which decides from where it will swing from. If the origin brush is
on the left then it is LEFT_HINGE. And if it is on the right it is RIGHT_HINGE. In terms
of VERTICAL doors the LEFT_HINGE would be on the lowest end of the door if looking at it
from the top, and the RIGHT_HINGE would be the top of the door if looking at it from the top
view.

*/
float HORIZONTAL_LEFT_HINGE = 0;
float HORIZONTAL_RIGHT_HINGE = 1;
float VERTICAL_LEFT_HINGE = 2;
float VERTICAL_RIGHT_HINGE = 3;

.float RSTATE, reverse, setpointdoor;
void() thc_door_open;

float(entity targ) infrontofdoor =
{
   local vector   vec;
   local float      dot;
   
   makevectors (self.angles);
   vec = normalize (targ.origin - self.origin);

if (self.setpointdoor == HORIZONTAL_LEFT_HINGE)
   dot = vec * v_right;

if (self.setpointdoor == HORIZONTAL_RIGHT_HINGE)
{
dot = vec * v_right;
dot = dot * -1;
}

if (self.setpointdoor == VERTICAL_LEFT_HINGE)
   dot = vec * v_forward;

if (self.setpointdoor == VERTICAL_RIGHT_HINGE)
{
dot = vec * v_forward;
dot = dot * -1;
}

   if ( dot > 0.3)
   {
      return TRUE;
   }
   return FALSE;
};

void() func_door_rotating =
{
   if (self.sounds == 0)//no sound
   {
      precache_sound ("misc/null.wav");
      precache_sound ("misc/null.wav");
      self.noise1 = "misc/null.wav";
      self.noise2 = "misc/null.wav";
   }
   if (self.sounds == 1)//generic
   {
      precache_sound ("thcdoor/open1.wav");
      precache_sound ("thcdoor/close1.wav");
      self.noise1 = "thcdoor/open1.wav";
      self.noise2 = "thcdoor/close1.wav";
   }
   if (self.sounds == 2)//metal squeaky gate
   {
      precache_sound ("thcdoor/open2.wav");
      precache_sound ("thcdoor/close2.wav");
      self.noise1 = "thcdoor/open2.wav";
      self.noise2 = "thcdoor/close2.wav";
   }
   if (self.sounds == 3)//heavy metal
   {
      precache_sound ("thcdoor/open3.wav");
      precache_sound ("thcdoor/close3.wav");
      self.noise1 = "thcdoor/open3.wav";
      self.noise2 = "thcdoor/close3.wav";
   }
       
   setmodel (self, self.model);
   self.takedamage = DAMAGE_NO;
   self.solid = SOLID_BSP;
   self.movetype = MOVETYPE_PUSH;
   self.RSTATE = 0;
   if (!self.targetname)
      self.touch = thc_door_open;
   
   self.nextthink = self.ltime + 9999999999999999999;
   self.think = thc_door_open;
   
   if (!self.wait)
      self.wait = 0.1;
   
   if (self.targetname)
      self.use = thc_door_open;
   
   if (!self.setpointdoor)
      self.setpointdoor = 0;



   self.avelocity = '0 0 0';

};
void() thc_door_closed =
{
   self.avelocity = '0 0 0';
   self.RSTATE = 0;
   self.nextthink = self.ltime + 9999999999999999999;
   sound (self, CHAN_VOICE, self.noise1, 1, ATTN_IDLE);
   self.touch = thc_door_open;

};

void() thc_door_closing =
{
   self.nextthink = self.ltime + 1;
   self.think = thc_door_closed;

   if (!self.reverse)
      self.avelocity = '0 -80 0';
   else
      self.avelocity = '0 80 0';
   
   sound (self, CHAN_VOICE, self.noise2, 1, ATTN_IDLE);
};

void() thc_door_opened =
{

   if (!self.targetname)
   {
      self.avelocity = '0 0 0';
      self.nextthink = self.ltime + 2;
      self.think = thc_door_closing;
   }
};

void() thc_door_opening =
{
   self.nextthink = self.ltime + 1;
   self.think = thc_door_opened;

   if (!self.reverse)
      self.avelocity = '0 80 0';
   else
      self.avelocity = '0 -80 0';
   
   sound (self, CHAN_VOICE, self.noise2, 1, ATTN_IDLE);
};

void() thc_door_open =
{
   self.avelocity = '0 0 0';
      self.touch = SUB_Null;

if (!infrontofdoor(other))
self.reverse = 1;

if (infrontofdoor(other))
self.reverse = 0;

   if (self.RSTATE == 0)
   {
      self.RSTATE = 1;
      thc_door_opening ();
      sound (self, CHAN_BODY, self.noise1, 1, ATTN_IDLE);
   }

};


To get around WC's habit of stripping the "origin" key from my brushes, I would put this in the QC before any function...

Code:

.vector rotating_door_origin


... and modify the function infrontofdoor, specifically the line that says...

Code:

vec = normalize (targ.origin - self.origin);


to

Code:

vec = normalize (targ.origin - self.rotating_door_origin);


... so that I can put a key called rotating_door_origin in Worldcraft.

It's still not working. What am I doing wrong?
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger
Chris



Joined: 05 Aug 2006
Posts: 78

PostPosted: Fri Nov 02, 2007 11:01 am    Post subject: Reply with quote

What you're doing there is determining how to turn the door based on the origin you predefined in the map editor, but not actually changing the origin of the brush door itself.

If the way you're thinking works (Not quite sure) you could simply set the origin at the end of the func_door_rotating to it's

self.rotating_door_origin .


Now will this move the world brush to this origin or even work? I don't know, but if it would this is how it would do it, and then revert the normalize code back to how it is.

It revolves around the origin of the door / origin brush of door. That whole bit you edited simply controls (quite hackily by the way) the direction player is coming at the door, and map controlled value so it swings in and out correctly from both directions..
Back to top
View user's profile Send private message MSN Messenger
Nash



Joined: 19 Oct 2007
Posts: 95
Location: Kuala Lumpur, Malaysia

PostPosted: Fri Nov 02, 2007 11:15 am    Post subject: Reply with quote

It's not working. Changing the brush's origin will only position it in the world; the fact that it will STILL rotate at world's 0 0 0 remains.

I am now going to read up on hiptnotic's stuff to get it working if I still want to stay with the Quake map format.

(I don't want to use Preach's method because of the lighting problems)
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger
Preach



Joined: 25 Nov 2004
Posts: 122

PostPosted: Fri Nov 02, 2007 1:01 pm    Post subject: Reply with quote

It's not a lighting problem, it's a lighting advantage. You're better off with it in a seperate file. The wierd out of place shadows I was describing are what happens if you keep it in the same map file instead.
Back to top
View user's profile Send private message
Dr. Shadowborg
Inside3D Staff


Joined: 16 Oct 2004
Posts: 726

PostPosted: Fri Nov 02, 2007 4:05 pm    Post subject: Reply with quote

Nash wrote:
Decided to use Preach's solution. It's working good so far... except when RT world is turned off, the door BSP is fullbright.

I want to make sure my maps are playable with and withour RT world. How do I get the door to have proper lighting? The door.bsp is just a map with zero lights BTW...


Note that in worldcraft (unless they changed it since 1.6a) you set the generic lighting of a level via Map->Map Properties then setting the "default light level" to how bright you want it. Compile the map into a .bsp and you should be good to go. (Don't forget to also run light on it! vis probably won't work though, but don't worry about that since it's not like anybody will be loading it up like a normal level anyway without a info_player_start)
_________________
"Roboto suggests Plasma Bazooka."
Back to top
View user's profile Send private message
Nash



Joined: 19 Oct 2007
Posts: 95
Location: Kuala Lumpur, Malaysia

PostPosted: Fri Nov 02, 2007 4:29 pm    Post subject: Reply with quote

Preach, yes but it will look very weird in a generally dark map. Everything's dark then bing! all of a sudden there's a fullbright block standing out in the darkness.

Another disadvantage is that the fake door will not block light coming from outside of the room so any lights outside the room will bleed into the room.

Dr. Shadowborg, yes I use the regular compiling presets for the door so that includes vis and light too. I'll try the default light level.
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger
Preach



Joined: 25 Nov 2004
Posts: 122

PostPosted: Fri Nov 02, 2007 5:14 pm    Post subject: Reply with quote

It won't be fullbright if you add lights to door.map and recompile it as you would any other map with lights. All you have to do is set the light values so that they correspond to that area's light values and it's no longer fullbright! As Dr. Shadowborg says, you can set the default light level and just use that to control it, so the light level is uniform. It's possible that this trick doesn't work if there are no light entities in the map, so if you add one light anywhere then it'll run and use the default level.

As a more complicated example, if the light in your map around that door only comes from floor mounted lights, you could just put 4 conventional lights near to each side of the door, at ground level, and it'd probably make for a good match. Also regular map based doors don't block lights from the other side of the door - other entities aren't considered when lighting the world. So this method is no worse than keeping everything in one file.
Back to top
View user's profile Send private message
spinduluz



Joined: 14 Jan 2008
Posts: 6

PostPosted: Mon Jan 14, 2008 10:39 pm    Post subject: Reply with quote

Sorry I've opened this topic again,

I finally got a door to rotate in a DP Q1BSP map using dpmods info_rotate and func_rotatingdoor. However it doesn't look like the door is handling collisions, it simply kill me and I get a message that I "was in a solid"

Am I doing something wrong or is it some limitation with the Q1 bsp format?
Back to top
View user's profile Send private message
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Tue Jan 15, 2008 5:33 am    Post subject: Reply with quote

spinduluz wrote:
Sorry I've opened this topic again,

I finally got a door to rotate in a DP Q1BSP map using dpmods info_rotate and func_rotatingdoor. However it doesn't look like the door is handling collisions, it simply kill me and I get a message that I "was in a solid"

Am I doing something wrong or is it some limitation with the Q1 bsp format?


Hmm, interesting - I'd better disable that death in dpmod Smile

But there is probably something more dire at work here.

Mind posting a test map (could be a regioned compile of your map or whatever) demonstrating the problem?
Back to top
View user's profile Send private message Visit poster's website
spinduluz



Joined: 14 Jan 2008
Posts: 6

PostPosted: Tue Jan 15, 2008 3:34 pm    Post subject: Reply with quote

LordHavoc wrote:
spinduluz wrote:
Sorry I've opened this topic again,

I finally got a door to rotate in a DP Q1BSP map using dpmods info_rotate and func_rotatingdoor. However it doesn't look like the door is handling collisions, it simply kill me and I get a message that I "was in a solid"

Am I doing something wrong or is it some limitation with the Q1 bsp format?


Hmm, interesting - I'd better disable that death in dpmod Smile

But there is probably something more dire at work here.

Mind posting a test map (could be a regioned compile of your map or whatever) demonstrating the problem?


Yeah I'll post my test map I used when testing this.
http://web.telia.com/~u26503161/test6.zip

I really appreciate that you're looking into this, and feel free to laugh at me if it's just me doing something really stupid! Very Happy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Mapping All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 3 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group