[WMCoolmon]

You should probably try to base it on the stable branch if you can at this point. Recent developments in the SCP internal suggest that we may end up restarting the unstable branch due to how unstable it is, and selectively porting code over to the new one. Or something like that. But basically the plan is to have the stable be the starting point for the new new unstable.

[Samuel]

You should probably try to base it on the stable branch if you can at this point

Thanks for the advice WMCoolmon, I will do that...


I've just completed porting HUDbrackets to CHUDBrackets, and after doing so I have a few questions. I think Backslash will be in the best positing to answer, but If anyone else can give some input it will be much appreciated.

In HUDBrackets, in the function hud_target_show_dist_on_bracket(int x, int y, float distance)  there is a line:

Code: [Select]

displayed_distance = distance * Hud_unit_multiplier;

Now Hud_unit_multiplier is declared in hudparse.cpp, and not in
hudparse.h, and HUDbrackets includes neither of these files.
By what voodoo magic is this variable visible?

There is something even more curious in HUDbrackets, a function definition standing by itself:

Code: [Select]

int num_ships_attacking(int target_objnum);

but this function is again declared in AiCode.cpp, this time with an implementation.

In HUDbrackets in a function called draw_bounding_brackets
the function above is actually called in the line:

Code: [Select]

//Maybe show + for each additional fighter or bomber attacking target.
if ( (target_objnum != -1) && hud_gauge_active(HUD_ATTACKING_TARGET_COUNT) ) {
int num_attacking = num_ships_attacking(target_objnum);
}

Now, this line seems pointless because as far as I can see it is going to use the definition of num_ships_attacking that is defined in HUDbrackets, which as you can see has no implementation whatsoever.

Furthermore, it bothers me that AiCode.cpp does not have a header file? How is it ever used?

I hope someone can shed some light on these issues.

Many thanks

Samuel

P.S. The code seems to be littered with magic variables and functions like the ones I mentioned above. Is it perhaps an abuse of #includes?

[WMCoolmon]

You should probably try to base it on the stable branch if you can at this point

Thanks for the advice WMCoolmon, I will do that...


I've just completed porting HUDbrackets to CHUDBrackets, and after doing so I have a few questions. I think Backslash will be in the best positing to answer, but If anyone else can give some input it will be much appreciated.

In HUDBrackets, in the function hud_target_show_dist_on_bracket(int x, int y, float distance)  there is a line:

Code: [Select]

displayed_distance = distance * Hud_unit_multiplier;

Now Hud_unit_multiplier is declared in hudparse.cpp, and not in
hudparse.h, and HUDbrackets includes neither of these files.
By what voodoo magic is this variable visible?

Hud_unit_multiplier is declared on line 352 or so of hudparse.h, and hudparse.h is included in hud.h, which is included in hudbrackets.cpp.

hudparse.h doesn't appear to be in the project file for MSVC2003 though, I can't speak for other versions. That means if you search "Entire Solution", hudparse.h isn't going to appear in any of the search results. It really ought to be added to the project.

There is something even more curious in HUDbrackets, a function definition standing by itself:

Code: [Select]

int num_ships_attacking(int target_objnum);

but this function is again declared in AiCode.cpp, this time with an implementation.

In HUDbrackets in a function called draw_bounding_brackets
the function above is actually called in the line:

Code: [Select]

//Maybe show + for each additional fighter or bomber attacking target.
if ( (target_objnum != -1) && hud_gauge_active(HUD_ATTACKING_TARGET_COUNT) ) {
int num_attacking = num_ships_attacking(target_objnum);
}

Now, this line seems pointless because as far as I can see it is going to use the definition of num_ships_attacking that is defined in HUDbrackets, which as you can see has no implementation whatsoever.

Er, what? As you pointed out, num_ships_attacking is only declared in hudbrackets.cpp, not defined, and it is defined in aicode.cpp. Function declarations can be for a function definition in a separate file; it's a major part of the C and C++ programming language.

Furthermore, it bothers me that AiCode.cpp does not have a header file? How is it ever used?

Most of the functions are declared in ai.h, IIRC.

I hope someone can shed some light on these issues.

Many thanks

Samuel

P.S. The code seems to be littered with magic variables and functions like the ones I mentioned above. Is it perhaps an abuse of #includes?

I can't answer that without being a little rude - all of your complaints about 'magic' seem to be the result of inexperience rather than due to abuse. The header files are definitely not really organized, but you should be able to find all of the functions in less than 30 seconds or however long it takes you to do a find for the entire solution. In this case I can see why that wouldn't work; but when I first read your post, you made it sound like you had searched hudparse.h specifically and couldn't find any declarations, which makes it sound like an out-of-sync-with-SVN error.

There's rarely any coding magic of this sort that's involved. If your declarations and definitions are mixed up, it generally means that either the compiler/linker is working with a different set of source code files than you are, or you have out-of-date intermediate files that are getting linked. But that only happens if you had a function and then changed it, and generally intermediate files will only cause a definition to appear or disappear; the compiler will complain about a lack of declaration when it tries to create the intermediate files. Deleting all the intermediate files and compiling with scratch, or compiling from a fresh checkout from SVN/CVS, will get rid of linker errors due to intermediate file mixups.

[Samuel]

I can't answer that without being a little rude - all of your complaints about 'magic' seem to be the result of inexperience rather than due to abuse. (WMCoolmon)

You are totally right about my inexperience, and I will be a bit more careful of slinging terms such as voodoo and magic.

I am using the MSVC2003.

I don't see the point of declaring a function in a totally (conceptually) unrelated .cpp file such as HUDbrackets.cpp which is actually used in AiCode.cpp. In my opinion that is bad software design, even if the programming language technically allows for such a thing. Nevertheless, since it is done and I am inexperienced in C/C++ I don't want to argue the point.

Thanks for taking the time to respond. I don't find this insulting, but rather insightful since I learned something and that's the whole reason for why I want to get involved anyway.

~Samuel

[WMCoolmon]

I don't see the point of declaring a function in a totally (conceptually) unrelated .cpp file such as HUDbrackets.cpp which is actually used in AiCode.cpp. In my opinion that is bad software design, even if the programming language technically allows for such a thing. Nevertheless, since it is done and I am inexperienced in C/C++ I don't want to argue the point.

Er, that wasn't what I was trying to say.

Disorganized header files is bad software design, but things have a tendency to get that way unless someone makes a concerted effort to fix them. Things in the FSSCP are not that bad right now; there's roughly one header file per cpp file, and although some of the #includes could be more efficient and some of the functions could be declared better, they just aren't.

Abuse, at least to me, suggests something altogether different from disorganization due to inattention. Like having one header file per struct, or a header file for structs and one for functions, even if there's no compelling reason to do so and especially if there's only one member per struct or one function per header file. Or if you had a trail of six header files leading up to the one with the only function declarations. Something that's obviously going to a lot of extra effort just to shoot yourself in the foot.

[Backslash]

Indeed... never attribute to malice that which can be explained by stupidity.  Or laziness combined with snowballed complexity, in this case

I think a lot of it has to do with how old some of this code is.  (It's hard to believe it's already been 10 years since the game came out!)  Back in the '90s a lot of 'proper' C++ style hadn't taken hold.  The HUD in partcular is mostly just C, some of it "bad C" (at least, as I understand) and a lot of it was probably just recycled from Freespace 1.

I'm speaking as another programmer with not a lot of experience (yet), but I see lots of stuff in there that my computer science professors taught me not to do.  There's even GOTOs, ffs!

So yeah, it's high time for what you're doing and it'll make everything better.  I'll do my best not to make your job harder with my changes
P.S.  Just about done with the weapons gauge, and I've enhanced support for more than 4 primaries and secondaries, should we add support for that in the future elsewhere in the code!

[Titan]

first: awesome! this is way better than those other cockpitted ships!

second: it doesn't have to be symetrical in the outline shape. that way you could fit in more.

third: will this work in-game?

[Cobra]

Dude, it already does. It just doesn't have  any functionality at the moment other than having a (buggy) cockpit without needing -show_ship in the tables.

[Kopachris]

In case no one's already suggested this, maybe something similar to X-Plane, regarding how it works.  Instead of having to make a full 3d cockpit each time, you could use a default or custom 2d panel and drag the instruments around, rotate them, scale them, etc.  Even make your own bitmaps for the instruments.  It would require a huge rewrite of the .pof file format, but it could work.

[Cobra]

Not to mention a complete (re)rewrite of the interface code.

[Kopachris]

Not to mention a complete (re)rewrite of the interface code.

Yeah, that too.  Maybe we can schedule it for FS2_open version 4 or 5 (or 6 or 7)?  I'd try to help as much as I can, but I'd be new to the code, and I'm a novice programmer anyway.  It would, of course have to have an option in the launcher to use the normal hud, in case you accidentally delete all of your hud/panel files.  Or maybe just restore the default.  Eh, whatever, it's not high on my priority list.

[WMCoolmon]

In case no one's already suggested this, maybe something similar to X-Plane, regarding how it works.  Instead of having to make a full 3d cockpit each time, you could use a default or custom 2d panel and drag the instruments around, rotate them, scale them, etc.  Even make your own bitmaps for the instruments.  It would require a huge rewrite of the .pof file format, but it could work.

You don't need to rewrite the POF, you just need a file with a set of values. You could probably work it out with Lua right now, provided you used RTT with a render-to-polygon function that let you control all of those.

[Scooby_Doo]

I'm speaking as another programmer with not a lot of experience (yet), but I see lots of stuff in there that my computer science professors taught me not to do.  There's even GOTOs, ffs!

There's a few situations where GOTO isn't terrible.  In fact sometimes can actually make things cleaner (example, something fails, start over and try again).

[Topgun]

I always use goto instead of loops.

j\k

[Nuke]

P.S.  Just about done with the weapons gauge, and I've enhanced support for more than 4 primaries and secondaries, should we add support for that in the future elsewhere in the code!

you know how long ive been hearing that.

so how many other pieces of code need to be reworked th have a virtually limitless and rather rediculous supply of guns. soon as those get tossed in il start working on a battletech mod



anyway what is the purpose of a .h file, what makes it different from a .c file. ive never been able to figure that out. i tend to just stick everything in a c file myself (or rather cpp cause i suck at c). i understand how to program fairly well but i havent a clue what the compiler is doing or how it really works.

[Kopachris]

anyway what is the purpose of a .h file, what makes it different from a .c file. ive never been able to figure that out. i tend to just stick everything in a c file myself (or rather cpp cause i suck at c). i understand how to program fairly well but i havent a clue what the compiler is doing or how it really works.

I tend to put things like classes, structs, and functions I'll use a lot in the header files, then just have the c files include them.  What the compiler does when it encounters:

Code: [Select]

#include "file.h"
is it basically copies the contents of "file.h" into the C file it's compiling, at compile time.  The stuff in the header file is not actually copied into the C file.

What a compiler does, or at least, what I'd design a compiler to do, is it takes the code and turns each item, a variable, function, etc., into a token.  The tokens are then turned into assembler code or the hex equivalent.  The hex is then turned into the binary ascii stuff that you see when you open an executable in a text editor.  Then the computer reads the binary and follows its instructions.  I could go into how a processor works, but I don't think you need that much info.

[KewlToyZ]

 
//I thought this was a neat demo trick:
#include <iostream>
#define REPEAT do{
#define UNTIL( condition ) }while(!(condition));
using namespace std;
int main(int argc, char *argv[])
{
   int count_Up = 0;
   int count_Down = 12;
   REPEAT
   cout << "The value of count_Up adding to 12  =: " << count_Up << "\t Counts. " << endl;
   cout << "With count_Down subtracting from 12 =: " << count_Down << "\t Counts. " << endl;
   count_Up++;
   count_Down--;
   UNTIL(count_Up==12 || count_Down==0)
 
system("PAUSE");
return EXIT_SUCCESS;
}

[Twaysan]

Hey, I've been watching these forums for a while now, And I'd like to help. I'm not much in the way of a coder, but I do know a little of the basics. I don't really have any idea where to start though.

[Titan]

Target aquired! Lurker configuratoin!
FIRE ALL BEAMZ!

[Deepblue]

The beam is blue now? And where is the obligatory orientation?