[WMCoolmon]

This was brought up in another topic, and I'd like to extend the idea.
The reason behind making the TBL files binary is to improve loading speed, as well as (slightly) reduce size. For all you non-coders out there, making the files binary would be stuffing all the info into a file end-to-end. A program would have to be made to  edit the files with a friendly GUI.
Taking this a step further, I'd like to suggest the TBL data be added as a chunk to each model's POF-if it doesn't exist, FS2 does the normal table checking routine. This is for a few reasons:
First, it means Freespace only has to open one file for each model, which further improves loading speed.
Second, it makes it much, much easier to add/remove ships in general, and especially for Freespace/2 newbies.
Third, an addition to POFCS would mean only one program would be needed to move a ship into Freespace.

The result: Table data would be integrated into the POF files, with the usual .tbl files being supported.

Comments? Complaints? Heated responses?

[demon442]

nice ideas...wow...like to see this in the next release.

[vadar_1]

Well... that sounds like of work... both during and after implementation. Personally I dont see whats wrong with the current system. Missions load plenty fast for me, and installing a ship is easy as plunking down a chunk of values into the middle of a text file. Making table entries is as easy as copy and pasting.

[WMCoolmon]

Originally posted by vadar_1
Well... that sounds like of work... both during and after implementation.

The code to parse the tbl file is already there, as is the code to read the POF files. File I/O isn't too hard, anyway.

Personally I dont see whats wrong with the current system. Missions load plenty fast for me,

It can be faster, though, and even an insignificant increase in speed (.25 seconds) will quickly add up when loading 10-20 ships.

and installing a ship is easy as plunking down a chunk of values into the middle of a text file.Making table entries is as easy as copy and pasting.

Which is easier:
"Copy the POF to data/models and run freespace."
"Copy the POF to data/models. Next, download VPView and install it on your system. Open up root_fs2.vp and enter the tables directory; extract ships.tbl to data/tables/ships.tbl. Open it up in a text editor, such as notepad, and copy the following into it just below the 'GTF Ulysses' entry. Save and exit the file, then run freespace."

[vadar_1]

Originally posted by WMCoolmon

Which is easier:
"Copy the POF to data/models and run freespace."
"Copy the POF to data/models. Next, download VPView and install it on your system. Open up root_fs2.vp and enter the tables directory; extract ships.tbl to data/tables/ships.tbl. Open it up in a text editor, such as notepad, and copy the following into it just below the 'GTF Ulysses' entry. Save and exit the file, then run freespace."

Most of us already have the table extracted. It allows easy access to all ship code in a central database, changing and modifying fields, grabbing values from other fields, cloning entries, etc, etc, etc, etc. Its like having a database where, each entry is its own database.... whats the point of the database then? Imagin the calculator on your computer, where each function (add, subtract, divide, multiple, mod, etc) where a program of its own. Sure its really easy to perform one function. But what if you need to integrate all those functions together? Youd need to do one function, copy the value to the next program, perform the function, copy the value... etc. Well the same would be for creating a manipulating fields in the ships table opposed to built in tables for each individual model.

[WMCoolmon]

Originally posted by vadar_1
Most of us already have the table extracted.

But not all, and it's a lot easier to copy a file from a zip to a folder than it is to go through the process above to add it. Then you have to hunt down the entry in the TBL rather than just deleting the POF.

It allows easy access to all ship code in a central database, changing and modifying fields, grabbing values from other fields, cloning entries, etc, etc, etc, etc. Its like having a database where, each entry is its own database.... whats the point of the database then? Imagin the calculator on your computer, where each function (add, subtract, divide, multiple, mod, etc) where a program of its own. Sure its really easy to perform one function. But what if you need to integrate all those functions together? Youd need to do one function, copy the value to the next program, perform the function, copy the value... etc. Well the same would be for creating a manipulating fields in the ships table opposed to built in tables for each individual model.

Unless you're basing a ship off of three or four other ones, you ought to be able to open two instances of POFCS side-by-side and copy the data between the two. Besides, why don't you want POF data in the TBL files so that it's easier to use as a "database"?

[vadar_1]

How wrong I was

I love this idea

My opinion has not been influenced.

__________________
[glow=blue]Full Circle Campaign[/glow]
"All I see is blackness! oh... my hood is down" - Undead Acolyte

Naming your online comic:

Example #2: Comic is about a single father (Bob) trying to raise his wisecracking son (Tim).

BAD TITLE: "Adolf Hitler's Rotating Testicle of Doom". While being somewhat catchy, references to the Nazi party and most genitalia should probably be avoided.

[/size]
Last edited by WMCoolmon on 08-13-2002 at 11:49 PM[/size]

[Bobboau]

... eh looks like WMCoolmon has admin powers...

anyway, I don't want the table data moved out of the ships table, I want all my ship stats together in one central database

on the other hand I do (obviusly) like the idea of an optional binary table reading/writeing
we wouldn't need a new tool or anything, we just need to have a comandline swich for compileing the text tables in to binary, and one for useing the compiled binary tables rather than the text ones

loading time is a major major major concern for me becase it takes me between five and fifteen minutes to load a mission

[vyper]

*holds head in hands* Oh they're gonna do it... my tables... my lovely tables....

[Sesquipedalian]

Could we make it so that the tables are compressed into binary on engine startup?  FS2 reads the files once at the beginning anyway, so why not use that time to compress them into binary?  Then they could continue to exist in their current text-based format to our eyes, while still giving faster load times when one starts an actual mission.

[Sandwich]

Originally posted by vadar_1
How wrong I was

I love this idea

My opinion has not been influenced.

__________________
[glow=blue]Full Circle Campaign[/glow]
"All I see is blackness! oh... my hood is down" - Undead Acolyte

Last edited by WMCoolmon on 08-13-2002 at 11:49 PM [/B]

Nice try Vadar, but next time, keep the time differences in mind. Oh, and remember that one's siggy doesn't usually appear when the post is quoted.

Fishy-smelling posts aside *ahem*, I personally don't like the idea, simply because TBLs are an understood storage medium for ships and verything. Doing away with them would mean that, while adding a new and completed ship would be a bit easier, developing that ship in the first place - testing the POF in-game to see if there's any holes, for example - would be more complicated.

[WMCoolmon]

Could we make it so that the tables are compressed into binary on engine startup? FS2 reads the files once at the beginning anyway, so why not use that time to compress them into binary? Then they could continue to exist in their current text-based format to our eyes, while still giving faster load times when one starts an actual mission.

Converting them into a binary format every time Freespace 2 loads is a bit inefficient-loading them on startup would accomplish the same thing in less time. Missions would load faster, but Freespace 2 would take more time to start up.
This would have the bonus of making the TBLs directly readable by the engine and a person without making a binary, but would force you to restart Freespace to reload the TBLs-no alt-tabbing back and forth.
On the other hand, if Freespace were to create the binary format from the ships.tbl if a binary file is not found, that would have the added effect.

Originally posted by Sandwich
Fishy-smelling posts aside *ahem*, I personally don't like the idea, simply because TBLs are an understood storage medium for ships and verything. Doing away with them would mean that, while adding a new and completed ship would be a bit easier, developing that ship in the first place - testing the POF in-game to see if there's any holes, for example - would be more complicated.

I disagree. For the ships.tbl, having it in the POF and adding support for another chunk would make it quick and easy to make changes to the POF and the ship info at the same time- just click a tab. (Assuming POFCS adds support for the chunk)
For the other tbl files, having them in binary format wouldn't be too much of a problem, since support would have to be added for editing them-likely in the form of a GUI. To preserve backwards compatibility, and to keep the project legal, a TBL->binary conversion function would have to be made for each TBL and making a binary->TBL conversion function would take little time at all.

At any rate, I've started on a ships.tbl->binary converter (Directly, not doing anything with POFs.)

[Sandwich]

Also, as I see it, the reason Freespace is so MODdable is because of the "user-readable" TBL and FS2 files.

Also, when you want to add a new section to a table entry for something that was just coded into the source, who wants to wait for the binary coder to be updated? And what if the person doind the coding has to depart the FS scene?

Take an example from Terminator - don't put your complete dependance on machines.

On the other hand, what I think would be cool is a FRED2 for TBLs - something that parsed the textual TBL files and provided quick-and-easy fields to work with. That way you'd have that convienence without loosing the flexibility factor.

[Kazan]

POF files are for MODEL DATA only - the contents of the table are not MODEL DATA

the human-readability of the tbl files allow joe blow to mod the game

I don't support any waste of time making the tbl's binary - as it will cause more problems and waste massive ammounts of programming time making it harder to mod that game.  

besdies the table loading occurs ONCE in the game - and bitbltting text and converting it to binary isn't too complex of a task

[Sandwich]

Originally posted by Kazan
POF files are for MODEL DATA only - the contents of the table are not MODEL DATA

This is a good point, and one that seems to be overlooked. If I want to model the Defiant from DS9 as a player-flyable ship, first thing would be to see how feasable something like that is - meaning I'd plug the TBL entry of a bomber with the POF of a cruiser and take her for a spin. Having that interchangeablity is crucial to the testing process.

As an aside, I actually did make a very primitive Defiant, and I got it working in-game fairly well. Pulse phasers and all.