[WMCoolmon]

No one is saying that.  Changing the behavior is just silly, but that is essentially what adding a ship-copy system would do.  A ship-copy system is just a bad hack, mainly because it creates more problems than it solves, but also because it doesn't properly address the problem at hand.  Ship-copy doesn't make any sense for expanded use, since you not only have to set all of the values for that entry, you also have it set it up as a real entry.  The copy then has to provide all changes that deviate from the original.  That's a convoluted way to go about something like this.

So what does properly address the issue at hand, then? (I assume you're talking about the original post and not the current discussion of ship templates) You seem to acknowledge that ship templates aren't really meant for this kind of thing later on in your post, and you don't like the idea of adding ship copy functionality.

Further, I don't see why you say that you have to set up ship entries as real entries. It was never my intention for that to be the case with XMTs; in making all the fields optional, I meant for them to be as optional as possible, so that you could add ships into the game and test them out as fast as possible. The only toplevel required field should be $Name:. This would also allow you to tweak the template entry as you were making it, and then add the "no fred" flag (or whatever it is) once you were done and had finalized your changes.

Finally, I don't understand what you mean when you say that providing all the changes is part of a "convoluted way" to do something like this. If the modder only provides some of the changes that he wants in the ship entry, how else will the game know about any of the other changes?

The templates thing is merely an additional section in the tbl/tbm, just like #Ship Classes is currently.  The only difference is that the templates don't take up any ship entries at all.  So you can still have 130 ships if you wanted, rather than wasting one on the template/default.  The template is little more than a mod definable version of init_ship_entry(), simply providing the default values for a ship entry and then all of the optional stuff in that entry makes any changes that are wanted.  Other than a #Ship Templates section in the tbl/tbm, the only change required is to add a "+Use Template:" for any ship entry that wants to use a template.

Removing the ship limit is something that has been the focus of a lot of code/discussion, and it was my understanding that The Plan had it gone by 3.7, so I don't consider that a very persuasive point. I do not see the point to replacing init_ship_entry when the modder can already override all of the variables that it sets as they please. I also don't think it's a good idea to go back and re-implement required fields or, worse yet, implement some kind of dual parsing code where the fields are *sometimes* required, and *sometimes* optional.

No one said that it did/would.  It could be used to solve the original problem however, assuming that the method of doing the change in question uses templates instead of the full ship entries, but it's not specifically to address that issue. 

If used properly, templates don't seem like they would solve the issue. General consensus seems to be that you would have templates like "Shivan Bomber" or "Terran Gas Miner". Those sound more like ship types, to me (rather than ship classes). Those also wouldn't let you take an entry from a TC or mod, tweak it a little, and then use it in your minimod or campaign without having to worry about it getting made inconsistent in the next revision. And if the TC or mod decided to change the templates, you'd still be stuck altering the ship for each revision.

And if you're defining templates for every single ship class, I don't see how that's very different from simply implementing a ship copy feature.

Basically, it seems to me like you have a problem with the idea of any ship class being based on anything that could be changed apart from it, which means that there can't ever be a good solution to the problem for you, even if the modder is willing to take the risk. But that's an inherent possibility when one mod is based on any part of another mod. What would you consider to be the proper solution to the OP's request?

[taylor]

So what does properly address the issue at hand, then? (I assume you're talking about the original post and not the current discussion of ship templates) You seem to acknowledge that ship templates aren't really meant for this kind of thing later on in your post, and you don't like the idea of adding ship copy functionality.

Ship-copy is a cheap and hackish method of creating a "template" feature.  At one level they are the same thing, but actually implementing templates is the right way to go about it.  Templates are just a way to define a stock entry and use it for any number of ships, that's all.

If you actually think about it, ship-copy is just a way to use one ship as a template to make another ship.  The issue is that it's full of problems and can very easily screw up data, balance, etc.  That also have limited usefulness since everything is based on a ship entry that can change later on in parsing, you are basing it on a ship that needs to exist in the tbl before anything that copies it, and you have to change every single value that doesn't apply to all other ships which you it, as oppsed to having a simple set of default entries which applies to everything.

But if you actually add a true template for those two ships, then you only have to deal with the values that are different between them in both ships.  Ship-copy has limitations in usefulness, and major issues with implementation.  Templates on the other hand, still allow you to get the same functionality (albiet a bit differently) but with a much broader range of usefulness, easier maintenance, cleaner implementation, and considerably fewer problems.

Further, I don't see why you say that you have to set up ship entries as real entries. It was never my intention for that to be the case with XMTs; in making all the fields optional, I meant for them to be as optional as possible, so that you could add ships into the game and test them out as fast as possible. The only toplevel required field should be $Name:. This would also allow you to tweak the template entry as you were making it, and then add the "no fred" flag (or whatever it is) once you were done and had finalized your changes.

Ship entries as in a Ship_info[] entry, not the invidiual values.  Templates have nothing to do with individual fields.  The only differences in a template and a normal modular table entry is that +nocreate isn't valid, and $Name: is replaced with $Template:.  Otherwise they work the same, except for the fact that the template isn't going to take up a spot in Ship_info[].

Removing the ship limit is something that has been the focus of a lot of code/discussion, and it was my understanding that The Plan had it gone by 3.7, so I don't consider that a very persuasive point. I do not see the point to replacing init_ship_entry when the modder can already override all of the variables that it sets as they please. I also don't think it's a good idea to go back and re-implement required fields or, worse yet, implement some kind of dual parsing code where the fields are *sometimes* required, and *sometimes* optional.

Removing that limit is still going to happen for 3.7, but there is no reason to have to wait another year for a feature like this.  Adding templates is simple and clean and doesn't break any existing data.  It can be added now.  But there is still no reason to waste a Ship_info[] entry for it.

[Turey]

The code I'm using as a basis for this discussion can be found here, and is based on a recent download of HEAD. It's almost done, just needs to be checked over.

I do not see the point to replacing init_ship_entry when the modder can already override all of the variables that it sets as they please.

Can you point out where this is possible? I'm sitting here, looking at my copy of HEAD ship.cpp, and all of the values in init_ship_entry look like they're hard-coded. Maybe I'm just missing it.
Also, parse_template calls init_ship_entry in order to have a working ship_info entry before it parses the template. So I'm not replacing it.

I also don't think it's a good idea to go back and re-implement required fields or, worse yet, implement some kind of dual parsing code where the fields are *sometimes* required, and *sometimes* optional.

Nothing has been re-implemented. If it weren't for a need of informative warning messages, I could code this feature in such a way as to have the same code do 99% of the parsing (Everything other than "$Name:") for both ship classes and templates. As it is, I had to copy parse_ship into parse_template, but all the actual parsing code is exactly the same.
As you yourself said, parse_ship only has one required field, and that is "$Name:". The code for templates works the same way.

If used properly, templates don't seem like they would solve the issue. General consensus seems to be that you would have templates like "Shivan Bomber" or "Terran Gas Miner". Those sound more like ship types, to me (rather than ship classes).

Yes, but do ship types allow you to specify certain default settings to apply to just ships of that type? Yes, the prevalent use of these would seem to be similar to ship types or species, but those systems don't allow a moder to specify default ships.tbl values for each type/species (Except for thruster color).
There are also uses for this that are not directly related to ship types. For example, "Arwing" and "Inanimate Object" aren't ship types, but they're the templates I used when I went through and redid SoL's ships.tbl to use templates*.

Those also wouldn't let you take an entry from a TC or mod, tweak it a little, and then use it in your minimod or campaign without having to worry about it getting made inconsistent in the next revision. And if the TC or mod decided to change the templates, you'd still be stuck altering the ship for each revision.

Even with a ship copy feature, you're still stuck altering the ship for each revision. The fact that all the changes would get copied over wouldn't prevent the new tables from screwing up mission balance, difficulty levels, even making some missions impossible, depending on your campaign/minimod.
Let's say that someone has made a mod, with two opposing sides, "Terrans" and "Vasudans". You want to make a minimod in which a third side, "Shivans", shows up, and the "Vasudans" splinter into two groups, one of which helps the good guys, and one of which, "HoL", helps the "Shivans".
So you're making this minimod, and you want the "HoL" ships to be worse off than the good "Vasudan" ships, to help the player out. So you use copy ship, and half the maneuverability of all the "HoL" ships.
A few months after you release, the person who made the main mod decides the "Vasudans" are too hard, and reduces the maneuverability of all the "Vasudan" ships to one fourth of what they had. Now, your "HoL" ships are better than their "Vasudan" counterparts. You still have to alter your mod, even though you used copy ship.

Please note that, in Nuke's original suggestion, his reasons are thus:

but when you step back and look at maybe a tc, where the values are completely different. like in a tc like btrl. it would be nice to have a default fighter, a default bomber, ect. this not only makes the tc easier to develop, but it makes balance a hell of easier, since only values that are different will be shown in the tbms. it also has the added bonus of a facter tc development pipeline, as your not writing of redundant table code.

All of these are valid reasons to implement templates. If your only objection is that templates don't do enough, then I'm not sure that's a good reason not to do them.

*BTW, End result of use of  2 templates on SoL ships.tbl: Templated version had 498 fewer lines and was 20.7 KB smaller (a 20% reduction from the regular version).

[WMCoolmon]

Ship-copy is a cheap and hackish method of creating a "template" feature.  At one level they are the same thing, but actually implementing templates is the right way to go about it.  Templates are just a way to define a stock entry and use it for any number of ships, that's all.

You could do that with a ship copy feature. You don't necessarily have to do that with templates, either. What you're talking about is 'good design', which is independent of either system.

If you actually think about it, ship-copy is just a way to use one ship as a template to make another ship.  The issue is that it's full of problems and can very easily screw up data, balance, etc.  That also have limited usefulness since everything is based on a ship entry that can change later on in parsing, you are basing it on a ship that needs to exist in the tbl before anything that copies it, and you have to change every single value that doesn't apply to all other ships which you it, as oppsed to having a simple set of default entries which applies to everything.

This sounds like the first concrete reason I've heard for having ship templates. If, indeed, the parser is doing two passes of parsing .tbms - saving templates on the first, and then parsing ship classes - then I can see a usefulness for templates. Nobody has mentioned this being a feature of the template system prior to now. Nor did you mention it when I posted a clear list of what I understood to be a list of template characteristics. So

But if you actually add a true template for those two ships, then you only have to deal with the values that are different between them in both ships.  Ship-copy has limitations in usefulness, and major issues with implementation.  Templates on the other hand, still allow you to get the same functionality (albiet a bit differently) but with a much broader range of usefulness, easier maintenance, cleaner implementation, and considerably fewer problems.

Again, this is a design decision.

Ship entries as in a Ship_info[] entry, not the invidiual values.  Templates have nothing to do with individual fields.  The only differences in a template and a normal modular table entry is that +nocreate isn't valid, and $Name: is replaced with $Template:.  Otherwise they work the same, except for the fact that the template isn't going to take up a spot in Ship_info[].

(Ship limit)

Removing that limit is still going to happen for 3.7, but there is no reason to have to wait another year for a feature like this.  Adding templates is simple and clean and doesn't break any existing data.  It can be added now.  But there is still no reason to waste a Ship_info[] entry for it.

Given your description in this very quote, adding templates is less simple and clean, and just as likely to break existing data.

I do not see the point to replacing init_ship_entry when the modder can already override all of the variables that it sets as they please.

Can you point out where this is possible? I'm sitting here, looking at my copy of HEAD ship.cpp, and all of the values in init_ship_entry look like they're hard-coded. Maybe I'm just missing it.
Also, parse_template calls init_ship_entry in order to have a working ship_info entry before it parses the template. So I'm not replacing it.

Look at the values in init_ship_entry. Now look at the table variables. All of the values that are "hardcoded" in init_ship_entry can be changed when you define a ship.

Nothing has been re-implemented. If it weren't for a need of informative warning messages, I could code this feature in such a way as to have the same code do 99% of the parsing (Everything other than "$Name:") for both ship classes and templates. As it is, I had to copy parse_ship into parse_template, but all the actual parsing code is exactly the same.
As you yourself said, parse_ship only has one required field, and that is "$Name:". The code for templates works the same way.

Clearly you did not understand what I was saying. This sounds like the worst case I was thinking of, where you have two sets of code to parse the same variables. Now it will be necessary to remember to update both parse_ship and parse_template every time a new feature was added, and there's the possibility of them going out of sync and/or having different variable order.

Yes, but do ship types allow you to specify certain default settings to apply to just ships of that type? Yes, the prevalent use of these would seem to be similar to ship types or species, but those systems don't allow a moder to specify default ships.tbl values for each type/species (Except for thruster color).
There are also uses for this that are not directly related to ship types. For example, "Arwing" and "Inanimate Object" aren't ship types, but they're the templates I used when I went through and redid SoL's ships.tbl to use templates*.

If you're involving the #Ship Classes section of ships.tbl, you _are_ involving ship types, even if you don't specify any. There are places in the code that check for a lack of a ship type as well. Do not take ship type too literally; you could define a "Building" ship type just as easily as you could a "Fighter" ship type. (Except you'd have to come up with more of the variables yourself rather than copy-pasting them)

Let's say that someone has made a mod, with two opposing sides, "Terrans" and "Vasudans". You want to make a minimod in which a third side, "Shivans", shows up, and the "Vasudans" splinter into two groups, one of which helps the good guys, and one of which, "HoL", helps the "Shivans".
So you're making this minimod, and you want the "HoL" ships to be worse off than the good "Vasudan" ships, to help the player out. So you use copy ship, and half the maneuverability of all the "HoL" ships.
A few months after you release, the person who made the main mod decides the "Vasudans" are too hard, and reduces the maneuverability of all the "Vasudan" ships to one fourth of what they had. Now, your "HoL" ships are better than their "Vasudan" counterparts. You still have to alter your mod, even though you used copy ship.

Clearly the other person was happy with the balance when they tested it, and their entire point in releasing the mod was to change the balance. So why do you care about changing their version instead of just using the one you designed?

At any rate, templates wouldn't change anything. You'd still be stuck defining two sets of maneuverability, etc. values for both sides. If somebody else changed the Vasudans, the HoL would still remain unchanged, and you'd still have the same problems. Templates, as defined so far, are not a magical fix-all that will prevent people from messing with your mod balance or let you use mathematical operations to determine TBL values.

All of these are valid reasons to implement templates. If your only objection is that templates don't do enough, then I'm not sure that's a good reason not to do them.

*BTW, End result of use of  2 templates on SoL ships.tbl: Templated version had 498 fewer lines and was 20.7 KB smaller (a 20% reduction from the regular version).

Bluntly put, you clearly don't understand my objection to templates at all, nor do you even seem to have understood my post. Taylor is at least giving valid points that I haven't addressed already. But both you and taylor are making the fallacy of automatically equating good table design with templates, and bad table design with ship copy. There's no reason to think that your optimizations to the line count of the SoL ships.tbl couldn't be done using ship-copy rather than templates.

Furthermore, if you had actually taken the time to read my posts, you might've seen that I stated:

Basically what it sounds like to me is that because we would need to change two aspects of TBM behavior, what's being said is that we need to create a completely new system separate from TBMs. That's a rather silly jump.

I don't know how the hell you get "templates don't do enough" from that.

EDIT: I've tried three times to download the source file posted, but all I get is an empty file. Is anyone else having the same trouble?

[taylor]

This sounds like the first concrete reason I've heard for having ship templates. If, indeed, the parser is doing two passes of parsing .tbms - saving templates on the first, and then parsing ship classes - then I can see a usefulness for templates. Nobody has mentioned this being a feature of the template system prior to now. Nor did you mention it when I posted a clear list of what I understood to be a list of template characteristics. So

There isn't going to be two passes of parsing for templates.  There would have to be for ship-copy, but not for templates.  Templates don't add to each other, so you aren't going to piece something together to make a final template.  For maintenance issues, you can either define all templates in a single tbl/tbm, which is loaded before any ships using templates, or you can do a fighters-shp.tbm which contains all fighter templates and the ship entries as well.  Do that not only keeps the code simple, and help modders easily organize their info, but also makes it far less error prone.

Given your description in this very quote, adding templates is less simple and clean, and just as likely to break existing data.

No it's not.  Template functionality is simple to implement, clean, and doesn't break anything.


The exsting parsing code for ship entries is absolute crap.  It has gotten far too out of control and needs to be fixed, closer to how the mission parse code handles the same basic thing.  Yes, at the moment the way that Turey coded it means that you would have to add a new ship value to two locations for parsing, and yes, I told him to do that in this initial pass at the feature.  But it gives us the opportunity to clean up the exising parsing code and break it up into separate functions which make working on it in the future far easier and cleaner than it is now.

[Turey]

Look at the values in init_ship_entry. Now look at the table variables. All of the values that are "hardcoded" in init_ship_entry can be changed when you define a ship.

Yes, but you have to change those on a per-ship basis. Templates allows you to set defaults for a whole range of ships.

Nothing has been re-implemented. If it weren't for a need of informative warning messages, I could code this feature in such a way as to have the same code do 99% of the parsing (Everything other than "$Name:") for both ship classes and templates. As it is, I had to copy parse_ship into parse_template, but all the actual parsing code is exactly the same.
As you yourself said, parse_ship only has one required field, and that is "$Name:". The code for templates works the same way.

Clearly you did not understand what I was saying. This sounds like the worst case I was thinking of, where you have two sets of code to parse the same variables. Now it will be necessary to remember to update both parse_ship and parse_template every time a new feature was added, and there's the possibility of them going out of sync and/or having different variable order.

You're right. Re-written to use the same code for both. parse_ship and parse_template now call parse_ship_values, which fills a ship_info with the data in the table. Add any new ship table features there.

Yes, but do ship types allow you to specify certain default settings to apply to just ships of that type? Yes, the prevalent use of these would seem to be similar to ship types or species, but those systems don't allow a moder to specify default ships.tbl values for each type/species (Except for thruster color).
There are also uses for this that are not directly related to ship types. For example, "Arwing" and "Inanimate Object" aren't ship types, but they're the templates I used when I went through and redid SoL's ships.tbl to use templates*.

If you're involving the #Ship Classes section of ships.tbl, you _are_ involving ship types, even if you don't specify any. There are places in the code that check for a lack of a ship type as well. Do not take ship type too literally; you could define a "Building" ship type just as easily as you could a "Fighter" ship type. (Except you'd have to come up with more of the variables yourself rather than copy-pasting them)

Wait, what? Did you miss the first paragraph of that quote? Sure, you can define a "Building" ship type, but will every ship that uses the "Building" ship type automatically be given a speed of 0, and any other ship attributes you want associated with buildings? Templates will do that.

Templates, as defined so far, are not a magical fix-all that will prevent people from messing with your mod balance or let you use mathematical operations to determine TBL values.

No, but neither are ship copies, which was my point.

EDIT: I've tried three times to download the source file posted, but all I get is an empty file. Is anyone else having the same trouble?

It seems to work for me, but I've been having all sorts of trouble today with file hosting. FSOInstaller's FTP server went down, so I had to use myDataBus, which seems to be giving you problems.  Try this link.

EDIT:

The exsting parsing code for ship entries is absolute crap.  It has gotten far too out of control and needs to be fixed, closer to how the mission parse code handles the same basic thing.  Yes, at the moment the way that Turey coded it means that you would have to add a new ship value to two locations for parsing, and yes, I told him to do that in this initial pass at the feature.  But it gives us the opportunity to clean up the exising parsing code and break it up into separate functions which make working on it in the future far easier and cleaner than it is now.

And here I just spent 20 min merging the two... Can I leave it this way?

EDIT2: YAY, FTP back up! Latest Ship.cpp is here.

[taylor]

And here I just spent 20 min merging the two... Can I leave it this way?

Sure, the bigger cleanup can always be done later.

And the changes look good btw, nice work. 

[WMCoolmon]

This sounds like the first concrete reason I've heard for having ship templates. If, indeed, the parser is doing two passes of parsing .tbms - saving templates on the first, and then parsing ship classes - then I can see a usefulness for templates. Nobody has mentioned this being a feature of the template system prior to now. Nor did you mention it when I posted a clear list of what I understood to be a list of template characteristics. So

There isn't going to be two passes of parsing for templates.  There would have to be for ship-copy, but not for templates.  Templates don't add to each other, so you aren't going to piece something together to make a final template.  For maintenance issues, you can either define all templates in a single tbl/tbm, which is loaded before any ships using templates, or you can do a fighters-shp.tbm which contains all fighter templates and the ship entries as well.  Do that not only keeps the code simple, and help modders easily organize their info, but also makes it far less error prone.

But you do take the data from templates and add it to the data from ships, so it's basically the same thing. Instead of the process being:
init_entry --> template entry --> ship entry
You have
init_entry --> ship entry --> ship entry

So, really, the only reason that you would need two passes for ship copy is if you wanted to intentionally contradict TBM behavior, which doesn't make much sense.

The exsting parsing code for ship entries is absolute crap.  It has gotten far too out of control and needs to be fixed, closer to how the mission parse code handles the same basic thing.  Yes, at the moment the way that Turey coded it means that you would have to add a new ship value to two locations for parsing, and yes, I told him to do that in this initial pass at the feature.  But it gives us the opportunity to clean up the exising parsing code and break it up into separate functions which make working on it in the future far easier and cleaner than it is now.

I agree it's absolute crap, although I had a far more complete redesign than what you're describing. It's also completely irrelevant to ship copy.

Yes, but you have to change those on a per-ship basis. Templates allows you to set defaults for a whole range of ships.

Use ship copy for multiple ships.

Wait, what? Did you miss the first paragraph of that quote? Sure, you can define a "Building" ship type, but will every ship that uses the "Building" ship type automatically be given a speed of 0, and any other ship attributes you want associated with buildings? Templates will do that.

Yes, ship types could have done that, if you had chosen to implement the code there.

[Nuke]

what did i just start?
my bad, i didnt mean to make the coders fight

[karajorma]

Coder fights generally results in better code.

[Nuke]

oh ok, didnt want to look like a total ass there.