Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ARSPR on May 10, 2007, 02:11:54 am
-
I don't know if this feature is available now but it can be really useful to avoid conflics between mods and secondary mods, mainly mediavps.
Let me explain with an example. Imagine that I want to add in my mod or campaign a GTC Leviathan mk II. I want to use standard leviathan features, (mainly art features), with some modification in its speed, hull strength or whatever. Nowadays, (if the feature doesn't actually exist), I have to copy the full Levy entry from ship.tbl to my own extra tbm. And as I know I'm using mediavps I'd have to set pof as cruiser01x instead of retail cruiser01.
But imagine that the next version of media vps uses another model for Levy so cruiser01x, which is a media vp addition, is not available anymore. Then you have that my new mod is incompatible with this future version. So every time there's a revision in media vps, a lot of mods should be revised.
What I suggest is adding some kind of command in -shp.tbm to say that GTC Leviathan mk II is just a copy of GTC Leviathan. Then I'd have a scrath to modify through individual entries till I get the real features I want in my new ship. In this way, it doesn't matter if future media vps have changes in Levy art. They would be automatically applied to my new ship.
Imagine all the trouble we can save with new weapons, which are the most likely additions, where there are lots of art entries in weapons.tbl and/or -wep.tbm.
(I've noticed this after posting in PI campaign release (http://www.hard-light.net/forums/index.php/topic,46817.msg957913.html#msg957913)).
-
Ummm. That already exists. Open up the media VP files and check the .tbm files in there to see how they're done. You don't need to copy an entire table entry. People simply recommend that as a good starting point for newbies.
-
I'm pretty sure he means making a NEW entry based on an existing entry. A new ship, but with stats mostly copied from one that already exists. Unless I'm missing something and that DOES already exist?
-
IF I understand him correctly, +nocreate won't work for this problem, as he wants to be able to use the original and the modified one at the same time.
-
Sorry about my English...
Yes I want a command, let's say +Copy from xxxx, that would copy the full definition of a NEW ship/weapon from an original existing one. It should copy ALL the definition (the ship/weapon.tbl data plus all the -shp/-wep.tbm updates over them). Then FS2 would start applying the -shp/-wep.tbm changes for that NEW item.
As I have posted, it can be very useful to avoid conflicts with secondary mods, specially with Mediavps, if the modder is clean in its mod table building.
(You could restrict the use of +Copy from xxxx in just one level if that helps the coding. I mean +Copy from xxxx is not allowed from another +Copy from xxxx item).
-
Although this look like a good idea, I can't see anything but huge problems with it. Modular tables are loading in the order in which they are found, which means that the copy can end up with only some of the intended changes for the original. It also totally slaves the copy to the original. That means that any changes to the original also get applied to the copy, even if that causes problems for the copy since the copy didn't foresee those changes being made. It's nothing short of a Pandora's box and I can't see anyone being able to program around the myriad of issues that go with a feature like this.
It may be more work initially, but the only safe way to do this is to just make a new and complete entry, not relying on any existing table entries to function. It's far better code wise this way. And it's much better for you as well, since you will always know exactly what you are going to get. Such assurance is impossible with a copy feature.
-
Well, I'm going to post a real example.
CP5670's Procyon Insurgency has a SC Lilith and a SC Lilith 2 (both defined in ships.tbl in PImain.vp). As he is expecting mediavp use, he has a tbm in PIassets.vp that sets $POF file: cruiser03x in both ships. (Although lilith one is redundant because media vps tbms, he does need lilith 2 one).
But cruiser03x.pof is a mediavp addition and, Taylor, you are coding a feature that will allow to change this alternate model use with just a texture replacement over cruiser03. So maybe future mediavp editions are going to lack cruiser03x and PI is going to crash.
Of course, I know this feature can be quite like a Pandora's box in wrong hands. BUT if you use it wisely (as example only over a secondary mod like Media vps, a set you know is always going to have the same game balance settings), you could build mods which would be fully compatible with all future media vps editions, despite all their changes, and that will even 'autoupdate' art improvements. (Lilith 2 would use texture replacement instead of alternative model or new shockwave, Maxim 5 will use any new kind of particle, glow or whatever effect you add, and so on)
But, of course, I don't know HOW MUCH code work it supposes. And, as previously said, it is fully necessary that the copying command is applied over the final table result. So maybe you'll need to code two tbm readings. At the end of the first one, the items with +Copy would be ignored but copied from their sources. During the second one only the items with +copy would be read, and their own updates would be applied.
-
what about default templates for tbls? instead of +nocreate: have something like +use template: template name, while nocreate modifies an existing entry, use template copies another entry and then stacks its changes on top of it. take the herc 2 entry, say i want to take the herc's stats, but i want to make it faster and a little more maneuverable, but i don't want to modify the original. so i make a new entry with its own name, say advance herc 2, then i have +use template: herc 2, and i use any other entry for each part i want to change. so now i got what is essentially a herc 2 but its got a new name and a new set of stats.
now in that example it doesnt make it clear why i would need to do this. sure all that can be done in various other ways, like copying the old herc's table. 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 alot 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 alot of redundant table code.
but then again im starting to understand how much the insides and outsides of a program differ from each other, thanks to my continuing work on my own game engine. so if the idea dont work, please toss it into the great barrel of shattered dreams :D
-
But cruiser03x.pof is a mediavp addition and, Taylor, you are coding a feature that will allow to change this alternate model use with just a texture replacement over cruiser03. So maybe future mediavp editions are going to lack cruiser03x and PI is going to crash.
The new texture replacement stuff makes that optional, but it's not going to break with old tables. In my personal VPs I have already switched the Levy to use the standard cruiser01 and the Lilith to use cruiser03. They look exactly the same as before, but use the same POF. If the MediaVPs do the same thing then obviously PI will need to include the missing POF(s) in it's VPs, or change the tables to match. Technically that's a problem either way though. This is going to get off-topic pretty easily, but we probably need to work out community content packs once the next set of MediaVPs comes out. That would allow us to cut down on the base MediaVP content, and then have series of content packs which provide addition models/textures/effects. It adds a dependency issue, but does add considerably to compatibility.
Of course, I know this feature can be quite like a Pandora's box in wrong hands. BUT if you use it wisely (as example only over a secondary mod like Media vps, a set you know is always going to have the same game balance settings), you could build mods which would be fully compatible with all future media vps editions, despite all their changes, and that will even 'autoupdate' art improvements.
Yeah, the "wisely" is the problem. I'm confident that it's beyond my coding abilities to make what you want work properly. There is just too much that can go wrong, and the way my brain works, I can think of new problems all day long. I don't see it really being used that much, and it's probably going to require a significant amount of code work to pull off. But even it were done, the "wisely" part is going to kill us. There is so much room for abuse in a feature like this that we are going to get bug reports, ones that are extremely difficult to diagnose, like there's no tomorrow. Abuse with EFFs only gives you memory issues, but abuse with this can lead to all sorts of mission bugs, game crashes, and who knows what else.
Maybe one of the other coders will have an idea to make this work that I can't think of, but from where I sit, this particular feature isn't remotely worth the work and trouble that it brings. Perhaps karajorma or Goober5000 have something to add which makes the idea more feasible that what I'm thinking of.
what about default templates for tbls? instead of +nocreate: have something like +use template: template name, while nocreate modifies an existing entry, use template copies another entry and then stacks its changes on top of it. take the herc 2 entry, say i want to take the herc's stats, but i want to make it faster and a little more maneuverable, but i don't want to modify the original. so i make a new entry with its own name, say advance herc 2, then i have +use template: herc 2, and i use any other entry for each part i want to change. so now i got what is essentially a herc 2 but its got a new name and a new set of stats.
I thought that you were talking about the same thing as ARSPR at first, but that I realized what you were asking for: not a copy of a ship entry, but a stock template feature. That's actually a pretty damn cool idea. :D
In either the existing ships.tbl, or in tbms, you could just define a stock template. Those templates would be stored in a dynamic array, only during parsing, and a ship entry could reference that template as it's default values. The array would then be free'd after parse, since those templates would no longer be needed.
So you would have something like:
#Ship Templates
$Template: Fighter01
(normal ship entries which define the template)
#End
And then just reference in the ship entry. You wouldn't waste ship entries on the templates, the templates could be easily expanded via tbm, and you could specify the template and the entries that use it in the same tbm.
Does that should like what you had in mind. If so then that is most certainly doable, and I doubt it would take more than a weekend to code and test. :)
-
Whatever taylor decides is fine with me. :)
Also, on a tangential note (and possibly opening another can of worms...) is there a way to make POF files themselves modular? For example, Silent Threat: Reborn uses a number of model files with subsystems moved or dock points added. If someone wants to use the mediaVPs, the models will remain low-poly because the STR vp will take priority.
-
Wow, you're right, the $Template idea is awesome. And with a little creativity it could be made to do most of ARSPR's original idea's goal -- granted, with a few modifications to the mediavps someday. But even without that, where this would really shine is with TCs that don't use the 'retail' content. Especially if this could be done for weapons as well (or is that a good idea?)
Good point Goober. Come to think of it, the Leviathan and Fenris have different numbers of turrets, or is that accomplished just by setting some of the turrets to nothing?
-
The Leviathan and the Fenris have the same number of turrets.
-
I thought that you were talking about the same thing as ARSPR at first, but that I realized what you were asking for: not a copy of a ship entry, but a stock template feature. That's actually a pretty damn cool idea. :D
In either the existing ships.tbl, or in tbms, you could just define a stock template. Those templates would be stored in a dynamic array, only during parsing, and a ship entry could reference that template as it's default values. The array would then be free'd after parse, since those templates would no longer be needed.
So you would have something like:
#Ship Templates
$Template: Fighter01
(normal ship entries which define the template)
#End
And then just reference in the ship entry. You wouldn't waste ship entries on the templates, the templates could be easily expanded via tbm, and you could specify the template and the entries that use it in the same tbm.
Does that should like what you had in mind. If so then that is most certainly doable, and I doubt it would take more than a weekend to code and test. :)
thats pretty much what i was thinking. this also has the capability of vastly reducing table size which should speed up parsing alot. rather than loading 50-60 entries, it could find 10, and a bunch of relatively tiny entries for everything else.
Whatever taylor decides is fine with me. :)
Also, on a tangential note (and possibly opening another can of worms...) is there a way to make POF files themselves modular? For example, Silent Threat: Reborn uses a number of model files with subsystems moved or dock points added. If someone wants to use the mediaVPs, the models will remain low-poly because the STR vp will take priority.
i was thinking about this as well. something along the lines of an ascii baded pof format. same structure but in a readable format. mainly usefull for advanced pof tweaking. it also makes writing script based model converters possible on languages with dynamic data types. considering that every modeling program out there has some form of built in scripting system, wether it be python, ruby, lua, whatever. it would provide better support for users of those programs so they can create their own custom converters. or rather than an ascii format, what about an ascii format for chunk data only. then make it possible where you can run new models with an ibx and the chunk data. of course this makes that setup even more confusing.
or the other think that can be done is come up with a newer format from scratch. something a little more modern than pof. it can bring model features which would be more friendly to planned features like shaders, more optimized sorting of poly lists and other stuff like arbitrary use of transparency, and better animation capabilities like skelital anim and more advanced turret handeling.
-
I'd be willing to take a stab at coding in templates. It sounds like fun, and I can certainly see lots of use for it.
Of course, if someone like Taylor wants to take this and finish it in half the time it might take me, go ahead.
-
I'd be willing to take a stab at coding in templates. It sounds like fun, and I can certainly see lots of use for it.
Of course, if someone like Taylor wants to take this and finish it in half the time it might take me, go ahead.
Go for it. :)
I'm pretty excited about this one (not at all complicated to code up, massive benefit, practically zero negatives), but it won't be until after 3.6.10 is released that I would work on it anyway. You might as well take it in the meantime. I have worked out in my head the basics of coding it, so if you'd like any ideas of where/how to start then let me know.
-
The template system would be very useful. In the example ARPSR brought up, the Lilith 2 is identical to a normal Lilith except that it does not give off smoke when hit by weapons, so it could run off the Lilith and only incorporate that change. However, I'm not sure if it would really solve the original problem.
In the case of PI, I was planning to simply update the TBMs in it whenever a major media VP version comes out, which happens infrequently enough that it wouldn't be any real inconvenience.
Also, on a tangential note (and possibly opening another can of worms...) is there a way to make POF files themselves modular? For example, Silent Threat: Reborn uses a number of model files with subsystems moved or dock points added. If someone wants to use the mediaVPs, the models will remain low-poly because the STR vp will take priority.
The best thing would be if some of that data could be specified in the table entry in some way (overriding the data in the model). PI also uses several duplicate models with only the mass, MOI or FOV values changed around, so this would make that a lot cleaner.
-
I much prefer the ship copy system as well, when compared to creating an all-new system that people will have to know about and learn to use.
Although this look like a good idea, I can't see anything but huge problems with it. Modular tables are loading in the order in which they are found, which means that the copy can end up with only some of the intended changes for the original. It also totally slaves the copy to the original. That means that any changes to the original also get applied to the copy, even if that causes problems for the copy since the copy didn't foresee those changes being made. It's nothing short of a Pandora's box and I can't see anyone being able to program around the myriad of issues that go with a feature like this.
It may be more work initially, but the only safe way to do this is to just make a new and complete entry, not relying on any existing table entries to function. It's far better code wise this way. And it's much better for you as well, since you will always know exactly what you are going to get. Such assurance is impossible with a copy feature.
XMTs have the same problem of unforseen changes with the +nocreate flag. However I would view that as a strength rather than a weakness in this case, because it means that you don't need to modify 20-some copies at the same time (If that's the route that you end up going). If you include templates, in order to answer these objections, you would have to change the TBM and XMT rules for precedence and overriding that are used for everything else.
So now you have two interconnected types of data running around, possibly across multiple files, but with different types of behavior. One can be instantiated, one can't. One can be overridden, one can't. One can be modified in later files, one can't.
And what do you do if somebody derives a template from the MVP Orion template, and then tries to base the Orion on that template? Do they have to make a new copy of the Orion? It seems that if you allow a ship entry's template to be modified from the original it was created with, you again risk that a lower-order TBM will override it, and thus it will behave differently than intended. Restrict that, and now you're creating even more exceptions to TBM behavior, but in even more specific and not-so-easily categorized places.
Rather than implement an all-new system with a different set of behavior, you could just add a has_been_copied boolean to the ship_info struct. If it gets modified after that variable is set, you could throw a warning or an error.
-
the key is usage really. tcs can use the template+tbm system as they will be replacing everything anyway. individual ship mods can use the tbms alone unless theyre based off other templates. weapon mods need to use xmts to make their guns work with existing ships. with templates you can add weapons compatability on a per template basis, so if you got a weapon for light machine gun, you can apply it to the intercepter template, and all ships that use that template will also have that weapon. when youre stacking lots mods is where problems really occure because thats a messy way to do things as it is. you have a bunch of ships of varying levels of balence, with different aproaches to table usage which might not all be cross compatable. templates helps to clean up that mess more easily.
you could toss some standard templates into the media vps, based on averages of ships in the fs universe for a particular class. it wont screw with cannon because the fs ships will stick to the legacy static tbls. they will be loaded and tossed, or not loaded at all. then again you always come back to are the modders smart enough to use the features correctly. templates are also a good way to implementnew features quickly. say the newtonian gliding feature. you need lateral thrusters on a bunch of ships, add it to the templates, and youre done. think of it more as a replacement for the static tbl system of old.
-
You could still do all that with a ship copy system. All you'd need to do would be to define a ship class named "Bomber", never use it in FRED, and have all the bombers copy from it. Though to be honest, we already have a ship type called Bomber, so it might make more sense to find some way to integrate objecttypes and ship classes in that kind of case.
Am I correct in this assumption?
A template...
- is a ships.tbl entry with ordinary ship variables
- Uses $Template: instead of $Name: and/or resides in a #Ship Templates section
- Does not appear in FRED
- Cannot be overridden or modified via TBMs
- Copies all of its attributes to ships which use it.
- Is unloaded after parsing is complete
Or am I missing something here? (1) is just like a TBM entry. (2) is arbitrary. (3) is, I believe, already possible. (4) would only require an additional TBM flag, that should probably be added anyways (5) also requires a TBM flag, but its implementation is no different than the proposed ship copy feature. (6) is hardly worth mentioning, as TBL data makes up a very small slice of memory usage.
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.
In addition, the proposed feature doesn't even solve the original problem.
-
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.
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.
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.
In addition, the proposed feature doesn't even solve the original problem.
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.
-
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?
-
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.
-
The code I'm using as a basis for this discussion can be found here (http://www.mydatabus.com/public/tureyhall/z/ship.cpp), 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 alot 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 alot 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).
-
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 :wtf:
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.
:blah:
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?
-
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 :wtf:
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.
-
:blah:
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. :sigh: Try this link (http://www.fsoinstaller.com/ship.cpp).
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.
:sigh: 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 (http://www.fsoinstaller.com/ship.cpp).
-
:sigh: 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. :yes:
-
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 :wtf:
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. :)
-
what did i just start?
my bad, i didnt mean to make the coders fight :D
-
Coder fights generally results in better code. :)
-
oh ok, didnt want to look like a total ass there. :D