SSU Development Thread (3.0 to 4.0)

[Urwumpe]

Still getting the can't find PIDControl.h error when trying to build the Centaur sources.

Are you working in 2013? Then give me a moment to cross check

 

[DaveS]

Are you working in 2013? Then give me a moment to cross check

No, I'm using VC++ 2010. The updated IUS project builds fine but the Centaur project is being stubborn.

 

[Urwumpe]

Can't get the IUS project to build, because of some strange VC2010 toolchain problem (Version 100 instead of Version 120). Updating the project files fails here as well, looks like something is corrupt there.

 

[GLS]

Still getting the can't find PIDControl.h error when trying to build the Centaur sources.

There's something going on: here it currently compiles well, but if I go to the Centaur settings and try to edit the include paths, it tells me that the "..\" are pointing at the wrong place....
Could you go to Centaur project properties > C/C++ > General > Additional Include Directories, and tell us what is there? Here it is "..\..\..\include;..\..\..\libUltra\include", which not only works but makes sense.
If it is the same try to click there and then in edit, and check the checkbox at the bottom and recompile please.

---------- Post added at 07:02 PM ---------- Previous post was at 07:00 PM ----------

Can't get the IUS project to build, because of some strange VC2010 toolchain problem (Version 100 instead of Version 120). Updating the project files fails here as well, looks like something is corrupt there.

Are you trying to update the 2010 files to 2013?

 

[DaveS]

There's something going on: here it currently compiles well, but if I go to the Centaur settings and try to edit the include paths, it tells me that the "..\" are pointing at the wrong place....
Could you go to Centaur project properties > C/C++ > General > Additional Include Directories, and tell us what is there? Here it is "..\..\..\include;..\..\..\libUltra\include", which not only works but makes sense.
If it is the same try to click there and then in edit, and check the checkbox at the bottom and recompile please.

This is what I have (note the pristine SSU_Centaur project files):

 

[Urwumpe]

Are you trying to update the 2010 files to 2013?

Yes, after copying the project files for maintaining the 2010 files. Does not work. I think I will attempt a clean sheet project for that.

---------- Post added at 08:38 PM ---------- Previous post was at 08:32 PM ----------

With a new project, it works without issues.

 

[GLS]

This is what I have (note the pristine SSU_Centaur project files):

You are using the release settings... I only use the debug so I forgot to add the paths to the release. :facepalm::facepalm:
Fix going to the repository now.

 

[Urwumpe]

You are using the release settings... I only use the debug so I forgot to add the paths to the release. :facepalm::facepalm:
Fix going to the repository now.

Make sure all paths are the same, if possible.

 

[GLS]

Make sure all paths are the same, if possible.

Yes, I checked all the other projects as well. It has to work now

 

[DaveS]

Yes, I checked all the other projects as well. It has to work now

All is well with the 2010 side of the projects now.

 

[GLS]

I just noticed that the position of the aerosurfaces isn't saved/loaded to the scenario files... is this on purpose (due to some kind of SSU or Orbiter aero limitation)?

 

[Urwumpe]

I just noticed that the position of the aerosurfaces isn't saved/loaded to the scenario files... is this on purpose (due to some kind of SSU or Orbiter aero limitation)?

I suspect that's an Orbiter behaviour.

 

[GLS]

So, after a bit of fighting with the menus I just finished the CST stuff. Only the IDPs "light up" (but all the data is bogus), the rest needs a more advanced IDP to provide the data.
I only added the menu buttons that led somewhere... I don't really see the point of adding more stuff to the CRTMFD, as it's just going to be too messy. Leaving the Orbiter MFD system and drawing everything in the MDU should make things much simpler. Also, the current menu button outline texture should be dumped and the 19 lines there drawn "manually" by the MDU.

 

[Urwumpe]

I only added the menu buttons that led somewhere... I don't really see the point of adding more stuff to the CRTMFD, as it's just going to be too messy.

I agree there - the CRTMFD is already used for stuff that goes way beyond what can be expected of a MFD, especially in terms of performance.

I want to reduce CRTMFD and in the long term the IDP/MDU combination to become plain dumb terminals, and move all intelligent stuff into the GPC software and towards the developers of SSU.

 

[GLS]

I agree there - the CRTMFD is already used for stuff that goes way beyond what can be expected of a MFD, especially in terms of performance.

I want to reduce CRTMFD and in the long term the IDP/MDU combination to become plain dumb terminals, and move all intelligent stuff into the GPC software and towards the developers of SSU.

I think we could do away completely with CRTMFD, as the ExtMFD allows access to the "regular" Orbiter MFDs and it would make things easier on the menu front.

 

[Urwumpe]

I think we could do away completely with CRTMFD, as the ExtMFD allows access to the "regular" Orbiter MFDs and it would make things easier on the menu front.

Yes, but then, Orbiter 2016 also comes with quite a few improvements in our favor, it is not an urgent change if we switch to Orbiter 2016 soon

 

[GLS]

Yes, but then, Orbiter 2016 also comes with quite a few improvements in our favor, it is not an urgent change if we switch to Orbiter 2016 soon

Speaking of which, any news from SiameseCat on any work done in the OrbitersimBeta branch? It has been 2 months and no activity there... I don't want to re-do anything that was already done, but I'm tempted to move to Orbiter 2016 and start working there anyway.

 

[Urwumpe]

Suggestion: Make a new thread in the subforum, create a poll about YES or NO and set a date by which we would switch to the Orbiter 2016 version in case of YES.

As long as the date is not closer to today than 60 days, you have my YES.

 

[GLS]

Suggestion: Make a new thread in the subforum, create a poll about YES or NO and set a date by which we would switch to the Orbiter 2016 version in case of YES.

As long as the date is not closer to today than 60 days, you have my YES.

And what's wrong with someone starting the conversion work on a branch? I'd be suprised if a fully working version is available in less than 2 months. The decision is then: when do we merge that branch to the trunk and add 2016 capability? And if we want to keep SSU working in Orbiter 2010, that adds even more time in the branch to make sure it works on both ends of the bridge.

 

[Urwumpe]

And what's wrong with someone starting the conversion work on a branch? I'd be suprised if a fully working version is available in less than 2 months. The decision is then: when do we merge that branch to the trunk and add 2016 capability? And if we want to keep SSU working in Orbiter 2010, that adds even more time in the branch to make sure it works on both ends of the bridge.

I thought we wanted to move the trunk to 2016 anyway to reduce the conflicts