How to create rotating doors?

Discuss the construction of maps and the tools to create maps for 3D games.
LordHavoc
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA
Contact:

Post by LordHavoc »

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
Nash
Posts: 95
Joined: Fri Oct 19, 2007 5:56 pm
Location: Kuala Lumpur, Malaysia
Contact:

Post by Nash »

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...
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Post by leileilol »

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...
i should not be here
Sajt
Posts: 1215
Joined: Sat Oct 16, 2004 3:39 am

Post by Sajt »

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.
Preach
Posts: 122
Joined: Thu Nov 25, 2004 7:20 pm

Post by Preach »

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.
Nash
Posts: 95
Joined: Fri Oct 19, 2007 5:56 pm
Location: Kuala Lumpur, Malaysia
Contact:

Post by Nash »

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: Select all

/* 
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: Select all

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

Code: Select all

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

Code: Select all

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?
Chris
Posts: 79
Joined: Sat Aug 05, 2006 5:31 am

Post by Chris »

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..
Nash
Posts: 95
Joined: Fri Oct 19, 2007 5:56 pm
Location: Kuala Lumpur, Malaysia
Contact:

Post by Nash »

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)
Preach
Posts: 122
Joined: Thu Nov 25, 2004 7:20 pm

Post by Preach »

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.
Dr. Shadowborg
InsideQC Staff
Posts: 1120
Joined: Sat Oct 16, 2004 3:34 pm

Post by Dr. Shadowborg »

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)
Nash
Posts: 95
Joined: Fri Oct 19, 2007 5:56 pm
Location: Kuala Lumpur, Malaysia
Contact:

Post by Nash »

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.
Preach
Posts: 122
Joined: Thu Nov 25, 2004 7:20 pm

Post by Preach »

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.
spinduluz
Posts: 6
Joined: Mon Jan 14, 2008 10:20 pm

Post by spinduluz »

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?
LordHavoc
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA
Contact:

Post by LordHavoc »

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 :)

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?
spinduluz
Posts: 6
Joined: Mon Jan 14, 2008 10:20 pm

Post by spinduluz »

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 :)

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! :D
Post Reply