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

[chuck_starchaser]

Sorry, I thought you had a way of doing it that didn't need an extra column.
I once helped spiritplumber to add a column to units.csv for a "tractorable" flag, so as to make jump points non-tractorable; but it was a lot of work and can't remember a thing about how I did it. And when it was done it was buggy, and other people fixed it afterwards.
And I don't even know what "prohibited upgrades" are. I keep hearing that term being used, but it means nothing to my ears.
I don't know what "multiplier prefixes" are either. I was hoping you were understanding more than I did what JackS was talking about. I saw enough of it on the code side to know what it does. Basically, you have an upgrade that multiplies a parameter by 1.5 or 2 or 77.7, so you have a base thickness for armor, and the upgrade doubles that, or whatever. I think that's what we need, but I don't know how one specifies a multiplicative upgrade data side.
But yeah, what we want is to enter centimeters in the armor figures for each ship, and then have plasteel double it, tungsten quadruple it, isometal x8 it.

[jackS]

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.

Take a look at unit_csv.cpp: 978 - 993. AssignIf does multiple things, but the return value (what we're concerned about for counting faces) is just 1 or 0 depending on whether there is, or is not, respectively, a value in for that row in the requested column. The resultant number of facings is then used in the more or less immediately following code.

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.

So, here's how the current engine's damage stack goes (to the best of my knowledge - I'm a bit fuzzy on how it decides to damage weapons - I think it just treats them the same as other internal systems/upgrades):

There are 4 things which can be damaged, shields, armor, hull, and systems/components.

Damage is first applied to shields, if any.
Then, remaining damage is applied to armor, if any.
Finally, remaining damage is then applied to the hull. If hull strength becomes non-positive, the ship goes boom. Every time the hull is damaged, there is a percentage chance that internal systems will take damage. I know that, historically, at least, there was some affinity between some systems (e.g. sensors) and a facing of the vessel (e.g. front) but I haven't looked at the system damage code in a very long time.

I'm not certain that there's currently a notion of external vs. internal systems (i.e. in the above model, systems capable of being damage before armor is eroded vs. those taking damage only once it is entirely depleted.) - see my first parenthetical concerning my fuzziness of memory concerning when weapons can start to take damage.

In any case, it would not seem to be a perfect match with what you were describing.

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?

There's a column in units.csv that contains a list, each entry of which can declare one of 3 types of upgrade restrictions:
1)if a category name is given, then upgrades from that category are not allowed.
2)if the name of a particular upgrade is given, then that upgrade is not allowed.
3)the above can be modified to allow N of a particular upgrade/category by appending :N to the end of the specified name.

For examples of use, in the current SVN version of units.csv for VS, there is an category of upgrades called upgrades/Overdrive (think afterburner). These upgrades are multiplicative (mult_overdrive01__upgrades, mult_overdrive02__upgrades, etc ) with values hovering around 2 for their AB thrust field (thus, applying this upgrade doubles your AB thrust). As it was not our intent to let one get 32x thrust by buying 5 of them, we place "upgrades/Overdrive:1" in the prohibited_upgrades column, thereby limiting the maximum number of upgrades coming from the upgrades/Overdrive category to 1. Some vessels cannot mount any overdrives at all, and have the an entry "upgrades/Overdrive" which can be taken as shorthand for "upgrades/Overdrive:0".

To continue the example into the realm of the hypothetical, if one wanted to specify that only a subset of overdrives were mountable by a vessel, one could specify each particular upgrade individually for restriction, with its own entry in the list, or one could split upgrades/Overdrive into, for example, upgrades/Overdrives_heavy and upgrades/Overdrives_light and prohibit the appropriate one(s) (I'd have to double check whether you need to split categories directly, or can split via subcategorizing. Flat is probably a safer bet). To turn this back toward armor, if you wanted to have distinct sets of armor upgrades (distinct categories) for fighter-sized, destroyer-sized, whatnot-sized, etc. this would likely be easier to manage than distinct armor upgrades for every vessel. Indeed, if there were distinct armor upgrades for every vessel, there would seem no reason to make them multiplicative - replacement would be sufficient, but there'd be a lot of them.

BUT...

As you're still using .template entries... I have no idea how the two interact. I haven't looked at the code for the managing things via the .template entries since the VS data set stopped using them - which was quite some time ago (there's some config toggle that can turn them on and off iirc, but I may not recall correctly). As Targ mentioned, the units.csv file structure expected by the two different and differently configured engine versions has some fundamental differences concerning how the data set communicates to the engine the restrictions on a given vessel being upgraded.

...

reaching back a bit in the thread, I just re-read this ....

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.

I think you may have misinterpreted how .templates are/were intended to be used.
The idea of the .template is not to contain every purchaseable upgrade. It is solely to have max stats for every field (which can be obtained by putting the best upgrade of each type in, presuming that A) each upgrade type is internally monotonic in "goodness" in all stats and B) the intersection between different classes of upgrades (e.g. shields and sensors) (excluding post-facto multiplicatives) is empty). The .template entry does not, in fact, have to have any upgrades specified. You could just pre-compute the max value for every stat and enter that in. The .template entry is used in a very simplistic manner when checking upgradeability, namely, the engine computes what all stats would be if the an upgrade were to be applied, and then, if this doesn't cause any stat to become better than the .template, it can be applied, otherwise not.

... unless I'm completely misremembering/have out-of-date-info, because I haven't played with .templates in many moons, and the implementation could have been altered since then.

[jackS]

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

See update to relevant thread in bug triage.
Exectutive Summary - probably not a rounding error, much more likely a refueling bug in 0.4.3, I wouldn't worry about multiplicative upgrades.

[targ collective]

So what this boils down to is this - as we don't have prohibited upgrade functionality (check the SVN; there's a column called prohibited_upgrades in there that controls all this) we can't do ship-specific armours. As .template entries in unit.csv don't have support for intelligent series recognition, basing prohibition on stat levels, we also are cut short in different armour thicknesses.

...

Which leaves only this as a solution - allow ships to use Plasteel (10*durasteel) as default, with the option to upgrade to just Tungsten pre-RF.

In RF, allow ships to use Isometal straight away, deprecating Tungsten support and forcing the upgrade. (Or auto-upgrade the Tungsten to Isometal, also possible).

Jack, is it realistic to think about upgrading the PU exe to support forbidden upgrades? Or would it be possible to filch the SVN .exe, nab the data structure converting ours to SVN status and magically have the patch which comes with PU working in spite of the massive changes? In short, is it possible for us to make this work?

[jackS]

So what this boils down to is this - as we don't have prohibited upgrade functionality (check the SVN; there's a column called prohibited_upgrades in there that controls all this) we can't do ship-specific armours. As .template entries in unit.csv don't have support for intelligent series recognition, basing prohibition on stat levels, we also are cut short in different armour thicknesses.

I don't see things quite so bleakly, even if the prohibited upgrades column is not utilized. You should be able to make per-ship armor thicknesses work solely with .templates. You won't be able to differentiate the cost factors for armoring a paradigm and a centurion, because the upgrade would be the same, but .template entries can easily enforce having a max of 1 multiplicative armor upgrade applied, as applying 2 should readily exceed the maximums specified in the .template.

[chuck_starchaser]

Thanks JackS; that should be all the info I need to get this armor configurations patch happening. I'll attack it when I get home.

[chuck_starchaser]

Allright. DONE! Well, almost... Compiles and links; but yet untested.
So, for the record, here's what I've done:

struct Armor, in file unit_armorshield.h, top of the file, changed to,

Code: Select all

  struct Armor {
    float frontlefttop, backlefttop, frontrighttop, backrighttop, frontleftbottom, backleftbottom, frontrightbottom, backrightbottom;
#ifdef USE_ARMOR_COUNT
    signed char number;
    Armor( )
		: frontlefttop(0)
		, backlefttop(0)
		, frontrighttop(0)
		, backrighttop(0)
		, frontleftbottom(0)
		, backleftbottom(0)
		, frontrightbottom(0)
		, backrightbottom(0)
		, number(0)
	{ }
#else
    Armor( ) : frontlefttop(0), backlefttop(0), frontrighttop(0), backrighttop(0), frontleftbottom(0), backleftbottom(0), frontrightbottom(0), backrightbottom(0) { }
#endif
  };

IOW, I added the "number" member.


In float Unit::DealDamageToHullReturnArmor (const Vector & pnt, float damage, float * &targ), in unit_generic.cpp, line 4358:

Code: Select all

.......................
#ifdef USE_ARMOR_COUNT
    //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( armor.number == 8 )
	{
#endif
	  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;
			}
		}
	  }
#ifdef USE_ARMOR_COUNT
	}
	else if( armor.number == 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( armor.number == 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( armor.number == 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
#endif
...........................................

In function static void DrawShieldArmor(Unit * parent, const float StartArmor[8], float x, float y, float w, float h,bool invertfrontback), in file vdu.cpp, line number 530:

Code: Select all

#ifdef USE_ARMOR_COUNT
    //will #undefine ASAP...
	#define LESSER_OF(a,b) ((((a))<((b))?((a)):((b))))
/*	Remember the equivalences (from unit_generic.cpp):
	#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*/
  float temp; //will use for lesser of front/back or of top/bottom
  unsigned char armorcount = 0;
  for( size_t i = 0; i < 8; ++i ) if( StartArmor[i] > 0.0001f ) ++armorcount; 
  if( armorcount & 1 ) ++armorcount;
  switch( armorcount )
  {
	  //NOTE: The way we compute the four sides of display armor is not the same as vegastrike's:
	  //For PU/WCU, top on the hud represents front of the ship, etc.
  case 2: //Front and back only
	  //compute lesser of front and back
	  temp = LESSER_OF( armor[0]/(float)StartArmor[0], armor[1]/(float)StartArmor[1] );
	  DrawShield
		  (
		  //Right: lesser of front and back...
		  temp,
		  //Front (was Top):
		  armor[0]/(float)StartArmor[0],
		  //Back (was Bottom):
		  armor[1]/(float)StartArmor[1],
		  //Left: lesser of front and back...
		  temp,
		  x,y,w/2,h/2, invertfrontback,
		  GFXColor(iarmorcolor[0],iarmorcolor[1],iarmorcolor[2],iarmorcolor[3]),
		  GFXColor(marmorcolor[0],marmorcolor[1],marmorcolor[2],marmorcolor[3]),
		  GFXColor(oarmorcolor[0],oarmorcolor[1],oarmorcolor[2],oarmorcolor[3])
		  );
	  break;
  case 4: //Front, back, left and right armors
	  DrawShield
		  (
		  //Right:
		  armor[2]/(float)StartArmor[2],
		  //Front (was Top):
		  armor[0]/(float)StartArmor[0],
		  //Back (was Bottom):
		  armor[1]/(float)StartArmor[1],
		  //Left:
		  armor[3]/(float)StartArmor[3],
		  x,y,w/2,h/2, invertfrontback,
		  GFXColor(iarmorcolor[0],iarmorcolor[1],iarmorcolor[2],iarmorcolor[3]),
		  GFXColor(marmorcolor[0],marmorcolor[1],marmorcolor[2],marmorcolor[3]),
		  GFXColor(oarmorcolor[0],oarmorcolor[1],oarmorcolor[2],oarmorcolor[3])
		  );
	  break;
  case 6: //Front, back, left, right, top and bottom armors
	  //compute lesser of top and bottom
	  temp = LESSER_OF( armor[4]/(float)StartArmor[4], armor[5]/(float)StartArmor[5] );
	  DrawShield
		  (
		  //Right: lesser of right, or of top and bottom...
		  LESSER_OF( armor[2]/(float)StartArmor[2], temp ),
		  //Front (was Top): lesser of front, or of top and bottom...
		  LESSER_OF( armor[0]/(float)StartArmor[0], temp ),
		  //Back (was Bottom): lesser of back, or of top and bottom...
		  LESSER_OF( armor[1]/(float)StartArmor[1], temp ),
		  //Left: lesser of left, or of top and bottom...
		  LESSER_OF( armor[3]/(float)StartArmor[3], temp ),
		  x,y,w/2,h/2, invertfrontback,
		  GFXColor(iarmorcolor[0],iarmorcolor[1],iarmorcolor[2],iarmorcolor[3]),
		  GFXColor(marmorcolor[0],marmorcolor[1],marmorcolor[2],marmorcolor[3]),
		  GFXColor(oarmorcolor[0],oarmorcolor[1],oarmorcolor[2],oarmorcolor[3])
		  );
	  break;
  default: // 8=)
	  DrawShield //Similar but NOT the same as vegastrike's configuration: For PU/WCU,
		  //top on the hud represents front of the ship, etc.
		  (
		  //Right
		  (armor[0]+armor[2]+armor[4]+armor[6]) / (float)(StartArmor[0]+StartArmor[2]+StartArmor[4]+StartArmor[6]),
		  //Top
		  (armor[0]+armor[1]+armor[2]+armor[3]) / (float)(StartArmor[0]+StartArmor[1]+StartArmor[2]+StartArmor[3]),
		  //Bottom
		  (armor[4]+armor[5]+armor[6]+armor[7]) / (float)(StartArmor[4]+StartArmor[5]+StartArmor[6]+StartArmor[7]),
		  //Left
		  (armor[1]+armor[3]+armor[5]+armor[7]) / (float)(StartArmor[1]+StartArmor[3]+StartArmor[5]+StartArmor[7]),
		  x,y,w/2,h/2, invertfrontback,
		  GFXColor(iarmorcolor[0],iarmorcolor[1],iarmorcolor[2],iarmorcolor[3]),
		  GFXColor(marmorcolor[0],marmorcolor[1],marmorcolor[2],marmorcolor[3]),
		  GFXColor(oarmorcolor[0],oarmorcolor[1],oarmorcolor[2],oarmorcolor[3])
		  );
  }
	//and as promised...
	#undef LESSER_OF
#else //just the original code...
  DrawShield
     (
    (armor[0]+armor[2]+armor[4]+armor[6])/(float)(StartArmor[0]+StartArmor[2]+StartArmor[4]+StartArmor[6]),

    (armor[0]+armor[1]+armor[4]+armor[5])/(float)(StartArmor[0]+StartArmor[1]+StartArmor[4]+StartArmor[5]),

    (armor[2]+armor[3]+armor[6]+armor[7])/(float)(StartArmor[2]+StartArmor[3]+StartArmor[6]+StartArmor[7]),

    (armor[1]+armor[3]+armor[5]+armor[7])/(float)(StartArmor[1]+StartArmor[3]+StartArmor[5]+StartArmor[7]),

    x,y,w/2,h/2, invertfrontback,
      GFXColor(iarmorcolor[0],iarmorcolor[1],iarmorcolor[2],iarmorcolor[3]),
      GFXColor(marmorcolor[0],marmorcolor[1],marmorcolor[2],marmorcolor[3]),
      GFXColor(oarmorcolor[0],oarmorcolor[1],oarmorcolor[2],oarmorcolor[3])
    );
#endif

In unit_csv.cpp file, line 606, added function:

Code: Select all

#ifdef USE_ARMOR_COUNT
static int AssignIfElseZero(const string &inp,float &val) {
  if (inp.length())
  {
    val=stof(inp);
  }
  else
  {
	val=0.0f;
  }
  return val != 0.0f;
}
#endif

Same file, in function void Unit::LoadRow(CSVRow &row, string modification, string * netxml), starting at line 976:

Code: Select all

#ifdef USE_ARMOR_COUNT
  int armorcount=0;
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Front_Top_Left),armor.frontlefttop);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Front_Top_Right),armor.frontrighttop);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Back_Top_Left),armor.backlefttop);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Back_Top_Right),armor.backrighttop);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Front_Bottom_Left),armor.frontleftbottom);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Front_Bottom_Right),armor.frontrightbottom);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Back_Bottom_Left),armor.backleftbottom);
  armorcount+=AssignIfElseZero(OPTIM_GET(row,table,Armor_Back_Bottom_Right),armor.backrightbottom);
  armor.number = armorcount;
#else
  armor.frontlefttop=stof(OPTIM_GET(row,table,Armor_Front_Top_Left));
  armor.frontrighttop=stof(OPTIM_GET(row,table,Armor_Front_Top_Right));
  armor.backlefttop=stof(OPTIM_GET(row,table,Armor_Back_Top_Left));
  armor.backrighttop=stof(OPTIM_GET(row,table,Armor_Back_Top_Right));
  armor.frontleftbottom=stof(OPTIM_GET(row,table,Armor_Front_Bottom_Left));
  armor.frontrightbottom=stof(OPTIM_GET(row,table,Armor_Front_Bottom_Right));
  armor.backleftbottom=stof(OPTIM_GET(row,table,Armor_Back_Bottom_Left));
  armor.backrightbottom=stof(OPTIM_GET(row,table,Armor_Back_Bottom_Right));
#endif

Now, questions:
1) I didn't know of a good place where to define USE_ARMOR_COUNT, so I added it to the list of defines in the precompiler settings. Suggestions?
2) In DrawShieldArmor I wasn't sure where to get armor.number, so I just counted the non-zero armors. Suggestions?
3) I modded a few days' old cvs version of vegastrike; What version should I migrate these changes to, for PU's sake, and where in cvs do I find it?
4) How in Hell am I gonna test this?

[jackS]

Glad to have been useful

FYI - I'm somewhat insanely busy for the next 2+ weeks, and may not have time to respond until mid-June (sorry - need to do some work for the people who sign the paychecks, if you know what I mean ).

For testing, my top-of-the-head advice -

take a look at the .mission files in mission/test/ (if this doesn't exist in the PR/PU/P0/GG data set, grab one from VS - the format should be exactly the same)

The XML schema is fairly simplistic, so it shouldn't take too long to get the hang of it.

running the mission is easy, just give the mission file name as the lone argument to the binary, and it will run that mission instead of the default.

Make a simple mission with a base and your flightgroup, putting multiple ships in your flightgroup ( preferably, pick a class of ship large enough to be able to tell which face you shot). Shoot your wingman. Switch to his vessel. Dock, look at ship stats, and see whether or not the stats that get spit out make any sense.

[chuck_starchaser]

Glad to have been useful

That's an understatement; I'd've been catmeat without your help.

...(sorry - need to do some work for the people who sign the paychecks, if you know what I mean ).

Been planning to do just that for like the past year, but keep procrastinating... One of these days I fear I'll get fired.

For testing, my top-of-the-head advice....

Excellent. Thanks once again. I'll try that. Hope you get a lot done at work.
Once you're back to normal schedule, I may have started to look into radar; I want to implement a simple "silent mode", so I'll probably have lots of questions. After that it's shaders. To hell with Ogre; I can program a shader in two days flat; just need to know where to stick it.

[targ collective]

All of this goes way over the top of my head. One thing doesn't though - Jack, you told us that more than one multiplicative upgrade should work, but that's not entirely true - that only applies if the best upgrade is less than twice as good as the worst. We have Durasteel (base 1), Plasteel (base 10), Tungsten (base 20) and Isometal (base 40) (where base = multiplicative factor).

The first is ten times as good as no armour, and the next two levels are twice as good as the previous.

The .template entry does not allow the purchase of any multiplicative upgrades unless they are stated in the .template entry.

Stating the most powerful upgrade causes max 4 Plasteel, max 2 Tungsten, max 1 Isometal (or 2 Plasteel and one Tungsten). This is not supposed to happen.

Unfortunately I am powerless to fix this - incredibly frustrating but I wouldn't know where to start - but the obvious solution would be to migrate the forbidden upgrades cell across to PU. Then armour for each ship can be produced, under Armour/Merchant/Light, Armour/Hunter/Medium etc. ensuring that only places which produce a ship class produce the armour for that class. It is so close I can taste it - I already have units.csv halfway there - but it's all wasted effort unless we can introduce a more sophisticated prohibition system.

EDIT: Turrets don't have .templates - that's probably why they don't autotrack when piloted. I'll test that soon.

[chuck_starchaser]

Wish I could help you, Targ; but the stuff you're dealing with, on the data side, goes well over MY head

[targ collective]

The dataside stuff isn't that hard - I'm completely self-taught, took me around four weeks to get the hang of things. Seems an odd weakness in someone of your intellect that you should have problems there, maybe I should send a quick tutorial your way explaining what I know.

Somewhere in the subversion .exe there's a whole load of code that controls how forbidden uppgrades are handled. In theory a straight copy/paste of that code into the PU .exe should work - theory because programming being what it is, lots of variables will have been renamed, new dependencies created and existing dependancies renamed. So not just the code but everything it relies upon will need to go into the PU .exe, after an extensive overhaul of the whole data structure to be sure everything works as planned.

...

Bottom line: We need an expert. I'm assuming you don't have any contacts we can harry into doing this (I'm also assuming you'd have mentioned by now if you did); if you do, let me know.

Otherwise I'll post in Developer Help etc. Maybe we'll get lucky.

[chuck_starchaser]

Good idea.

Sure, I could use such a tutorial. I tried to learn stuff about units.csv from the wiki how-to's, but information is rather sparse there. Okay, let me play the part of idiot asking (hopefully) good questions , then. If we go back to what JackS said,

There's a column in units.csv that contains a list, each entry of which can declare one of 3 types of upgrade restrictions:
1)if a category name is given, then upgrades from that category are not allowed.
2)if the name of a particular upgrade is given, then that upgrade is not allowed.
3)the above can be modified to allow N of a particular upgrade/category by appending :N to the end of the specified name.

For examples of use, in the current SVN version of units.csv for VS, there is an category of upgrades called upgrades/Overdrive (think afterburner). These upgrades are multiplicative (mult_overdrive01__upgrades, mult_overdrive02__upgrades, etc ) with values hovering around 2 for their AB thrust field (thus, applying this upgrade doubles your AB thrust). As it was not our intent to let one get 32x thrust by buying 5 of them, we place "upgrades/Overdrive:1" in the prohibited_upgrades column, thereby limiting the maximum number of upgrades coming from the upgrades/Overdrive category to 1. Some vessels cannot mount any overdrives at all, and have the an entry "upgrades/Overdrive" which can be taken as shorthand for "upgrades/Overdrive:0".

It sounds to me like all we need is an "upgrades/ArmorMaterial" category, containing 4 items:

• Durasteel = 1.0 (mult_armormat01__upgrades)
• Plasteel = 10.0 (mult_armormat10__upgrades)
• Tungsten = 20.0 (mult_armormat20__upgrades)
• Isometal = 40.0 (mult_armormat40__upgrades)

And somehow we make this category multiplicative (not sure how this is done, myself).

Then, for each ship, we put in the durasteel equivalent figures from the manuals, into the armor columns.

Then, in the Prohibited Upgrades column for each ship, we'd have something like,

Code: Select all

upgrades/ArmorMaterial:1

The .blank version of each ship would already have durasteel upgrade, since ships wouldn't be made of plastic.

Finally, the .template version of each ship would have the maximum armor upgrade for each ship. The Kilrathi apparently never went beyond durasteel, so the .template version of every kilrathi ship would have the durasteel upgrade, same as the .blank version.

I'm probably missing something, but I don't know what

[targ collective]

You're on the right track, but my version is... richer. Rather than multiplicative upgrades, the stations stock armour for the hulls of the starships they sell (and the hulls too). You want Paradigm armour? Get outta here sonny, this is a mining base. Want Kamehk armour?... Your ship was just impounded for study son, material worth given to you in credits, treat yourself to a Broadsword, welcome to Perry Naval Base. Etc, Etc. All of which hangs on this [CENSORED FOR THE SENSITIVE] Upgrades cell. I really hate feeling so powerless, hate it with a passion - I've got the tech knowhow to make this work dataside, but I can't code Python for... um... beans.

I'm still waiting for your questions, Chuck! So far you've shown a pretty comprehensive understanding of the picture.

EDIT: Mult_ is a prifex which means 'multiplicative' when applied to the key of the item. __upgrades is a suffix that tells the engine not to expect an external reference but rather to generate the upgrade from the values on the line. What goes between could be Bill, Fred and Martha for all the engine cares - those numbers were just reference values for dataside wizards like me, not value placeholders.

[chuck_starchaser]

Ahh, I'm starting to understand, now.

Okay, here's another question, then:

Do you really want per-ship armor upgrades?

Think about it: Armor upgrades are already per-ship the moment you make them multiplicative.

And you go to a garage and say "I want winter tires installed"; you don't even need to specify they are for your BMW; because the mechanic already sees you're driving a BMW and not a farm tractor.

And having ship-specific armors would pollute the the upgrades screens with kilometric lists of items. The upgrades screen is already pretty long for my taste already.

And having ship specific armors would pollute units.csv, which is already pretty long as is.

And worst of all, adding a new ship would require adding ship-specific armors for that new ship, which IMO would result in no new ships being added ever again

The only benefit would be to NOT have specific upgrades in every base, and that would be a benefit, I readily admit; but is it worth the trouble?

(Well, there's another "benefit" I can see: One could vary the price of the armor upgrade based on ship size; but this is rather due to (possibly) a shortcoming in the code side, which I might be able to address in the code side.)

But consider the fact that now you'd have to list, for every base, which specific armors are or aren't available. ***TONS of work***.

And every time you add a new ship type, you'd have to update all bases.

So how about we just forget about ship-specific armors and content ourselves with having ship-specific armor figures? The benefit of this is enormous, and it comes at a fraction of the workload of having ship-specific armor types.

Just IMHO.

[targ collective]

It's worth it without a doubt. Don't doubt the power of find/replace.

Replace all starships/confed/milspec in column cargo with starships/confed/milspec armour/confed/milspec/ship1 armour/confed/milspec/ship2 etc...

Do this for each ship type and you'll have specific armour upgrades installed for each ship ingame as purchasable.

A simple copy/replace for all listed ships in master_part_list, group highlight the lot and replace starships/ with armor/ and all you need to handedit is the keys, which can be pasted straight from units.csv whole. Bigest job is the custom descriptions. Etc, etc, labour-saving device after labour-saving device.

It's the only way short of hardcoded (therefore unmoddable, or at least difficult to mod) pricing to get things acording to cost.

After I've broken the back of it people will only need to add six new entries with each ship (armour and hull) for which I will provide a detailed tutorial. I'm the guy who's got to deal with the workload in truth (and I'm pushing the idea!) - a simple Excel chart to autocalculate the armour values will see maintenance of balance through.

All of which is a moot point - I'd do this if I had to type it with my nose! I'm that committed now. But I can't do it without that blasted, blasted Forbidden Upgrades cell. Grrr...

EDIT: Whoah there. You'd only need to specify which armours aren't available for the ships - bases are a cut above and the base stats would preclude, say, Dralthi Isometal going on those things. A find/replace across Prohibited Upgrades will update all but one ship (your landmark) making parity easy to keep. Best of all the technology is already there, proven to work.

Doing this codeside is possible, but if you do I must insist on the following: Alow the users to change the formula for the price calcs. Best way is to allow master_part_list to reference the cells in units.csv, allowing the game to reference a total of all armour values divided by existing armour protection (by which I mean the Plasteel, Tungsten etc. that we have now) times existing armour cost.

At least, that's the method I used when calculating prices.

[chuck_starchaser]

Okay, allow me another suggestion, then:

How about just getting multiplicative armors to work, for now, and do ship-type-specific armors later?

And like I said, if the main issue is price, this should be solved in the code side. Multiplicative upgrades should have multiplicative prices. I can try and fix that, instead of bloating units.csv.

[targ collective]

Beat me to the punch. Either needs the same cell, and only one gives us the specific pricings, so it would make more sense to me to use specific upgrades now while under-the-hood price calcs are under development. Then your suggestion would logically replace my hack-job as a leaner, fitter and more efficient method, losing nothing. Agreed?

EDIT: Sorry, bit rushed... Don't want to come over abrupt but must get going. I'm suggesting we use this as a stand-in, to get matters working for now while this is done, basically.

[Dilloh]

Allow me a suggestion, or rather a question, please.

You've been talking about this forbidden upgrade cell for a long time now - why don't you just put it in? I mean, VS seems to have one, so all you need to do is locate the script which reads it out in VS, and then port it over to WCU again. My thoughts are, from a logical (but surely no expert) point of view, those things were in VS all the time, and then removed for WCU/PR - most likely not by manners of deleting the things within the main code, right?

Just an idea... I always make my progress with trying out things. Maybe I'm totally wrong but in the end, the winner takes it all

[chuck_starchaser]

@Targ: Agreed, if you want to do so much work for nothing in the end. I don't know how hard or difficult will be to fix this pricing "bug" in multiplicative upgrades, but who knows, it might prove very easy. I've got to run to work now, but I'll take a look at the code tonight.

EDIT:
Sorry Dilloh, we posted at the same time.
That's a good idea. I don't know what would be involved.
And this raises a question I've asked before: I'm working with a late cvs of vegastrike. I don't know what version of vegastrike PU uses.
And what about updating PU to use the latest VS cvs?

[targ collective]

Erm, Forbidden Upgrades is new to SVN, like the deprecation of .templates. It never existed in PU. Older version of Vegastrike.

EDIT: Simultaneous postings kill chronology... This thead just jumped in size!

[Dilloh]

I don't know what version of vegastrike PU uses. And what about updating PU to use the latest VS cvs?

I dunno two - is there a way to find it out? Maybe there'd be a hint looking at the upload date of the file, or the download link thread in the PU forum. Updating cvs would mean releasing a new exe, right? Or just some files?

Erm, Forbidden Upgrades is new to SVN, like the deprecation of .templates. It never existed in PU. Older version of Vegastrike.

Okay, so you'd need to go the other way around, by comparing the VS python files of the latest two releases, if a dev cannot give the answer straight away. If you found a python calling this cell in units.csv, you've got it. If not, maybe it is hardcoded, but I don't think so - I'm no progger but I believe all calls on csvs rely on independent files.

[chuck_starchaser]

I don't know what version of vegastrike PU uses. And what about updating PU to use the latest VS cvs?

I dunno two - is there a way to find it out? Maybe there'd be a hint looking at the upload date of the file, or the download link thread in the PU forum. Updating cvs would mean releasing a new exe, right? Or just some files?

Hopefully but unlikelily just a new exe; but if nobody has updated the PR/PU exe since back in the days of Mamiya Otaru, there's probably been 700,000 changes since then. One way to find out would be to compile a new exe, throw it into the Privateer/bin folder, and watch carefully the colors of the smoke coming out of the cpu and videocard
I compiled one such exe after I did the changes to the armor code, but when I try to run it it gives me a function not found error with SDL.dll. I'll see if downloading a new SDL.dll solves the problem.

Erm, Forbidden Upgrades is new to SVN, like the deprecation of .templates. It never existed in PU. Older version of Vegastrike.

Okay, so you'd need to go the other way around, by comparing the VS python files of the latest two releases, if a dev cannot give the answer straight away. If you found a python calling this cell in units.csv, you've got it. If not, maybe it is hardcoded, but I don't think so - I'm no progger but I believe all calls on csvs rely on independent files.

That's one of the many things that might blow up, BTW: the python scripts written for the old exe...

EDIT:
Found the problem I was having. I had, speaking of the devil, thrown the executable I got from compiling the newest VS svn into the PU bin folder and expected it to work. Thing is, there's every obsolete dll under the sun and in the shades of Hell in that PU bin folder.
But then I tried running the compiled vegastrike.exe in its own data4x folder and I get an access violation... :-/

[targ collective]

A complete search of all files in the Privateer Universe directory shows the unit.csv heading combat_role appearing in four places: Moo.txt, units.csv, serialised_xml and vegastrike.exe.

No python scripts. Nothing tweakable. This is all hardcoded, and therefore out of my hands - I simply don't have the resources to tackle this.

EDIT: Call to arms has been posted in Internal How-Tos. Here's hoping!

[chuck_starchaser]

Sorry, Targ; yeah, I suspected there was no python involved; it's probably all in C++. Gotta run to work now; I'll fire up the compiler again tonight.