Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Mars on March 19, 2008, 11:03:46 pm

Title: Dumb question regarding XT builds
Post by: Mars on March 19, 2008, 11:03:46 pm
Are the XT variations from a totally different branch or is it configuration settings.

If the former, how would I acquire XT source?
Title: Re: Dumb question regarding XT builds
Post by: taylor on March 19, 2008, 11:47:29 pm
The Xt builds are from a separate source tree that I maintain.  I randomly release the source, but since it's a rather volatile tree, I only do so after it stabilizes to a certain point.  In the next couple of weeks though it's going to be added as a branch in SVN, for the super brave to play around with. :)
Title: Re: Dumb question regarding XT builds
Post by: Zacam on March 20, 2008, 12:05:14 am
Heh. You mean I can compile my own XT instead of waiting for your own awesome work? That would only drive home the amount of fail I have, I think. But I will do it anyway. :->

PS: 0314 is way nice. I am almost nervous that I have not encountered a problem, so I am going to try and create some.
Title: Re: Dumb question regarding XT builds
Post by: Mars on March 20, 2008, 12:48:07 am
Yeah... for an ultra-unstable branch it sure seems... stable.

So far of course.

Of course I've only been tuning in recently so I could be wrong.
Title: Re: Dumb question regarding XT builds
Post by: taylor on March 20, 2008, 01:23:22 am
Yeah... for an ultra-unstable branch it sure seems... stable.
It is intended to be an ultra stable base on which I can develop new features.  It's also probably to most stable, tuned, and tested code base we've ever had.  About 50 or so builds have been released from it, and it's in constant testing, so technically it is pretty solid.

The unstable of it simply comes from the volatility.  Basically where I simply use it to try out new things in a more public arena than I have in the past.  The normal mapping code, for instance, has been written and rewritten about 8 times now, and it works a little bit differently every time.  I'm also constantly trying out various little tweaks for visual things (like adding alpha fades to make particle effects get transparent the closer they are to the viewer) and performance issues (such as changing to using GL_QUADS as much as possible since D3D is no longer holding us back there).  I will often release builds with known bugs in it just to get feedback on a particular issue.  And of course there is volatility in the form of external sources, where tables or data or config info will differ from build to build as I work out what actually is the best way to deal with that particular item.  And last but not least, the fact that I really don't care to hear about bugs in the Xt tree except from the testers (there are a few people that I rely on for most/all of my testing, since their input is invaluable).  That doesn't mean that I ignore bug reports on Xt builds, but the likelihood of me already being aware of the bug is really really high, I tend not to respond to them all that much (except for Mantis bugs on Xt specific issues, which I close out when I see them since they don't belong in Mantis).

But most of all, I frequently add partial code that doesn't really work all the way.  This is something that I historically do not do.  When people see what I'm working on it's generally because I'm either completely done with it, or I need their input in order to finish it in which case the build is handled privately.  The new texture replacement code is a good example of this, since it's perfect until you get to the point where you realize that it's unusable by scripting or SEXPs in it's current state of implementation.  I generally have about a dozen or so little code projects in progress in the tree at any given time, rather than working on one or two until they are done and then moving on.

But this was the point of the Xt builds in the first place, to dump as much new stuff in as I could and not be burdened by actually making it work just yet.  I still refuse to commit anything that isn't complete to the normal stable branch, and that isn't going to change, but I still wanted to get really far really fast.  Overall it simply worked out better than it was supposed to: more changes were made during the first 4 months of starting the Xt tree than all of my work in the previous year and a half, and a few hundred bugs and other assorted issues have been fixed since starting the Xt tree.  The downside is that there is enough unfinished code in there, now which is mixed with and dependent on working code, that it's not really possible to commit the bulk of what I've got.  :sigh: