Rotating Door Support progs.dat + source +example bsp

[Baker]

Target audience: Moderately experienced qc guys with good mapping knowledge at this point.

Download: Rotation Example progs, qc source and bsp [qc for doors borrowed from Avirox's QuakeLife mod.]

Example Command line: c:\quake\darkplaces.exe -game rotate +map rotate_example

Engine this works with: DarkPlaces, FTEQW and Avirox's FuhQuake and, well, if you compile it, both this Flash engine and this Kurok PSP engine.

Status of QC: Appears to work well but the code is a bit messy in places and includes some unnecessary stuff.

Changes: Very few, just doors.qc + addition of hl_doors.qc plus one line in defs.qc and including the hl_doors.qc in progs.src

DarkPlaces Caveats: Oddly enough, the Avirox Rotation engine tutorialized engines (his FuhQuake, my PSP one, my Flash one) work better with collision of rotating objects at least in the example map than DarkPlaces. Honestly the DarkPlaces entity collision with the doors is not very good, but with Avirox's engine tutorial the results are awesome.

FTEQW Caveats: The Quakeworld protocol, like standard NQ, uses bytes for angles (versus DP which uses floats) so despite the fact that FTEQW has excellent collision with doors, the movement feels a bit jerky. I didn't see a sv_protocol cvar in FTEQW to try to get a smoother one.

Future note: I do have a modified FitzQuake 0.85 with rotation support that uses floats for angles and everything is as smooth as you could possibly imagine and the collision is super. However, using floats for angles for smoothness breaks compatibility with all existing NQ protocols so I am considering the idea of adding an exception and using that "protocol" only when maxplayers = 1, sv.active = true, IsDedicated = false and no demo is recording This gets 99% of the benefit at 1% of the effort and inconveniences no one and breaks no compatibilities.

Making a map supporting rotating doors: You must use LordHavoc's hmap2 map compiler and manually create your own origin brushes for now. I have a tool that preprocesses the origin brushes to hmap2's liking to make it easy, but I'm not quite ready to write up instructions on that or therefore link up the tool. (TODO). Also, I need to make the func_door_rotating entity definition for Worldcraft available. (TODO)

My purpose here is at least to start with documenting this and I'm starting with the raw unfinessed QC. (And by posting it, makes it less likely it can disappear or get lost on my hard drive).

[Ranger366]

Thanks baker, i putted it into my "fame" progs, now the Map from Half-Life The-Specialists Roleplay works fine. Only problem is that all Doors begin to rotate with an touch. (oh sorry, just edited hl_doors.qc because at beginning they didnt opened, nevermind)
A tutorial or something else wich tells howto stock progs with Quake-Life Entities will be awesome.

edit: wow, even this same. lol, sorry, doors still do this.

[Baker]

Thanks baker, i putted it into my "fame" progs, now the Map from Half-Life The-Specialists Roleplay works fine. Only problem is that all Doors begin to rotate with an touch. (oh sorry, just edited hl_doors.qc because at beginning they didnt opened, nevermind)
A tutorial or something else wich tells howto stock progs with Quake-Life Entities will be awesome.

edit: wow, even this same. lol, sorry, doors still do this.

QuakeLife is a great mod and Half-Life is a great game, but my goal here is bring rotating doors and objects to Quake and that's the narrow scope of this project.

Doors in Quake open when approached or triggered, so I removed the "push it open" code, but you could look at the hl_doors.qc and doors.qc in Quake Life and use something like WinMerge and add those lines back in the QuakeLife SVN at https://customtf.svn.sourceforge.net/sv ... fe/ql_src/

[Spike]

thought doors didn't open automatically if they had a targetname. This is how come the lift at the start of e1m1 can actually be a door.

traditional doors contain something like:
if (targetname == "") createtriggerarounddoor();

those rotating doors seem to have vaugly similar code, except you actually have to touch the door itself, instead of the area around the door.
except if spawnflag&256 in which case it'll always open when touched.
so I'm not sure what's going on there

[Baker]

He means doors that you have to press +use and such or literally push them open I think.

[Ranger366]

He means doors that you have to press +use and such or literally push them open I think.

i dint knew there is an Quake-Life SVN O_O
and if you mean that i wanna have +use then no, dont need for simple fun deathmatch. the problem still is in the map that when i push one door, all other doors that are func_door_rotating will rotate too, and in darkplaces i will get after 1 and a half minute or so some host errors in subs.qc and doors.qc, but i think i can fix this.

and 1000 thanks for the svn info baker

if i understood here something wrong then sorry, my english is worser than the Half-Life PSP Beta Code...

[Baker]

He means doors that you have to press +use and such or literally push them open I think.

i dint knew there is an Quake-Life SVN O_O
and if you mean that i wanna have +use then no, dont need for simple fun deathmatch. the problem still is in the map that when i push one door, all other doors that are func_door_rotating will rotate too, and in darkplaces i will get after 1 and a half minute or so some host errors in subs.qc and doors.qc, but i think i can fix this.

and 1000 thanks for the svn info baker

if i understood here something wrong then sorry, my english is worser than the Half-Life PSP Beta Code...

My code isn't meant for Half-Life map entities and have no idea how it will react to them and as I get the chance I will be stripping out the rest of the Half-Life specific entity stuff.

But the Quake-Life source is for Half-Life map entities so use that instead.

The code in this will get better as I have more time to make complex maps and do entity testing and things like ensure the doors work right with gold/silver keys and such.

[Ranger366]

My code isn't meant for Half-Life map entities and have no idea how it will react to them and as I get the chance I will be stripping out the rest of the Half-Life specific entity stuff.

But the Quake-Life source is for Half-Life map entities so use that instead.

The code in this will get better as I have more time to make complex maps and do entity testing and things like ensure the doors work right with gold/silver keys and such.

Ok Baker, now there is a big challenge.. get Quake-Life fixing in DarkPlaces, a very important engine, poor that it crashes or you will spawn in the 0 0 0 coordinates...

[Baker]

My code isn't meant for Half-Life map entities and have no idea how it will react to them and as I get the chance I will be stripping out the rest of the Half-Life specific entity stuff.

But the Quake-Life source is for Half-Life map entities so use that instead.

The code in this will get better as I have more time to make complex maps and do entity testing and things like ensure the doors work right with gold/silver keys and such.

Ok Baker, now there is a big challenge.. get Quake-Life fixing in DarkPlaces, a very important engine, poor that it crashes or you will spawn in the 0 0 0 coordinates...

QuakeLife's primary target engine is FTEQW. As a Quakeworld engine, FTEQW will default to DEATHMATCH 1 not deathmatch 0.

You will need to do -game halflife +deathmatch 0 +map c0a1a or whatever because if you don't then it will be in deathmatch mode and there are no info_player_deathmatch entities in Half-Life single player maps.

So this is not the fault of the mod, but that you are using the mod wrong.

[Spike]

if (fteqw)
{
if (dedicatedserver)
deathmatch.default = 1;
else
deathmatch.default = 0;
}

:)


The deathmatch and coop cvars toggle which start spots are used.
As far as I'm aware, its meant to work in DP too, and uses an NQ progs for this reason (its progs.dat and not qwprogs.dat, right?).

Make sure you are using the correct game directory in DP. Halflife maps have no start spots at all, and use info_landmarks to specify the map change areas, or something like that, which will not be recognised by other mods.

DP does not feature a hub system of any kind, thus DP will not preserve the state of each map, and may not spawn you in the correct spot on the next map. But as far as I am aware, it will place you on *a* spot.

[Ranger366]

My code isn't meant for Half-Life map entities and have no idea how it will react to them and as I get the chance I will be stripping out the rest of the Half-Life specific entity stuff.

But the Quake-Life source is for Half-Life map entities so use that instead.

The code in this will get better as I have more time to make complex maps and do entity testing and things like ensure the doors work right with gold/silver keys and such.

Ok Baker, now there is a big challenge.. get Quake-Life fixing in DarkPlaces, a very important engine, poor that it crashes or you will spawn in the 0 0 0 coordinates...

QuakeLife's primary target engine is FTEQW. As a Quakeworld engine, FTEQW will default to DEATHMATCH 1 not deathmatch 0.

You will need to do -game halflife +deathmatch 0 +map c0a1a or whatever because if you don't then it will be in deathmatch mode and there are no info_player_deathmatch entities in Half-Life single player maps.

So this is not the fault of the mod, but that you are using the mod wrong.

i used coop 1 with Quake-Life, but never got it to work with deathmatch only (modifying qc code) that was my problem.

for HL SP im using FTE, but i need the QuakeLife code for "DarkPlaces" Portation on PSP, it gives the perfect base. thanks for all the reply's

[Spike]

read the progs.src of the quakelife code.
there are some #defines in there that define how it is to be compiled.

[goldenboy]

If this really works, it is a solution for a long standing problem. New protocol required is not a problem.... I will try this, and the engine modification, and if it works, it'll be integrated into the RMQ engine and QC. (and maps)

Can't really believe yet that this is real.

[Spike]

[paranoid]
one thing to verify is that pitch rotations work correctly. yaw is easy, but carmack messed up with pitches, you'll likely need to verify that it pivots in the same direction as the renderer.
[/paranoid]

[Baker]

New protocol required is not a problem....

Doesn't require a new protocol at all. A GLQuake or FitzQuake 0.80 client could connect to a server engine with rotation support and play a demo recorded in a rotation-modified client just fine.

It's just physics.

(It would benefit from a protocol or a protocol extension with a bit better angle precision than original NQ or sadly even aguirRe or Metlslime's protocols which do use mere bytes for angles.)