That was sort of the solution in Prydon Gate, the door had a separate visible model and collision shape, and once it was fully open it changed shape.Teiman wrote:a lame way to make the colision part of a rotating door is this:
- don't do it.
Make the door a solid, no one can cross, and make is unsolid wen you start the animation that open it. Lets say.. is binary: is closed and solid or open/opened and nonsolid, the opening animation just eyecandy.
How to create rotating doors?
Yeah did a quick test. A bit tired right now..LordHavoc wrote:Fixed hmap2 bugs with compiling rotating doors, try again.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?
http://icculus.org/twilight/darkplaces/ ... 100113.zip
Rotation with collision works more than good enough in Darkplaces now as far as I'm concerned.
There's still stuff that needs a bit of tinkering but thats my job now I guess
Thanks mate.
The defacto is still Hipnotic rotating entities (Scourge of Armagon).
It sucks, of course. Maybe it was an illusion to think that you could teach an old horse new tricks. There is not really a request from the mappers (there isn't even a "the mappers") for a hipnotic substitute. Quite the contrary - the popular mapper toolkit Quoth kinda cemented the status of the hipnotic way as the default.
I still wish I could have some qc code, general engine support, and map compiler support for "normal" (ie Half-Life etc) rotating brushes. I can't do that myself atm because I already hit my limit with the Remake Quake thing. My plate is more than full :-/
As with many problems, the root of it is that most people actually using rotating doors (ie mappers) don't see the problem with the existing solution; thus, there is no pressure to fix it. You know, "it has been like this for 12 years" and all that.
To put it bluntly, there is not enough innovation in Quake. It is incredibly limiting to have to do stuff the way it was done in 1997, yet most people think that's fine. Darkplaces is halfway innovative, but map compiler support for origin brushes is nonexistent, the most popular map compiler doesn't even support colored light FFS... most engines don't support CSQC even though example implementations exist... I think there are even some engines without support for colored light. There are several different ways to specify fog, to give another example. Creating assets is also unnecessarily hard. The technical side of Quake is largely a disaster, really, hence most mappers for example use the lowest common denominator.
13 years after Scourge of Armagon, its rotating doors are still the standard across Quake as a whole. Speaks volumes, doesn't it.
It sucks, of course. Maybe it was an illusion to think that you could teach an old horse new tricks. There is not really a request from the mappers (there isn't even a "the mappers") for a hipnotic substitute. Quite the contrary - the popular mapper toolkit Quoth kinda cemented the status of the hipnotic way as the default.
I still wish I could have some qc code, general engine support, and map compiler support for "normal" (ie Half-Life etc) rotating brushes. I can't do that myself atm because I already hit my limit with the Remake Quake thing. My plate is more than full :-/
As with many problems, the root of it is that most people actually using rotating doors (ie mappers) don't see the problem with the existing solution; thus, there is no pressure to fix it. You know, "it has been like this for 12 years" and all that.
To put it bluntly, there is not enough innovation in Quake. It is incredibly limiting to have to do stuff the way it was done in 1997, yet most people think that's fine. Darkplaces is halfway innovative, but map compiler support for origin brushes is nonexistent, the most popular map compiler doesn't even support colored light FFS... most engines don't support CSQC even though example implementations exist... I think there are even some engines without support for colored light. There are several different ways to specify fog, to give another example. Creating assets is also unnecessarily hard. The technical side of Quake is largely a disaster, really, hence most mappers for example use the lowest common denominator.
13 years after Scourge of Armagon, its rotating doors are still the standard across Quake as a whole. Speaks volumes, doesn't it.
I thought we got this working already. Just use the hipnotic map compiler to set the rotating brush's "origin" and use the engine+qc code from the thread I posted three posts up.goldenboy wrote:The defacto is still Hipnotic rotating entities (Scourge of Armagon).
It sucks, of course. Maybe it was an illusion to think that you could teach an old horse new tricks. There is not really a request from the mappers (there isn't even a "the mappers") for a hipnotic substitute. Quite the contrary - the popular mapper toolkit Quoth kinda cemented the status of the hipnotic way as the default.
I still wish I could have some qc code, general engine support, and map compiler support for "normal" (ie Half-Life etc) rotating brushes. I can't do that myself atm because I already hit my limit with the Remake Quake thing. My plate is more than full :-/
As with many problems, the root of it is that most people actually using rotating doors (ie mappers) don't see the problem with the existing solution; thus, there is no pressure to fix it. You know, "it has been like this for 12 years" and all that.
To put it bluntly, there is not enough innovation in Quake. It is incredibly limiting to have to do stuff the way it was done in 1997, yet most people think that's fine. Darkplaces is halfway innovative, but map compiler support for origin brushes is nonexistent, the most popular map compiler doesn't even support colored light FFS... most engines don't support CSQC even though example implementations exist... I think there are even some engines without support for colored light. There are several different ways to specify fog, to give another example. Creating assets is also unnecessarily hard. The technical side of Quake is largely a disaster, really, hence most mappers for example use the lowest common denominator.
13 years after Scourge of Armagon, its rotating doors are still the standard across Quake as a whole. Speaks volumes, doesn't it.
We did get it working, I don't see much of a problem. Defacto is that hmap2 has the best support for compiling rotating doors. It's still a problem in other bsp-compilers.
Origin brushes are overrated, you can do fine with the func_rotating->info_null combo to get origin, no need to specify it manually. (Or was it called rotate_object?)
I'm starting to feel like I should make a tutorial for this, as it's still a problem.
Origin brushes are overrated, you can do fine with the func_rotating->info_null combo to get origin, no need to specify it manually. (Or was it called rotate_object?)
I'm starting to feel like I should make a tutorial for this, as it's still a problem.
I was once a Quake modder
I've not read all the thread, so it may have been covered, but couldn't we use models for doors? They'd light differently I suppose and placement may be tricky. It would be even easier if we had map to mdl conversion tool, then you could make the door in the level editor, convert, then 'animate' the open and shutting of it in qme or whatever????
-
- InsideQC Staff
- Posts: 1120
- Joined: Sat Oct 16, 2004 3:34 pm
Problems arise with collisions (unless you have poly perfect collision detection, it'll look stupid with a bbox, which isn't a problem with bsp based entities), and in some engines, perspective making the door's texture look uglahy.ajay wrote:I've not read all the thread, so it may have been covered, but couldn't we use models for doors? They'd light differently I suppose and placement may be tricky. It would be even easier if we had map to mdl conversion tool, then you could make the door in the level editor, convert, then 'animate' the open and shutting of it in qme or whatever????
Back in ye old times, I planned for my medieval game to have doors made out of MDL *and* BSP components. The BSP would be invisible and handle the rotating collision. The MDL would be highly detailed, for example a wooden door made out of irregular planks with possibly some gaps in between, and with frames for different levels of splintery damage. (Yes, this game was going to be OpenGL-only, so no worry about texture warping in software engines.) I never got around to trying it in practice, but it sounds like it should work.
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.