[Nuke]

although it seems nearly impossible, it would be cool if we could have a freespace-c script (similar to quake c) to replace tables in freespace. quake-c is an easy script to learn and has spawned a great many mods. i know tables are really easy to work with and have made freespace modding a sinch, but it would be nice if we could have more versitility without having to suffer the massive headaches of modifying the source code directly.

[WMCoolmon]

This is a pretty good suggestion, and if it's applied anywhere, it'd be most useful to see it applied to the AI, so that people could quickly learn the scripting language and write new AI modes for FS2, or their campaign

[Nuke]

i like the idea of defining ships and weapons by strings of function instead of restrictive tables. it would also serve as a medium to implement much demanded model animation. it would be generated by altering the orentation of subobjects.

[penguin]

this is too scary a subject for me to even deal with at this point, so I'll keep my head buried until someone decides what we're gonna do with this

This one definitely goes into the "Big Honking Major Changes" folder.

[Nuke]

now if we could only get the coders to look at it.

[Sesquipedalian]

You just did.  They ran away.

[penguin]

"Discretion is the only part of valor"  -- Larry Niven

[Nuke]

well that sucks. i just wanted a kinda intermediate coding system, not as tedious as straight c++ but not as restricting as the tables. just think if you implement something like this then you delegate many a stupid idea to be implemented by less able coders like myself.

[EdrickV]

Developing such a system for FS2 would be a huge task. And if you removed table support that would break backwards compatability with all the existing MODs and the original campaign. Tables (and similar files) are only as restrictive as they are designed to be. On the other hand, the more data that is stored in tables means the slower loading times will be. (It's a lot faster to access data stored within the exe then it is to access an external file.) Tables are also easier to understand for non-programmers. I'm not saying this is a bad idea, but it would need a lot of design work to figure out how to impliment it. (Not to mention designing and building an interpreter.)

[Bobboau]

you know I've been thinking, maybe we should make a binary table file,
preserve the old text table reading but include the ability to load and save a binary table, maybe comand line swiches
-bintable ~ would load binary table data
-compiletable ~ would compile all text tables into binary tables
else
it would do nothing diferently
why do I want to do this, simple, it would make data loading much faster

[penguin]

Loading a binary table would certainly be faster, but it has the major downside that you now need a tool to edit it, or even to inspect it... you can't just pull it up w/ Notepad.

And a corrupted binary file is much more difficult to detect.

I say this with a certain degree of confidence At work, we are currently converting all of our text-based tracking files to a binary format.  These are big files, the text files total about 500M, which we must process every 15 minutes, so load time and file size are a big deal...

What we've experienced:

• The size is decreased to about 60% (FS2 tables would probably compress even better, since there's so much white space)
• Load time is about five times faster if they're fixed record length; if there is a lot of variable length stuff, they seem to load about 1.5 times faster.
• A corrupt file (especailly w/ a bad record length indicator) can wreck your whole day

[Bobboau]

well what I am sugesting is useing text based tables while developing a mod and when you are done editing tables for a while, you get them compiled and can focus on mission balencing, wich will be easier if you're missions load faster, then make sure everything is working then you can send text and bin tables out with your mod

we could posably make a binary table editor (and I was also thinking about makeing a native POF data editor) in Fred

[Eishtmo]

Originally posted by penguin
"Discretion is the only part of valor"  -- Larry Niven

"Bravery is but the lack of common sense."  -- The Sage

[WMCoolmon]

I like the compiled tables idea, and it would be feasible to make a compiled table editor.

[Mehrunes]

Aren't the TBL files only about 2 megs total? This looks like quite a bit of work for what would seem to be a negligible return.

[Bobboau]

I don't think it would be that dificult, and the retusrns wouldn't be in the size of the file but the time it takes to proces it

[EdrickV]

I can't say this for sure as I don't have any way to test it right now, but I imagine that parsing tables (and missions) probably don't take all that long. What I think takes up most of the loading time is likely loading and parsing the POF files and loading the textures. The filesize of the Orion model is about 641 Kb. And that is just one model. The big C's POF is over a megabyte in size. And that doesn't count textures, which are in seperate files.

[mikhael]

Originally posted by Nuke
well that sucks. i just wanted a kinda intermediate coding system, not as tedious as straight c++ but not as restricting as the tables. just think if you implement something like this then you delegate many a stupid idea to be implemented by less able coders like myself.

This is where I recommend Python again. There's already embedded versions of Python ready to be used as an ingame scripting engine. Heck, Freedom Force makes extensive use of Python in all aspects of the game. The important thing about Python is that its easy to learn, easy to read, and most importantly, easy for someone (you or anyone else) to debug your scripts.

[penguin]

I'm w/ Edrick on this one, unless someone convinces me otherwise...

The load time is not that long, and there's a lot to be said for human-readable files, and especially backward compatibility.

If we wanted to chuck backward compatibility out the window, there are a lot of changes we could make to the files to make them load faster and still keep them in text format....

[WMCoolmon]

Originally posted by penguin
If we wanted to chuck backward compatibility out the window, there are a lot of changes we could make to the files to make them load faster and still keep them in text format....

IMO, we should try to do this. Backwards compatibility is nice, but it shouldn't be the prime directive for the project. If need be, conversion programs can be made.