DDL wrote:I just went for a fairly straightforward sqrt approach. Allow for random variation left/right, then calibrate based on that exactly how much total allowable up/down is avaliable to describe a circular field, then randomise that.
Code: Select all
offset = frand()-0.5; //random left/right
upset = 2*sqrt(0.25 - offset**2); //calculate up/down space
EndTrace = StartTrace + (1128*Accuracy * offset*Y) + (1128*Accuracy *(frand()-0.5)*upset*Z); //randomise up/down space. Multiplier is 1128 to account for circular area rather than square
EndTrace += (FMax(1024.0, MaxRange) * vector(AdjustedAim)); //extend end as before
That isn't quite correct. I see what you're trying to do, and it
will approximate a circular cone, but for one thing, treating it as a "circular area" is the same flawed approach that resulted in my initial math problems to begin with, although it's probably very close for the values encountered in-game. Basically, a given method for determining where a point is on/within a circle using its coordinates, or vice versa,
does not work the same way as determining where a ray is along/within a circular cone; I learned that the hard way! You're using math that works for coordinates on a plane, not for angles in three dimensions; more trig is required! Secondly, because you're starting by choosing a flatly-distributed yaw, the pitch and yaw are
not treated similarly by the game. If you were to visualize a probability density (of where a shot is likely to go in the firing cone of possibilities), you'd see that the yaw is flatly distributed but that the pitch is only flatly distributed for each given value of yaw. For higher yaw values, the pitch values are more tightly clustered, because the game scatters the pitch around a vertical line (or rather, set of lines) determined by yaw. In other words, if you stand at a wall and fire a whole ton of bullets at it, the grouping will be tighter vertically toward the left and right edges of the circle, but not tighter horizontally toward the top and bottom (not that you'd want either). Essentially, you're randomizing yaw flatly, but then compressing the randomized pitch to accommodate it, leading to that effect.
Let's say, hypothetically, that 1128*Accuracy in this case equals 85 degrees (of course, it will never be this severe). Now let's say that offset winds up being 0.25, so we're roughly firing diagonally. Upset winds up being roughly 0.866. You wind up firing with 21.25 degrees yaw, and then anywhere between 0 and 36.805 degrees pitch. The final angle of fire winds up being anywhere between 21.25 degrees and 40.14 degrees. For comparison, let's say that 1128*Accuracy represents 10 degrees in a certain case, with the same offset (and therefore the same upset). In this case, yaw is 2.5 degrees and pitch is between 0 4.33 degrees, with an angular magnitude between 2.5 degrees and 5.0 degrees. As you can see, the It's clear to me that not only is the math probably subtly wrong in its concept, but that it's difficult to actually tell
how it's wrong, because it doesn't have any concept of the absolute angle at which you're firing, just the components, and those are determined as if they're points on a circle with a linear correlation between radius of the circle and angular magnitude, which isn't the case. It's just conceptually weird, given the skewed probability distribution and inability to really analyze where the firing cone lies in the general case, and I wish I were better at math so I could further explore it and say some more concrete things instead of rambling like this.
The benefit of my approach is that firing angle (i.e. the angle by which your shot is "off") is easily determined and its limits are predictable, and is guaranteed to be even distributed along the possibilities. Same with the orientation of that trajectory. Either way it's probably not the most realistic way to simulate gunfire, but working within the constraints and assumptions of the game and its scripting engine, I'd say it's probably the best that is actually feasible. The drawback is that there's more math involved, but considering that my seven-year-old Intel-graphics Acer laptop seems to handle it okay and you work with HDTP, I doubt a few added trig functions are a problem to you.
My laser sight code is a bit complicated and weird, but aside from the aforementioned changes I'll have to make to a couple formulas, it's fairly conceptually sound and should work okay. It's a work in progress though, which is why the code is sloppier than usual. The numbers for it are easily tweaked, so feedback is appreciated! The idea there was to make the laser sight useful but not overpowered, borrowing Shifter's concept of having it wander along your potential firing cone (or pyramid, in Shifter's case), but implemented in a way that hopefully feels nicer and respects the real-cone firing angle I have set up.
If I didn't have those constraints (UnrealScript, gameplay assumptions regarding how aim works), it would be interesting to do some kind of gaussian distribution of firing angle, so there's less of a hard outer boundary and shots would be more likely to hit at lower angles than at higher ones. I think some games do that, actually.