cricket wrote:Not sure I understand why this does not constitute "vector" movement.
Technically the way airplanes move is vector mechanics too - there's a thrust vector, a lift vector, a gravity vector, and drag, which is effectively a negative modifier applied to the first two. (This is a simplification that makes my aeronautical engineering friends reach for something strong to drink...)
A vector is a mathematical expression of magnitude and direction. In this system, every ship has a speed (magnitude) and heading (direction). The limitations on a ship's movement are based on the amount of thrust required to change from one vector to another. (e.g. if a ship starts the turn traveling 3 hexes/turn to the "north" and ends moving 4 hexes/turn to the "south", the amount of thrust applied was 3 + 4 = 7.)
In the context of space combat games, a vector movement system is a system where the vectors of travel are completely independent of the ship's facing. A ship's direction of thrust IS tied to its facing (usually), and changing facing is used to rotate the ship, generate thrust, and create a vector in a different direction, with those vectors being added together and consolidated.
Your system conflates direction of thrust-and-facing to direction-of-travel as a simplification, as a way to minimize record keeping, and does not produce an actual Newtonian vector solution. It does teach players how to maneuver with momentum.
(Your system is like Mode 1 movement in Squadron Strike, vector movement is Mode 2. Your original, momentum-less movement system is equal to Mode 0 movement in SS. AV:T would be Mode 3, since it's vectors, plus continuous thrust over time scales less than a turn, and tracks fuel mass fractions and their impact on thrust.)
The fact that the actual math is hidden from players, or that for simplicity's sake a ship's facing always equals its heading (absent the optional "pivot" rule), doesn't mean the system is any less vector-based (which is typically how I refer to it). But to call it "momentum-based" or "airplanes in space" doesn't really encompass what's going on -- IMHO, of course.
If someone can add or subtract their thrust rating from their current velocity by using the STRAIGHT AHEAD maneuver, why can't they move backwards? This is something that a vector movement system WOULD allow.
If I have a vector of 12 in map direction A and apply a thrust of 3 in direction C (120 degrees off), I will end up with a vector of 9 in A and 3 in B....and my ship (assuming I have one thrust direction capable of moving the ship), will be facing direction C while I do this. This is another thing a vector movement system allows, and yours does not.
Vector movement with Newton's laws is a different experience from what you're providing; you're doing a momentum based movement system. All I'm quibbling on is the terminology; you're using a privileged frame of reference where the ship's facing directs its momentum, hence momentum-based movement.
By the way - consider renaming your STRAIGHT AHEAD maneuver to APPLY THRUST and SLOW DOWN, while moving the "subtract your thrust from your current speed" to SLOW DOWN and make it a fourth maneuver order. I say this because it took my third read through the rules to realize that STRAIGHT AHEAD would slow me down before I caught it, and I was actively looking for "OK, so I can't turn when my speed is higher than my thrust, how the hell do I slow down?"
Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...
Not really - your old 12-point firing arc system where you listed arc letters is 30 degree firing arc resolution. Your nomenclature was interesting; I'd done it as 12-o-clock-is-forward and going clockwise around the base, because most people remember "He's on your 6! He's on your 6!" from WWII movies. 
It does add an extra hex counting step - is the target 3x as far away in one map direction as its adjacent one. If so it's in a cardinal map direction, otherwise it's on a spine.
You could be referring to the firing arc penalty that's part of yourcolumn shift dice system, but I strongly suspect that that's solvable.
I'd also seriously think about referring to these not as -1 and -2 modifiers, but as "column shifts". I'd also set your convention to the base shift as the left most column and make all the shifts go in the same direction, rather than your current minus-and-plus system. It saves a type of math step at the table.