[ARSPR]

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

[karajorma]

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.

[Backslash]

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?

[Turey]

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.

[ARSPR]

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

[taylor]

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.

[ARSPR]

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.

[Nuke]

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

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

[taylor]

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. 

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:

Code: [Select]

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

[Goober5000]

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.

[Backslash]

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?

[Goober5000]

The Leviathan and the Fenris have the same number of turrets.

[Nuke]

 

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. 

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:

Code: [Select]

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

[Turey]

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.

[taylor]

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.

[CP5670]

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.

[WMCoolmon]

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.

[Nuke]

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.

[WMCoolmon]

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.

[taylor]

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.