SSU Development Thread (3.0 to 4.0)

Thanks for the new adapter! Could you provide the diameter at the IUS and Centaur ends (so I can add them to the manual to give payload developers the data to do other adapters)?
 
Thanks for the new adapter! Could you provide the diameter at the IUS and Centaur ends (so I can add them to the manual to give payload developers the data to do other adapters)?



I'll get them tomorrow. Speaking of manuals, I think we should convert them to PDF. Currently they're in DOC format.
 
I'll get them tomorrow. Speaking of manuals, I think we should convert them to PDF. Currently they're in DOC format.

That's what I'm doing now. I had some things already done, but I'm now putting it all together. It's not finished anyway, so I'll just leave those measurements as x.xxx for now.

---------- Post added at 03:55 AM ---------- Previous post was at 12:18 AM ----------

Ok, I finally finished the upper stage integration (just more content is missing from the manual, and I can't update the VS2013 projects so I'll have to leave that for who can).

Also, I want to give a heads-up on some files that were versioned in the IUS branch but were long gone from the trunk, but came back when the merge was gone.
This is of concern as these files are part of the default Orbiter installation and might have been overwritten and need replacement:
Textures\Exhaust_atsme.dds
(all files inside) Textures2\Atlantis\
I should have paid more attention, my apologies. :(
 
Centaur G/Prime adapter base diameter: 2.74 m
IUS adapter base diameter: 2.89 m
 
Urwumpe, when you have time could you look at the panel and panel group classes? I added a few new switches and found some kind of memory leak indication when closing the simulation. It was in the "scalar deleting destructor" of the panel, called from the panel group.
I eventually started to remove panels and it returned to normal. I then enabled all the panels again, and now the very same code that crashed works fine. :idk:
 
Urwumpe, when you have time could you look at the panel and panel group classes? I added a few new switches and found some kind of memory leak indication when closing the simulation. It was in the "scalar deleting destructor" of the panel, called from the panel group.
I eventually started to remove panels and it returned to normal. I then enabled all the panels again, and now the very same code that crashed works fine. :idk:

No deal, can do it. Maybe just a bad state somewhere.

Did you keep the error messages about that problem?
 
Nop... :facepalm: :facepalm:

No deal. Then I will just need to find out if there is a weakness somewhere. Maybe a good reason to do some review there and clean the code up.
 
No deal. Then I will just need to find out if there is a weakness somewhere. Maybe a good reason to do some review there and clean the code up.

A review is more of what I had in mind. Didn't you have some kind of tool to analyse the code?
 
A review is more of what I had in mind. Didn't you have some kind of tool to analyse the code?

Yeah, I remember something. Should I remember wrong, I just lint everything. :lol:

---------- Post added at 09:56 PM ---------- Previous post was at 04:35 PM ----------

25 issues with the code analysis of Visual Studio. Nothing related to the VC there. Most complain about how we use sscan_s, nothing serious.

There is an uninitialized memory issue in ssme.cpp which is pretty dire (bundle_power), also the bridgerail implementation in mission has a problem about array usage (A size of 13 means 12 is the highest legal index, not 12, a common C++ error).

I am a bit disappointed, because I know of more code smells, which we currently tolerate. Will look for a real tool.
 
Yeah, I remember something. Should I remember wrong, I just lint everything. :lol:

---------- Post added at 09:56 PM ---------- Previous post was at 04:35 PM ----------

25 issues with the code analysis of Visual Studio. Nothing related to the VC there. Most complain about how we use sscan_s, nothing serious.

There is an uninitialized memory issue in ssme.cpp which is pretty dire (bundle_power), also the bridgerail implementation in mission has a problem about array usage (A size of 13 means 12 is the highest legal index, not 12, a common C++ error).

I am a bit disappointed, because I know of more code smells, which we currently tolerate. Will look for a real tool.

The switches that caused the trouble are now committed. The problem didn't show itself again here. :shrug:
On the SSME.cpp bundle "issue", yes that could be a huge hole in the logic, but I did that (and still didn't change it) because the variable used by that switch is "controlled", i.e. that is not a problem unless we put 4 SSMEs in or the variable is overwritten or someone changes the SSME IDs to other than 1, 2 and 3. I can always change the last case to default to stop that warning.... and allow ID 4, 25 and 86. :lol:
I'll take a look at the bridgerails thing now.

---------- Post added at 01:10 AM ---------- Previous post was at 12:35 AM ----------

Fixed the bridgerail issue and added the payload adapter measurements to the manual.
 
I also did a check with cppcheck yesterday night, with some more issues. Most are about style(We use an earlier version of the language standard), nothing critical, but it also discovered some real issues in our code. Will fix the important ones and put the remaining issues as XML file into the source directory for reference.
 
Added engine gimballing to the upper stages, but it needs someone with vs2013 to add libUltra or it will only compile in vs2010.
Any news on the OrbitersimBeta branch? It was created by SiameseCat but there's no activity there.....
 
Added engine gimballing to the upper stages, but it needs someone with vs2013 to add libUltra or it will only compile in vs2010.
Any news on the OrbitersimBeta branch? It was created by SiameseCat but there's no activity there.....
I had some troubles building the Centaur and IUS projects. I solved them by adding PIDControl.cpp to the projects and ../../../libUltra/include to Additional Include directories in the Project Properties. Should I check in these changes to the projects?
 
I had some troubles building the Centaur and IUS projects. I solved them by adding PIDControl.cpp to the projects and ../../../libUltra/include to Additional Include directories in the Project Properties. Should I check in these changes to the projects?

Are you using the vs2010 projects? If so, then no changes should be needed as I updated those.
 
Are you using the vs2010 projects? If so, then no changes should be needed as I updated those.
Yes, I'm using the VS2010 solution. Yet it wouldn't build. And I just reverted the changes back to baseline rev. 2352 and have the same problems.
 
Bah, I was adding the library the wrong way. :facepalm: It was working as long as one didn't compile libUltra at the same time.... a fix will show up in a few minutes in the repository. Sorry!

---------- Post added at 05:38 PM ---------- Previous post was at 04:31 PM ----------

Took longer than I was expecting* but it should all work now. A full rebuilt should work with no problems.

*) I also fixed a problem with multi-core compilation (2 projects writting the same output file at once) by changing settings so intermediate files go to individual project folders. This also reduces the amount of "cra*" that shows up in the Modules folder.

Again this is just for vs2010, for 2013 someone else has to do it.
 
Again this is just for vs2010, for 2013 someone else has to do it.

No problem, I am still 2013 user. Should I upgrade to 2015, the confusion might become perfect. :lol:

Maybe we should try getting a Visual Studio version neutral build script one day.
 
No problem, I am still 2013 user. Should I upgrade to 2015, the confusion might become perfect. :lol:

Maybe we should try getting a Visual Studio version neutral build script one day.

And as Microsoft continues to downgrade their OSs, I might soon become a Linux user. Now that would be the perfect storm. :rofl:
 
Still getting the can't find PIDControl.h error when trying to build the Centaur sources.
 
Back
Top