[xenthorious]

I don't know if this is a dupe topic, but this has been bugging me for the past two weeks and I keep forgetting to put it up.  Now I'm at work and I really needed to put it up before I forget about it again.

Did the SCP team consider revamping all scripts in XML?  Why or why not?

The reason why I brought this up is because I have noticed that after each time FS2 is loaded into memory, shortly after it pulls information from each and every script file, the curser information seems to be unequal to what was previously placed within the notepad document.  I also noticed that several errors which could develope in a game or project are often found in a humen error found within the script files.

To my best knowledge, I believe XML could resolve many of these problems and increase performance to the software as well.  If anyone here knows anything about XML, they should know that many of the features within XML could help reduce some of code which protects the FS2 software from fatal errors caused by incompatabile entries within the script files.

Do not get me wrong, I am not posting this as a dreamer with no idea of the work load required.  What I'm trying to say is, I do understand that there would be a great deal of work needed to recode the FS2 code to pull from XML rather then notepad documents, but I also know that many benifits can come from it.

[Inquisitor]

that there would be a great deal of work needed to recode the FS2 code to pull from XML

Yup

[xenthorious]

hehehe

Let me assume that at least the idea is appealing to you.  How could we help reduce the work load?  Here's a few things that could be done.  Someone could create a small program that allows anyone to convert text scripts into XML and visa versa.  After this is done, the code could be used to create a new build of FRED.  Once FRED makes mission in XML, the code from FRED could help reduce the needed code in FS2.  And in the midst of the transition, though FRED would make XML files (which would not work in FS2 for that time), the custom tool created first would resolve that issue, letting the FS2_SCP team work at there leasure.  What do you think?  Is the idea even worth thinking about?

[WMCoolmon]

XML would take longer to write out than the table format, and, in general, it's good for what it does.

Not to mention every time somebody posted TBL code on HLP, the boards would mutilate it (thinking it was html)

[phreak]

going in the other direction, i wonder how fast fs2 would load if we just saved the contents of Ship_info (for example) to a binary file, eg ships.tbb.  it could probably cut down file size since there's no whitespace, comments or field tags to get in the way.

[xenthorious]

That's a really good idea, but every tool would need to apply the same concept or no one would be able to edit them.  On another view of this, the scripts are initilized on entry of game and/or mission.  Thus, if I am not mistaken, increased speed would only apply to the transition from one area of the game to another.  

Currently, the speed of this does not really bother me, but the frequency of crashes and slow developement does.  XML would fix this.  Binary could too, but unlike XML, creating a format to use and programs to decript the binary code generated by FS2 would take much longer.  XML could be intergraded into FS2 and FRED smoothly and slowly without hindering developement (provided that an XML Notpad translation program is created first).

Never-the-less, if the FS2 team and FRED team were willing to take the challange and time to reformat in binary code, I would fully support it.  As long as things are done right, it could produce the same results XML produces and increase speed between transitions within the game.  But again, it's a great deal more work and harder to apply.

[WMCoolmon]

I've thought about this. Many, many, times, in fact. I actually designed a binary ships.tbl format for .pof files, to be embedded as a chunk, but never finished it. And my test_shiplib exe was a sort of toss-up as to whether it would be a binary converter or not in the end.

The fact is though that it's not so much the parsing that gets things as it seems to be the actual media.

[xenthorious]

You have a point WM.  Now that I think about it more in depth, it is the media that tends to be more of the pain.