04/30/98 Cobra AWE turret

Description:

Agile Wall mounted Extended angle range turret (184 x 108 x 148).
I decided to name it "Cobra" because it is somewhat poised like
the creature of the same name but mainly because it is fast and
lethal. Mobility is the name of the game if you want to defeat
this snake while avoiding its deadly bite. So you'd better run
and run fast because you can't hide (much). Also, even though the
shuffle is way out of style, this critter is sure to bring forth
a renewed interest in this archaic dance ;)
____________________

Technical specifications:

Overall dimensions: Length:184  Width: 108 Height: 148

Minimum pitch angle: -60 degrees (towards floor)

Maximum pitch angle: 90 degrees (towards ceiling)

Minimum yaw angle: 0 degrees

Maximum yaw angle: 360 degrees

Speed: 100 (double the default of 50)

Damage: 2 (default)
	      
Entities: turret_base, turret_breach, turret_driver and info_notnull
                          _
Textures: e1u3/turret2_1   |
          e1u3/turret3_1   |- barrel and breach proper
          e1u1/black      _|

          e1u3/turret6_1 : driver's handle & trigger (just a whim)
                          _
          e1u3/turret5_1   |
  	  e1u3/turret7_1   |
          e1u3/turret8_1   |
          e1u3/turret9_1   |- control cabin (p. of turret breach assy')
          e2u1/metal36_4   |
          e2u1/metal3_1    |
          e2u1/metal3_3   _|
                          _
          e2u1/metal37_1   |
          e2u1/metal3_2    |- control cabin spindles + housings
          e2u1/metal4_2   _|
                          _
          e2u1/metal36_1   |
          e2u1/metal36_2   |
          e2u1/metal37_2   |- main swivel bracket (turret base assy')
          e2u1/metal37_3   |
          e2u1/metal37_4  _|
                          _
	  e2u1/basic1_8    |
          e2u1/blbk2      _|- wall mounting bracket + main spindle

          e1u1/origin : origin brushes

Note: So I used 22 different textures, I wanted it to look good, OK? ;)
      There's nothing in the book that says you can't change them...
      that's if you want to, of course. Oh, another thing: some of the
      textures on the swivel bracket (turret_base) look like they're
      dis-aligned in the editor. DON'T TRY TO RE-ALIGN THEM: they are
      perfectly aligned in the game itself which is what truly matters.
      This is caused by that strange "rotating object texture alignment
      bug" that many of us have experienced when building rotating
      entities in Quake2. It's the only possible workaround of this
      nasty problem.
______________________________

Prefab and map design info:

Just insert this prefab in map, choose the wall on which
it will be placed, rotate the wall mounting bracket ONLY
and move the complete assembly to make the back of the
bracket butt against the wall it will be fixed to. Make
sure that no part of the turret sticks outside the "world"
into the void, otherwise the map won't compile properly.
The size and shape of the mounting bracket is designed to
enable the turret to traverse a full 360 degrees without
penetrating the back wall. Making sure the barrel doesn't
penetrate any angled walls adjacent to the mounting wall
is the resposibility of the map designer. The minpitch
and maxpitch values are already optimized to provide the
maximum pitch range while preventing the barrel from
penetrating the wall bracket itself in the event that it
traverses around the back with the barrel pointing fully
downward. So you shouldn't have to modify those values.

Most importantly, do NOT rotate this prefab in your map.
If you want it to start at an angle other that 0 at the
beginning of the game, set the "angle" key accordingly
but LEAVE THE PREFAB DRAWN AT 0 DEGREES otherwise it
won't work properly. Also, if you want to limit the
sweeping arc of the turret (presently set at 360), make
sure that the PORTION OF ARC in which it traverses DOES
NOT STRADDLE THE 0/360 DEGREE LINE. For more detailed
info on this, read the section at the end entitled:
"An in-depth look at turrets in Q2". It also contains
a small history of the process I went through with this
prefab plus some mildly controversial rant. Frankly, it's
a bit long so you can skip it but if you're interested in
how turrets work, I suggest that you read it.
________________________

General info:

Prefab type: Quake 2

Editors used: Worldcraft 1.6a and qED v2.0

Build time: I stopped counting after the 4th day

Files: You should have: wturret.txt (this file)
			wturret.map

Author: EutecTic (jfgrol@cam.org)

Credits: Valve Software for Worldcraft. Matt Tagliaferri, the creator
         of qED and Id software, the creators of Quake 2.

Legal stuff: This prefab can be used and modified to make maps
             and new prefabs at will provided that it's
             redistributed for free. Oh yes,... a little credit
             is always appreciated ;)
________________________

ADDENDUM: An in-depth look at turrets in Quake 2

Ok, this may be a bit long but I feel that it's worth discussing.

When I first started out (like a month ago), my intention was to build
a very compact wall mount to make the turret hug the wall as closely as
possible. I would then have limited its horizontal arc appropriately to
prevent the turret from penetrating inside the back wall on which it's
mounted with the minyaw and maxyaw attributes for the turret_breach.
In fact, this is exactly what I did and after many hours of modeling
the brushes and changing my mind about 1000 times about their shapes
and sizes, I went for the testing stage. I had figured that I was done
and all that was left was texturing (this was about a week ago).

So here I am, all confident and everything, turret start angle:0,
minyaw: 90 and maxyaw: 270 since my turret point east and is anchored
to the west side wall. I start the game and... whaa? Not only my turret
starts at 90 degs and not 0 but also, it traverses in the portion of
the arc that I specifically want it to avoid: the west half of the
full circle (it's actually traversing 360 degs)... Deception and anger,
followed by my usual 3 or 4 hours of bitching about how unflexible and
improperly tested the Q2 entities are (sorry Id, your game rocks but I
often feel that guys like us were left with their asses hanging in the
breeze when it comes to this. I guess it's my fault for not being a DM
enthusiast instead coz that's where all the "improvement" effort goes).
Oops! Sorry Mr. Cash, you're right. Those aren't bugs, that's just the
way entities work in Q2 right? But I digress...

Well... 2 boxes of Kleenex later, I'm finally over wiping my tears so
I pick up my sorry ass and resign to tedious testing and poring over
the entity source code (again) and I think I found the answer. Angle
orientation in maps go from 0 deg (east) and increase positively in the
counter-clockwise direction; 90 deg (north), 180 (west), 270 (south)
and finally 360 which is the same as 0. And THAT, boys and girls, is
the problem. Even though 0 and 360 are the same in terms of angle, they
are different NUMERICAL values. And the source code of the entity has
to work with numerical values to figure out the initial orientation and
travel arc of the turret. So not only did I find the cause of the
problem but this has also led me to a better understanding of how
turrets behave in the Quake engine. The main conclusions are: 

1. The starting angle of the turret which is set by the turret_breach
   and turret_base angle attribute has to be set at a value that is
   NUMERICALLY greater than the value given to the minyaw attribute AND
   smaller than the value given to the maxyaw attribute in order for
   the turret to ACTUALLY start in that angle orientation.

	IOW:	minyaw < start angle < maxyaw (numerically speaking)

   If this condition is not met, the turret's start orientation will
   default to the value of either minyaw OR maxyaw, whichever is the
   smallest in numerical value. Let's use the initial setup of my first
   prototype of the Cobra turret to demonstrate this:

	Ex. turret_breach and turret_base angle= 0
            turret_breach minyaw= 90 & maxyaw= 270

   Now, the goal here was to have my turret point east at startup and
   travel an arc portion which rotates no farther left or right than
   90 degrees on either side. What actually happened was that the
   turret started at 90 degrees. Why? Because the condition:

	"minyaw < start angle < maxyaw" is not met since
	"90 < 0 < 360" is of course false!

   And of course, it chose the value entered in minyaw because it is
   smaller than the value entered in maxyaw. But wait! If we start from
   the previous example and swap the values of minyaw and maxyaw, the
   turret starts at 270 degrees in the game! WTF? Aha! This is because
   the portion of the full circle in which the turret traverses (which
   I will refer to as the "sweeping arc" from hereon) is straddled over
   the 0 degree line. This creates a particular condition which leads
   us to the next conclusion.

2. The sweeping arc of the turret must never straddle the 0 degree
   line. Otherwise, it will not operate reliably or predictably. Why?
   I'm not exactly sure but I suspect it's due to the way that the
   angle offsets are calculated in the source code to determine the
   sweeping arc of the turret. There is an inherent numerical value
   discontinuity at the 0/360 degree line and I have a hunch that this
   is the root cause.

   The example used above is a typical case of this.

Note:

   The only exception to this rule is if the sweeping arc is a FULL 360
   degrees: the turret will then behave normally as long as minyaw is
   smaller than maxyaw (IOW, minyaw=0 and maxyaw=360). In this case,
   the start angle, whatever its value, always either meets the
   condition:

	minyaw < start angle < maxyaw

   or defaults to minyaw if start angle=360 (which is the same as 0,
   so why would you use that value anyway?)

3. Forget about using negative angle values or values higher than 360
   (using -90 to express 270 or 450 to express 90 degrees for example)
   to try to force the:

	 minyaw < start angle < maxyaw

   condition to be met. Been there, done that... This confuses the
   entity big time and you will only succed in making the operation of
   the turret even more erratic. If you absolutely need the turret's
   sweeping arc to straddle over the 0/360 degree line in your map,
   you have no choice but to let it traverse the full circle, period.

So, to loop the loop, this is the reason why I decided to modify my
first prototype by allowing it to traverse a full 360 degrees. This
also forced me to redesign the wall bracket to provide enough clearance
for the barrel so it won't penetrate the back wall when the turret
traverses around. And also to provide enough downward clearance so the
barrel doesn't penetrate the bracket itself when traversing around the
back while pointing all the way downward. Preserving that wide pitch
range was essential since this was the main characteristic I was aiming
for when I started out. The downside is that the aesthetics have badly
suffered from this by forcing me to replace the sleek and elegant wall
bracket I had in my first prototype by this visually disproportionate
and ungainly angled wall bracket. I could also have made the bracket
pencil thin to minimize the "visual shock" but I feel that would have
been even worse in terms of model realism: IOW, in the real world, a
very small bracket could not support something as heavy as that turret
and I'm very picky about realism.

But overall the most important reason for modifying the turret is to
make sure it is a fully useable prefab when placed in a map so it will
work properly no matter what orientation the map designer needs. This
way, he can place against any wall he wishes in his map (east, west,
north, south or even an angled wall). The only thing he has to worry
about is to rotate the wall mounting bracket ONLY and butt the whole
turret assembly against the wall.

Some textures were rotated to fit the particular shape of those brushes
(the roof support braces). Those might have to be re-aligned after
moving the turret around even if you have he latest version of texture
lock featured in build 072 of QER (it locks everything except textures
with angles other than 0 or 180).

Who knows? Maybe someday we'll have an editor or a game engine that
provides complete, unconditional texture lock but until that day,
the only sure way to avoid this is to move the turret in multiples of
128 in either of all 3 directions (or the size of the largest texture
used in the prefab if you decide to change them) with texture lock OFF
and build the room around the turret instead of the other way around.
Of course, this might not always be possible or even practical.
______________________

Conclusion:

So to conclude, is this "don't straddle the 0 degree line" condition
a bug in the entity or an inherent limitation caused by the way angle
values work? While I'm convinced that some of the Quake 2 entities are
somewhat bugged or flawed, I have a hunch that this one can't really be
fixed although some brilliant programmer might (hopefully) prove me
wrong on this someday...