Multiple hardpoints for heavy body?

Discuss the future of Warzone 2100 with us.
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon » 06 Dec 2006, 21:53

DevUrandom wrote: If you are going to think about an enhancement of the PIE format, you might also think about a new (probably binary) format, which also adds more possibilities to artists. Maybe you want to have a look at the OGRE3D format, as it allready has good support for various editors.
At least this is a target for 2.1 (maybe delayed to 2.2, if nobody has time to work on it sooner).

Apart from that I think the ideas are quite good. Especially those several-guns-several-targets (incl. the tactical benefits you explained) idea I like. :)
It just needs someone to implement. :) 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. :)

Watermelon: Your "Code Readme" looks good. Could you get that as DoxyGen comments into the code? I'll bug Kamaze again to setup some "live doc generator" so we have the latest (eg. daily generated) docs available online.
I dunno how to do DoxyGen comments,think I better write them into a text file,then send to person who updates online docs regularly,which is cleaner to do than writing them into source files.

Also I am still working on the source,so the little 'code readme' project might get lagged behind.
tasks postponed until the trunk is relatively stable again.

Solitaire
Trained
Trained
Posts: 32
Joined: 05 Dec 2006, 22:47

Re: Multiple hardpoints for heavy body?

Post by Solitaire » 07 Dec 2006, 01:04

Short note: Kage's ideas for the viability of a realism mod are good, but I would actually add those thing to standard WZ, as this would add a good bit of tactical thought to gameplay. It would also add the possibility of more diverse propulsions - ones with a heavier 'bias' between front/rear armor and a turret in each side, and less recoil penalties when still are better siege units while faster ones that have less of a weakness in the rear and light low-recoil weapons make good skirmishers. Point being, if you could slip AT-equipped skirmishers behind slow-turning siege units laying waste to your base... is that a table I just saw turned?

User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon » 07 Dec 2006, 09:51

Solitaire wrote: Short note: Kage's ideas for the viability of a realism mod are good, but I would actually add those thing to standard WZ, as this would add a good bit of tactical thought to gameplay. It would also add the possibility of more diverse propulsions - ones with a heavier 'bias' between front/rear armor and a turret in each side, and less recoil penalties when still are better siege units while faster ones that have less of a weakness in the rear and light low-recoil weapons make good skirmishers. Point being, if you could slip AT-equipped skirmishers behind slow-turning siege units laying waste to your base... is that a table I just saw turned?
if I understand correctly,you mean the propulsion should add armor bonus to specified 'side(s)' of a tank?
tasks postponed until the trunk is relatively stable again.

sq2
Greenhorn
Posts: 10
Joined: 16 Nov 2006, 11:46

Re: Multiple hardpoints for heavy body?

Post by sq2 » 07 Dec 2006, 10:56

this seemed a better place to post rather than the,
new propulsion component thingy thread ...

watermelon : you said something along the lines of
i want 6 turrets, but there is not enough gui to do so.

why not use the two 'spaces' to have a "next turret" and
"previous turret" or something, and cycle them.
using the green "your wepon would go here" thing to display
which you have selected, if that is possible.
might not be easy or do-able, but if you want something
you gotta work for it hey?

just a thought

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Multiple hardpoints for heavy body?

Post by kage » 08 Dec 2006, 00:50

Watermelon wrote: dunno,maybe there is already a blender export script according to the forum posts.
the multi-turret droids are a bit weak atm,because of 'weight' speed penalty and the expensive weapon components,mid-late game weapon costs > body + prop,so a tri-weapon droid costs up to 2x-3x as much as a single weapon droid,but only 1.5-2x HP,because the major hp bonus are from body and prop.
I am not very familiar with the .txt files,maybe ammo and numRounds are already working and can serve as the ammo limits,I think the rotation limits on vtol and rotation limits on weapons are 2 different values,one is applied when loading weapons,the other one is applied when doing turret rotation actions.
I meant some sort of assault helicopter,with more ammo or infinite,less firepower,but also more durable compare to regular vtol.
it's already done in my local copy of svn,I added additional 10 armor values to body.txt,it looks like somthing like this:
armor[front][kinetic] armor[front][thermal]
armor[rear][kinetic] armor[rear][thermal]
armor[kinetic] armor[thermal]
armor[kinetic] armor[thermal]
armor[top][kinetic] armor[top][thermal]
armor[bottom][kinetic] armor[bottom][thermal]

also I changed projectile functions to calculate the angle between the projectile and the target's direction,so it should choose the proper 'side' of the armor to check against in damageDroid function.
wz source is not that big as you might expect,it only took me few days to familiarize the parts I wanted to mess around with ,though I am still not familiar with the parts I havent touched.

btw I began to write a little code function reference text yesterday,not sure if it will be useful or not,I'll continue if it's proven useful.
okay, cool. i'm surprised that any kind of armor stuff happened so quickly -- nice work on that.

have skimmed the code reference: looks like it'll help things about a bit when i get time to look into the code.
Solitaire wrote: Short note: Kage's ideas for the viability of a realism mod are good, but I would actually add those thing to standard WZ, as this would add a good bit of tactical thought to gameplay. It would also add the possibility of more diverse propulsions - ones with a heavier 'bias' between front/rear armor and a turret in each side, and less recoil penalties when still are better siege units while faster ones that have less of a weakness in the rear and light low-recoil weapons make good skirmishers. Point being, if you could slip AT-equipped skirmishers behind slow-turning siege units laying waste to your base... is that a table I just saw turned?
there will always be some old players who are interested in playing the original campaign with the original gameplay for nostalgic reasons, or just from preference (not everyone is going to like any new gameplay change you make, whether or not it's more realistic), and there'll be some new players who might want to play the original campaign in its original state for historical-signifigance type reasons (don't really know what to call it -- maybe "educational purposes"). in any case, i'd like to reiterate that all gameplay-changing features should either be able to get turned off, or the code should be granularized (some people refer to this as "modularization", but that's not quite correct - this could be as simple as a few "#ifdef" statements) and stored so that a fork can be made that can incorporate all old gameplay yet still be able to patch itself to new graphics, new architecture ports, etc. if each gameplay-altering feature can be turned off, then, as devurandom was suggesting, the original campaign could be maintained in a seperate mod, and the "official dev project campaign" could evolve with the engine.
DevUrandom wrote: If you are going to think about an enhancement of the PIE format, you might also think about a new (probably binary) format, which also adds more possibilities to artists. Maybe you want to have a look at the OGRE3D format, as it allready has good support for various editors.
At least this is a target for 2.1 (maybe delayed to 2.2, if nobody has time to work on it sooner).
i have no objection to this. there are those that have voiced resistance to this idea in the past, but as long as we provide some sort of "compatibility preprocessor" library that could be loaded solely for the purpose of converting pie files to the new format (and possibly caching them for later use, using timestamp-validation), or instead create a "object loader" api, for which the binary format and pie format code could be seperated into seperate "just in time" libraries.

most 3d modelling programs support lots of types of material data -- we might even be able to use something like "depth" or "density" or something along those lines to eventually support a per-poly armor value system if the engine supports an accurate enough collision detection system, though such a thing would require a bit more processing power, however, such things could be done server side in multiplayer games, and we might even be able to make some effective "multi-daemon" server system where one comp can act as a collision physics daemon that just goes around and does fine-tune calculation of events marked as "probable collisions", returning the results to the logic daemon, possibly running on another comp.

in fact, if we do go ultra-realistic, most explosive shells will end up missing their targets and hit the ground, so a "logic daemon" wouldn't have to do much work for collision detection - it uses a "quick guess" algorithm that either marks a projectile as being unable to collide with anything that tick (or with scheduling, that determines that there's no way for, say, an artillery shell to have any chance of collision until some tick a few seconds later, as it is in high parabolic flight through the air, and no further checks need be done until the first "possible collision" tick). and ticks being marked as possible collisions get passed to the collision physics daemon, which can conclusively determine if a collision is to occur, and where it will occur (striking which surface of an object) - it can then pass back information concerning the damage of a projectile, or if the projectile does something like ricochet's off the armor of a tank, it can pass back new a new vector and velocity, at which point the projectile is in flight again.

making everything event based instead of purely tick based does have advantages but is also a bit more costly in terms of processing power required, but event based computing is easily distributed, allowing good performance "full physics" game servers on multicore-proc servers and micro-farm servers groups. and best yet, each player's client need not be any faster to handle this sort of stuff, since it isn't handling any of this stuff.
DevUrandom wrote: Apart from that I think the ideas are quite good. Especially those several-guns-several-targets (incl. the tactical benefits you explained) idea I like. :)
It just needs someone to implement. :) 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. :)
yeah, i've definitely been one of those people : ( . in the next few days i plan to figure out the source and see what i can do.
Solitaire wrote: Short note: Kage's ideas for the viability of a realism mod are good, but I would actually add those thing to standard WZ, as this would add a good bit of tactical thought to gameplay. It would also add the possibility of more diverse propulsions - ones with a heavier 'bias' between front/rear armor and a turret in each side, and less recoil penalties when still are better siege units while faster ones that have less of a weakness in the rear and light low-recoil weapons make good skirmishers. Point being, if you could slip AT-equipped skirmishers behind slow-turning siege units laying waste to your base... is that a table I just saw turned?
indeed. in rl you never have everyone lay seige -- you make sure someone stays around to protect those doing the slaughtering.
Watermelon wrote: if I understand correctly,you mean the propulsion should add armor bonus to specified 'side(s)' of a tank?
this is a tricky area where really the concept of "global hp" falls through -- the propulsion would slow down any shells coming at the side of a tank, but the propulsion would get wasted in the process -- a tank would still be able to shoot, and it's occupants may have just been saved, but the tank would be a sitting duck after that.

User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon » 08 Dec 2006, 08:29

sq2:that's possible,but it will buggy when editing exist templates i think.

ultra-realistic collision/physics is not do-able because it'll be too costy for a RTS game.(hundreds of tanks/infantry sending tons of projectiles at one time.)

ricochet is already possible with a penetrate flag I recently added(actually the penetrate'd projectile creates a new projectile trying to reach the old one's intended destination),I can change it to create a new projectile with the move direction perpendicular to the impact angle to simulate such behaviors of projectile-bounce-off-armor.Also creating new projectile upon impact is also useful for creating fragments to all directions when a sabot/artillery shell is exploded.
tasks postponed until the trunk is relatively stable again.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Multiple hardpoints for heavy body?

Post by kage » 08 Dec 2006, 15:28

Watermelon wrote:ultra-realistic collision/physics is not do-able because it'll be too costy for a RTS game.(hundreds of tanks/infantry sending tons of projectiles at one time.)
that's not necessarily true, since it's something that can be extremely optimized... if you're using floating point numbers for most of this kind of math, then it's entirely unoptimized and takes too much processing power (almost all processors handle integer math much much faster than floating point math, and even if a processor handled both types at the same speed, integer alternatives would usually be faster anyways) -- there are other ways to do it, and certain things can be fudged:
  • if there really is a very innacurate but fast "will definitely not hit for next x ticks -- check back then" or "may possibly hit, but not until tick y", then you both increase per-projectile calculation by something like 40% time but actually decrease overall collision detection processing by something like 80% compared to the brute force method most people go with (has this projectile's path intersected with the hit box of anything else).
  • we can completely remove the ability for normal ground-aimed projectiles (everything aside from aa fire) to collide with vtols, such as artillery or weapons fire that missed its target -- even when you're aiming at a fast moving aircraft, it's really really really hard to hit, and is pretty well unlikely for such fire to accidently score a hit -- eliminating this eliminates 50% of the processor power required for something that would only happen .003% of the time.
  • calculate a "maximum hitbox height", or "height of highest point on model" (in terms of distance above ground), and store it as a value, which i'll call cDetectionHeight -- this can be hardcoded (bad -- this saves a little math now to add a lot more math later), or can be calculated as each model is loaded into server memory (if you're doing accurate collision detection, the textures don't need to be loaded, of course, but the polys do) -- best way to really do this is to check and, if need be, modify this value each time a player adds a new design to gameplay, or each time a unit design no longer exists: each design has a unique id: store the ids of each in-use design in order of maximum height -- this isn't as much memory usage as it sounds, and can easily be a doubly-linked list -- every in use design has a pointer linking it to its id in the list, and every time a design no longer exists on the game map, its corresponding node within the list is unlinked, and the sibling nodes are linked together (standard linked list operations). if that node was at the front of the list (indicating it has the highest point of any in-use ground vehicle), then you update cDetectionHeight with the max_height of the next highest design in the list. removing a design from the list is not at all processor intensive, but adding it is, at least in the above example, a full iteration of the list to find where to enter an in-use design into the list -- you could optimize the storage type to be something like a binary tree, but it's probably not worth it since adding a design only happens once every few thousand ticks at the most -- it's better to spend time optimizing areas of parts of the codepath that actually get run frequently. cDetection will be come extremely useful as you'll see below.
  • convert all free-flight projectile weapons to using an actual parabolic flight path: although this actually takes more time to calculate, in many cases (perhaps 50% of cases for direct fire weapons) this will actually signifigantly reduce the amount of collision detection required. this can actually be further optimized by, for all direct-fire projectile weapons, given that each weapon has a fixed and unchanging muzzle velocity, calculating the maximum distance at which the weapon can be fired "point blank" -- that is, the distance at which the "gunner" does not have to adjust for gravity to hit a target. this, again, can be calculated every time a weapon is put into the field (not a really intensive calculation, and only would be done every few thousand ticks), or any time the weapon gets a range upgrade through research (doing this all at level load would bludgeon any chance of a quick level load). then, at the creation of each direct-fire projectile, if the target's distance is less than the aforementioned threshold and the virtual "gunner" is aiming equal to or lower than the "elevation" angle needed to strike the target (there's probably a slightly better way to do this last check), then make the projectile's flight path linear, so that collision detection is much simpler (no parabolic flight calculations) since it is mostly flying in straight line anyways, and then add to the event queue an event that will change the projectile back to using a parabolic flight path on the tick when it reaches the "maximum threshold distance" (bad name, i know) -- the reason this should be done is so that it can hit the ground where it needs to, and in the rare case where the weapon is firing at a target on the edge of a cliff, the projectile needs to be able to "fall down" past that cliff and hit the ground below.
  • to accomodate the above, on projectile creation, any projectile that has any possibility of being parabolic (as in everything but lasers and certain types of rockets), it needs to have its x,y,z coordinates, x,y,z rotational angles, and muzzle velocity get stored within the projectile itself.
  • since it's nearly as unlikely for any parabolic projectile that will travel above cDetectionHeight to hit any unit (before the projectile reaches its peak) as it is for that projectile to inadvertantly hit a vtol in flight, then don't bother doing any unit collision detection in that area, except where calculated below. this pretty much means, don't bother trying to see if the projectile hits anything before it even has a chance to get airborne.
  • as soon as any projectile becomes parabolic (either if it is created as such, or is converted to being parabolic), you'd find all parts of unit-accessible terrain that come are equal or less than cDetectionHeight from the projectile's flight path, and check if any structures intersect (do not calculate which poly of the structure will get hit - only do a bounding box calc), and perform those calculations starting from the initial creation/conversion of the parabolic projectile until it is found that the projectile comes in contact with a structure's bounding box or it strikes the terrain, and if there's a scheduler (for any of this to be efficient or doable, you'd need an event scheduler), you just add a "projectile strikes ground/water" or "check collision against structure #structure_ID" event at the time and coordinates of strike, then add "check collision against unit" events for every point in time when the projectile is exactly cDetectionHeight above any given chunk of ground-unit accesible terrain, with some sort of parameter that indicates to the collision detection function that it'll not calculate collisions further than a distance of cDetectionHeight from the start of calculation (it is impossible for a collision to occur past that point until the next scheduled "check collision event"). this is the area where all sorts of optimization can occur -- you could write a very thick book on all the ways you can save time in this stage.
  • in the immediately above bulleted section, i suggested only checking against the bounding box of any structures -- this is because if there is one of those to-be-checked unit-accessible terrain areas, it is possible that it will collide with a unit there, in which case you just wasted an expensive "accurate collision detection" calculation. if you do a just-in-time calculation when the event comes up in the queue, then you're doing what you would've had to have been doing anyways, without extra processing time.
  • appearantly obvious optimization of the above two points: find the first event (terrain within cDetectionDistance of flight path, structure, or actual ground), and stop there. when the event comes up, if it collides with anything, process the collision, otherwise, find the next event as described above - this eliminates any chance for wasted processing to occur.
  • all "collision check" events should use a linear flight path for the projectile within that calculation, since, in all the above cases where a collision check needs to occur, the distance is short enough that there is virtually no difference between the parabolic flight path and a "best fit" linear equivalent, and simple vector math is much simpler.
  • rapid-fire weapons can, using a bit of trigonometry and some other tricks, be group their collision detection into a grouped calculation: if you're sending 4 rounds per second into an enemy unit, often enough you will find out that when one of those rounds hits a given poly on an enemy vehicle, several will... you pretty much just work out the rate of change for each angle, and figure out, based on the current "rate of travel" of the impact trail left by those rounds, the earliest possible moment that the rounds will either hit another poly or stop hitting that vehicle, or more, alternatively, find out what is the latest possible time a projectile from that weapon could've been fired to hit that poly: when you figure that, you can quite accurately assume that all projectiles fired before that "last possible" point in time, and after the first impact to that poly will hit that same poly! in some cases, you could've just eliminated the collision detection calculations for 30 projectiles, having done all those calculations via one broad calculation, storing the effect and reusing it until some "calculate for new poly" comes along.
under the above model, even during a heavy battle, you may well find a lot of ticks in which no collision detection checks need to be done -- some basic areas of interest are tagged and checked at the right time, but generally speaking, the processor ignores the projectile, and the projectile just kicks its feet up as it sits around in your main memory. when properly done (i'm not saying authoritatively that this is the best way to do it, but it beats brute force), "dead accurate" collision detection is far less processor intensive that "check every tick" detection that gives you barely enough information to say "it hit object x". even if this kind of method isn't coupled with "dead accurate" detection, it's still way faster than tick-by-tick, if that's what you're doing.

not to mention, unlike before, if you have a whole lot of tanks in a giant group on level ground (as is often the case), then upon targeting a nearby enemy, then pretty much only your tanks on the edge of the group nearest the enemy would be able to shoot without hitting friendlies -- most of your tanks would be sitting there doing nothing -- given that you now also have the downside of having to deal with that "traffic jam" you get whenever you have a lot of tanks: any tanks on the perimeter that are taking too much fire and need to retreat will get walled in and slaughtered by your own units -- a smart enemy could have 2 groups of 6 tanks take out your group of 50 tanks: they just have one group repair while the other group attacks, and since only a dozen or so of your own tanks can safely fire on the enemy, they wont have much trouble... that said, this will probably reduce tank battles to a dozen or so tanks on each side, spread out and on the move, while putting a whole lot more value into veterancy, thus any kind of collision-detection based ballistics (that don't just "go through" friendlies) will force battles down to manageble sizes anyways, thus allowing for better game physics due to leaving the processor with a lot less of a workload.

below are some diagrams of common flight paths and what should happen in each according to the above. note, neither of the below are to scale.

Image
  • alpha: this is the area in which collision detection, in this situation, should occur: you can form a bounding box around the parabolic path starting at the point where the path is cDetectionHeight above the ground to do a quick check here. in almost all situations using artillery, this is the only area in which you'll score a hit of any kind, unless you are attacking a structure.
  • beta: depending on how you optimize your algorithms, this is an example of doing a bounding box check for a structure directly below the flight path.
  • gamma: this would've normally created something like a "check unit collision" event, but since that terrain is not accessible to ground vehicles, there's no reason to bother.
  • delta: uh... why are you running collision checks in these areas? there's nothing the projectile could possibly hit, and i want my processor back
Image

you might have to look closely to distinguish between the colors -- sorry about that. this might be confusing because the flight paths "pass through" the artillery unit. most of the below is assuming that the projectile misses the artillery unit and continues on, even though the artillery unit was the target.
  • alpha: this is the "linear flight path" that should be used for collision detection in this case, since the difference between this and the parabolic path are negligable -- anything that'd get hit by one would get hit by the other (the parabolic path doesn't exceed a height of cDetectionHeight), and probably on the same poly at that, not to mention the linear flight path is much faster (as i'm redundantly reiterating yet again) if you have to check for the possibility of several objects congested in the way of the path as you often have to do with direct fire weapons.
  • beta: this is the vestigial (unused) parabolic flight path -- nothing in this segment needs be calculated via this kind of flight path, as it is being handled via a linear flight path
  • gamma: when the linear flight path reaches that "maximum linear threshold distance" thing, it is converted back to using parabolic flight: as you can see, there is a little bit of a spatial jump (though you can program it in such a way that the linear flight path bisects the parabolic one exactly, but i don't want to think about that right now, and that'd require some extra math, and in any case i can think of, that "gap" isn't large enough to let an object get missed by the linear path when it would've been hit with the parabolic one. at the instant of conversion, you'd find the next area of possible collision, which starts at delta, and tag it in the event queue. other than that, no calculations should be done during the gamma segment, since there's nothing it could possibly hit. also, this shouldn't look wrong to any clients, since the clients should be doing simple parabolic path rendering until they receive a collision event from the server (flight path will always look fine, and at the most, an explosion will occur 2 pixels away from where it appeared that it would have happened -- nothing noticable).
  • the delta segment starts when the parabolic flight path is cDetectionHeight distance above the terrain. note that if the linear flight path had not been converted back into a parabolic one, the projectile would have hit the rock-face some distance above the tank in that valley.
some notes:
  • there are some cases where an event is queued based on a value of cDetectionHeight that gets updated, making the event slightly stale -- this kind of thing would be extremely rare, and on top of that, the phenomenon affecting any of the collision checks would be extremely rare, making the whole thing ridiculously rare. however, if it does happen that the new value of cDetectionHeight is larger than before (this is the only possibility that could cause any fuss), and a projectile was checked against the design with a height higher than the old value of cDetectionHeight, the projectile may well start its collision detection calculations inside the vehicle. this is not an issue though, as the projectile will be found to collide within an inside face, which isn't supposed to happen -- upon discovering this, all you have to do is reverse the direction of your vector, and make the projectile's acceleration negative until, and continue the detection until you run into another interior face: this will be the correct exterior face that the projectile was supposed to collide with... just don't forget to reverse your vector again (to send it in the right direction) or abs your accel (though since you know the accel is negative, you should just multiply it by -1, as not only does this save a function call [unless your compiler is nice enough to inline functions like that], but it also saves the processor from having to check a conditional).
  • similarly, when a unit is on a steep hill and a collision check is started, since the angle of terrain isn't accounted for (this would be too much work for zero benefit), the projectile may well start its collision calculations within a unit. resolution of this issue is the same as above.
Watermelon wrote: ricochet is already possible with a penetrate flag I recently added(actually the penetrate'd projectile creates a new projectile trying to reach the old one's intended destination),I can change it to create a new projectile with the move direction perpendicular to the impact angle to simulate such behaviors of projectile-bounce-off-armor.Also creating new projectile upon impact is also useful for creating fragments to all directions when a sabot/artillery shell is exploded.
cool. i hope the projectile is recreated with a lower velocity than that at point of impact (in either the case of a ricochet or penetration -- more for penetration), as that would always happen. though it does sound like, by penetration, you mean full penetration of the vehicle, which isn't too bad for light vehicles, but really slows down a projectile for anything with going through 2 seperate plates of armor, usually to a dead stop (unless it's light armor and a really big shell).

ooh. nm... i guess it's a moot point since i just remembered that warzone doesn't really take projectile speed into account when calculating the damage, and until parabolic flight paths are put into the code, a shell slowed down to 2 km/h would still somehow keep on flying.

once again, nice work.

User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon » 08 Dec 2006, 16:46

Some great optimization suggestions there:

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.

2.ignore vtol's
I will ignore vtol's for direct fire weapons,indirect fire weapons dont shoot as frequent as direct ones,so I think it's better leave them alone.

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.

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)

5.terrain:
wz does check terrain 'height' against projectile z when updating projectiles every frame,so we dont need to redo this.

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.
tasks postponed until the trunk is relatively stable again.

themousemaster
Regular
Regular
Posts: 608
Joined: 10 Nov 2006, 16:54

Re: Multiple hardpoints for heavy body?

Post by themousemaster » 09 Dec 2006, 16:30

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...

User avatar
lav_coyote25
Professional
Professional
Posts: 3434
Joined: 08 Aug 2006, 23:18

Re: Multiple hardpoints for heavy body?

Post by lav_coyote25 » 09 Dec 2006, 17:57

themousemaster wrote: 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...

for those that play maps that are not FLAT and use vtols and scourge - you will have noticed that the above is so true - scourge missiles will impact the ground if the ground is between the missile point and the target.
‎"to prepare for disaster is to invite it, to not prepare for disaster is a fools choice" -me (kim-lav_coyote25-metcalfe) - it used to be attributed to unknown - but adding the last bit , it now makes sense.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Multiple hardpoints for heavy body?

Post by kage » 11 Dec 2006, 11:02

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).

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Multiple hardpoints for heavy body?

Post by DevUrandom » 11 Dec 2006, 19:46

Indirect fire: We currently have this projectile lifetime. Is it possible to calculate how long till a arty-projectile hits the ground and use that as the lifetime? At least from a mathematic point of view it is. (We know the destination and the offset created by the dices, so we know the target height. We also know the source-height and the angle...)

User avatar
Warmaster
Rookie
Rookie
Posts: 19
Joined: 19 Dec 2006, 21:38
Location: Finland

Re: Multiple hardpoints for heavy body?

Post by Warmaster » 03 Jan 2007, 00:21

Sorry to just barge in here, but how can one try out this mod? :D
Where to download?  ::)
:D

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Multiple hardpoints for heavy body?

Post by DevUrandom » 03 Jan 2007, 01:31

It is no mod, it is the SVN version. (The most current development version.)
Maybe I'll create a development snapshot...

User avatar
Warmaster
Rookie
Rookie
Posts: 19
Joined: 19 Dec 2006, 21:38
Location: Finland

Re: Multiple hardpoints for heavy body?

Post by Warmaster » 03 Jan 2007, 01:40

Well it looks awesome and so I was wondering if there'd be a way for me to try it aswell. :D
:D

Post Reply