Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nuke on August 05, 2002, 10:29:45 pm
-
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.
-
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 :nod:
-
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.
-
:eek: 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.
-
now if we could only get the coders to look at it.
-
You just did. They ran away.
-
"Discretion is the only part of valor" -- Larry Niven
-
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.
-
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.)
-
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
-
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
-
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
-
Originally posted by penguin
"Discretion is the only part of valor" -- Larry Niven
"Bravery is but the lack of common sense." -- The Sage
-
I like the compiled tables idea, and it would be feasible to make a compiled table editor. :nod:
-
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. :confused:
-
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
-
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.
-
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.
-
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....
-
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 :D for the project. If need be, conversion programs can be made. :nod:
-
how would an optional binary table loading affect backward compatability?
also the text files would still be used, I am only sujesting after you have you're tables done, you compile them so they can be loaded faster.
-
i for one do not care much for backward compatability. the whole point of making changes is to broaden the capabilities of the freespace engine. if you have to write fancy scripts to get all the old ships to work again then so be it. i want more options on how i can implement my own ships, weapons and anything else that can be moded.
-
IF you make changes like that WARN people when that version comes out for people who don't know what it really means (like me!). I like the way it is now (even wit it's problems) I've had minimal trouble implementing all the mods together cause to me it was really simple (and I am NOT a programmer, I'm just a gamer). If you sacrifice conductive modding for faster response that's all well and good but I thought the Overall goal was focused towards the common modder???
-
Originally posted by Star Dragon
IF you make changes like that WARN people when that version comes out for people who don't know what it really means (like me!). I like the way it is now (even wit it's problems) I've had minimal trouble implementing all the mods together cause to me it was really simple (and I am NOT a programmer, I'm just a gamer). If you sacrifice conductive modding for faster response that's all well and good but I thought the Overall goal was focused towards the common modder???
There is no "overall goal." There might be a Plan™ but we have no defined goals... ;)
Some of this popped up in another thread, too. At some point, we may have two executables released:- a "legacy" executable, that can run the FS2 main campaign and the current set of mods, with whatever new features we can throw in that don't break compatibility
- the "new" executable, that has lots of new features, but might not run existing capaigns/mods. New tbl formats, maybe new UI, Hud, etc.
I assume whatever incompatible changes are introduced, some kind soul will provide a converter if the changes are non-trivial :)
But we can't move too far forward without breaking something, I guess... Much the same way as FS1 mods don't work on FS2 without some tweaking.
-
...back on topic(ish)
the place that I would most like a scripting language of some type would have to be in mission making...personally I prefer functions over SEXPs...for example...
if ("GTVA Collosus".hp / "GTVA Collosus".maxhp <= 30)
{
send_message("Alpha! Take out those beam cannons!!, "GTVA Collosus", high)
}
but thats just me...
-
Originally posted by Analazon
...back on topic(ish)
the place that I would most like a scripting language of some type would have to be in mission making...personally I prefer functions over SEXPs...for example...
if ("GTVA Collosus".hp / "GTVA Collosus".maxhp <= 30)
{
send_message("Alpha! Take out those beam cannons!!, "GTVA Collosus", high)
}
but thats just me...
When you come right down to it, the SEXPs really are functions. It's just that the syntax for using them isn't quite the same as C/C++. (Being that it's in a menu driven editor.) At least in SEXPs you don't have to worry about a missing ; screwing up your whole code. :) The big difference with how they work under the hood as compared to how that code would work if it was in the source code (which isn't the point but is for comparison) is they don't directly pass the arguments. They pass a "node" argument which is used to look up the arguments. One thing that results from accessing the arguments via the function coded into the program ( CTEXT() ) is that it can understand the difference between a variable and plain text. There's also the fact that some SEXPs may actually have the results of other SEXPs as arguments which would probably be harder to do in a C/C++ script then the SEXP system. :)