Targ Collective's Autotracking Turrets Pack - Release-Ready!

Discuss the Wing Commander Series and find the latest information on the Wing Commander Universe privateer mod as well as the standalone mod Wasteland Incident project.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Right, complications. Vegastrike uses eight arnour values intead of two, four to the top of the model, four to the bottom of the model, and does not allow you to use any less.

It uses two to the top front (left and right), two to the top rear (left and right), four to the underside (top/bottom left/right).

Bang! There goes any possibility of Privateer-style damage modelling. There is no way to model front/back/left/right damage with four surfaces. Eight surfaces are forced on us and the old weak point philosophy must be abandoned.

Okay, time for a rethink. First of all we're working with eight values, so each value must be divided by two and used twice. Secondly - and more importantly - we must determine where to put the different values.

I have opted to use a philosophy of weak undersides in the armour. Top front takes the front values, top back takes the back values, underside takes the (weaker) side values.

However instead of four quite durable pieces of armour plating this leaves us with eight moderately weak pieces of armour plating. This is why the default hulls will be given values equivalent to one third of the total resistance of the armour. Unfortunately this means there will need to be ship-specific upgrades for hulls too, for all the armour types.

Righteous Fire integration is beyond my ken, but I have Dilloh who is wise in such matters. Therefore at the same time I publish the new armour, hull and ship stats Dilloh will find in his PM inbox a master_part_list_RF.csv and my copy of factionships.py, along with a polite request to integrate matters fully.

Once that has been done I will publish those changes too.

Sorry I can't restore the values to true Privateer fashion. I cannot prevail against engine limitations.

EDIT: Astonishing - it seems that my predecessors actually had enough brain to use that philosophy behind damage modelling, if not enough brain to produce ship-specific armours or boost the hull to compensate. Let's hope that there will be similar surprises in the future.

EDIT: Ah, my predecessors did not use that philosophy, or at least not consistently, and did not always use the correct figures.

In light of this I have been correcting the default hull and armour values, after which I will create ship-specific armour and hull upgrades. It may be optimistic to say there wil be a release today in light of this; nevertheless there will certainly be a release, if not today, then tomorrow at the latest. Look forward to it everyone!
Last edited by targ collective on Wed May 23, 2007 12:47 pm, edited 1 time in total.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Alright, I'll download svn tomorrow, see if I can find where the armor pieces are hard-coded.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

You'll need to change how the engine draws it's collision zones around the ships. While no doubt possible, I would not consider it worth the effort given that I have now designed a system which can effectively work as a workaround. More to the point your efforts in other areas - the Drayman model, those turrets etc. - are guaranteed to pay dividends, where your efforts in the SVN have no such guarantees attached to them, so for my part I'd rather you spent your time on the modelling. But hey, it's your time.

I would personally consider asking the Devs, who are wise in such matters, how this could be sorted out. They will undoubtedly be able to fix it by going directly to the source of the problem.

Not sure which SVN version PR is based on, so your first port of call should lie with that if you mean to tackle this.

EDIT: Just finished the armours! Starting on the hulls, after which I'll add my tweaks to make armours ship-specific, then I'll write the master_part_list entries. Final job will be to single out the Righteous Fire items and throw them Dilloh's way. There'll be no upload today - this all has to be tested - but expect one tomorrow.
Dilloh
Elite Hunter
Elite Hunter
Posts: 1149
Joined: Mon Aug 14, 2006 3:56 pm
Location: Black Forest, Germany

Post by Dilloh »

targ collective wrote:If you're adding any new ships in the next release I'll need the damage values now, and once I've got them I'd be grateful if you froze adding new ships until I have this working.
Sure, I'm currently only planning to add chuck's cutter class. Please keep in mind that I haven't asked Zool or Melonhead about rebalanced armor settings yet - I value their opinion and I'll handle the armor thing as optional until I know about their thoughts.
just follow the documentation to add the new values - it just means shifting the values for armour up one in the .template entires and adding your new armours in unit.csv, I'm sure that won't give you any trouble once I've broken the back of things.
Fine for me.
No, wait - as I was typing this I just had a brainstorm and it came to me in a flash how I can make this truly ship-specific. I won't go into detail here except to say it will be even easier to maintain, if not implement, as implementation requires a dummy value for each ship armour.
You will add milspec, not appearing armor plates to units.csv and add the plate to the relevant shiptypes blank, milspec and template. So you only need to change the plate values whereas the ship itself comes with no armor at all. Correct? 8)
Righteous Fire integration is beyond my ken, but I have Dilloh who is wise in such matters. Therefore at the same time I publish the new armour, hull and ship stats Dilloh will find in his PM inbox a master_part_list_RF.csv and my copy of factionships.py, along with a polite request to integrate matters fully.
I hope I understood correctly; do you want me to rebalance the armor values for the beginning of RF, for PU ships only, or for all ships?
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Rebalance? I want you to make Fusion heavies and ship-specific Isometal armours purchasable.

Any rebalancing, well, I'll compile my source data used in this thread into the values that went into the cells, and include instructions on how to do the same with other ships, with the Changes package in due course.

Then I'll let you guys sort it out - I imagine that you'll want different values for the Galaxy Gunship, for example, than might be found on the stock Galaxy. Likewise the Kukhri to the Gladius. You missed the boat on that one though; you had a day or two to append my stat list and chose not to. All variants use the armours that their 'base' ships use for now, and any changes/fiddlings are up to the infamous PU devteam. So there.

EDIT: Milspec invisible armours? I was going to give all milspec ships visible Tungsten upgrades. (Once again, the upgrade to Isometal in RF is your domain). Bearing in mind armours will be quite expensive, what with the ratio of price to protection being kept constant with the 1cm armour as a base, I would expect the ship prices to rise to... Well, more or less what they are now in Zool's Rebalance, really.

It should be quite fun.
Sunfire
Bounty Hunter
Bounty Hunter
Posts: 143
Joined: Sat Apr 08, 2006 11:41 pm
Location: Livin the Dream... kinda

Post by Sunfire »

chuck_starchaser wrote:What I'm not too happy with is the cannons; they look more like conventional gun barrels than like plasma/particle things; I'll have to figure something out...
do you have a copy of armada? the opening scene has a kilrathi carrier in it and on the ship, a kilrathi turret... id post a pic but i am extremely illiterate on how do such a thing... (not that its hard im sure... just never needed to post a pic online...) s'pose i could email it to you...
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

That'd be great; thanks! Sent you a PM.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Used my texturizer to have an edge-enhanced upscaling

Image

Interesting; looks sort of like this, to me:

Image

This is kitty tech, though, but inspiring. might do something pretty similar...
Thanks!

EDIT:
What am I talking about? We need kat turrets too! Targ!
Sunfire
Bounty Hunter
Bounty Hunter
Posts: 143
Joined: Sat Apr 08, 2006 11:41 pm
Location: Livin the Dream... kinda

Post by Sunfire »

chuck_starchaser wrote: EDIT:
I've no idea about spawn rates. About a year ago, LOAF, of CIC fame, was working on documenting the exact number and kind of enemies encountered in every Privateer mission. I don't know if he finished that or not; and it wasn't about non-mission-specific, random spawns.
I can confirm that each system had different spawn rates, for sure: Playing the original Privateer (which I did like a dozen times) I only once encountered a randomly spawned Kilrathi ship in Troy, for example. So their spawn rate there was very low but not zero.

If you find the figures somewhere, there's an issue to consider with the VS engine: In the original game, if you encountered say 12 Demons, only 2 of them were actually shooting at you at any given time. The VS engine is able to do AI and physics for all ships involved, and so encounters with multiple enemies are a lot tougher, all other things being equal.
something i liked to do was play priv in "pacifist mode" killing only those which i *had* to kill in order to finish the missions... and running from everyone else.... this had an interesting effect in RF... the game designers assumed you were hostile with the bounty hunters... so in effect, the hunters would ride your 6 but not shoot you because you were friendly... then, if pirates spawned at the same point, they would pick off the hunters one by one whilst i flew slowly in a straight line then turned around to tractor them all in as slaves! :twisted:

riding as a pacifist lets you see mission specific enemies very clearly (they follow you, not the jump point) and heck... i was thinking about making a record of them myself while i was playing... any idea on how to tally the spawn rates of randoms?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Interesting; I never remember ships following me like that.
No idea on the last question. Some hacker must have hacked the original WC engine's code and files, and published where to find this or that, I'm sure.
Dilloh
Elite Hunter
Elite Hunter
Posts: 1149
Joined: Mon Aug 14, 2006 3:56 pm
Location: Black Forest, Germany

Post by Dilloh »

targ wrote:Rebalance? I want you to make Fusion heavies and ship-specific Isometal armours purchasable.
Ah, okay. Sorry if I have to reask some things - english isn't quite my mother-language.
You missed the boat on that one though; you had a day or two to append my stat list and chose not to. All variants use the armours that their 'base' ships use for now, and any changes/fiddlings are up to the infamous PU devteam. So there.
...
Milspec invisible armours? I was going to give all milspec ships visible Tungsten upgrades.
Just brainstormed about a way to make armor changes faster, easier and more secure.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

I'm afraid I have some bad news for you all.

Ship-specific purchaseable armours of different streams are unsupported by the engine.

Let me go into a bit of detail... Now, when Zool told me about hard-limiters, he told me that the way to prevent too powerful items from going into ships was to give the .template entry the best items you wanted the ship to have.

Following this advice, I created a seperate item class for every ship-specific piece of armour and hull. That was a total of 150 item classes (6 times 25), of which there were two entries - a level_0 which was a dummy entry to prevent the level_1 being enabled in the wrong ships, and a level_1 which was the purchasable upgrade. I will not speak of generating the Forbidden Upgrades string, and switching the right level_0 entries to level_1 in the template entries, and I will not speak either of the time it took to generate the prices for the purchasable upgrades. That would merely depress you.

Suffice it to say that adding 150 new entries to each .template's Upgrades cell did not work as expected - the wrong armours were purchasable, and for some reason my DraymanCVL was unable to purchase any shields. No problem, I thought, I've probably overloaded the internal arrays - time for plan B.

Plan B was to order the armours and hulls by type and strength, so the enemic and weak Salthi is plasteel_level_1 and the flying fortress Paradigm is plasteel_level_25, for example. This method would allow a Drayman to use Talon armour but not Kamekh armour, setting a hard limit at a set point preventing ships from using thicker armour than they should, with a few anomalies like the Talon and Krant. Not perfect, but just six entries and not susceptible to file bloat over time.

It was when this didn't work I started getting suspicious, and started looking in detail at just what I could not put on my DraymanCVL.

The hard limit seemed to kick in at the Kamehk or Paradigm tungsten armours, I forget which. Whichever it was, the reason is the Tungsten armour for the given ship was stronger than the Isometal armour the Drayman used (although as my file is pre-RF I couldn't see the Isometal armours). From this I reasoned that the .template entry controls which upgrades can be bought through checking for more powerful items than those in its upgrades cell, rather than looking at the item keys and ordering things that way.

This means that if I publish people pre-RF will get equivalent-Isometal strength armours and hulls, and will be able to use just about anything Plasteel. This obviously won't do.

So, how to work around this?

1. Ensure that only one item class is available at a time. Workable with Isometal but Plasteel won't be helped by this as there are only two unit.csv files.

2. Merge SVN Forbidden Upgrades functionality with the PU executable - workable but may overload the internal arrays.

3. Chuck's idea, add support for armour multiplication factors - by far the best choice but will need some work to be realised.

4. Embed best upgrades available at a given time into all ships in unit.csv and do away with purchasable hulls and armours entirely - in effect, include them with the ships. Upgrade to Isometal in RF. Primitive but robust and easy to implement, this is the only solution that can be immediately realised.

I vote for 4 until we can realise 2 or preferably 3. I'm not going to release until I have some feedback on this though.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I vote for doing nothing until we can do the right thing, myself; I don't like hacks, personally; and probably we're in this quagmire precisely because someone removed per-ship armor in order to hack in armor upgrades... I had a gut feeling this project wasn't going to be easy. Let me get svn tonight and see if I can find the area of the code where all this armor stuff is happening.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Okay, good luck with that.

One road we could go down as an interim measure is equipping all ships with Plasteel as stock, having buyable Tungsten upgrades pre-RF and then post-RF disabling the Tungsten in favour of Isometal.
Dilloh
Elite Hunter
Elite Hunter
Posts: 1149
Joined: Mon Aug 14, 2006 3:56 pm
Location: Black Forest, Germany

Post by Dilloh »

the wrong armours were purchasable, and for some reason my DraymanCVL was unable to purchase any shields.
You might want to check out if you typed everything correctly - VS is character sensitive, small or big chars might mix everything up.
so the enemic and weak Salthi is plasteel_level_1 and the flying fortress Paradigm is plasteel_level_25
If you took those values from the shieldgenerator/reactor-examples, you might have missed something - like "___upgrades", or there's an extra entry like "add_shield_generator_capability", which needs to be adapted to armor - just a theory though.
Whichever it was, the reason is the Tungsten armour for the given ship was stronger than the Isometal armour the Drayman used (although as my file is pre-RF I couldn't see the Isometal armours).
With the beginning of RF, PR takes the entries of unitsRF.csv and overwrites the values from units.csv with those (in your RAM, not in the file itself). So you won't find any entries about isometal, fusions or things like that in your units.csv.
From this I reasoned that the .template entry controls which upgrades can be bought through checking for more powerful items than those in its upgrades cell, rather than looking at the item keys and ordering things that way.
This is correct, at least concerning items which have different levels - like armor, reactors, shields.

There need to be some sort of "key" which indicates that tungsten is higher/better than plasteel. Finding this indicator would be the solution. You could then add your ship-specific armors again (e.g. Plasteel_Ferret), or just give the .blank ships stock armor values which sum up with a common armor to the new value (like Plasteel_Fighter, Plasteel_Bomber, Plasteel_Capship).
4. Embed best upgrades available at a given time into all ships in unit.csv and do away with purchasable hulls and armours entirely - in effect, include them with the ships. Upgrade to Isometal in RF. Primitive but robust and easy to implement, this is the only solution that can be immediately realised.
Changing basic values at a certain time is only possible at the beginning of RF - anything other would require change to code, at least this is my current assumption.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

Pardon me if this has already reached some resolution (I was just idly browsing through this subforum and haven't read the whole thread) but this may be pertinent information for some of the things being discussed:

To change things to use less than 8 armor faces, or to otherwise reorient armor faces, see the function

Unit::DealDamageToHullReturnArmor(const Vector & pnt, float damage, float * &targ)

in unit_generic.cpp.

It should be much easier to keep the underlying data structure for armor untouched, pick some arbitrary subset of the faces to be the LRFB, and just change this one function which decides which armor face was hit given a unit sphere coordinate (at least, I think it was the unit sphere coordinate and not the directional vector - that I'd have to doublecheck). Otherwise, a large number of files may have to be touched (armor facings are rather a bit on the hardcoded side :-/ )

Edit: also realized that you'd need to change the VDU code to have it properly display the armor facing strengths. That should all be in

static void DrawShieldArmor(Unit * parent, const float StartArmor[8], float x, float y, float w, float h,bool invertfrontback)

in vdu.cpp -- but I haven't verified that there aren't any other places that would immediately need attention. Basecomputer may print odd stats, but it does that anyway :-P.

re: thoughts on multiplicative armor upgrades - specifying a normalized thickness and then making all armor upgrades multiplicative should be doable data side without engine changes with the caveats that, depending on the values involved, the forbidden upgrade features "upgradename:1" or "upgradeclass:1" may be required to ensure that only one armor upgrade can be applied at a time, and all multipliers must be >1 (otherwise removing the armor upgrade would improve the armor stats).

Hope something from that was useful.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

jackS wrote:Pardon me if this has already reached some resolution (I was just idly browsing through this subforum and haven't read the whole thread) but this may be pertinent information for some of the things being discussed:
No resolution whatsoever; thanks! Very useful and timely info.
To change things to use less than 8 armor faces, or to otherwise reorient armor faces, see the function

Unit::DealDamageToHullReturnArmor(const Vector & pnt, float damage, float * &targ)

in unit_generic.cpp.

It should be much easier to keep the underlying data structure for armor untouched, pick some arbitrary subset of the faces to be the LRFB, and just change this one function which decides which armor face was hit given a unit sphere coordinate (at least, I think it was the unit sphere coordinate and not the directional vector - that I'd have to doublecheck). Otherwise, a large number of files may have to be touched (armor facings are rather a bit on the hardcoded side :-/ )
Alright, here's a first crack at modding the function:

Code: Select all

    ................................................
    //will #undefine ASAP...
	#define ARMOR_FRONT armor.frontrighttop
	#define ARMOR_BACK armor.frontlefttop
	#define ARMOR_RIGHT armor.frontrightbottom
	#define ARMOR_LEFT armor.frontleftbottom
	#define ARMOR_TOP  armor.backrighttop
	#define ARMOR_BOTTOM  armor.backlefttop
	if( ArmorSubdivisionCount == 8 )
	{
	  if (pnt.i>0) {
		if (pnt.j>0) {
			if(pnt.k>0){
				targ=&armor.frontlefttop;
			} else {
				targ=&armor.backlefttop;
			}
		} else {
			if(pnt.k>0){
				targ=&armor.frontleftbottom;
			} else {
				targ=&armor.backleftbottom;
			}
		}
	  }else {
		if (pnt.j>0) {
			if(pnt.k>0){
				targ=&armor.frontrighttop;
			} else {
				targ=&armor.backrighttop;
			}
		} else {
			if(pnt.k>0){
				targ=&armor.frontrightbottom;
			} else {
				targ=&armor.backrightbottom;
			}
		}
	  }
	}
	else if( ArmorSubdivisionCount == 6 )
	{
		if(pnt.k>=0.7071f) targ = &ARMOR_FRONT;
		else if(pnt.k<-0.7071f) targ = &ARMOR_BACK;
		else if(pnt.i>=0.7071f) targ = &ARMOR_LEFT;
		else if(pnt.i<-0.7071f) targ = &ARMOR_RIGHT;
		else if(pnt.j>=0.0f) targ = &ARMOR_TOP;
		else targ = &ARMOR_BOTTOM;
	}
	else if( ArmorSubdivisionCount == 4 )
	{
		if(pnt.k>=0.7071f) targ = &ARMOR_FRONT;
		else if(pnt.k<-0.7071f) targ = &ARMOR_BACK;
		else if(pnt.i>=0.0f) targ = &ARMOR_LEFT;
		else targ = &ARMOR_RIGHT;
	}
	else if( ArmorSubdivisionCount == 2 )
	{
		if(pnt.k>0) targ = &ARMOR_FRONT; else targ = &ARMOR_BACK;
	}
	//as promised...
	#undef ARMOR_FRONT
	#undef ARMOR_BACK
	#undef ARMOR_RIGHT
	#undef ARMOR_LEFT
	#undef ARMOR_TOP
	#undef ARMOR_BOTTOM
    ................................................
I think that should work, numbers-wise. I picked the armor facings equivalences so that we'd fill values from left to right in units.csv, and go in the order, Front, Back, Right, Left, Top, Bottom. Now, I have a dummy variable there, "ArmorSubdivisionCount", which could come simply from counting the number of non-zero armor data fields for a given ship in units.csv. I suppose it could be a member of unit; I should be able to figure out where a unit is initialized from units.csv, to init that member.
Edit: also realized that you'd need to change the VDU code to have it properly display the armor facing strengths. That should all be in

static void DrawShieldArmor(Unit * parent, const float StartArmor[8], float x, float y, float w, float h,bool invertfrontback)

in vdu.cpp -- but I haven't verified that there aren't any other places that would immediately need attention. Basecomputer may print odd stats, but it does that anyway :-P.
Haven't had much luck understanding this one, yet. I guess shield and armor are drawn by a pair of calls to DrawShield with different arguments; and, in the case of armor, it seems to be combining all four front facing armor corners onto a front armor draw, and so on. That much I'm getting. But I was thinking of making some display addition for top/bottom armor, but Draw Shields gets pretty inscrutable towards the bottom of the function... Okay, never mind; I'll just combine them onto four display sides, same philosophy.
re: thoughts on multiplicative armor upgrades - specifying a normalized thickness and then making all armor upgrades multiplicative should be doable data side without engine changes with the caveats that, depending on the values involved, the forbidden upgrade features "upgradename:1" or "upgradeclass:1" may be required to ensure that only one armor upgrade can be applied at a time, and all multipliers must be >1 (otherwise removing the armor upgrade would improve the armor stats).
Any idea what part of the code is involved? I'm asking because I could then go to town and put in ship size considerations into it. Like my thought, from the start, was that not all shots would hit the exact same spot, so even piercing through a similar thickness of armor in a much larger ship should take longer; though I might use the square root of ship size, so as to not make things too different.

Another question: I remember there was a file for mod-specific configuration things but I can't remember the name of it, and I've no idea how I'd add a variable like "ArmorStrengthConsidersShipSize" to it, and then get its value from the code.
Hope something from that was useful.
Extremely. I'm not sure I'd ever have found the right functions, really. Thanks!
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Brilliant! That ought to get us started, Jack.

This is a little deep, which is to say I haven't the foggiest idea what is going on beyond a vague understanding it should work, but one thought that should be borne in mind has come to me: milspec ships will have to be given visible armour upgrades, else when the player buys them they'll have the option of going to 100, 200 and 400 times basic damage resistance as Plasteel, 200, 400 and 800 as tungsten and 400, 800 and a whopping 1600 times base damage resistance with base-stats at Isometal.

That leads into the question of how to manage spawned enemy ships - will the engine be able to do this multiplication on the fly?

Chuck, I've though about your concept of insystem Pirates using Draymen as fleet carriers, and I reckon if we create a CapEscort pirate Talon to complement the existing pirate Talon, give the pirates Draymen at a high spawn rate and somehow force the three to appear together when they do appear, we'll have a section of pirates that loot, a section that escort the Drayman and the Drayman itself. I suspect we should give the Drayman the Capital role to be on the safe side.

As for Talons jumping outsystem, even if their fuel were reduced to zero they would still do that. I'm not sure if that behaviour can be supressed.
jackS
Minister of Information
Minister of Information
Posts: 1895
Joined: Fri Jan 31, 2003 9:40 pm
Location: The land of tenure (and diaper changes)

Post by jackS »

chuck_starchaser wrote:
Alright, here's a first crack at modding the function:

Code: Select all

    ................................................
    //will #undefine ASAP...
	#define ARMOR_FRONT armor.frontrighttop
	#define ARMOR_BACK armor.frontlefttop
	#define ARMOR_RIGHT armor.frontrightbottom
	#define ARMOR_LEFT armor.frontleftbottom
	#define ARMOR_TOP  armor.backrighttop
	#define ARMOR_BOTTOM  armor.backlefttop
	if( ArmorSubdivisionCount == 8 )
	{
	  if (pnt.i>0) {
		if (pnt.j>0) {
			if(pnt.k>0){
				targ=&armor.frontlefttop;
			} else {
				targ=&armor.backlefttop;
			}
		} else {
			if(pnt.k>0){
				targ=&armor.frontleftbottom;
			} else {
				targ=&armor.backleftbottom;
			}
		}
	  }else {
		if (pnt.j>0) {
			if(pnt.k>0){
				targ=&armor.frontrighttop;
			} else {
				targ=&armor.backrighttop;
			}
		} else {
			if(pnt.k>0){
				targ=&armor.frontrightbottom;
			} else {
				targ=&armor.backrightbottom;
			}
		}
	  }
	}
	else if( ArmorSubdivisionCount == 6 )
	{
		if(pnt.k>=0.7071f) targ = &ARMOR_FRONT;
		else if(pnt.k<-0.7071f) targ = &ARMOR_BACK;
		else if(pnt.i>=0.7071f) targ = &ARMOR_LEFT;
		else if(pnt.i<-0.7071f) targ = &ARMOR_RIGHT;
		else if(pnt.j>=0.0f) targ = &ARMOR_TOP;
		else targ = &ARMOR_BOTTOM;
	}
	else if( ArmorSubdivisionCount == 4 )
	{
		if(pnt.k>=0.7071f) targ = &ARMOR_FRONT;
		else if(pnt.k<-0.7071f) targ = &ARMOR_BACK;
		else if(pnt.i>=0.0f) targ = &ARMOR_LEFT;
		else targ = &ARMOR_RIGHT;
	}
	else if( ArmorSubdivisionCount == 2 )
	{
		if(pnt.k>0) targ = &ARMOR_FRONT; else targ = &ARMOR_BACK;
	}
	//as promised...
	#undef ARMOR_FRONT
	#undef ARMOR_BACK
	#undef ARMOR_RIGHT
	#undef ARMOR_LEFT
	#undef ARMOR_TOP
	#undef ARMOR_BOTTOM
    ................................................
I think that should work, numbers-wise. I picked the armor facings equivalences so that we'd fill values from left to right in units.csv, and go in the order, Front, Back, Right, Left, Top, Bottom. Now, I have a dummy variable there, "ArmorSubdivisionCount", which could come simply from counting the number of non-zero armor data fields for a given ship in units.csv. I suppose it could be a member of unit; I should be able to figure out where a unit is initialized from units.csv, to init that member.
Looks reasonable. For ArmorSubdivisionCount, you should be able to look at how the number of shield faces is determined - it's pretty similar to what you had in mind. Had a somewhat tangential idea that one might want to do a switch statement on an enum of "armor facing types" rather than just number of faces so that different orientations of the same number of faces could be supported while still being readable, but, as I said, a tangential thought at this point (as no one is using alternate orientations).
chuck_starchaser wrote:
re: thoughts on multiplicative armor upgrades - specifying a normalized thickness and then making all armor upgrades multiplicative should be doable data side without engine changes with the caveats that, depending on the values involved, the forbidden upgrade features "upgradename:1" or "upgradeclass:1" may be required to ensure that only one armor upgrade can be applied at a time, and all multipliers must be >1 (otherwise removing the armor upgrade would improve the armor stats).
Any idea what part of the code is involved? I'm asking because I could then go to town and put in ship size considerations into it. Like my thought, from the start, was that not all shots would hit the exact same spot, so even piercing through a similar thickness of armor in a much larger ship should take longer; though I might use the square root of ship size, so as to not make things too different.
I'm assuming you're asking which part of the code would be involved in applying the multiplier? (please correct me if I'm mistaken) That would be the same upgrade code that everything else goes through. The way upgrades are done ... it's rather messy, really. It's in unit_generic.cpp. Look for upanddowngrade and for things that call it. That should get you started.

One thing I'd consider though is whether, if you're going to start changing around the codebase for modeling armor, you really just want the one feature change for armor, or if you're really interested in implementing an improved damage model. If it's the former, you may well be able to approximate it reasonably dataside, and if it's the latter, then that probably goes beyond anything mod specific, and should probably be generic enough to be configured to act as any of several distinct damage models (getting the latter right, therefore, may be somewhat more difficult). All of which reminds me that I should ping Klauss again one of these days and ask him if he's done any more ruminating on the generalized damage model he was working on...

As for how the dataside approximation could work:

caveat one - ships with no armor at all will have anomalous values. Fortunately, these values can be made arbitrarily small.

for each armor facing give it a thickness (or, effective thickness due to modification by ship size) in units such that the value is << value range of actual armors (e.g. kilometers of (effective) armor thickness). These base values must be very small because they will be (mis)interpreted as actual armor ratings when no armor is applied.

Specify armor upgrades using the mult_ prefix modifier to their names, and use the appropriate conversion factor (e.g. equivalent cm of durasteel per kilometer of armor thickness) as the value in the armor field. As it is a mult_ type upgrade, when the upgrade is applied, the fields will be multiplied together (IIRC, FWIW, multiplier upgrades are always applied last on the upgrade stacks - replacement types first, then additives, then multipliers - I don't know if you were planning on multiple armor modifiers).

@Targ: this upgrade process is exactly the same for both player and AI units, excepting that .blank type AI units are upgraded by a guided-random picking of upgrades (one presumes that most players are not ;-) ) and milspec vessels are not upgraded at all by the AI. Thus, the only thing one would have to double-check is to make sure that, when changing around the names of the armor upgrades you haven't caused the AI to not pick any armor at all - I doubt this is the case though, as I believe that the AI picks out armor based on category, rather than specific upgrade name (could be wrong, haven't checked).

If you're still using templates, the multiplier values in the armor upgrades should be sufficiently large that squaring the multiplier and applying it to the base armor would exceed template stats for max armor value. If not, then forbidding the armor upgrades category would prevent runaway armor, as would, as you mentioned, making the armor explicit and upgradable/downgradeable (i.e. specifying thicknesses and then including the appropriate armor upgrade in the upgrades column). (I should admit that my knowledge of the workings of template stats is somewhat rusty, as VS hasn't been using them for a while now)
chuck_starchaser wrote: Another question: I remember there was a file for mod-specific configuration things but I can't remember the name of it, and I've no idea how I'd add a variable like "ArmorStrengthConsidersShipSize" to it, and then get its value from the code.
Sorry, don't recall offhand - I haven't spent much time looking at mod-specific concerns.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

jackS wrote:For ArmorSubdivisionCount, you should be able to look at how the number of shield faces is determined - it's pretty similar to what you had in mind.
Been looking for it since yesterday without success... Whereabouts does that happen? I can think of dozens of candidate places, like unit, unit_generic, csv, there's also a shield class, I found a LoadRow function being used, but can't find where it's defined.
Had a somewhat tangential idea that one might want to do a switch statement on an enum of "armor facing types" rather than just number of faces so that different orientations of the same number of faces could be supported while still being readable, but, as I said, a tangential thought at this point (as no one is using alternate orientations).
That crossed my mind too. But it would require an extra column in units.csv to specifiy facings configuration.
re: thoughts on multiplicative armor upgrades - specifying a normalized thickness and then making all armor upgrades multiplicative should be doable data side
I guess the question is "how?". I've no idea, and I assume Targ doesn't know either; otherwise I'm sure he'd have done it already.
without engine changes with the caveats that, depending on the values involved, the forbidden upgrade features "upgradename:1" or "upgradeclass:1" may be required to ensure that only one armor upgrade can be applied at a time, and all multipliers must be >1 (otherwise removing the armor upgrade would improve the armor stats).
Thoughrouly over my head, though if Targ understands it, that should suffice. Targ, do you?
I'm assuming you're asking which part of the code would be involved in applying the multiplier? (please correct me if I'm mistaken) That would be the same upgrade code that everything else goes through. The way upgrades are done ... it's rather messy, really. It's in unit_generic.cpp. Look for upanddowngrade and for things that call it. That should get you started.
I had a look ... I think I give up on that idea already. :D (Biggest problem being, non-const pointer parameters... Anything I do there might have unforseeable repercussions.)
One thing I'd consider though is whether, if you're going to start changing around the codebase for modeling armor, you really just want the one feature change for armor, or if you're really interested in implementing an improved damage model. If it's the former, you may well be able to approximate it reasonably dataside, and if it's the latter, then that probably goes beyond anything mod specific, and should probably be generic enough to be configured to act as any of several distinct damage models (getting the latter right, therefore, may be somewhat more difficult).
Well, I'm sitting on the fence on this. I'd love to *be able to* work on a better damage model, and I could probably write one from scratch in one day; but I doubt I'll be done in a month if I try to mess with the VS code. So, how exactly could we do this data-side?
As for how the dataside approximation could work:

caveat one - ships with no armor at all will have anomalous values. Fortunately, these values can be made arbitrarily small.
Well, actually, in WC there's not just the armor; after armor there's hull, and after that there's "core strength", which are similar to "armor" in physical terms, so lack of armor shouldn't result in divisions by zero or anything like that; and maybe this could be implemented data-side also? Namely, we got 3 layers of protection: Shields regenerate. Armor doesn't regenerate, but it's cheap to replace; though damage to external subsystems begins once shields are down.. Hull doesn't regenerate either, and, unlike armor, it's very expensive to repair. Once the hull is breached, damage to internal subsystems begins. That's how it is, or "should be", in WC.
for each armor facing give it a thickness (or, effective thickness due to modification by ship size) in units such that the value is << value range of actual armors (e.g. kilometers of (effective) armor thickness). These base values must be very small because they will be (mis)interpreted as actual armor ratings when no armor is applied.
Okay, so, "0.00000345 kilometers", say...
Specify armor upgrades using the mult_ prefix modifier
this I've no idea what it means
to their names, and use the appropriate conversion factor (e.g. equivalent cm of durasteel per kilometer of armor thickness) as the value in the armor field. As it is a mult_ type upgrade, when the upgrade is applied, the fields will be multiplied together (IIRC, FWIW, multiplier upgrades are always applied last on the upgrade stacks - replacement types first, then additives, then multipliers - I don't know if you were planning on multiple armor modifiers).
I think I'm starting to catch the drift... Yeah, no, only multiplicative upgrades.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Sorry I've been out of the loop these past few days - I meant to warn y'all Friday, events conspired against me.

Chuck, there could be a problem with multiples - rounding errors. Someone posted about how engine and handling stats decrease over time when basic repairs are done, and the finger of blame seems to be pointing at the mult_upgrades. I'd love to say I knew about this and that was why I didn't add the prefix, but I honestly didn't know about the mult_ technique. It may not be an issue with armours using multiples of 10; I will check (although I have come to favour an alternate solution, more on that later).

I'm pretty sure Jack was just warning us not to try to use a multiple of 0.25 to increase armour strength by a quarter. (IE the multiples are not additive but inclusive). Those variables he mentioned - by context, he's telling us how to ensure that we forbid installation of Plasteel, Tungsten and Isometal at the same time. Presumably mult_upgrades use different rules and are normally stackable unless stacking is forbidden in the code for that item... But I could have completely the wrong end of the stick here.

Now, I laid out our options before (and multiplicatory upgrades look better now than they ever did, especially if I can find that forbidden upgrades tech) but I have come to favour another road, spurred on by ever-faithful realism.

It makes no sense for a Salthi, at 8 armour resistance all sides, to pay the same rate for an armour upgrade as a Paradigm at a total resistance of 260.

In the original Privateer this was glossed over somewhat - there were only three ships plus I think a Broadsword or a Demon that the player could fly - so disparity made little impact, but this is PU, the remake to the remake, and Gemini has got bigger and better and full of Privateers compensating for something with big, big Paradigms.

In the Vegastrike SVN right now, there is a cell listing all of the upgrades specific vessels cannot apply. My proposed solution is to put every other ship's full list of armour and hull upgrades in that cell so that each ship is only able to apply its own individually priced, hand-crafted armour. This would remove any possibility of rounding errors, ensure that there are no armours cheap or expensive to an unbalanced degree and also be relatively easy to maintain. We'll need that implemented into PU if it's to be used; could you direct your energies to looking at that?

Meanwhile, I'm going to try and handle the multipliers - there's enough information here, thanks to Jack's interest, to make a crack at that now (I just need to do a full text search and that should get me started). I should be able to publish that tomorrow, deity of choice willing, and that can act as a stand-in for a true price-specific armour system.

Jack, could you give us an example of an upgradename or upgradeclass where the forbiddenness tech is already applied? If I can't find it today I could use the example as a handle; the current release of Vegastrike should be similar enough to PU to transfer the implementation over.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I still have the VS engine code opened in Visual. If you say there's a rounding bug somewhere, maybe I can take a crack at finding it. Can you give me a more detailed description of the symptoms? I know there used to be a bug with upgrade space; not sure if it's still there, that sometimes you couldn't fit some equipment because your available space was like 0.99999912345 instead of 1, or showed you having 0.000000000012345 tungsten armors, and stuff like that. Is that problem still there?
I would try to avoid having ship specific armor upgrades. That would make units.csv megabytes big. I would say, let's forget about price for now. I could try to find a way on the code side to enable upgrades whose price is based on a parameter, such as strength. Would be a lot more elegant, and, until then, I don't think price is so important an issue.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Megabytes big is an exaggeration - we'd need far more ships in use than we have now to approach that - and maintenance is easy enough with a bit of tactical find/replacing. Codeside is better though. Upgrade problems are there, at least in SVN, and the rounding errors - if they are the cause - are not the sole cause of the bug; more testing has shown this to take place all the time to a small degree.

More unpleasant is the fact that I seem to have got the wrong end of the stick. Percentages are additive - maybe he was warning us about rounding errors. And I can't seem to find the Forbidden Upgrades tech; whatever it is, it's not in Modules.

I've had exactly the same problems with pecentage upgrades as non-percentage upgrades, then a bit more. You can put up to four Plasteel, two Tungsten, one Isometal if the .template entry has them. The .template entry seems to automatically apply the hull. Repairs must be done to enable the new stats. The success rate is not 100%.

In other words it's a mess. Frankly it weould be far less trouble, evben wiuth some file bloat, to apply a Prohibited Upgrades cell and work things from there, at the very least as an interim measure - otherwise this could take months to do before we see anything.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Alright, go for it whichever way you think is best then; I've taken a second look at the shields code and still not getting anywhere trying to find where they are counted. Perhaps I'll start looking at radar, for a break; maybe it's a matter of looking at the VS engine code long enough that at some point it starts to make sense.
targ collective
Bounty Hunter
Bounty Hunter
Posts: 237
Joined: Fri Mar 30, 2007 2:57 pm

Post by targ collective »

Um, I don't know how to make these things work. Sure I can add a column to the .csv file, but it will be ignored unless the engine knows what to do with it. I'm not going to risk trying to put the SVN executable in PU - it's SVN, and above all it uses a different file structure. If, on the other hand, you were to dig in there and find out how SVN uses prohibited upgrades, applying it to a new version of the PU executable, we could get somewhere... Or perhaps give me a quick tutorial on how to sourcedive to tweak these things? (I'm always willing to learn.) Sorry for relying on you like this, but I really don't know much aside from unit.csv.

I can create a unit.csv, master_part_list.csv, tweak the tech section of factionships etc. to any spec you want now but unless we get the basics in - the ability to control what to buy and sell to whom - we're stymied.
Post Reply