Multiple hardpoints for heavy body?

Discuss the future of Warzone 2100 with us.
themousemaster
Regular
Regular
Posts: 611
Joined: 10 Nov 2006, 16:54

Re: Multiple hardpoints for heavy body?

Post by themousemaster »

Watermelon wrote: I just changed design.c a bit,so it uses 'weaponSlots' rather than 'body size' in body.txt to detect how many turrets should be installed on this body.

I'll be working on multi-turret building and multi-targetting with multiple weapons if noone thinks they will break the game.  :)

That sounds cool...

What were your ideas of how it's planned though?

As in, will multiple turrets determine which target they'd do the most damage to and fire at them?  Or will you have some key combination that lets you assign, say, your Howitzer to the enemy hardpoint while your 2 HC's fire at their vehicles?
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon »

themousemaster wrote:
That sounds cool...

What were your ideas of how it's planned though?

As in, will multiple turrets determine which target they'd do the most damage to and fire at them?  Or will you have some key combination that lets you assign, say, your Howitzer to the enemy hardpoint while your 2 HC's fire at their vehicles?
there is a function created by Troman to choose the 'best target',though I think using mortar and HC's on the same body will be problematic,since the mortar requires the droid to change direction/orientation to aim while HC's dont.

btw,I just 'widen' the python body a bit,so they should look less 'silly' now:(no more 'stacked' turret)

tri HC tracks with new turret position/connector position:
[img width=300 height=225]http://img82.imageshack.us/img82/1103/w ... 164xb1.jpg[/img]

http://img82.imageshack.us/img82/1103/w ... 164xb1.jpg

tri LC hover and tri HeavyMG half-tracks in action:
[img width=300 height=225]http://img154.imageshack.us/img154/8357 ... 169ky9.jpg[/img]

http://img154.imageshack.us/img154/8357 ... 169ky9.jpg

I will 'widen' other heavy/S.heavy bodies if this one looks ok,I couldnt create new bodies because I have zero skills in modelling/pieslicer.
tasks postponed until the trunk is relatively stable again.
User avatar
lav_coyote25
Professional
Professional
Posts: 3434
Joined: 08 Aug 2006, 23:18

Re: Multiple hardpoints for heavy body?

Post by lav_coyote25 »

what you have done so far is awesome - others have tried and ...  well needless to say they gave up.


way to go!! ;D
‎"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
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon »

lav_coyote25 wrote: what you have done so far is awesome - others have tried and ...  well needless to say they gave up.


way to go!! ;D
thanks,maybe I am just lucky that I can get my hands on the source code to implement such features.  :)
tasks postponed until the trunk is relatively stable again.
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon »

Multi-targeting is a bit tricky,so I think I need someone who is more familiar with DORDER,DACTION states and psTarget,psAction related functions to help me to finish it.

The multiple weapon building is finished,I also changed the structures.txt and structassignweapons.txt to store more weapons,current limits is 4 weapons per building,here is a picture of the 'new' cannon fortress in game: :)
[img width=300 height=225]http://img231.imageshack.us/img231/5900 ... 176pr2.jpg[/img]
http://img231.imageshack.us/img231/5900 ... 176pr2.jpg
tasks postponed until the trunk is relatively stable again.
Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: Multiple hardpoints for heavy body?

Post by Troman »

Watermelon wrote: Multi-targeting is a bit tricky,so I think I need someone who is more familiar with DORDER,DACTION states and psTarget,psAction related functions to help me to finish it.
This is tricky indeed, it's a bit chaotic and can be easily broken.

Maybe it would make sense to visualize DORDER and DACTION state changes with some visualization program (any program capable of drawing state machine charts will suffice).
The multiple weapon building is finished,I also changed the structures.txt and structassignweapons.txt to store more weapons,current limits is 4 weapons per building,here is a picture of the 'new' cannon fortress in game: Smiley
People preferring to turtle will sure like this one.
Sign Up for Beta-Testing:
?topic=1617.0
themousemaster
Regular
Regular
Posts: 611
Joined: 10 Nov 2006, 16:54

Re: Multiple hardpoints for heavy body?

Post by themousemaster »

I assume the HP of a multi-turret building is also accoutned for...

It's true that a turtler would like the quad-HC hardpoint, but... I imagine a single Tri-hellstorm tank would trash it in under 5 seconds  :P.




Ya know, that makes me think...

Would it make life any easier (in regards to the multi-turret designs) if it could be restricted such that you can only have direct-fire OR indirect weapons on a single body?  I imagine that would remove the "needs to turn to aim" problem on trying to combine directs and indirects...
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon »

themousemaster wrote: I assume the HP of a multi-turret building is also accoutned for...

It's true that a turtler would like the quad-HC hardpoint, but... I imagine a single Tri-hellstorm tank would trash it in under 5 seconds  :P.




Ya know, that makes me think...

Would it make life any easier (in regards to the multi-turret designs) if it could be restricted such that you can only have direct-fire OR indirect weapons on a single body?  I imagine that would remove the "needs to turn to aim" problem on trying to combine directs and indirects...
not sure how to do this atm,probably some filter applied to component list when select 2nd and 3rd weapons in design screen.
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 »

haven't gotten a chance to try it out, but you've done some really great work, watermelon! i'd say you've gone about 90% further than a "novice c/c++" developer could do, and beyond that, have made happen what many of us vets had been wanting to see happen for 7 years, so once again, nice work.

in truth, though, the way warzone is laid out (at least from the source code as it was released to us) doesn't really deserve something of this signifigance -- to accomodate your feature to the fullest, the following really should happen in some way (if not already done so) - i'm proposing a method of implementation here in addition to suggesting what would be especially useful to a multi-hardpoint implementation:

the pie format needs to be extended: each connector should have something like a propulsion type mask: one digit for each propulsion type. as an example, let's say the mask was 5 binary digits long, with the order being as follows: wheel -> half-track -> track -> hover -> vtol. given that, if a connector were to apply to all land based propulsion, it'd have a mask of 11110 (or 30 in decimal, or 0x1f in hexadecimal), while a vtol-only connector would have a mask of 00001. if you wanted a connector for that body to only work with half-track propulsion, you'd have a mask of 01000.

of course, there are more than 5 types of propulsion in warzone, many of which are entirely unused. the above would provide a great deal of flexibility - if anyone wanted a mod that had specific hard point layouts based solely on propulsion, they could do so. for backwards compatibility, "basic" hardpoints (ones without a propulsion-type mask) would be treated as such: the first connector would be given an implicit "everything but vtols" type mask, or whatever is equivalent to the current handling in warzone, and the second connector would get an implicit "vtol only" (or current implementation equivalent) type mask.

however, if both "basic" and "extended" connectors are found within the same pie file, then the basic ones should be used as backups only, to where the basic connectors are entirely ignored unless a unit design is created with a propulsion type not covered by the any of the extended connectors -- for example, if all extended connectors have a mask of 10111, and the player creates a design with that body and half-tracked propulsion (which isn't covered), then the 1st basic connector should get used. note, in the above example, the second basic connector (usually reserved for use with vtol bodies) would never get used, since vtols are specified in the above mask.

given the way warzone is structured (seperation of models from data), the propulsion type mask should be in a seperate data file with everything else (in this case, i believe it is something like "bodies.txt").

additionally, there should be some way of limiting the effective size of a weapon that any hardpoint can hold. in almost all cases of multiple-armament vehicles in real-life, there is a distinction between "primary weapon" and "support weapons": on a typical tank, for example, the vehicle is built around the cannon, where the whole purpose of being is the cannon, and the ability to protect and manuever the cannon for best effect; any other weapons (cupola mounted machine-gun, auxiliary ultra-light cannons, coaxial machinegun, etc) are primarily designed and intended for defensive purposes - specifically to patch any weaknesses that the tank might have.

also, "all weapons pointing forward" is something that is not very common on heavy vehicles, such as tanks, where often you'll have a weapon positioned mainly for rear defense: even the warzone programmers appearantly were setting themselves up to support this in warzone, as within the datafiles, if you want to indicate that a weapon can rotate, you specify it as having a max rotation of "180" and with fixed weapons, you specify the max rotation as "0" - at least, as of the initial source code release, all other values are meaningless (i don't know if support for weapons with custom rotation has been included in warzone yet). implementing support for custom values here would allow for a tank that might have, for example, a "mostly fixed" cannon that can aim to the left or right by 15 degrees.

to support weapons that could have an arbitrary orientation (like a machinegun pointing to the rear, or a mini-cannon pointing off to the right of the tank), it would be best to extend the pie format, as such things are usually model dependent - an extension to the connectors could be made to give them an orientation (in terms of x,y,z), and any "basic" or legacy models with simple connectors would be assumed to have an orientation of 0,0,0 for the first connector (ground bodies), and the inverse, or "up side down" for the second connector (vtol bodies).

given the above, i can provide a tip/suggestion regarding any problems you may have been having regarding fixed weapons (such as the mortar) and vehicle orientation: the first weapon selected would be the primary weapon -- the whole purpose of the vehicle is the best make the primary weapon effective, thus, all priority for orientation should be on the primary weapon (first weapon), and you need not even consider the needs of the other weapons - they should be more along the lines of "i'll shoot if the opportunity arrises".

attempting to do it any other way would require dozens or hundreds of lines of more code, when in real life, aside from the main weapon, all other weapons on a vehicle can rotate (we'd might as well try to emulate that here, and really, two fixed-orientation mortars can really be considered one effective weapon, since when one is in a position to fire, the other can't not be).

i'm guessing that a lot of the above might not make sense - i typed this in two settings and i'm somewhat confused. at any rate, watermelon, your contribution is the first thing to have given me enough incentive to download the code and start looking at it, so if any of the above ideas seem reasonable, and no better solution exists, i'd be more than happy to try to figure out the wz code and implement them.

mainly, i need to know what parts of the above ideas make sense, don't make sense, are good, bad, etc.
Solitaire
Trained
Trained
Posts: 32
Joined: 05 Dec 2006, 22:47

Re: Multiple hardpoints for heavy body?

Post by Solitaire »

additionally, there should be some way of limiting the effective size of a weapon that any hardpoint can hold. in almost all cases of multiple-armament vehicles in real-life, there is a distinction between "primary weapon" and "support weapons": on a typical tank, for example, the vehicle is built around the cannon, where the whole purpose of being is the cannon, and the ability to protect and manuever the cannon for best effect; any other weapons (cupola mounted machine-gun, auxiliary ultra-light cannons, coaxial machinegun, etc) are primarily designed and intended for defensive purposes - specifically to patch any weaknesses that the tank might have.
Bingo! I knew I wasn't the only one who thought that! My idea was fixed on one big gun with size class fairly relative to chassis size, and on larger vehicles, some backup guns (either co-ax or propulsion-mounted). All the exceptions to the rule are mostly high-tech - the earliest (Anaconda assault chassis) is late T2 and most are T3 (other assault bodies, walkers), all of which are specifically very heavily armed and armored siege or cavalry "shock" units which are deployed tactically and sparingly owing to cost/effectiveness.

The air units are another story - although Strike/Bomber VTOLs should rely on missiles/bombs as primary with a small MG/pod/laser as a high-capacity backup, gunships and gunboats are another story altogether. Although they're late T2/T3 as well... ;)

Of course, adding size-specific weapon hardpoints to propulsions themselves will be a pain...
It's true that a turtler would like the quad-HC hardpoint, but... I imagine a single Tri-hellstorm tank would trash it in under 5 seconds
I'd prefer more resilient defenses rather than more heavily armed... only main base buildings and our old friend the Fortress should be able to add a plethora of (smallish) guns. This also reduces a key weakness of the Fortress too...
User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Multiple hardpoints for heavy body?

Post by kage »

heh, there was no way i really could've put all my ideas coherently into one post the way i did. probably should've broke it up more

anyways, solitaire made me remember another point:

in real life, take the example of a tank: tanks are really very vulnerable only because they are extremely lucrative targets -- it only takes one guy with the right type of firepower to destroy a tank, and often simple explosives can more than easily disable a tank (the movie "saving private ryan" shows a good example of that).

whenever a tank finds itself in an urban zone, it's almost always wanting some flexible infantry cover: pretty hard for a soldier to run up an strap explosives to the treads or underbody when there are six soldiers standing on either side of it. on the other hand, when the tank is in full-on combat, those soldiers don't want to be anywhere near: the muzzle blast from a tank's main cannon creates a similar effect as a flash-bang strapped to your ear if you're near the front of the tank and aren't wearing any ear-protection -- if you're in the general direction that the cannon is aiming (the shell wont hit you, but would come within 2 meters), and you're no more than 12 meters away from the muzzle, you're usually assured death: the shockwave will pretty well mutilate you (same thing if you're standing within 12-15 meters directly behind a personal rocket launcher).

if it is not possible for a tank to have nearby infantry cover in an urban enviornment, you'd better hope those machineguns are manned and have a bit of ammo, since the main cannon is effective at clearing a lot of infantry over a spread-out area: it's slow to reload, slow to aim, and doesn't have a lot of ammo. on the other hand, a .50 calibre machinegun will rip infantry apart (in one supposedly noted case, hitting a soldier in the chest with 1 .50 cal bullet caused the arm to rip off at the shoulder). but, as imagined, that .50 cal wont do anything against other tanks.

suffice it to say, warzone, while being ludicrously more realistic than almost every other real-time strat ever in existance (in regards to being able to actually use some real-world tactics to some effect), it does not accomodate such painfully realistic concepts as "5000 light-arms bullets strike a tank: needs a paint job. 1 painfully cheap (compared to the cost of building and maintaining a tank, as well as training its crew) anti-tank rocket launcher that you didn't dispose of, and you need a new tank"

if that were the case, in warzone, and things like cyborgs could be armed with realistically effective anti-tank weaponry, not to mention tank-to-tank battles would take a long time at long range (because hitting the enemy at 4 km while manuevering is not an easy task) and would last almost no time at close range (all it takes is one sabot shell against the side or rear armor), you'd find that the game balance would shift dramatically to a more modern layout: players would keep around a few mobile anti-tank units, but would invest almost entirely on anti-infantry/anti-light-vehicle weaponry because it would be cheap and effective (7-10 wheeled vehicles with machineguns would cost the same as one standard tank), and the person who chose to invest a large part of their funds in the creation of tanks would find their force entirely invincible against anti-infantry vehicles (no chance for the enemy vehicles to penetrate even the thinnest armor on a heavy tank), yet would also find that the enemy could manuever in 2 or three really cheap anti-tank vehicles and lay waste to the heavy tanks. that's why a tank wouldn't have 3 cannons on it, it would have 1 cannon, and say, at least one fully rotatable machinegun, so that, while the main gunner picks off enemy tanks or structures across the screen, the machinegunner would be protecting it from threats to the tank, such as cyborgs, light vehicles, and infantry, which are fairly resilient to cannon-fire (if you've got 5 guys spread out aiming at you with anti-tank ordinance, it would take a few minutes to kill them all with the main cannon, but little time to dispose of them with a machinegun, as in real life, one bullet is usually enough to kill or at the very least, incapacitate a soldier for some time, especially if it's a really big bullet).

if the above happened, it would be necessary to have a targeting system where only the main weapon always followed attack orders, while auxiliary

as this is not nearly the case in warzone, you would never really find a situation where a tank with 1 cannon and 2 machineguns are more effective than a tank with 3 cannons, since, let's face it, tank warfare in warzone is a matter of attrition (slow drawn-out death), not tactics.

i think i'll try to make an ultra-realism mod if we ever work out the following 3 things in the warzone engine:
  • limited ammo: vehicles would have to reload themselves, either in the field via some sort of supply or repair vehicle, or some maintainance facility or supply depot.
  • multiple weapons on vehicles (this part done, of course, thanks to watermelon), each independent of the others (each can have a different target) and with seperate arcs of fire (one that can hit anything to the side of the vehicle, one that can rotate to cover any direction -- think of the heavy crusiers in homeworld), not to mention that each weapon would have some kind of mini-ai for priority targeting (a machinegun would always target everything else before it would shoot at something with medium or heavy armor -- if there are limits on ammunition, the machinegun wouldn't shoot at tanks ever, though there could be an additional interface button such as "fire without constraint" next to "fire at will" that would allow a vehicle's gunners to unwisely expend ammunition even when it would have very little or absolutely no effect.)
  • plate based armor: each side of a tank would have a different layer of armor, with traditionally the front being the strongest, the sides being of medium strength, and the top and rear armor plates having the least. veteran tank crews should, instead of having a lower chance of simply getting hit, spend a lot of time manuevering to attack the sides and rear of an enemy tank, while always keeping the front armor towards the greatest threat; a "green" tank crew would turn around and retreat at full speed, while a veteran tank crew would retreat in reverse, which, while slower, would signifigantly increase their life expectancy.
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon »

kage wrote: haven't gotten a chance to try it out, but you've done some really great work, watermelon! i'd say you've gone about 90% further than a "novice c/c++" developer could do, and beyond that, have made happen what many of us vets had been wanting to see happen for 7 years, so once again, nice work.

in truth, though, the way warzone is laid out (at least from the source code as it was released to us) doesn't really deserve something of this signifigance -- to accomodate your feature to the fullest, the following really should happen in some way (if not already done so) - i'm proposing a method of implementation here in addition to suggesting what would be especially useful to a multi-hardpoint implementation:

the pie format needs to be extended: each connector should have something like a propulsion type mask: one digit for each propulsion type. as an example, let's say the mask was 5 binary digits long, with the order being as follows: wheel -> half-track -> track -> hover -> vtol. given that, if a connector were to apply to all land based propulsion, it'd have a mask of 11110 (or 30 in decimal, or 0x1f in hexadecimal), while a vtol-only connector would have a mask of 00001. if you wanted a connector for that body to only work with half-track propulsion, you'd have a mask of 01000.

of course, there are more than 5 types of propulsion in warzone, many of which are entirely unused. the above would provide a great deal of flexibility - if anyone wanted a mod that had specific hard point layouts based solely on propulsion, they could do so. for backwards compatibility, "basic" hardpoints (ones without a propulsion-type mask) would be treated as such: the first connector would be given an implicit "everything but vtols" type mask, or whatever is equivalent to the current handling in warzone, and the second connector would get an implicit "vtol only" (or current implementation equivalent) type mask.

however, if both "basic" and "extended" connectors are found within the same pie file, then the basic ones should be used as backups only, to where the basic connectors are entirely ignored unless a unit design is created with a propulsion type not covered by the any of the extended connectors -- for example, if all extended connectors have a mask of 10111, and the player creates a design with that body and half-tracked propulsion (which isn't covered), then the 1st basic connector should get used. note, in the above example, the second basic connector (usually reserved for use with vtol bodies) would never get used, since vtols are specified in the above mask.

given the way warzone is structured (seperation of models from data), the propulsion type mask should be in a seperate data file with everything else (in this case, i believe it is something like "bodies.txt").
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.
additionally, there should be some way of limiting the effective size of a weapon that any hardpoint can hold. in almost all cases of multiple-armament vehicles in real-life, there is a distinction between "primary weapon" and "support weapons": on a typical tank, for example, the vehicle is built around the cannon, where the whole purpose of being is the cannon, and the ability to protect and manuever the cannon for best effect; any other weapons (cupola mounted machine-gun, auxiliary ultra-light cannons, coaxial machinegun, etc) are primarily designed and intended for defensive purposes - specifically to patch any weaknesses that the tank might have.

also, "all weapons pointing forward" is something that is not very common on heavy vehicles, such as tanks, where often you'll have a weapon positioned mainly for rear defense: even the warzone programmers appearantly were setting themselves up to support this in warzone, as within the datafiles, if you want to indicate that a weapon can rotate, you specify it as having a max rotation of "180" and with fixed weapons, you specify the max rotation as "0" - at least, as of the initial source code release, all other values are meaningless (i don't know if support for weapons with custom rotation has been included in warzone yet). implementing support for custom values here would allow for a tank that might have, for example, a "mostly fixed" cannon that can aim to the left or right by 15 degrees.

to support weapons that could have an arbitrary orientation (like a machinegun pointing to the rear, or a mini-cannon pointing off to the right of the tank), it would be best to extend the pie format, as such things are usually model dependent - an extension to the connectors could be made to give them an orientation (in terms of x,y,z), and any "basic" or legacy models with simple connectors would be assumed to have an orientation of 0,0,0 for the first connector (ground bodies), and the inverse, or "up side down" for the second connector (vtol bodies).

given the above, i can provide a tip/suggestion regarding any problems you may have been having regarding fixed weapons (such as the mortar) and vehicle orientation: the first weapon selected would be the primary weapon -- the whole purpose of the vehicle is the best make the primary weapon effective, thus, all priority for orientation should be on the primary weapon (first weapon), and you need not even consider the needs of the other weapons - they should be more along the lines of "i'll shoot if the opportunity arrises".

attempting to do it any other way would require dozens or hundreds of lines of more code, when in real life, aside from the main weapon, all other weapons on a vehicle can rotate (we'd might as well try to emulate that here, and really, two fixed-orientation mortars can really be considered one effective weapon, since when one is in a position to fire, the other can't not be).

i'm guessing that a lot of the above might not make sense - i typed this in two settings and i'm somewhat confused. at any rate, watermelon, your contribution is the first thing to have given me enough incentive to download the code and start looking at it, so if any of the above ideas seem reasonable, and no better solution exists, i'd be more than happy to try to figure out the wz code and implement them.

mainly, i need to know what parts of the above ideas make sense, don't make sense, are good, bad, etc.
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.

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.
Bingo! I knew I wasn't the only one who thought that! My idea was fixed on one big gun with size class fairly relative to chassis size, and on larger vehicles, some backup guns (either co-ax or propulsion-mounted). All the exceptions to the rule are mostly high-tech - the earliest (Anaconda assault chassis) is late T2 and most are T3 (other assault bodies, walkers), all of which are specifically very heavily armed and armored siege or cavalry "shock" units which are deployed tactically and sparingly owing to cost/effectiveness.

The air units are another story - although Strike/Bomber VTOLs should rely on missiles/bombs as primary with a small MG/pod/laser as a high-capacity backup, gunships and gunboats are another story altogether. Although they're late T2/T3 as well...

Of course, adding size-specific weapon hardpoints to propulsions themselves will be a pain...


I'd prefer more resilient defenses rather than more heavily armed... only main base buildings and our old friend the Fortress should be able to add a plethora of (smallish) guns. This also reduces a key weakness of the Fortress too...
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.

to reply new post(because the quote will be too long to fit a single replay):
1.ammo:
I dunno if the 'ammo' and 'numRounds' of a weapon works in current source or not(VTOL uses some sort of hack to tell whether it has certain type of ammo or not,it doenst use 'ammo' or 'numRounds' according to the source),but I will take a look and try to 'fix' it if it's broken.

2.multi-targeting:
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.

3.armor:
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)
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 »

ooh, i realize i did a very poor job of seperating "as is now" from "as could be eventually" - my apologies.
Watermelon wrote: 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.
Watermelon wrote: 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).
Watermelon wrote: 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.
Watermelon wrote: 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.
Watermelon wrote: 2.multi-targeting:
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.
Watermelon wrote: 3.armor:
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.
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Multiple hardpoints for heavy body?

Post by Watermelon »

kage wrote: ooh, i realize i did a very poor job of seperating "as is now" from "as could be eventually" - my apologies.

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.
dunno,maybe there is already a blender export script according to the forum posts.
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 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'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.
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.
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.
I meant some sort of assault helicopter,with more ammo or infinite,less firepower,but also more durable compare to regular vtol.
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.

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.
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.
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.
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.
Attachments
codereadme.txt
(5.11 KiB) Downloaded 395 times
tasks postponed until the trunk is relatively stable again.
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Multiple hardpoints for heavy body?

Post by DevUrandom »

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