[WMCoolmon]

Recently it has come under debate whether or not the FSSCP should maintain backwards compatibiliy - that is, runnable without any extra media besides vanilla Freespace 2 data.

Specifically, the issues currently under discussion are

• Whether or not the old jump node rendering should be implemented
• Whether or not a new POF format, which is fully compatible with index buffers, replace the old one. Obviously a converter would be made, since this would invalidate older ships

So, how important is backwards compatibility to you?

[Nuke]

seriously i can only play a game so many times through before i get bored. and i have out played freespace. 99% of all my freespaceing is dedicated to testing my mods.

[Kamikaze]

I don't see much reason to play the game without the new media. If you're dedicated enough to go get and use FSSCP, getting a bit of media shouldn't be much of an issue.

Also, if people are concerned with backwards-compatibility why not make it a compile-time option? Does it have to be unalterably broken if changes are made?

[Bobboau]

"Does it have to be unalterably broken if changes are made?"
yes

remember folks a lot of stuff is said to be imposable becase of backwards compatibility issues

I think a good rule is if backward compatability is broken then he who broke it is responsable for makeing replacement data.

[WMCoolmon]

In neither of these cases does it *HAVE* to be broken. FS2 already converts the old POF data to new model data in Bob's builds, I believe. It is very slow compared to loading the data from a file, according to Bobb.

The new jump node rendering code doesn't have to break it either, it's just very difficult, according to Bobb.

[Trivial Psychic]

Originally posted by WMCoolmon
FS2 already converts the old POF data to new model data in Bob's builds, I believe. It is very slow compared to loading the data from a file, according to Bobb.

Again, "me not coder"... but IIRC, Bob's new system takes more time because it has to convert the models to the new pof system, internally.  The way to speed this up would be to convert these models and save them under the new format, so that FS2 doesn't need to convert them when each is loaded.  This does break backwards compatability, but with our pof editor programs such as Modview, PCS, and Aurora.  It would also mean that if anyone made new models based on this system, they'd be imcompatable with any FSO build prior to the addition of the new system.

Later!

[Fineus]

I pick "don't care" but with one condition... that is that it is possible to convert any old format or file to the new type somehow - preferably using a converter. The reason for that being that there's a lot of cool older stuff out there whos original creators may have since lost interest but which people still want to play.

However.

By forcing yourselves to maintain backward compatability I think you may risk limiting the progress of the SCP and in turn losing out on the opertunity to do some cool stuff for the sake of ensuring that things are backwards compatable.

At the very end of the day, if you're unable to create a converter for old file types and I still want to play them then I'll turn off the SCP and play them using vanilla. It might not look as pretty but that way I get the new features of the SCP as it advances, as well as the content of the old stuff that may not have been converted.

[Nico]

I don't care for backward compatibility. If I want to play the old FS2, I play the retail version.

[Singh]

The only back-wards compatibility I think there should be is that it should be as Bug-Free as Retail FS2

[Bobboau]

new model format would mean that we would naturaly need to make a converter.
and there is no way we can keep things backward compatable for ever, it takes 30 seconds for the loading code to convert internaly the HTL finres alone.

[kasperl]

What about calling the new format .pf2 or something, and if a pof is found, it'll be converted, while if a pf2 is found, it'll get loaded directly.

[RandomTiger]

We should keep backwards compatibility but favour new features. The loading delay that Bob mentions is an acceptable limitation of using the old model system if a new better system is made avaliable.

[StratComm]

I agree, let the backwards compatability be the long load-time to convert the models in this case.  As for the extension "Paralax object format" seems a little out of place for something created for the SCP, so maybe .fso (FreeSpace Object)?  If it's not taken of course.

[Nuke]

if you guys do come up with a new format and update the model converters, would it be too much to ask to implement full autogen capability? please? thank you

[Kazan]

we're not changing the extension - we can internally make the change to the format easily though


backwards compat = unneccesary, we can convert the data

[SadisticSid]

I think most of us are beyond the point where backwards compatibility is important now - an extra gigabyte isn't too great a cost to those who want vanilla FS2 anyway

[WMCoolmon]

Originally posted by Kazan
we're not changing the extension - we can internally make the change to the format easily though


backwards compat = unneccesary, we can convert the data

If it's so damn easy to write a converter, why is it so impossible to put one in FS2_Open?

[Kazan]

It would probably take between 1 and 2 seconds per model, times about 123 models in the basic pack that's  between 2 minutes and 3 seconds and 4 minutes, 6 seconds

[WMCoolmon]

So backwards compatibility would still be implemented, and it would mean you wouldn't have to convert every model or go on a search for new models every time you loaded a mod that used an older model.

Not to mention you could save the updated models in the data/models folder so the next time it would load normally.

[ChronoReverse]

Stabilize 3.6

Designate that as the last SCP build that's Backward Compatible.

Break everything you want in post-3.6