SSU compliation in VC2010 failing

[jevans]

Hi everyone, de-lurking to ask!

I'm trying to compile the SSU modules using VC 2010 express, and the 2010 solution file included in the svn repository. Some of the projects compile fine, but others fail needing dependencies. First one is the OrbiterSoundSDK header. I've got this and tried pasting it in some likely locations, but the compiler never seems to find it. Where do you put it?

Second is the afxres file that's mentioned in the development sticky - I'm using the express editions so I don't have the MFC libaries. I did find a version of it here(http://wiki.yoyogames.com/index.php/Afxres.h) but evidently that's not the real thing, as it gives EOF errors on compile. Do I really need to download the whole platform SDK to get hold of this, or is there a simpler way?:facepalm:

Thanks for putting up with the questions - if I can get it to work I'd love to see what I can do development wise!

 

[orb]

Second is the afxres file that's mentioned in the development sticky - I'm using the express editions so I don't have the MFC libaries. I did find a version of it here(http://wiki.yoyogames.com/index.php/Afxres.h) but evidently that's not the real thing, as it gives EOF errors on compile.

Did you try to press enter to make a new line at the end of file?

Did you check this thread?

 

[jevans]

No, I wasn't editing the header file, I was trying to use a pre-built one. I didn't find that thread, thank you! I suppose I only searched for SSU specific problems. I'll try that and report back.:thumbup:

---------- Post added at 05:46 PM ---------- Previous post was at 03:15 PM ----------

Ok, that worked, thank you very much. I solved the dependency on OrbiterSound just by copying the lib and h files to the global include directory and the ssu compile directories.

Only one thing now does not compile - "SSUPad.cpp". It includes Atlantis.h, but that file is located in the parent directory, not the same directory as indicated in the code:

#ifndef __SSUPAD_H
#define __SSUPAD_H
#pragma once

#include "orbitersdk.h"
[B]#include "Atlantis.h"[/B]

static const char* DEFAULT_MESHNAME_FSS="SSU/LC39A_FSS";
...
...

If I change the path, the header file is then found, but then "Atlantis.h" itself can't find "Subsystem.h", which is located in the libUltra folder. Do I have to change some build settings somewhere to enable all these paths to be found, or are these errors in the code( which I doubt!)

Is this a bug, or is there some higher meaning I don't see? Can anyone else confirm the VC2010 solution has the build settings set up, or does anything need changed?

Sorry to keep asking the questions, but of course, I can't change any of the source files to simply add the paths, because of svn etc.

 

[DaveS]

In the SSUPad project settings add ...\LibUltra and ...\Space Shuttle Ultra to the Include paths.

 

[SiameseCat]

DaveS, I think it's better to properly set the paths in the file (#include "../Atlantis.h") instead of adding include paths. I'll check in update versions of the files (I want to change the venting code a bit, as well).

---------- Post added at 03:12 PM ---------- Previous post was at 01:42 PM ----------

Everything should compile now without any changes.

 

[jevans]

Thank you - all compiles without a hitch now!:thumbup:

 

[retro]

wish you would make a project file already to go {colmpile} for idiots like me that just dont get it:lol:

 

[jevans]

Well, the VC2010 solution files should now all compile without any modifications to the files. It all works for me - why not try that?

 

[deltawing777]

wish you would make a project file already to go {colmpile} for idiots like me that just dont get it:lol:

I second that.Using the *.sln files I have been trying off and on for about a week with vs2008 and 2010. Im not having any luck compiling. Not sure how to do the global search paths. So I have been dragging and dropping files that I think its needing based on the errors I get and still no luck. But I will say the little I have been able to see and run of SSU in orbiter2010 It is a very beautiful model.

 

[jevans]

The problems are not the code files now as supplied, it's references such as OrbiterSoundAPI and the afxres file, which you won't have unless you have MFC installed. To be honest, I just copied the OrbiterSound API to multiple locations I thought might work until the error messages had gone.

 

[SiameseCat]

The OrbiterSound .lib file needs to be in the orbitersdk/lib folder, and OrbiterSound.h should be in orbitersdk/include. Apart from that, no further changes need to be made.

I'm thinking it might be a good idea for someone on the SSU team to regularly compile the dlls and post it on sourceforge. Any comments?

 

[Urwumpe]

I'm thinking it might be a good idea for someone on the SSU team to regularly compile the dlls and post it on sourceforge. Any comments?

No problem with nightly builds, but remember that most people here think that anything we release is final and not a development snapshot.

Aside of the extra work, it would also mean a lot more trouble for us with people who can't write proper bug reports.

 

[orb]

No problem with nightly builds, but remember that most people here think that anything we release is final and not a development snapshot.

Well, you can always control what's displayed on the green "Download now" button people usually click, and it doesn't need to be the development snapshot there.

 

[zerofay32]

And you could give a disclamer that the builds are 'unsupported'. But I would think that usefull bug reports, from different folks using different hardware, could be beneficial to you. My two cents anyways

 

[SiameseCat]

No problem with nightly builds, but remember that most people here think that anything we release is final and not a development snapshot.

Aside of the extra work, it would also mean a lot more trouble for us with people who can't write proper bug reports.

I was thinking more weekly/monthly builds, released only when we know there aren't any glaring bugs. After that, we can declare the development snapshots as unsupported, and ignore any useless bug reports. As it is, the only way to use SSU with Orbiter 2010 is compile it yourself.

 

[Urwumpe]

I was thinking more weekly/monthly builds, released only when we know there aren't any glaring bugs. After that, we can declare the development snapshots as unsupported, and ignore any useless bug reports. As it is, the only way to use SSU with Orbiter 2010 is compile it yourself.

Yes, but I would like to add as counter-argument, that nobody really cares about the disclaimers. Regardless how much you write, that something isn't done or supported, people will bother you with such responses.

A 2010 build is pretty much overdue. Maybe we can include displaying a small explicit warning line in both debug string and orbiter log, what version and kind of version is used, so we can quickly tell if somebody is still using a months old snapshot version and not the latest one, despite all hints.

 

[n72.75]

Could you wright some script that would post compiled binaries each time a new change is committed?

 

[Urwumpe]

Could you write some script that would post compiled binaries each time a new change is committed?

I couldn't. It would also be a major P.I.T.A since we have multiple revisions until a complete version is done sometimes. Not every one of us does complete commits.

 

[SiameseCat]

Could you wright some script that would post compiled binaries each time a new change is committed?

Bad idea. A lot of the compiled binaries would have bugs, etc. It's much better for one of the developers to post a set of binaries we know 'works' at regular intervals.

 

[retro]

The OrbiterSound .lib file needs to be in the orbitersdk/lib folder, and OrbiterSound.h should be in orbitersdk/include. Apart from that, no further changes need to be made.

I'm thinking it might be a good idea for someone on the SSU team to regularly compile the dlls and post it on sourceforge. Any comments?

that would be so sweet!