[taylor]

Species_defs modular table...

*-sdf.tbm

All the basic features of a XMT, put +nocreate after each $Species_Name: entry to modify an already loaded species, if it exists.  Otherwise if you don't have +nocreate then the entry will be created.  As with the normal species_defs.tbl most of the tbl options are required if you are creating a new entry.  Most of those will probably go optional at some point, but that will have to wait.


Fireball modular table...

*-fbl.tbm

These TBMs are special since the fireball table has a very specific number of entries in a very specific order.  The normal fireball.tbl has 6 entries with a specific function and must be listed in the following order: Medium sized explosion, Normal warp effect, Knossos warp effect, Asteroid explosion, Large explosion 1, Large explosion 2.  Each is required, though there is no real check to make sure that you have all of the entries, and the same effect name can be used for multiple entries.  An optional $LOD: entry exists to specify a lod count, at least 1 is assumed if not specified.  Note that in the case of the standard warp effect only 1 lod will ever get used.  If you make a DDS enabled EFF then create mipmap levels for it so you get the same benefit of using lods.

For the modular version of the fireball table, after the $Name: entry, there are 6 possible options and at least one is required.  These special entries are neither required nor supported in the standard fireball.tbl file, they are only for TBMs.  No entry in the modular table will ever be created since there can only be 6 options currently, they are only listed to modify an existing entry.  None of the 6 options are required in any order and you don't have to list all 6 in one TBM.

The options should be pretty self evident, but here they are:

+Explosion_Medium	the specified name and LOD count will be used for the medium explosion effect
+Warp_Effect	name and LOD count used for the normal warp effect
+Knossos_Effect	for the knossos/special warp effect
+Asteroid	asteroid explosions
+Explosion_Large1	name and LOD count for the 1st of the large explosions
+Explosion_Large2	name and LOD count for the 2nd of the large explosions

No effect in the fireball tables (modular or otherwise) is actually loaded until after all TBMs have been parsed and it determines exactly which 6 effects to use.  This modular table is rather restrictive compared to the others but that's a necessary evil in order to support the old tables and the current fireball code.  Hopefully it's still usable enough for everyone though.

[WMCoolmon]

Hmm, not to rain on the parade, but I would suggest swapping the "+Explosion_Medium" and other identifiers for something like "$Type: Explosion medium". It works better for arrays and parse warnings/errors.

It is very nice to see another coder actively support TBMs.

[taylor]

I did that at first actually, since it kept with the standard, but changed it since the new way was much easier to check for.  This way I didn't have to check for the line, stuff the string, do a few stricmp() calls, and error check at the end.  Doing what I did allows the parser to handle all of that and I just set the override based on what it found.  I'm not against changing it though if it's a bother in table, but it makes the code considerably cleaner as is.

[WMCoolmon]

Hmm, well I was thinkin something along the lines of

Code: [Select]

if(optional_string("$Type:")) {
   char buf[32];
   stuff_string(buf, F_NAME);
   for(int i =0;i<Num_exp_types;i++) {
      if(!stricmp(Exp_types[i].name, buf)) {
         lod_check.override = Exp_types[i].value; //Or Var_to_set = i;
      }
   }
}
Which (theoretically at least) would make it easier to add more types via scripting or otherwise. I haven't looked at the code in question to see how they're dealt with to see if that'd be practical. It also keeps more closely with classical table format, so is easier to document, etc. The other cases where this is used (right off the bat) are XMT parsing - where it works because it obviously differentiates the "+nocreate" from the rest of the fields - and subsystems, where I want to change that to a $Flags:() style deal since it'd be the same as ships, use more horizontal space, and possibly be able to reuse a function and make that whole thing more efficient (Right now each subsys flag uses a ubyte bool rather than a bitflag.)

[taylor]

The problem is that the fireball stuff is left-over from FS1 days and is neither forgiving nor easily expandable.  It looks something like weapon_expl.tbl in format but is nothing like it in function.  Using it in an expandable way only makes sense if you actually can expand on it.  The fireball code would have to be rewritten to do that.  I wanted it to be useful but it has to be restrictive enough so that it doesn't break how the current code works.  What I added was supposed to mimic "+nocreate", but in the opposite fashion, a "+create_as" type of thing.  It's not a flag style of option but a very exact course of action.

It would be better to just scrap the current fireball.tbl format (and parts of the code) and do it in a way that's forgiving and expandable and less prone to errors.  I'd rather wait for Bobboau's material system before deciding how best to do that though.

[BlackDove]

You know, I have no idea what you guys are talking about, but I have a feeling I should say "Good work" or "Thanks" or something.

So... Good Work and Thanks.

[Polpolion]

I don't even know how to use modulare tables. 

[WMCoolmon]

http://www.hard-light.net/wiki/index.php/Main_Page

Specifically:
http://www.hard-light.net/wiki/index.php/Modular_Tables

[Grug]

Modular tables are a god-send if you ask me.
They are so freaking handy its not funny. Especially when your just making a mod that adds on to the exisitng Freespace universe. ^_^

Kudos.