[Aszarsha]

Before anything else : sorry for my poor English...

So... I would like to take part of this project. I'm a C.S. student, not so bad with C++ programming, and I love AI.
I've looked through CVS repos. for 30 minutes.

What's the policy over the source code language ?
The code is A LOT more C than C++ ; in fact, haven't seen any C++ specific thing. Do you want to maintain the C-ish inclination of the code or are you ok for more (really more) C++-ish constructions, since the code seems to be compiled through a C++ compiler. Are you ok to use Boost libraries witch are improvements/implementation/adds of/over the standard C++ library.

Do you want, at long term, FS2_open be more a SpaceSim engine or just FS2 engine improvements ?
Haven't seen the original source from Volition, but it seems that the actual code is more improvements over it than major changes. Is it actually one of the main goal or are you open for major changes (keeping backward compatibility, of course).
I've never modded, nor inspected modifications but it seems that the actual engine support little, if any scripting. Do you want it to change ?

It's not easy to understand a such project code from scratch ; can some main developers here tell me where i should begin my read ? Is there any UML (or other) diagram somewhere that could help ?


Thank you to have read me, hope my English allow me to be understood.

[HermeZ]

I can't help you...or.... yes I CAN help you
FS2Source
And I understood you quite well

(If hosting source code is illegal - just give me a word and I will delete it )

[phreak]

A good bit of the code written for freespace2 was written back in 1993/94 as part of the descent codebase, which is why 99% of the code is written in C.  I think a few additions have been added by us that use some simple c++, such as the inheritance in the 'jump_node' class that WMCoolmon rewrote a year ago.  We're probably not planning on modifying the underlying code to use the regular oo features (inheritance/polymorphism) because that would take too much time for little return.  Yes it may be easier to follow and for new coders to pick up, but we need to weigh the performance benefits (if any) as well as if the actual time spent coding could be put to better use (optimizing existing code, fixing bugs, adding new stuff).

We don't have any UML diagrams to show you, the only thing that could be of any use is the Doxygen output of the original source released by volition, located here: http://fs2source.warpcore.org/dox/.  We haven't run Doxygen for fs2_open ever, and I really dont see much of a point since most of us use Visual C++ and intellisense does of that for us.

[karajorma]

As far as major new features are concerned the SCP has mostly been busy with supporting the total conversions recently so we don't mind big changes as long as the goal is to make the best Space Sim engine ever.

[WMCoolmon]

* WMCoolmon gets out his scissors

Before anything else : sorry for my poor English...

So... I would like to take part of this project. I'm a C.S. student, not so bad with C++ programming, and I love AI.
I've looked through CVS repos. for 30 minutes.

AI is one of those fields which it would be great to have some improvement in, but there seems to be a black hole buried somewhere in there. Every programmer who's offered to work on the AI code has disappeared. Maybe one of them is actually working behind-the-scenes and this thread will bring him out of the woodwork. But regardless, the AI is a tangled mass of code that is generally treated as a black box, partly because it's virtually impossible to improve AI behavior without breaking a lot of the existing msssions.

What's the policy over the source code language ?

Don't break backwards compatibility.

The code is A LOT more C than C++ ; in fact, haven't seen any C++ specific thing. Do you want to maintain the C-ish inclination of the code or are you ok for more (really more) C++-ish constructions, since the code seems to be compiled through a C++ compiler. Are you ok to use Boost libraries witch are improvements/implementation/adds of/over the standard C++ library.

Adding boost seems a bit silly, given that it would require someone to go to a considerable amount of effort to make it useful. Then it would also require us to include it in CVS, and include the license in all additional documentation. It doesn't seem very useful to try and modify things, at this point, to use Boost.

Do you want, at long term, FS2_open be more a SpaceSim engine or just FS2 engine improvements ?
Haven't seen the original source from Volition, but it seems that the actual code is more improvements over it than major changes. Is it actually one of the main goal or are you open for major changes (keeping backward compatibility, of course).
I've never modded, nor inspected modifications but it seems that the actual engine support little, if any scripting. Do you want it to change ?

http://www.hard-light.net/forums/index.php/board,145.0.html

and/or see code/parse/lua.cpp

It's not easy to understand a such project code from scratch ; can some main developers here tell me where i should begin my read ? Is there any UML (or other) diagram somewhere that could help ?


Thank you to have read me, hope my English allow me to be understood.

What are you trying to do?

[Grizzly]

Is it actually one of the main goal or are you open for major changes (keeping backward compatibility, of course).

I think that retaining the backward compatability is one of the major reasons there where no major changes.

[karajorma]

Tough ****. We're not breaking backwards compatibility.

Given the length of time it takes to makes a campaign we'd have 2 years of a great engine with absolutely no playable missions for it.


Besides I don't believe that backwards compatibility is holding us back half as much as some people like to complain it does.

[Turey]

Besides I don't believe that backwards compatibility is holding us back half as much as some people like to complain it does.

I think that a bigger problem is that some sections of the code are just really awkward code-wise...

[karajorma]

Yep. That's the big issue really.

People who want to break backwards compatibility generally haven't thought things through. Say we do break it? What happens a couple of months later when we find something else we could make cooler by breaking compatibility? What reason do you give to say why the previous change was allowed and this one shouldn't be? And if you allow that change what happens the next time?

Breaking backwards compatibility results in an engine with no games and which doesn't remain stable long enough for there to actually be any games for it.

[WMCoolmon]

Backwards compatibility is exactly why so many of the AI improvements that have been added have then been removed. The code that caused turrets to not fire through their parent ship, as well as the code for huge beams to not target bombs, broke compatibility in at least one mission (In the latter case, it pretty much was just one mission).

The last big coding discussion on AI was about how one should go about trying to branch things to maintain backwards compatibility. In the end, nobody seemed to come up with a solution without at least one major flaw.

It is virtually impossible to change any aspect of the AI code without breaking backwards compatibility in some fashion. The alternative - keeping track of every change and enclosing it in conditionals - will only make the AI code more convoluted. Altering the AI code in any respect, to make it more organized, is, of course, more or less impossible because it would break backwards compatibility. Complete replacement with another conditional statement to optionally switch to the new code is the only way of really cleaning things up (on some level) without risk.

When one does make a change to the AI code, even if they follow all the rules, once they choose to upgrade it, they will have to provide toggles for every additional change that they make, if it was actually used for something.


That backwards compatibility doesn't even play enough part in all of that to be worth mentioning is not a premise that I accept. You can tout all the good reasons if you like, and pretend like it hasn't, nor ever will be, a reason for excluding code, and I suppose I will just have to agree to disagree.

But I don't think that will help when somebody who wants to work on the AI comes along, and realizes that his time is probably better spent on a project that really wants AI improvements. Where he can actually spend time on building a better AI, coming up with something new and interesting. It's a far cry from the SCP, where AI improvements are only OK if they either fit into the extremely complex, rigid, and hacked-together structure of the AI code, so they don't break backwards compatibility, or if he's willing to spend the time to completely redo those segments before he (or she) can do anything else.

[Aszarsha]

AI is one of those fields which it would be great to have some improvement in, but there seems to be a black hole buried somewhere in there.

I love AI, but i don't think I'm actually as good as it would need to do really better AI than actual one. Maybe in one year after my AI class and a lot of books in my head !
I also love game programming in general, and that's why i want to take part of the project. I also love Science Fiction, and particularly Space Opera !

I think that a bigger problem is that some sections of the code are just really awkward code-wise...

Yes, some parts of the code are.... Not reader friendly. But of course backward compatibility must be saved. Maybe, the code should be reworked...
At least some parts of it. It need to be modularized ; maybe, a better interface, a lot less monolithic and really more scripting-efficient, should be implemented and the actual code encapsulated inside and no more changes (just minor) should be done on it.
This would allow new module done, not necessarily from scratch, for example physic module with Newtonian physics, or AI module that could be... just readable, it would be a great change !

If this if done, I think (and I of course could be wrong) that Boost (at least the TR1 implementation part) could be a great help. Allowing staticaly-sized array, witch is a lot less error prone than C array, while having 100% of it's speed, for example.
Also, adding Boost to the project is not really a problem since it don't need any compilation ! It's 97% (yes, some part of it that are useless here) done with template.
I'm not totally objective since I really love C++, and I don't really understand why people continue using C.


There is also another thing in the actual game (FS2_open 3.6.9 build ; haven't looked through the code) that astonish me : every interaction with the player is ASCII and QWERTY based ! You have understood, I'm not English, and my keyboard isn't QWERTY. It's in my mind one of the most important thing that have to be done to make it more an engine than FS2 improvements. The player have to be able to have accentuated letters in his name, and see an A and not a Q (for an AZERTY keyboard) in the control selection while actually want the A key on his keyboard.
I've never done anything related to internationalization through, so I don't know how it could be done.


For scripting, sorry WMCoolmon, haven't seen your work before. It seem really powerfull and very well built !

What are you trying to do?

I'm actually trying to understand the whole engine. And it's a hard work... I don't really know where to beggin, so I just jump from a file to another, without really understanding the ins and outs ; without really understanding anything in fact that's related to data flow. C programs that long are a pain to read.
I've found some indentation inconsistencies through the code (HEAD branch) and it don't simplify the job. I also have some compilations error that I don't know how to solve : some VFX_* constants in swff_lib.cpp that are don't known, and an overload to CreateLuaState in lua.cpp that isn't known also.

I'll continue to read, but if there is somewhere I should really look, please tell me !

EDIT : my message was written and post before i saw WMCoolmon's one.
If I, a day (don't know how to say that in English, sorry), understand the engine, I'm ok to try the BIG work of encapsulating actual code, maybe rewrite it in C++ fashion some parts, before beginning another. It will improve my programmation skills and that would not be lost time !

[Goober5000]

There's nothing preventing us from making a pluggable AI, the way Phreak set up radar and radarorb.  We'd just have to stub out ai_frame for a new AI module, and go from there.

[taylor]

I've found some indentation inconsistencies through the code (HEAD branch) and it don't simplify the job.

I agree, and I hate it when the others do that.  Using different formatting styles for brances, comments, and spacing, does nothing but complicate the code.  It is nothing less than a bug.  Almost the entire code base is K&R style, but Goober, karjorma and Kazan use C++ style brace formatting.  WMCoolmon uses a freakish mix, often using several different brace styles in the same function.  Bobboau doesn't actually have a style, at least nothing consistent, unless you consider "Bobboau" a coding style.   And all to often, white space (at least horizontal if not vertical) is of no concern what so ever.

I'm not totally free in those issues either.  I use a mixed K&R style.  In part to stick with the formatting of the existing code base (which every good coder should do automatically, and without question), but "mixed" with the idea of formatting that greatly helps with bug finding/fixing.  Since I'm the one that does most of the work on bug fixes, it only makes sense to give myself an easier time of it.  I tend to use single-line if statements without braces, and I use a different formatting style on switch statements.  The switch statement formatting is my biggest diviation from the existing code formatting, but done for ease of readability, ease of future maintenance, and ease of debugging.  But I still feel dirty from using a different formatting style as the existing code every single time that I do that.

Thankfully, Turey seems to be more of the K&R type, which means that he can bring some more stability to the code formatting, and my spiral into complete insanity can be delayed for a little while longer.

There is also another thing in the actual game (FS2_open 3.6.9 build ; haven't looked through the code) that astonish me : every interaction with the player is ASCII and QWERTY based ! You have understood, I'm not English, and my keyboard isn't QWERTY. It's in my mind one of the most important thing that have to be done to make it more an engine than FS2 improvements. The player have to be able to have accentuated letters in his name, and see an A and not a Q (for an AZERTY keyboard) in the control selection while actually want the A key on his keyboard.
I've never done anything related to internationalization through, so I don't know how it could be done.

This is already planned to be fixed for 3.7.  There is a lot that has to go into it though, not just in the input code, but also the pilot file code, graphics code, adding TTF support, better lcl support, better text file format handling, many data type changes, etc.  It is not a small task.

If I, a day (don't know how to say that in English, sorry), understand the engine, I'm ok to try the BIG work of encapsulating actual code, maybe rewrite it in C++ fashion some parts, before beginning another. It will improve my programmation skills and that would not be lost time !

I actually prefer C, and only use very small parts of C++.  I have just never understood the appeal of C++ really.  I agree that it has a lot of positives to it, but not everyone agrees with how "positive" those are, including me.  Most of the C++ in the code is just tacked on, though with some sections obviously being written for C++ in the first place (like the UI code, audio steaming code, some of the joystick code, etc.).  But most of the C++ is actually not from at all, such as the audio streaming code being a copy&paste from original work by a Microsoft developer, and the Windows FF code being mostly from a Microsoft SDK.

Mixing C and C++ to the extent that some of it is done does little more than hurt readability and future maintenance.  But it's not exactly easy to complain about that, since that generally results in not getting any code at all.   

A lot of the code is in C, and I personally think that it needs to stay that way.  Some of us have been using the code for 5 years now, so if anyone were to go in and start redoing things to be more C++-ish, that would only hurt those of us that are already very familiar with the code.  I've spent years getting to know the code layout very well, and I have not intention of doing that again. 

[phreak]

probably the only good c++ like extension i'd like to see in the source code is overloaded operators for the vec3d class so we could write something like v3 = v2 + v1; instead of vm_vec_add(&v3, &v2, &v1);.  It should help the readability a bit, but thats about the only positive thing i see coming out of it.

the reason i don't see this happening is that:
a) there are of vm_vec_* calls
b) i don't know if this will hurt performance.

[taylor]

probably the only good c++ like extension i'd like to see in the source code is overloaded operators for the vec3d class so we could write something like v3 = v2 + v1; instead of vm_vec_add(&v3, &v2, &v1);.  It should help the readability a bit, but thats about the only positive thing i see coming out of it.

Agreed.  That is one thing this tends to piss me off at random times in the source.  Having working things like "dp = vec3d.dotproduct(vec3d)", "vector = vec3d", "vec3d = vector", etc. would be a lot nicer than what we have to deal with now.  I don't know about speed, but I'd bet that it would likely be both faster and slower, depending on the function in question, and would end up being about the same overall.

But, you are right, there are a LOT of vm_vec_* calls.  But if someone had the time and patience to do it then it might be worth while for everyone.

[Aszarsha]

In fact, function overloading WILL improve performance, if well done. Is it like any function call at worst, so there can't be any perf. lost, however it can be inlined (operator are this functions that greatly benefit from it) witch is also doable form actual functions, but would need some work as operators. The only perf. lost would come from binary size increase, witch would finish to cache miss... But on today's processors, it's worth doing.


For indentation inconsistencies, as I will read almost the whole code, I can try to correct this, but i'll need a guidline. And a CVS write access, too.
Bah, it's not for today, nor this week (, nor mouth ?), so there is times...
I've found that the MS2005 project is also machine dependant. There's plenty of c:\project\... inside ! Corrected this, too.


For vec3d, why not implementing operators, beginning using it, and change old functions call while finding one ?

[karajorma]

Backwards compatibility is exactly why so many of the AI improvements that have been added have then been removed. The code that caused turrets to not fire through their parent ship, as well as the code for huge beams to not target bombs, broke compatibility in at least one mission (In the latter case, it pretty much was just one mission).

First up I was talking about the entire codebase not just AI. I agree that in the AI code it can be a problem but even there it's not an insurmountable one.

That backwards compatibility doesn't even play enough part in all of that to be worth mentioning is not a premise that I accept. You can tout all the good reasons if you like, and pretend like it hasn't, nor ever will be, a reason for excluding code, and I suppose I will just have to agree to disagree.

Who said it wasn't an issue? Turey got the point. The issue is not being compatible with the way the engine worked but the fact that the horrific AI code makes it hard to add changes and stay compatible. As you say that means that the engine needs a lot of work before we can make AI changes easily. Goober's suggestion of making the AI pluggable is the way to go.

However every time you raise the issue of backwards compatibility you'll get comments from some halfwit (and I'm not referring to anyone in this thread) who believes that we should throw out compatibility and just improve the AI. That's what I was on about when I said it wasn't as big a problem as some people believe. Not what you seem to think I was talking about.

[ni1s]

The code isn't nessecarily awkward, it's just that it appears to hardcoded and fit around the original Freespace 2 Campaign. If you want to grasp how one little bit works, you pretty much need to grasp how the majority of the codebase works(not that this in in anyway uncommon). Add inconsistencies throughout the code and the fact that FSO is seemingly void of direction and you scare away a lot of developers. Something I would really see is some "Guide to the Source", you've probably seen a lot of Open Source project have these, they are filled with DO's and DON'T's of indentation, (curly) braces, naming convention, whatever. And most importantly, the general idea.

This project is great, every time I got the spare time(and energy) I sit down with the code, hack'n'wack at it, trying to understand it a little better. Never forgetting that this is the code that allowed us to play the best space sim ever conceived by man. And good advancements are being made, advancements that have enabled modders to do amazing stuff.
But the lack of direction, the (from an observers perspective) stale developer community and the uncomfortable surrounding "tone" of secrecy( e.g the lack of spirit of the letter of the GPL ) is anything but welcoming.

I'm not having a go here, I'm just saying. 

[Turey]

( e.g the lack of spirit of the letter of the GPL )

What do you mean by this? FSO isn't under the GPL. In fact, FSO isn't really Open at all, according to the definition at opensource.org:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

We can't sell any program with this code, and therefore FSO isn't under an open license. This is why we can't use code under the GPL, because GPL is an (extreme example of an) open source license, which "infects" (For lack of a better word) the FSO code and would cause the SCP to be in violation of one of the two agreements. The conflicting clauses are:

6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.

conflicts with:

"Copyright (C) Volition, Inc. 1999.  All rights reserved.

All source code herein is the property of Volition, Inc. You may not
sell or otherwise commercially exploit the source or things you
created based on the source."


Modifications by members of the FreeSpace Source Code Project are
released under whatever terms the individual authors choose, but the
above notice continues to apply to all fs2_open code.

Any code under LGPL or some of the other, less forceful licenses (Including my personal favorite, EPL1.0)  can be used with FSO with little or no problem.

As always, if I got anything wrong, don't hesitate to correct me.

P.S. Wow, I got kinda off-topic with this post. Sorry about the off-topic-ness and the length.

[ni1s]

Oh! I'm by no means talking about actual licensing here. I'm referring to the ambition to invite, learn, open and so forth in regards to development.

And my apologies for the hijacking of this thread.