SSU Development Thread (2.0 to 3.0)

[GLS]

I believe we already have the option to use different textures for the ETs, ET_TEX_NAME.

Yep, but not for the extra mass. :thumbup:

Yes, it's not a lot, but it's something.

---------- Post added 07-19-15 at 11:50 AM ---------- Previous post was 07-18-15 at 10:44 PM ----------

confirmed the issue was related to filesystem corruption on our storage platform

anticipate bringing additional services online through mid-week

Full crisis report here.

Given this and what they did to GIMP, VLC and other projects, if the discussion ever comes up, I support moving SSU somewhere else.

 

[DaveS]

Yep, but not for the extra mass. :thumbup:

Yes, it's not a lot, but it's something.

---------- Post added 07-19-15 at 11:50 AM ---------- Previous post was 07-18-15 at 10:44 PM ----------



Full crisis report here.

Given this and what they did to GIMP, VLC and other projects, if the discussion ever comes up, I support moving SSU somewhere else.

What exactly did they do these projects?

 

[GLS]

What exactly did they do these projects?

Not much
http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/
http://www.pcworld.com/article/2930032/sourceforge-stops-ad-bundling-without-permission.html

 

[Urwumpe]

Given this and what they did to GIMP, VLC and other projects, if the discussion ever comes up, I support moving SSU somewhere else.

I agree there. I am for at least keeping the option open to leave Sourceforge behind. Not that I like changing a running system, but right now, the system does not run.

But to also make one thing clear: My preferred option would not be a Sourceforge 2.0 or a Github or similar, but rather having the possibility to use a build system for automatization.

 

[DaveS]

I'm in process of fixing some issues with the Orbiter and I'm a bit unsure if I have gotten the OME null angles correct. Could someone translate the following graphic from the SODB into angles that can be used in a 3D program?

 

[GLS]

I think the null positions are 15.824444º up and then 6.5º to the side.

 

[DaveS]

Donamy: Found some cleaner versions of the OMS pod TPS layout for you:

 

[GLS]

As I "can't" do more changes to the existing stuff because I already have a bunch of stuff to commit (it could get messy to change too much at once), I was thinking about changing direction so I can keep working (at least until sourceforge comes back from the dead). I see 3 things I could do:
>> IUS, good choice IMO as it could piggyback on the Centaur interface work, but don't know what the status of it is (code/meshes/textures).
>> MissionEditor, but I don't know the planned language (which I don't remember the name ATM, but I know that I don't know it :lol.
>> adding more displays to the GeneralDisplays class, even if it's just the static parts it's something and saves time when they get moved to the proper location for use.

Any picks?

 

[DaveS]

As I "can't" do more changes to the existing stuff because I already have a bunch of stuff to commit (it could get messy to change too much at once), I was thinking about changing direction so I can keep working (at least until sourceforge comes back from the dead). I see 3 things I could do:
>> IUS, good choice IMO as it could piggyback on the Centaur interface work, but don't know what the status of it is (code/meshes/textures).
>> MissionEditor, but I don't know the planned language (which I don't remember the name ATM, but I know that I don't know it :lol.
>> adding more displays to the GeneralDisplays class, even if it's just the static parts it's something and saves time when they get moved to the proper location for use.

Any picks?

You could try implementing the IUS. Here's the L10 panel required for it that Donamy created a while back: https://dl.dropboxusercontent.com/u/24122088/Orbiter stuff/IUS panel.zip

The texture goes into the IUS subfolder.

 

[Urwumpe]

Don't we have some bugs to fix for the next release before looking at new features to add?

And if no bugs - can we release?

Mission Editor: I still can't really decide between C# and Java ... C# would fit better into our already used toolset, Java would permit us to use much better tools like Google Guice or OSGI (All C# projects in that direction died in development hell, including the Microsoft projects)

My personal preference would go to Java, because I am more skilled in it and we would be much more flexible in development.


Don't forget that we develop for public releases not for development features.

 

[GLS]

You could try implementing the IUS. Here's the L10 panel required for it that Donamy created a while back: https://dl.dropboxusercontent.com/u/24122088/Orbiter stuff/IUS panel.zip

The texture goes into the IUS subfolder.

I just remembered that there's a thread for the IUS, so I went there and gattispilot already has some code for it. I assume we can use that as a starting point.

 

[GLS]

Don't we have some bugs to fix for the next release before looking at new features to add?

And if no bugs - can we release?

Mission Editor: I still can't really decide between C# and Java ... C# would fit better into our already used toolset, Java would permit us to use much better tools like Google Guice or OSGI (All C# projects in that direction died in development hell, including the Microsoft projects)

My personal preference would go to Java, because I am more skilled in it and we would be much more flexible in development.

Bug fixing, that was pretty much what I was doing, but without the capability to "get rid" of the changes and without the SVN version history it's hard to continue.
About the ME, know somethings about java (probably because it isn't that different from c/c++) but I don't really like it, and then c# knowledge = 0.

 

[Urwumpe]

Bug fixing, that was pretty much what I was doing, but without the capability to "get rid" of the changes and without the SVN version history it's hard to continue.
About the ME, know somethings about java (probably because it isn't that different from c/c++) but I don't really like it, and then c# knowledge = 0.

Well, I still earn my money with Java, despite not developing any software in it (right now)... And I learned a lot of C# in the beginning of the year, because I needed some project flexibility...now I own the three German standard books by Rheinwerk about C#. I can do it both, but Java a few orders of magnitude better.

I don't think that we will get much more joy by adding features without SVN. I know we are itching to add them. But I am more itching to get a release done. Without SVN, I can't really do much here as well.

We could do some analysis and design in the next days, since this does not depend on SVN. For example some requirements engineering.

 

[DaveS]

What is the reason for not using C++ for the Mission Editor? And as far as a public release goes, as long as we close the more important tickets we have right now without creating new ones, that's good enough for me.

One important that I do remember was that the OMS burn targeting system needs work as it frequently misses the DV targets by a large degree (sometimes up to 12 fps in any one axis) requiring RCS post-burn trimming.

 

[GLS]

What is the reason for not using C++ for the Mission Editor? And as far as a public release goes, as long as we close the more important tickets we have right now without creating new ones, that's good enough for me.

One important that I do remember was that the OMS burn targeting system needs work as it frequently misses the DV targets by a large degree (sometimes up to 12 fps in any one axis) requiring RCS post-burn trimming.

The most important ticket for me wasn't even created... it's the panel behind the view getting the clicks instead of the panel in front. I was going to create it if I didn't succeed in finding the cause. And I had done all I know, without success, except going back in time to see if it was there all along, or if it showed up when something as changed. But then our server went on vacation and here we are. :facepalm:
(I have a screen of the ticket page as it last appeared, so if the damage is terminal at least we have the names of the tickets)

BTW: Urwumpe, how are you interfacing the CISS and Centaur vc panel, having a subsystem in the middle to run the show, or it runs all from the panel?

 

[Urwumpe]

BTW: Urwumpe, how are you interfacing the CISS and Centaur vc panel, having a subsystem in the middle to run the show, or it runs all from the panel?

Have a subsystem between, so its easier to also remove the panel and the CISS. Also the panel and the CISS do not need to be completely reworked, should something change on the code behind.

Also, I think about creating a logical separation between the CISS and its visual representation, so both can be removed on runtime. But that idea needs some more life.

---------- Post added at 10:55 PM ---------- Previous post was at 10:52 PM ----------

What is the reason for not using C++ for the Mission Editor?

C++ is a very ugly programming language for GUI applications, especially since many modern concepts and frameworks are not available or only poorly accessible from C++. Especially since we can expect many changes to the mission editor as SSU gets improved, we should limit the work on the mission editor to the necessary effort and not get some more by using a bad suitable programming language for the job.

 

[GLS]

Have a subsystem between, so its easier to also remove the panel and the CISS. Also the panel and the CISS do not need to be completely reworked, should something change on the code behind.

Also, I think about creating a logical separation between the CISS and its visual representation, so both can be removed on runtime. But that idea needs some more life.

I thought so. I asked so the CISS and the ASE share the same architecture, so it becomes easier to maintain as they do similar things.

 

[Urwumpe]

I thought so. I asked so the CISS and the ASE share the same architecture, so it becomes easier to maintain as they do similar things.

Yeah makes sense, especially since the differences are pretty small.

 

[GLS]

Small heads up about SF: the tickets page is now loading for me (and the dates all match my "backup" so nothing lost there), and the code page is now showing a different error than a few hours ago. Hopefully this mess is nearing the end.
IMO, when it all comes online, we should keep it all read-only for a few hours to make sure it the system holds.

 

[SiameseCat]

Given this and what they did to GIMP, VLC and other projects, if the discussion ever comes up, I support moving SSU somewhere else.

Me too.

Face has been maintaining a SSU repo on Bitbucket (https://bitbucket.org/face/ssu), although it doesn't seem to have been updated in a while. If we do want to dump Sourceforge, this might be the simplest option.