View previous topic :: View next topic |
Author |
Message |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Thu Nov 01, 2007 6:04 pm Post subject: |
|
|
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 |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Fri Nov 02, 2007 5:44 am Post subject: |
|
|
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 |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Fri Nov 02, 2007 6:11 am Post subject: |
|
|
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 |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Fri Nov 02, 2007 6:34 am Post subject: |
|
|
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 |
|
 |
Preach
Joined: 25 Nov 2004 Posts: 122
|
Posted: Fri Nov 02, 2007 8:41 am Post subject: |
|
|
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 |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Fri Nov 02, 2007 8:44 am Post subject: |
|
|
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 |
|
 |
Chris
Joined: 05 Aug 2006 Posts: 78
|
Posted: Fri Nov 02, 2007 11:01 am Post subject: |
|
|
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 |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Fri Nov 02, 2007 11:15 am Post subject: |
|
|
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 |
|
 |
Preach
Joined: 25 Nov 2004 Posts: 122
|
Posted: Fri Nov 02, 2007 1:01 pm Post subject: |
|
|
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 |
|
 |
Dr. Shadowborg Inside3D Staff

Joined: 16 Oct 2004 Posts: 726
|
Posted: Fri Nov 02, 2007 4:05 pm Post subject: |
|
|
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 |
|
 |
Nash

Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia
|
Posted: Fri Nov 02, 2007 4:29 pm Post subject: |
|
|
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 |
|
 |
Preach
Joined: 25 Nov 2004 Posts: 122
|
Posted: Fri Nov 02, 2007 5:14 pm Post subject: |
|
|
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 |
|
 |
spinduluz
Joined: 14 Jan 2008 Posts: 6
|
Posted: Mon Jan 14, 2008 10:39 pm Post subject: |
|
|
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 |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Tue Jan 15, 2008 5:33 am Post subject: |
|
|
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? |
|
Back to top |
|
 |
spinduluz
Joined: 14 Jan 2008 Posts: 6
|
Posted: Tue Jan 15, 2008 3:34 pm Post subject: |
|
|
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!  |
|
Back to top |
|
 |
|