Include files

[krogothe]

I started rewriting KAI for real, to make it neat and easy to debug.
One of my changes was grouping definitions, structs and include files, guessing that it wouldnt matter much, i copied all the includes off OTAI, changed it appropriately (commented out the ones that shouldnt be needed) and went to see if it would run. Heres where i got to:

http://www.fileuniverse.com/?p=showitem&ID=3013

Unfortunately, both the sunparser and the logging bits cause errors if i uncomment the lines in globalAI.cpp.
I figured someone here must know better if this practice is wrong (seems to take longer to compile) or if its something else altogether.
Theres little code so it shouldnt take long to spot a problem, its hard to learn good programming practices!

thanks

[AF]

Look at the include.h file, all th #include statements are upside down, you have the base fundamental stuff at the bottoma dn the highest elvel code at the top when ti should eb the other way round.

There's no need to ahve float3.h included in interface.cpp

Also make sure you've got your VS project setup to include the correct directories, OTAI doesnt have such a VS project as an example though sicne veylon uses codeblocks....

That and having so many hardrive partitions doesnt look too nice

[krogothe]

I reversed the include order (it makes sense), but still the same result. The partitions shouldnt be a problem (works with oldKAI) and if the include directories were wrong i wouldnt be able to compile i think...

It must be something:
-that the compiler doesnt catch
-that causes spring to freeze but with 0% cpu usage, it basically stops the program
-that has to do with using the GetDef() feature of the sunparser and creating an instance of a ofstream()

[Tobi]

I didn't look at your source, but I recommend using relative paths in #includes (it seems you're even using drive letters in them??), and developing as if the AI is in the place where the AI's are in the SVN. Then don't copy over header files from spring (OTAI used to do that in a version some time ago) but #include them with their relative path. That way it's way less maintenance burden when some of those headers gets a bugfix or anything.

[krogothe]

I didnt copy over the files (especially since they are always getting updated, it would waste time), and i didnt put the file letters in the includes, only the relative paths like this:

Code: Select all

#include "./Sim/Weapons/WeaponDefHandler.h" 
#include <iomanip>
#include "ExternalAI/IGlobalAICallback.h"
...etc

ive tried doing away with the include file and putting the separate includes in the appropriate header files to no avail. I honestly have no clue whats wrong. Would the project properties have something to do with it?

[Tobi]

what kind of errors?

[krogothe]

It compiles with 0 errors. Debug mode doesnt work on my machine, it always crashes regardless. When i run spring it immediately freezes, separates into two processes (start bar comes up) with 0% cpu activity. Probably a crash but the error box didnt display.

[jcnossen]

That is a runtime problem, it has nothing to do with the order of including files.
Not that I know a fix, but it has nothing to do with this for sure.

[krogothe]

would the working folder make any difference?
this is very odd, i cant think of what else is needed for me to be able to do

Code: Select all

std::ofstream *LOGGER = new std::ofstream("log.log");

[krogothe]

Will i be damned and burnt alive for it! When rewriting i considered using vs2003 but was stubborn and thought, hell it wont make a difference if i go vs2005. Turns out copying the EXACT files and project settings to a new vs2003 project makes it work. both of them. Perfectly. Id love to know why but i guess ill never find out!
What a joke! MS should be shot for backwards compatibility, thanks either way guys

[Bobris]

Again STL from VC 2003 and STL from VC 2005 are not compatible, so using STL in any dll interface is just plain wrong decision as you have to use same STL, or make hacks already written by me here on this forum.

[krogothe]

Again STL from VC 2003 and STL from VC 2005 are not compatible, so using STL in any dll interface is just plain wrong decision as you have to use same STL, or make hacks already written by me here on this forum.

haha thanks, that explains a LOT, why i always got debugger errors in the STL, and why things like changing the order of statements inside ifs made a difference between crashes and smooth gameplay!
Plus i should be able to try again at my unit selector and see if it wont crash this time!

Thanks bobris, it makes sense afterall (ill carry on with vs2003, the intellisense works now too, which is very handy)