[blackhole]

Well, i'm browsing through the source code (there's a lot of it o.O), and i find this:

Functions.
Structs.
More functions.
Some #defines.
More functions.
More functions.

Apparently, the FS2 programmers didn't like an object-oriented approach to the game... Are there plans to convert a large amount of this code to classes or structs with constructors and methods? Looking at all those functions make my eyes bleed

I am happy to report, however, that the majority of the FS2_open code IS object oriented, thank god.

[WMCoolmon]

Not really, no.

I started some work on making the ship_weapon struct object-oriented friendly and to add the possibility of having as many weapon supertypes as you liked. (Primary, secondary, tertiary, quaternary, etc)

However after 4-5 hours of work there were still so many compiler errors that it gave up after 100 in the AI code alone. Obviously it'd be nice to redesign things so that they work "properly", but it simply becomes a matter of having to spend a hell of a lot of time reworking code that you still can't do completely properly because everything else isn't object-oriented and isn't designed from the ground up with that in mind. For example, it makes more sense to integrate the ship_weapon struct with all of the other weapon and firing point data in the ship and model structs because turrets have the same general function. Alas, doing so would be pure hell and require serious reworking of massive amounts of code that has a high risk of breaking compatibility - assuming it would even be possible to do all that without breaking backwards compatibility for most everything.

If you really want to do things object-oriented style, you're better off finding another project to work on. Not to drive you off, but if you want to make FS2_Open object-oriented, you're basically going to be spending the time and effort it would take to make a new game, even if you don't try to add more functionality.

[blackhole]

I'd rather work on FS2_open then spend months searching for a non-retarded project to work on that has good code structure. Unfortunatly it doesn't appear that i've really been accepted into the code team nor do i have any idea how to get myself accepted into the code team. I can't really do anything with the code unless i have some kind of clear goal in mind. You guys seem to want more programmers, so here i am. Feel free to tell me to do something when you have something for me to do, until then theres not much i can do but sit and wait.

[WMCoolmon]

There is always something to do.

Right off the top of my head I can name four semiprojects that I've started, but can probably have additional work done on them.

hudparse.cpp (hud_gauges.tbl)

This code takes care of moving around the retail gauges and letting you to set certain text or image fields. I designed with the assumption that somebody else would be taking a crack at it, so it's a little more up-front (I hope) than the rest of the code. Wing Commander Saga has used this already, and probably has "more hud gauges in hud_gauges.tbl" buried in their billion requests.

Modular tables
This is a little less immediately useful but would be nice. Taylor implemented a special modular table loading function, but a lot of the parsing code still needs to be updated to take advantage of modular tables. In addition some tables could be made XMT-compliant where they aren't already.

objecttypes.tbl
I forget what file this is stored in. Basically what you do is do a search for SIF_* and move the hardcoded behavior into variables in objecttypes.tbl. You take the original values for whatever-the-behavior-was and stick it in the default objecttybes.tbl located in def_files.cpp

Lua and scripting
I have done very little serious work on making Lua work with the interface. It still works, but there's not enough interactivity to let you substitute something like the options screen with a scripted variation. You could also pick and choose any set of variables or objects to port into the Lua code. I've been very protective of it because I've tried to make it organized well and object-oriented, and safe, and fast, but if you can work on it and make it better I have no qualms about it.

wmcgui.cpp
This is somewhat reaching, but it's still around and it's still object-oriented. This is basically supposed to be a more flexible UI system than the FS2_Open default that also supports skinning. This skinning support wasn't really working at the time, because gr_bitmap wasn't working with OpenGL and D3D had issues of its own. It's only used for the lab right now, but I've been thinking of expanding it into scripting. Taylor is also working on his own UI replacement, which I don't know anything about except it's supposed to have a graphical editor.

Wing Commander Saga Requests
There's 2-3 pages worth of these. Other campaigns have their own requests, but WCS is notorious for making the most outlandish and bizarre (IMHO) and numerous requests. There's a small mountain of those sitting in one of the forums that isn't generally visible to the public. Talk to Starman01 or Tolwyn about WCS requests, I'm not sure who has the final say.

DaBrain runs Shadows of Lylat, a Starfox mod, and has some requests that sound bite-sized. chief1983 would also like auto-gun convergence for the Star Wars mod, which doesn't sound too bad, it would require knowledge of ship flags and/or table variables, as well as 3D math.

Bobboau's code
Bobboau made a big commit a few months ago that contained things like turrets that didn't shoot through their parent ship's hulls, and the ability to mount turrets on the sides of a ship or at any angle you pleased. There's also some defunct damage decal code in there. Basically this code needs to be fixed up and/or made neater.

Mantis
And, of course, there's an eternal pile of bug reports to sort through, diagnose, and fix.

The AI Code
Fabian is working on making the AI code more modular. This would be very useful to have, since it would let us make the AI smarter without breaking every mission already released. You could ask him if he has any specific jobs he wants done.



However, my recommendation would be to start small and look for some minor requests that campaigns have put out there and make some patches of those. That way you don't take on too much all at once, you can get some sample work done, and you learn about the code while doing it. Also, I suggest you apply some critical thinking to requests: is the person asking for it because it just sounds cool, or do they actually plan on making a mission that uses the feature?

Welcome to the SCP, I hope I haven't scared you off.

[karajorma]

Beyond the Red Line has a similarly long list of stuff we want too. And I'm sure IP Andrews could give you a long list of stuff he wants for the Babylon Project.

[taylor]

While all of those lists are great, and getting that stuff worked on would be a big help, those lists always leave out one of the biggest problems that we have with the engine:  collision detection.

The collision detection code is really our single greatest problem right now, because it absolutely decimates performance.  Someone needs to go through and either fix it, upgrade it, or totally rewrite it.  I don't have the math skills, or know how a good collision detection system should be setup, so I avoid working on that code except for fixed the most basic bugs.  The current code just wasn't designed with hi-poly models in mind, so the more that we add, the worse the performance gets.  Right now it's not uncommon for you to get an 80% performance drop in-mission, and that's just the result of the collision detection code.  So while this is one of the biggest projects that anyone could take on, it's also probably the most important and would provide a major boost to engine capability.

[karajorma]

Actually CD was on my list. I remember you mentioning that it was responsible for a lot of the problems in BtRL.

[RazorsKiss]

It would be awesome if a list like this was stickied, or kept up on the wiki.  I would volunteer to keep that section up, if you folks will keep me up on what's fixed, what's not, and what status the requests are at

[karajorma]

We've tried request lists before and not had much success. But not having a central go-to person was probably a factor in that.

[RazorsKiss]

Like I said - I'd be willing.

I'd also like to see about trying to organize a post on Gamedev, or somewhere similar, to get us a few more coders.

A project that is as well-established as the SCP is will do phenomenally well on Gamedev, as far as getting people who really want to do something meaningful.  Most of the time, the issue is that noone *knows* about a project like this.  I know we've talked about it before, kara - but I wantd to see what the other folks here think.

Especially for projects like collision detection and network coding.  Those are specialties you'd be MUCH more likely to find at a place like Gamedev.

[Aszarsha]

I'm not yet a developper in the project, i only work on it on my way; until i have something to commit. So my opinion don't really mean something.
But I'm here, so: it's true, a lot of good programmers would come from GameDev; and it's a problem, in my mind.

I see the FS2 project as a big cohesive community, with known coders, who know artists involved; and with lot of people that love THAT great game (as i).
Also, on GameDev, there's lot of awesome programmers, but most are more proficient with C++, which is not the case there.

Involving lot (because there will be a lot !) of programmers from GameDev (or any community like this one) would lead to a lost of the spirit of the project...

[RazorsKiss]

What do you consider "the spirit" that would be lost?

Most folks won't work on a game they don't enjoy.  Especially a free one.

One of the biggest issues I've seen is the dearth of programmers to implement the features we all want in our specific mods.  Most of the features we want are specific things that will likely only be needed by that specific mod of TC.  For those sort of features, I think the TC's are better-served by having internal programmers that concentrate on the features they, in specific, want.  Our mod, for example, has 2 coders we're gearing up specifically to look at those feature elements we're going to need.  This weekend, we're having a meeting to explain what, exactly, we're looking for - specifically, that we'd like most feature implementations to be flag-oriented.  However, what I'm talking about are the larger-scale issues like collision detection and netcode that programmers who specialize in those areas mioght be able to fix more readily.

If, instead of recruiting via a specific mod for these sort of areas, we recruit *for those areas* as the SCP en toto, and ensure they realize what the project guidelines are, we can get quality coders, and keep the "spirit" of the project, imho.

Mod-specific features can often be, and even should be, looked at by coders recruited by that mod - but with the understanding that the goal is to make it compatible with the overall SCP project, as well as incorporate the features we need.  For the large-scale projects, I think a bit of SCP-wide recruiting could be extremely valuable.

[karajorma]

I say bring em over.

*Karajorma prepares brainwashing ray*


Seriously though as long as we explain at the start that we have two main goals

1) Preserving compatibility with FS2 Retail
2) Making the most kick arse multi-platform space combat engine ever

in that order we should be fine. We only really have problems when someone thinks that the first goal is less important than the second.

@Aszarsha : I do see your point but I think that the smart thing to do is get the coders over here. Those who want to work with the project without spoiling the community feeling will carry on and the others will get dispirited and leave.

[RazorsKiss]

I think I'm going to write up a post in the format GameDev likes.

I'll post it here, first, and let you coder folks sign off on it, add/subtract what you like - and if one of you would rather post it, that's fine with me. 

I just want coders, y'know?

To fix the issues that will affect the "polish" of my mod, certainly, but also that of every other mod that wants that retail-quality "polish"  when they get to release time.

It's important stuff.

[blackhole]

I could go through and search for possible math optimizations, but my math skills are limited to a sophomore's knowledge of Intermediate Algebra, so i would recommend keeping me away from collision detection

I may give the code a bit of a looksee today, after my piano lesson. I have a gut feeling that i might actually be able to do something with collision detection that has nothing to do with math. I'll update you if i get anywhere.

It would be awesome if a list like this was stickied, or kept up on the wiki.  I would volunteer to keep that section up, if you folks will keep me up on what's fixed, what's not, and what status the requests are at

Having a list like that would make organization far easier. Espiecally for me

In the mean time, is there a list of really tiny bugs i could look through?

[Goober5000]

objecttypes.tbl
I forget what file this is stored in. Basically what you do is do a search for SIF_* and move the hardcoded behavior into variables in objecttypes.tbl. You take the original values for whatever-the-behavior-was and stick it in the default objecttybes.tbl located in def_files.cpp

I need to add a caution to this.  There are two different property lists in FS2: ship types and ship classes.  The flags between the two of them are almost completely disjoint, despite being very similar conceptually.  Whoever takes charge of porting the SIF_* flags over is going to need to make sure nothing breaks when the two lists are merged.

[blackhole]

Well i've been searching through the collision detection code but have been unsuccessful in my attempts to understand it. I assume that somewhere in that mess its iterating through the vertices located on a ship? This is what would start hitting preformance with big models. In this case there are most likely optimizations that could be made to help out, but the main problem is that no physics engine can handle large amounts of polys, its limited by computer power. What lots of engines do is create a second model for collision detection, similar to Freelancer's infamous SUR files. I think that a HUGE preformance gain could be made by simply passing a different model to the collision detection routines. It could be an untextured POV file, or whatever you want, just make sure its not rendered. Then, take the loaded model file (which would basically be a lower-poly version of the high poly models, using one of the high poly model's LODs would be an excellent idea) and pass that to the collision detection routine or otherwise force it to use that model instead of the high poly one. You'll get less accurate collisions, but its doubtful that they will be noticed, espiecally if the collision model is properly done.

Thats my take on it. I'm going to look for something else to work on... *goes bughunting*

[Bob-san]

Here's something that can be a bit easier or a bit harder for you...

Any chance you could add in several flags to FRED and whatnot?

1) FirePrimary (causes target ship to fire primary weapon at normal rate for x number of miliseconds)
2) FireSecondary (causes target to shoot secondary weapon for x number of times and at x target)
3) FireCountermeasure (causes target to shoot x number of dummy countermeasures)
4) FireTurret (causes turret to fire at a specific location)
5) Move-Rotation (causes ship to rotate at a specific angle-- -179 to 180)
6) Move-Flightplan (causes ship to follow a specific flightplan)
7) IgnoreAllButOrders (causes ship to always ignore everything except the current active order strain)
8) UseAfterburner (causes ship to use afterburners for x number of seconds)
9) ForwardShields (causes shields to be augmented forward)
10) RearShields (backward)
11) LeftShields (to the left)
12) RightShields (to the right)
13) TogglePrimary1 (set to fire first primary bank)
14) TogglePrimary2 (set to fire second primary bank)
15) ToggleSecondary1 (set to fire first secondary bank)
16) ToggleSecondary2 (set to fire second secondary bank)
17) ToggleSecondary3 (set to fire third secondary bank)
18) MissionMod (directs the mission to use a specific mod file from the \Freespace2\ directory)
19) MissionModMod (directs the mission to use a specific mod file from the \Freespace2\*modname*\ directory)
20) SetBothPrimary (set to fire first and second primary banks)
21) SetDoubleSecondary (set to fire current secondary bank on double mode)
22) MissleHitsCounter (set to cause dummy countermeasure to take out missiles)

Yes, by several I mean more than 20. I need all of those for some cutscene work. Either that or direct me toward a rendering engine.

Quick question while we are on the programming talk... is it possible to have FS2 do a complete simulation if it is saved correctly? I don't mean using FRED, I mean like using a seperate OGL/DX renderer inside the game.

[Turey]

You'll need to be more specific on 6 and 22, but I think all of them are possible except for 18 and 19. While they could be coded, it'd be a mess and extremely prone to failure.

[WMCoolmon]

Yes, by several I mean more than 20. I need all of those for some cutscene work. Either that or direct me toward a rendering engine.

Have fun.