Author Topic: Variants: Templates of the FUTURE  (Read 981 times)

0 Members and 1 Guest are viewing this topic.

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Variants: Templates of the FUTURE
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:

Code: [Select]
#Ship Classes

$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)
$end_multi_text
+Tech Description:
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)
$end_multi_text
$POF file: Bonus2t-01.pof
$Ship_icon: iconbonusarty
$Ship_anim: ssbonus2t-01
$Ship_overhead: loadBonusartemis

#End

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:

Code: [Select]
$Name: GTB Artemis D.H.
$Max Velocity: *1.2
$Rotation time: *0.9
$Afterburner: YES
+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?

Code: [Select]
#Primary Weapons

$Name: Subach HL-8
+Variant of: @Subach HL-7
@Laser Color: 255, 127, 0
@Laser Color2: 127, 0, 255
$Velocity: +50
$Damage: +5

$Name: Subach HL-9
+Variant of: Subach HL-8
@Laser Color: 255, 255, 0
@Laser Color2: 255, 0, 255
$Velocity: +100
$Damage: *1.5

#End

"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:

Code: [Select]
$Name: Rockeye#Shivan
+nocreate
+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:

Code: [Select]
$Name: Rockeye
+novariant
$Damage: 1000

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.


UNANSWERED QUESTIONS:
  • 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?

GENERAL ODDITIES:
  • 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.
« Last Edit: November 18, 2017, 06:30:32 pm by AdmiralRalwood »
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Axem

  • Administrator
  • 211
Re: Variants: Templates of the FUTURE
This sounds really cool and I hope this gets implemented. I have so many near dupe weapon entries for JAD where the only real difference is color (Ships too!). Sometimes I rebalance one weapon and forget about another, so this would be pretty cool.

Now crazy question: Let's say I'm making a mod where you can do things like buy upgrades for your weapons. So you'd have like Prometheus S, Prometheus S-A, Prometheus S-B. Now to cut the player a little slack with keeping their weapon loadout manageable, could there be like a $Supersedes field that would instantly replace the older version in the loadout?

Like I'm armed with Prometheus S. I get the upgrade and the mission does a unlock-weapon Prometheus S-A. The game sees "oh hey, the S-A supersedes the original and both are available. So let's throw it in even though the FREDder says default loadout is Prometheus S." (And obviously the superseded entries are now hidden.)

(Note: I am not making a mod like that yet...)

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Variants: Templates of the FUTURE
Now crazy question: Let's say I'm making a mod where you can do things like buy upgrades for your weapons. So you'd have like Prometheus S, Prometheus S-A, Prometheus S-B. Now to cut the player a little slack with keeping their weapon loadout manageable, could there be like a $Supersedes field that would instantly replace the older version in the loadout?

Like I'm armed with Prometheus S. I get the upgrade and the mission does a unlock-weapon Prometheus S-A. The game sees "oh hey, the S-A supersedes the original and both are available. So let's throw it in even though the FREDder says default loadout is Prometheus S." (And obviously the superseded entries are now hidden.)
This wouldn't even require the Variant system; I'm hesitant to say it wouldn't be much work (I've looked at the loadout code before and it's anything but simple), but it would definitely be less work than completely changing how tables are parsed (which I expect Variants to require), and could be worked on entirely separately.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Axem

  • Administrator
  • 211
Re: Variants: Templates of the FUTURE
Okay well I guess it wouldn't require Variants, but I feel it would sure go hand in hand with it really well. Instead of making extensive duplicate entries, you just have a few extra lines about the upgrade. (Even as a other project thing)

 
Re: Variants: Templates of the FUTURE
Having a kind of inheritence system sounds like a neat idea.

My variant script doesn't do weapons and only covers a limited number of fields.

 

Offline The E

  • He's Ebeneezer Goode
  • Global Moderator
  • 213
  • Nothing personal, just tech support.
    • Skype
    • Steam
    • Twitter
Re: Variants: Templates of the FUTURE
I am somewhat against the idea of defining variant values as modifiers of existing ones. From a maintenance and balancing standpoint, it's a nightmare; any sort of action-at-a-distance is a bad thing there.
**** every cause that ends in murder and children crying. ― Iain Banks
Join the fun at the HLP IRC channel. Get the latest spam and gossip as long as it's fresh!

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Variants: Templates of the FUTURE
I am somewhat against the idea of defining variant values as modifiers of existing ones.
Then don't; the existence of an option does not require it to be used, and specifying an absolute value would still work.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 
Re: Variants: Templates of the FUTURE
From a programming perspective, this is a brilliant, brilliant thing. Balance-wise, like The E said, it might be a little tougher to maintain if you have a lot of nested variants at length with modifiers, and then you edit the "parent class" variant, but that's more of a problem of organization than anything and easily solved. And of course you can just use absolutes for stuff that is likely to be rebalanced, or everything, if you want to have at-a-glance info about a variant's stats. Or you could just comment the defaults after the modifier values for reference down the road, etc. That and the +novariant flag would make a lot of base class modifications flexible. Cool stuff.

 
Re: Variants: Templates of the FUTURE
I would say that this feature idea would actually work the best with a would be nice feature z64555 and I were discussing for wxFRED, which is table editing. Basically, we were saying how nice it would be if, once the basic functionality was working, we could some day extend wxFRED into an all in one (model creation excepted) modding tool. If we were able to do this, eventually, I could see where it could be set up that when a table entry is loaded, the UI also puts a link to any parent or child objects of the entry. This would minimize the unintended consequences issue, as the modder would know what they are working with at any time.
There are only 10 kinds of people in the world;
those who understand binary and those who don't.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Variants: Templates of the FUTURE
It's time to talk about VARIANTS some more!

Okay, firstly, as I'm working on adapting the old objecttypes expansion to the current codebase, it's obvious that objecttypes would be another table that would benefit greatly from being able to define variants, so I'll be be modifying the first post to remind myself later (when I finally implement this stuff). Secondly, I had an idea for another potential parsing change that could be made at the same time:
Code: [Select]
+Aburn Max Vel: $Max Velocity$ * 1.5
Modders! How useful would it be to define some values as being relative to other values in the same entry? Would anyone use that functionality if it were available?
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Axem

  • Administrator
  • 211
Re: Variants: Templates of the FUTURE
Recalls the countless times he's increased the max speed for a ship but forgets to increase the max overclock speed of a ship and wonders why the speeds never seem right

Maybe.

 

Offline Cyborg17

  • 29
  • A-1 Supar
Re: Variants: Templates of the FUTURE
Missed this when it was posted in the first place.  I love everything about this, except, I am not sure why the +nocreate flag should follow that usage.  The way I see it, if no original exists, then a warning should pop-up on debug and the game should ignore the rest of that entry so as not to spout a dozen other errors.   That way if someone unintentionally removes the original, the game will yell at them for the right thing and they will know how to fix the issue.

If they were to create an entry with a +nocreate flag and make the same mistake, their variant disappears from the game and they may not be able to figure out why, especially if working from someone else's tables instead of documentation.  Add to this the name confusion that can come from +nocreate, and some newb modder in the future is going to be banging their head against the wall.

If the original does not exist, then we probably cannot create a complete variant anyway, and the modder should complete the variant entry manually or iirc they could comment out the variant until they come up with some other solution.

(in most cases we are depending on the main stats of the original entry to save time, few people would create a variant with almost all unique entries except for adjusted flags or some other nonsense)

And no, I do not know exactly how often modders would use the special case suggested, since I am a less experienced modder.  I could totally be wrong. But we should at least use a different name for this usage -- +iforiginalvalid or something like that.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Variants: Templates of the FUTURE
I love everything about this, except, I am not sure why the +nocreate flag should follow that usage.
Because the MediaVPs shouldn't throw warnings when used with a custom weapons table, and ideally they shouldn't litter it with Shivan variants of weapons that no longer exist, either.

EDIT: To be clear, "+nocreate" should only be used in the kinds of situations you want this "+iforiginalvalid" to be for. There is no use case for +nocreate outside of mods like the MediaVPs.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.