Re: [GZG] FT Vector: Alternative Fire Resolution Distance

Martin:

You have made a somewhat satisfactory argument about endpoint vs.
midpoint fire. It still doesn't address what seems to me requisite
which is a greater number of averaging points for fire. But in a
'discrete simulation of a continuous process' it makes a lot of sense.

Also, an excellent explanation. That could almost live in FT designers
notes.

Bob:

Don't want everything from SFB or AV. AV is interesting and fun, but a
bit to 'mathy' or 'charty' for me generally. I do think SFB is an
excellent cruiser duel game or even for small engagements. Having
played games where it took 4 hours to get throught 32 impulses with
huge fleets, I can say I've seen the pain, but that was stupidity in
fleet sizing.

Damond:

Sort of agree. One thing I find missing is the feel of single ship
combat or even small squadron combat with a bit more detail.

Mind you, that's not what prompted it.

Big Brain:

I disagree with your wisdom at my peril, but.... I am known to be
foolhardy. My problem with 'having a lock every 15 minutes' is this:
You never do.

You might have a good sensor picture every 15 minutes, but unless your
ships are slow or your weapons blanked prodigious amounts of space
instantaneously, by the time you have received the 'locational data'
across the lightspeed lag from where the enemy is, made the firing
adjustments, fired and your weapons move at lightspeed (or less)
across that space, the enemy ship could perhaps easily have moved
enough to be out of the way. I did some math on this a while back and
concluded a lot depends on your assumptions about the accelerations
and ranges, but there are some reasonable assumptions (for game
purposes) of range and acceleration that allow this.

In short, with those basic assumptions on distance and acceleration,
no amount of clarity of sensors will prevent the enemy from having
manouvered and being potentially completely outside of your target
area.

The only thing I see around this is the averaging affect of turn-long
fire. With turn-long fire, you accept that you have a high chance of
not even being in near miss category for a single shot or volley, but
over the whole turn, your guesses and his dodges should at some point
align in your favour, and you'll actually have an opportunity to hit
and maybe penetrate. You're using masses of fire to try to line up a
statistical hit.

At least that's what seems like it should be happening to me. Which,
of course, fails to mesh well with the RAW.

John:

I see a flaw you've pointed out to me. I was thinking since vector
movement is additive, I can apply the 'change of vector' half at the
midpoint. But there's an issue with the reality of that....

The drift part is easy. Drift half before and after locating midpoint.
But that doesn't account for half of the change vector. You need to
figure out what it is. You can't apply half of its instructions.

To illustrate this, assume my drift vector is bearing 0 degrees. My
movement order is Rotate Port 3 (aka 270 degrees) Thrust 4. The net
effect over the turn is to move me 4 units @ 270 degrees the way we
consider it normally, because the RP is instantaneous BEFORE any of
the Thrust 4 is applied. If we tried to do this in halves, we'd Rotate
Port 1.5 (to bearing 315 degrees), thrust 2, then do the same at the
end of movement. The net effect would not put us at 4 units @ 270
degrees from our starting point. I'm a bit lazy to not do the math,
but it would be somewhere between 270 and 315 degrees bearing about
2.8 units away....

Now, I guess you could take the midpoint of the drift and apply half
the turn's aggregate change. That is, knowing that your action is RP3
Thrust 4,  you would know that half of the turn's aggregate change was
2 units bearing 270. If you apply that at both mid and endpoint you'd
still endup where the conventional rules take you.

For some people, something like this would brutally slowdown the game.
I'm willing to try it because I'm used to being done writing orders
before most people start.

Tomb
_______________________________________________
Gzg-l mailing list
Gzg-l@mail.csua.berkeley.edu
http://mail.csua.berkeley.edu:8080/mailman/listinfo/gzg-l