Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Tools => Topic started by: sigtau on November 01, 2010, 11:20:38 am
-
As per a request for a table <-> spreadsheet conversion program, I have taken the liberty of creating a program that does not only that, but also has the following features:
- Importing and exporting to the CSV file format (which can be opened in any major spreadsheet program)
- Clean up the indentation mistakes such as the ones found in many of the retail tables
- Ability to edit both TBL and TBM files
- Validate tables to further ensure less errors when testing in FSO
- Make SCP-only tables compatible with retail FS2
Here's a recent screenshot (an animated GIF which also demonstrates the menu GUI):
(http://img180.imageshack.us/img180/8486/menudemo.gif)
Any comments or feature requests?
-
Looks like something any modder would be happy to have, but where's the download? :D
-
Looks like something any modder would be happy to have, but where's the download? :D
This
-
I've been asked for a highlight but given that the developer (sigtau) is currently in touch with at least one of the people most on top of SCP tabling (Fury) I'll wait until release to spotlight it.
-
A couple things... would it be possible to group related fields (such as the laser bolt rendering info or beam data)? Does the program give you empty fields for flags that aren't included (such as SCP features)? And does it crunch any numbers for us (such as calculating damage per second or energy use per second)?
-
Does the program give you empty fields for flags that aren't included (such as SCP features)?
It's my impression it does this.
And does it crunch any numbers for us (such as calculating damage per second or energy use per second)?
Not sure about this, but then again this is what the whole export to CSV feature is for.
-
Kewl!! How about a live search (aka instant or immediate search)?
-
sigtau, you're MetalDestroyer's heir. :)
-
Just for the record guys, I'm still working on this. It's just taking a ****ing long time to complete due to how it handles table values--in this case, TBLView 2 has its own "table" which defines acceptable values for every entry in a .tbl or .tbm file, and this essentially means I'm having to read through the wiki and table every single possible entry for every table.
Coding the CSV conversion is the easy part compared to the sheer *amount* of work incurred by that.
-
Cool. Looks similar to that INI editing tool I-forgot-what-it-was-called for the old C&C series before I tried to figure out how to get by all those lines manually in Wordpad (I still don't know heads or tails of AI.ini even today, not to mention most of Rules... :lol:).
I guess all the INI editing helped me more-or-less understand the three common FS tables relatively quick (ships/weapons/sounds), but if a program can make it look less daunting then why not, I'd try it and see how it goes.
Sure beats staring at thousands of lines of text across multiple open files in Notepad... or something... and it might draw in more wannabe modders or two for FS down the line someday, who knows? :nod:
-
TBLView 2 has its own "table" which defines acceptable values for every entry in a .tbl or .tbm file, and this essentially means I'm having to read through the wiki and table every single possible entry for every table.
What does this mean? Are we going to have dropdown menus or checkboxes for $Flags:, or is it simply for table Error Checking?
-
Okay, sorry, my last post may have been a bit ambiguous. Here's a better explanation of how TBLView 2 handles tables and modular tables...
TBLView 2 operates on a configuration file of its own (with syntax similar to FSO's tables and Windows' INI files). The file is set up in this format:
# tblview.cfg example
# Lines starting with a # are treated as comments by TBLView 2.
# This is just an example of what TBLView 2 can do.
# In this block, we define the name of the table that TBLView 2 can read.
# For this example, we will be using species.tbl.
#
# As indicated by the second line under [Table], species.tbl cannot be made
# into a modular table (according to FSO). In practice, it could be made
# modular, but the SCP folks have yet to code that...
#
# The third line under [Table] states whether or not this table has an $End
# of some kind. A fourth line, $EndMarkerText, would define what text is used
# for the end marker ("End" in most cases), but is ignored (and unnecessary) if
# $EndMarker is set to 0.
[Table]
$Name: species;
$CanBeModular: 0;
$EndMarker: 0;
# This block defines what a single table entry would look like.
# We used the example at http://www.hard-light.net/wiki/index.php/Species.tbl#Sample
# The syntax for each line after [TableEntry] is as follows:
#
# $Field "FieldName",fieldType[,optionalParameter];
#
# The optional parameter's input will vary, depending on the field type.
# In the case of xstr, we define whether or not an $end_multi_text is necessary.
#
# For optional fields, we also have $OptionalField (not present in this example),
# and for field modifiers (fields beginning with a +, with the exception of +nocreate)
# we have $ModifierField (also not present in this example).
#
# Finally, we have $AlwaysRequiredField (which, regardless of TBL or TBM, it will always
# be written to and read from the table).
[TableEntry]
$AlwaysRequiredField: "Entry",ignore;
$Field: "Name",xstr,0;
$Field: "Anim",string;
$Field: "AlwaysInTechRoom",integer;
$Field: "Description",xstr,1;
[EndTableEntry]
# Just for completeness, [EndTableEntry] and [EndTable] need to be explicitly
# declared (to make the parser's job easier).
[EndTable]
TBLView 2 will parse this configuration file and use it to determine what values can be acceptably used in each table. This way, if a new table is added (or new options for a table are added) with a new version of FSO, we simply have to release an update for this file rather than releasing an entirely new program.
What I was trying to say in my first post, Galemp, was that this is how TBLView 2 determines acceptable input values. This is not just for error checking, it's for the whole program.
You won't need to ever touch tblview.cfg unless you're updating it. Doing so may cause TBLView 2 to generate invalid tables.
And as for whether or not we'll have dropdown menus or checkboxes for flags, I may just keep it a simple editable value where you directly type in the flags rather than using a checkbox or a dropdown menu. Java's Swing interface libraries aren't the most intuitive in the world, so a dropdown or checkbox would likely require me to re-invent the wheel just to get it working.
-
Looks good. Definitely needs a way to distinguish optional from mandatory fields though.
-
Just updated the specification. Any further objections or suggestions before I write the first version of the parser?
-
Looks good. Definitely needs a way to distinguish optional from mandatory fields though.
I would suggest the program not writing any lines with a null value unless the line is required which is not many if I remember correctly and of those lines some are only required in certain cases like pbank capacity which a warning along the lines of "pbank capacity not set in ships ####, ####, this might cause errors if any Ballistic primaries are assigned to this ship" would do when the table is being parsed
-
If you don't have any ballistic weapons in the ship's allowed loadout, debug builds will ***** and moan at you. In this case however, I would prefer debugs not to moan about it, only log it to debug log.
-
That's been fixed code wise.
-
Looks good. Definitely needs a way to distinguish optional from mandatory fields though.
I would suggest the program not writing any lines with a null value unless the line is required which is not many if I remember correctly and of those lines some are only required in certain cases like pbank capacity which a warning along the lines of "pbank capacity not set in ships ####, ####, this might cause errors if any Ballistic primaries are assigned to this ship" would do when the table is being parsed
Way ahead of you. If the field is optional and left blank, it won't even be included when it writes the table file. If it's required or optional and left blank AND it's a modular table (unless explicitly set inside tblview.cfg), it won't include it when it writes the table file. Any other time, it'll spew warnings (Null value found in this location, continue with save?).
-
What's happening with this?
-
:bump:
-
*sniffle* It's so sad when promising things die gruesome deaths... :(
-
*sniffle* It's so sad when promising things die gruesome deaths... :(
Sigtau's around plenty, wouldn't worry about this one just yet.
-
Yeah, just life and other projects (with a higher priority, unfortunately) have to come first, at least until Christmas weekend.
I've started work on the parser for TBL files. This is not dead.