ooh, i realize i did a very poor job of seperating "as is now" from "as could be eventually" - my apologies.
thanks.I think adding additional hexdecimal or decimal data fields to bodies.txt as 'byte mask' might be a better approach,since adding byte mask to pie may break the pieslicer,the only modelling program? available for .pie format.
yeah, for a while i was thinking it should be in the pie file until i realized this was a really bad idea.
also, in regards to modelling, if the pie format was ever extended to support floating-point precision coordinates for the "POINT" objects, then i was going to do a lot of modelling to take advantage of that. having learned a bit of [url=http://www.blender3d.org
]blender[/blender], i might just try to hack out a pie export script.
tbh I am unsure if multi-targeting will be useful for a ground to ground unit with multiple-weapons,think most player will use all weapons to focus fire on a single target rather than having weapons to engage different targets.The only instance that multiple-target will useful is when a unit can attack both ground and air target,like a flying fortress unlease bombs upon ground targets while having its front/rear/side turret gunners to engage incoming enemy aircrafts.
i was kind of going of on a "if tanks could die from a single rocket" tangent there -- i entirely agree with you, that as long as the gameplay exists as is (with the balance being in its current state), and there are no major mods bucking for source code features, there is almost no case in which multi-targeting vehicles would be strategically more useful than single-targeting vehicles. the only usable exception to this that comes to mind is in the case of a vehicle holding two weapons or more weapons with different ranges, and only if the target is out of range -- without multi-targeting, any weapons within range would fire at the target, and all other weapons would do nothing. with multi-targeting, any weapons within range would fire at the target, and all others could shoot at seperate targets within range. for the most part, this probably wouldn't happen, as i'm guessing almost every player would "3-up" every weapon (3 heavy cannons, 3 hellfire howitzers [which happens to be 9 barrels], etc), and thus range differences don't become an issue. though you would get some uselessness out of, say, a mortar sharing the same vehicle as a light cannon - without multi-targeting, the light cannon would almost never get used.
at the same time, though, think of it this way: with the way players are likely to design multiple-hardpoint units (unless we enforce some ability for each hardpoint to have a "maximum weight" restriction on its weapon), having 3 heavy cannons isn't any different than having a heavy cannon that fires 3 times as fast, and in a sense, until we make some way to encourage players to have different weapons sharing the same vehicle, then the multi-weapon feature you added is pretty much a souped up single weapon mod (not to discredit you -- it's the typical player's fault, not yours, of course).
The turret orientation/facing direction should be stored in 'DROID' structure in my opinion,the only weapon that has rotation limits is the vtol weapon,which uses a defined constant,it's not very brilliant to use constants in source to limit rotation i think.
i'm not quite sure what you mean there: as far as i've seen through mod-testing, aside from having a maximum-payload option (which can be set to either 0 or a negative number for unlimited ammo -- it's one or the other, i just don't remember which), vtol weapons behave exactly the same as ground-based weapons: you can set their maximum rotation to 0 to make the weapon fixed (which makes the vtol pretty much useless, since, in the current implementation, it can only effectively target structures or vehicles that are literally
not moving, and anything else requires 3-4 passes before it can get a shot off), or you can set it to 180 to make it have unrestricted vertical-axis rotation (rotating around horizontally), and, at least as of the initial source code release (or any closed-source official versions), any value between (but not including) 0 and 180 does not have the desired effect or specifying an exact arc of maximum rotation from the origin, but iirc, defaults to having the same effect as specifying 180.
as far as where such things should be stored, i say let the master decide how best to do his or her work.
some kind of gunboat with infinite ammo is good idea,since the current VTOL lacks the ability of holding position,but they probably need a new set of weapons designed specifically for them,or 'flying tanks' will break balance easily.
if by gunboat, you both are referring to something like an "airship" or zeppelin, or something along similar lines, then with the exception of flying at extremely high altitude, you run into a bit of a conundrum: they go so slow and are so big that much of the time they provide a fairly pleasant target for tanks -- armor thick enough to resist cannon fire, if even only present on the lower portions of the gunboat, is way
to heavy to keep the craft airborne without increasing the size of the gas-bearing "envelope" 5-fold or more (making a much easier target for ground fire). that's why airships involved in any military situation tend to have extremely high altitude, and aren't as concerned with armor as they are with anti-aircraft weapons (any historical gunship didn't have much in the way of anti-ground weaponry except for bombs if that), and a whole lot of patch kits. pretty much, if you zoomed out 10x further than you currently can in warzone, and are able to see an airship of some sort, then you can be assured, it will die quickly and with ease, however, if at normal operating altitudes achievable via technology available to us now ( probably 10 - 12 km above sea level ), it could be extremely effective ( extremely accurate saturation bombing, for example ).
on the other hand, if you're talking about some kind of new-fangled anti-gravity gunboat, then you pretty much could have a flying tank - perhaps something with so much mass that, aside from being able to somehow cancel-out gravity, needs thrusters to move around, which take a long time to make the craft accelerate (think of an armored box that flies around like a hot air balloon on a windless day, relying on consumer-level box-fans for movement). in reality, such a vehicle would be fairly easy to take down: if you found a weapon that could penetrate the armor fairly well, you just get in a vtol and attack it from a "head on" direction - since the gunboat would have little ability to "steer" or slow down, whatever weapon you fire at it not only has the penetrative power inherent to it, but the added bonus of ( ( the launching vtol's speed ) + ( muzzle velocity of the weapon or any speed obtained through the weapon's propulsion systems, if any) + ( speed of the gunboat ) ) which makes for a weapon that can penetrate the gunboat extremely well. depending on the amount of armor, indeed, this could possibly kill any concept of balance present in the game.
this is already prepared in svn,I changed a droid's target info from a pointer to an array of pointers,which is one target per weapon now,but I didnt find a way to implement multi-targeting properly.
indeed, from modding experience alone, even without looking at the source code, one gets the sense that 2/3 of the source is hack upon hack. i applaud your efforts.
the current combat function already takes projectile direction and target direction into consideration when sending projectiles,I can add such checks to proj_Impact(when a projectile collides with a target),so you can check against the different direction of tank's armor(front/rear/side/top).Also the droid's struct needs some changes too,to store the different armor strength for different direction(strong front armor,weak rear/side armor values etc)
ooh, that is very cool. if most of that's in place, i don't expect i should have much difficulty trying to add some kind of config file support - since it would probably be a bad idea to add to bodies.txt and make everything backwards-incompatible, i might give a go for something like "armor.txt". until such a time as we implement some proper physics engine (velocity and mass calculations for a start), it'd probably be easiest to just implement it as a damage divisor: each "plate" of a vehicle (there'd be six in all, assuming a fairly cubic or rectengular prismatic shape) would have a floating point value that could be equated to "armor thickness"... any value of 1 does not change the damage, while values greater than one (thicker armor) decrease the damage, and, conversely, values less than one increase the damage. don't know why i said all that, as i simply mean something along the lines of:
new final damage = old final damage ( as is calculated in warzone at this moment ) / armor thickness
all bodies that don't have an entry in armor.txt (or whatever would be used) would be considered as having an armor thickness of 1 for each plate, thereby not affecting gameplay in any way for mods that don't support it, while mods that support it should have "weak armor" as having a thickness somewhere in the range of 0-1, while thick armor should be greater than 1 -- that way weapon damage does not have to be rebalanced at all, and flanking will become an instantly classic tactic amongst gamers (as attacking head on would take too long, and attacking from the rear would be quick work).
in fact, no longer would flanking be an issue of posturing to attack weaker units, such as artillery, that usually is hidden behind heavily armored units (which is flanking on a strategic level) - it would make flanking apply to warzone in the tactical sense as well.
well, at this point i'm downloading code from the svn repository, and i'll see what i can do to help out - a question to you watermelon (or to any other wz devs, i suppose), if i may ask: from one self-proclaimed "novice c/c++ programmer" to another, how long did it take you to get into the source code? i'm pretty well versed in several other languages, some type-strict, some not, but have never done too much with large code-bases, so i'd be interested in knowing how deep of a hole i'll be having to dig myself out of.