The Pfhorums

I've always appreciated Quartz's theta error diagrams over at the old BattleCat Litterbox site. Now that the Litterbox has sunk below the waves into the depths of Archive.org, I thought I'd make a new diagram in the hopes someone might find my results interesting or useful.

My methodology was perhaps crude, but effective. After raising the dynamic paths in MML and creating a suitable darkroom in Weland, I set each weapon to fire a burst of 1024 slowed-down Pfhor staff bolts, with no recoil and no deltas, of varying errors. I set up a timer, and took a screenshot two seconds after firing. Three rounds of this got me up to theta 53, after which I began to experiment with "no horizontal error," "no vertical error," and "positive vertical error."

For reference, MA-75 primary has an error of 10, a green trooper firing bullets has 30, and a juggernaut firing rockets has 40.

Unique patterns from 0-53: Closeup on 0-11: Closeup on 12-30, as well as no horizontal and no vertical with an error of about 20: Positive Vertical Error doesn't work as I expected it would: taking the absolute value of the vertical theta. Instead, it uses only the top half of whatever pattern is input. I confirmed this behaviour in Marathon Infinity.

Here's theta pattern 40 with Positive Vertical Error. If A1 did anything other than discard the lower half, you'd see a crossed or more evenly spread pattern here. Fortunately Jugg rockets are guided so it doesn't really matter: Here are a few slightly cruder tests in Marathon Infinity using the no-vertical-error shot flag. Unlike Positive Vertical Error, there appears to be some math involved where it takes the error pattern and zeroes the vertical theta. 16 is a notable test, as it rules out the possibility of Infinity discarding out-of-bounds directions like it does with Positive Vertical Error. If that were the case, you'd only see two paths at extreme angles, rather like the M2 Alien Weapon secondary fire.

zero: two: sixteen: EDIT: Thanks to a late-night goof up on my Aleph One no-horizontal-error and no-vertical-error tests, I mistakenly posted that A1 ignores theta when this flag is set, but this is not the case.

Here's a tarball of all the normal patterns in the first pic from before I montaged them. Maybe they'd be useful if someone felt like making ShapeFusion display a little error preview or something. And all the patterns at full resolution in case you're curious:
https://drive.google.com/open?id=19GxHf ... _HcVK7o5aw

The banding patterns are caused by Marathon using a low-quality (by today's standards) PRNG, and it's very noticeable if you fire at a wall with shotguns.

The overall square (as opposed to circular) shape is due to Marathon calculating each projectile's yaw and pitch errors independently and making no attempt to limit the radial error (probably for speed/simplicity).

ravenshining wrote: No Horizontal and No Vertical error, in Aleph One, appear to use a preset linear pattern, regardless of weapon theta.

I don't understand; could you clarify? I played around with a custom physics model for Aleph One and didn't see anything amiss; weapon theta and those two flags all affect the shot pattern shape and size exactly as I expect them to. The code that calculates projectile error is basically untouched since the M2 source release.

As for the patterns, yes, I understand how and why they are created. I'm not saying there's anything 'wrong' with that, I just find it interesting, and as a scenario developer I find it useful to know what exactly those patterns are. For example, with this data one knows it is a bad idea to use a power of 2 for theta unless one is using a no-vertical- (or horizontal-) error flag or one actually desires that effect; or that a Green trooper may fire a more even spread if its theta were nudged to 31 or 29. Granted, for patterns 9 and below excluding 8, it doesn't really matter, but I've had to deal with some weapons using absurdly high error.

As for my supposed 'bug,' my apologies. It appears that at the late hour I was performing these tests I got a few weapons mixed up, which was easy to do since I had changed all their graphics to the fist to avoid excessively long or short firing sequences, and I had to turn off the HUD earlier to get wide enough shots for some of the higher error patterns. It does, in fact, work as it does in Marathon and Marathon Infinity. Before I realised I was wrong I was going to suggest that perhaps the new normalize_angle() function evaluates differently, but if it does it does not do so noticeably.

I've struck out the appropriate passages and will replace the montages with ones that exclude my 20 no (h,v) error later.

ravenshining wrote:Now that the Litterbox has sunk below the waves into the depths of Archive.org, I thought I'd make a new diagram in the hopes someone might find my results interesting or useful.

I always knew the randomness was wonky so it's a pleasure to see the shots plotted. Nice work getting this done for all of us to see.

My brother and I ended up combing through the source code to figure out how the "random" offsets are generated.

Turns out at the most simple level, it is doing bit-wise operations on the contents of a 16 bit memory location. The content is overwritten with each use based on its previous contents, and it eventually repeats. Every time the game starts, it sets the memory location with a default "seed" value.

Anyway, turns out that the default "seed" is as follows:
0xfded

I guess we know what the hud is referencing.