[Bobboau]

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.

[Nuke]

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.

[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???

[penguin]

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.

[Anaz]

...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...

[EdrickV]

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.