Ship templates are really limited.
They only apply within a single file, they're read-only, and they're not very intuitive.
Suppose you wanted to make a ship class, and then a variant of that ship class. You have two options: you can either copy&paste the entry and modify the second one accordingly, or you can make a template of the commonalities between the two and then make two ship classes that inherit from the template.
However, what if you want to make a variant of a retail ship class? Even worse, what if you want to make a variant, but incorporate changes made by the MediaVPs?
"Prepare for a lot of copy&pasting", some of you might be thinking. Under the current system, that's really the only option. But what if there were a better way?
I've been thinking a lot about a replacement for templates (one that, preferably, could be generalized to apply to more than just ship classes). The best way to find out how to implement such a system would be to find out how it would be used, however, so I could use the input of any modders who would be interested in such a system. Here's my basic ideas, though:
Individual ship/weapon/whatever-else-might-be-appropiate entries can be declared as "variants" of some existing ship/weapon/whatever. This will result in it copying the original and then applying any defined modifications (in a similar manner to ship templates). For example:
$Name: GTB Artemis D.H.
+Variant of: GTB Artemis
+Type: XSTR("Medium Bomber", 3005)
+Maneuverability: XSTR("Average", 3006)
+Armor: XSTR("Medium", 3007)
+Manufacturer: XSTR("Han-Ronald Corp.", 3008)
+Description: XSTR(" ", 3009)
XSTR("The GTB Artemis D.H. is an experimental variant of the standard Artemis class. The most notable change is that the Artemis's factory-issued Han-Ronald engines have been replaced by the same Nankam NA-27f powerplant now found in the GTF Ares fightercraft. The D.H. variant is faster and more maneuverable than the standard Artemis bomber, at no cost to armor or armament. During the OpEval period, Artemis D.H. bombers are being deployed in only select squadrons in different theatres of the war. If the evaluation trials go well, wider deployment of the Artemis D.H. class is expected.", 3010)
$POF file: Bonus2t-01.pof
That's a lot simpler than the actual entry for the Artemis D.H., isn't it? But wait, we've forgotten to actually change the engine performance! Let's modify it again:
$Name: GTB Artemis D.H.
$Max Velocity: *1.2
$Rotation time: *0.9
+Aburn Max Vel: *1.2
"What the hell did you just do?" some of you are probably wondering. Well, it seemed reasonable, to me, for variants to be able to specify some values as modifications of the original values (e.g. "$Damage: +5"). So I just increased the Artemis D.H.'s top speed (both regular and afterburner) by 20% and decreased the amount of time it takes to turn in a full circle by 10%.
Suppose you want to make a variant of a variant?
$Name: Subach HL-8
+Variant of: @Subach HL-7
@Laser Color: 255, 127, 0
@Laser Color2: 127, 0, 255
$Name: Subach HL-9
+Variant of: Subach HL-8
@Laser Color: 255, 255, 0
@Laser Color2: 255, 0, 255
"How does this work if the base variant changes?" Well, ideally, these would work in such a way as to make such changes apply retroactively (e.g., if a later TBM changed the velocity and/or damage of the Subach HL-7, the HL-8 and the HL-9 would use the new values as the basis for their modifications). Exactly how that would be implemented (whether they'd be done in multiple parsing passes or parsed all at the same time and then just processed later), I haven't decided yet, but the system wouldn't be much use if it didn't take such changes into account.Note to self: also consider things like $Max Velocity$ * 1.5.
One last thing. The MediaVPs introduce "#Shivan" weapon variants that have the same stats, but use a different model. These could be handled as variants fairly trivially along these lines:
+Variant of: @Rockeye
$Model File: S_Rockeye.pof
$POF target LOD: 0
$Flags: ( -"in tech database" )
First, I suppose I should address that "+nocreate". Normally it wouldn't make sense in combination with "+Variant of", just like it doesn't make sense in combination with "+Template": you're supplying the data for a complete weapon entry, so whether or not it existed before is irrelevant. However, in this case, the "+nocreate" wouldn't check for pre-existance of "Rockeye#Shivan" but rather of "@Rockeye"; this variant weapon would only be created if the original exists, and otherwise the entry is ignored.
Secondly, yes, it is
saying to clear the "in tech database" flag, thank you for noticing (syntax subject to change, of course).
With that out of the way... suppose you then want to perform balance changes on the original Rockeye without affecting any Shivan ships that might be equipped with "Rockeye#Shivan"s. If you try to just modify "@Rockeye" then the retroactive nature of variants will apply the same changes to "Rockeye#Shivan". So, I had this idea:
Well, somebody's a cheater, giving their rockeyes over twenty times the damage of their Shivan equivalents... the idea here would be that "+novariant" would make the entry be processed after "+Variant of" entries, allowing it to behave as an override, but only after any appropriate variants have been processed.
- What should happen if you try to make a circular set of variants (e.g. A is a variant of B, which is a variant of C, which is a variant of A)? My first thought would be "parsing error", but maybe C should just be treated as though it were a non-variant entry.
- Which kinds of data (besides ship and weapon classes) does this scheme make sense for?
- Well, objecttypes for sure.
- Which fields do modifiers (like "$Damage: *1.5") make sense for, and which fields do they absolutely not make sense for?
- Putting a "+novariant" modification entry in the same file as an item is defined allows it to magically reset changes later TBMs might make, which is... odd, to say the least. On the other hand, later TBMs can just make their modifications also use "+novariant"... but this rather ruins the point of allowing variants in the first place.
- Similarly, "+novariant" could presumably be used when the item was initially defined, preventing any variants from ever being made of it... although what reason someone would have to do that, I honestly couldn't say.
- Nothing really stops ship templates from being used alongside this system. If few enough mods use templates (AFAIK no currently-released mods do), it might be worth just getting rid of templates entirely in favour of variants.
So, what are your thoughts? What kinds of features would you like to see in this scheme (or even generally, in any kind of parsing overhaul, since one would probably be needed to implement this at all)?
It might help if people tried writing the kinds of table entries they wished
they could write, if they weren't constrained by the current system.