Watermelon wrote:
1.int vs float
afaik wz map/world coords is in UDWORD or unsigned int32 or positive integer,so we dont need to worry about the overhead of float number calculations.
that's very good. this is one place where the original psx release may have helped us out -- if they didn't make a psx release, we probably would be dealing with a whole lot of floats.
Watermelon wrote:
indirect fire weapons dont shoot as frequent as direct ones,so I think it's better leave them alone.
that's an assumption you're welcome to since you're the one that's taking a stab at it, and you leveraging your time is of greatest importance (and indeed, with stock warzone, indirect fire does shoot much less frequently), but keep in mind, that i have plans for slowly turning the gameloop over to using an asynchronus event-based system, and in doing so, i'll probably try to refine the collision detection system signifigantly.
Watermelon wrote:
3.'maximum hitbox height'
I am using a measure that is similar to your 'maximum hitbox height',basically it gets the body imd height max,then appends the weapon imd height max to the body imd height max value as the 'hitbox z radius' of a droid,though I think I need to change the order of the x,y,z diff checks,since currently it checks x,y diff before z diff.Think x,y diff is alot costy than the cheap target.z - project.z.
all dependent on the system used to locate potential colliders -- since i don't yet know what warzone uses, i can't comment (and the posts i've made above avoid suggesting anything that is dependent on implementation).
Watermelon wrote:
4.detailed projectile info
wz projectile struct is pretty detailed,it already contains most of the info you mentioned:
x,y,z,velocity XY(aka 2D velocity) and its own hp(though it's not used atm i think)
the hp var in that struct could be used as a shortcut to revise the damage system: each time a collision occurs, damage is based on the projectile's hp, and any richochets or penetrations using the code you're making can reduce the projectile hp -- this is probably a far easier stop-gap measure to make penetration and deflection realistic in terms of stopping power until the code is suitable enough to replace that with calculations based on velocity, mass, and a few other things
Watermelon wrote:
5.terrain:
wz does check terrain 'height' against projectile z when updating projectiles every frame,so we dont need to redo this.
granted, it's a fairly cheap calculation, but consider how many seconds it takes for a howitzer shell to strike the ground at maximum range from the time it war fired: usually about 3-4 seconds. if there are 1000 ticks per second, as is suggested by GAME_TICKS_PER_SEC in the source, then it each projectile must, on average, do this calculation 3500 times during its lifetime, or, if the tick rate is much more conservative, as suggested by devurandom, and is 60 ticks per second, then each projectile must make this calculation 210 times during its lifetime.
while 210 times doesn't seem very often, consider that players typically
don't just have one of these artillery units, but instead have somewhere around 12-25+ of these, and when connected to a sensor unit, which puts it at a minimum of 720 calculations per second, or 2520 calculations spent on all projectiles fired in one volley,
just to see if they'd hit the ground or not.
this is especially ridiculous when you realize that you can positively determine exactly when and where a parabolic projectile will strike the ground for about the price of 5-7 of "z terrain check" calculations currently in use -- if we say it takes 7 calculations, and predeterminative calculations were implemented, it would be an automatic minimum of 66% time savings over a howitzer shell's lifetime-worth of terrain collision checks at 60 ticks per second, or a 99.8% time savings spent achieving the same result if the game ran at 1000 ticks per second.
in short,
anything that must be done every tick stands in total opposition to efficiency. even graphics rendering should not be done every tick: ticks should fly by faster than you can render graphics, and updating the screen should be done in a seperate async thread. the only exception to this that i've seen is the very system which manages game time, which, in an aynchronus system, is the event system (in a synchronus system, it's the "game loop").
Watermelon wrote:
6.projectile grouping/chaining:
probably not very useful in wz,since the fastest RateOfFire in wz is 240 per minute,4 rounds per second at max might not worth the efforts of grouping collision checks.
agreed. only if we ever get beyond 240 rounds per minute, say up to 2000, as is common with a number of modern weapons, would it be of any use. keep in mind also, that this is a "inter-tick" calculation though -- the limit to the size of grouping is capped when the weapon's aim drifts enough to start hitting other polys, so it's not so much groups of four, as it would be groups of 12-14 based on the way vehicles tend to stay still currently in warzone. as soon as we start making them move around
or make rapid-fire weapons sweep accross their target it's usefulness is shot to hell until such a time as the rof of weapons increases substantially.
not worth even trying to implement until after we allow more than 240 rounds per minute and do just about everything else that needs to be done, and since it's a bit of a mathematically not-fun solution, only if we find we need to shave processor time/bandwidth by a bit.
the largest benefit of figuring out where a given projectile has possible collision zones is that when a projectile is not within one of those zones (in my first diagram above, those non-collisions zones are represented by the red dashed-lines), which comprises the majority of the flight time, the projectile literally disappears from gameplay, from the perspective of the server -- it is stored away in memory, but the processor doesn't spend a single instruction handling that projectile until the collision detection event it registered ends up on the front of the queue, at which point it magically reappears into gameplay, and most importantly, this super-efficient magic act has exactly the same outcome as if you did it tick by tick. of course, all the client does is render every projectile as having followed a parabolic path, and even though a projectile temporarily disappears from gameplay on the server, the client continues to render based on its original trajectory and velocity, but in no case would the client ever perform any sort of collision, since it relies on the server sending collision data to it, which both looks really nice, and saves a whole lot of processing power for each client.
themousemaster wrote:
I have a question regarding all that math above...
You say to leave vtols out of random hit algorithms (which is fine).
And to use a parabolic trajectory for long range shooting (which is fine)...
But what about direct-fire vtol weaponry? As the point of origin is somewhere in the atmosphere, what type of calculations would get applied to them? Or is it the case where we assume all vtols are firing lineraly, AND that since they have the advantage of elevation, that there is no "collide with anything else mid-route" calculation?
While the 2nd of those sounds easier, I'm not sure you could use it, because if the projectile misses its mark, it still has to collide with something...
hadn't really thought about vtol weaponry until you mentioned it, but it can fall into this quite nicely. if we assume that vtols fly at a fixed altitude agl (above ground level), which, afaik, they currently do, we can do some things a bit easier too, though i personally wouldn't mind seeing free-flight piloting done by the ai, to where they climb or dive to evade enemy fire, or where early sight radar (which doesn't depend on satellite updates) have difficulty seeing vtols who's pilots are experienced enough to fly low and fast.
so... if vtols do have a fixed height, we can remove the "parabolic weapons ignore vtol" rule, by, at projectile creation, adding an event to check if the projectile is
inside of a vtol on the tick when it has climbed to that altitude (and eventually, if it keeps flying, at the tick when it falls back to that altitude), and if it is determined that it is within a vtol, calculations can be made to determine the exact poly and direction of impact. again, this'll be something of a pointless endeavor, since, while a very cheap collision check, you'll find that even when shooting into skies littered with vtols, these collisions will have less than a 1% chance of happening, and if vtols are ever given freedom of movement in the vertical sense, then trying to detect collision against vtols here would be ridiculously expensive.
so, whether or not the above holds, you did ask about
vtol based weaponry, which made me realize a flaw in my suggestion that needs correcting. my flaw was that the decision points for determining whether a direct-fire projectile will start out being treated as having a linear-flight or parabolic-flight model was based on the assumption that all terrain was flat and level, which, as coyote25 pointed out, that certainly isn't the case. so, the calculations to determine linear or parabolic just need to be modified to take the delta-z between the muzzle and the terrain at that "maximum threshold" distance thing along the direction of the target. somewhat hard to describe -- i might make a diagram for that if someone wants it.
anyways, given the above modifications, vtols would take almost the opposite approach than would ground units: on fixed altitude (agl) flying, air-to-air direct fire weaponry would behave much like ground-based direct-fire weaponry: the same linear vs parabolic flight model would be chosen, depending on the type of weapon, but this time using the terrain offset by the fixed flight altitude (effectively, vtols would become virtual ground units for the scope of this decision), and as soon as the projectile passes through and below the flight altitude of the target area, it becomes parabolic and effectively disappears from gameplay (as described above) until it is
cDetectionHeight above the ground, at which point detection once again occurs.
any vtol weaponry that is targeting something on the ground would usually work like a parabolic artillery shell fired from its peak altitude, though there are a lot of exceptions to this, such as firing at terrain that is higher than the vtol's current altitude, which might benefit from a meshing of the concepts of air-to-air and air-to-ground -- i'd have to think about this a little more, and see if i can figure out any good clean way to do it.
also, occasionally projectiles simply leave the edge of the map: sometimes projectiles don't collide with anything (unless you consider the map boundary to be "something", but you'll notice that these projectiles don't appear to explode when this happens).
There was allways many people telling what they want to do, but then never did, on the old forums, and here we also got visited by some people of that sort, too. Hope this one is not of that type.
