Page 3 of 5
Posted: Thu Nov 01, 2007 6:04 pm
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
Posted: Fri Nov 02, 2007 5:44 am
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...
Posted: Fri Nov 02, 2007 6:11 am
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...
Posted: Fri Nov 02, 2007 6:34 am
by Sajt
I think all HL fixed was dlights on plats. Which must have been pretty straightforward.
Posted: Fri Nov 02, 2007 8:41 am
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.
Posted: Fri Nov 02, 2007 8:44 am
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...
... 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?
Posted: Fri Nov 02, 2007 11:01 am
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..
Posted: Fri Nov 02, 2007 11:15 am
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)
Posted: Fri Nov 02, 2007 1:01 pm
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.
Posted: Fri Nov 02, 2007 4:05 pm
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)
Posted: Fri Nov 02, 2007 4:29 pm
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.
Posted: Fri Nov 02, 2007 5:14 pm
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.
Posted: Mon Jan 14, 2008 10:39 pm
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?
Posted: Tue Jan 15, 2008 5:33 am
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?
Posted: Tue Jan 15, 2008 3:34 pm
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!
