SSU Development Thread (2.0 to 3.0)

[DaveS]

Looks like it was without the "trunk" part.

---------- Post added at 21:41 ---------- Previous post was at 21:32 ----------

Is it normal that when updating it asks for my password 4 times (I type it correctly)?

Yes that's normal. If you want to avoid it, right-click on the folder and go TortoiseSVN>Settings. Now click on Network and paste this into field for SSH client:

C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -l daves-ssu -pw *****

Once again, replace daves-ssu with your username and ***** after -pw with your password.

 

[Goth]

Working .NET prototypes of SSUToolbox and SSU Mission Control DLL dialog uploaded in the SSUToolbox SVN branch.
Next goal could be testing Orbiter API / libUltra functions with C++/CLR to see how it goes to confirm if the .NET route is "go / no go".

---------- Post added 18-03-14 at 20:45 ---------- Previous post was 17-03-14 at 23:14 ----------

I've tried wxWidgets too (it's on SVN) but it's not just a wrapper, it runs its own "main application" and its own "application loop" just as Qt. I managed putting a wxWidgets frame into an Orbiter dialog, but doing the events (click, etc) is a problem and I guess it requires doing a separate thread.
Still, it may be the best solution of the three.

Qt:

• very easy to use
• cannot do an Orbiter dialog

.NET (C# and Windows Forms):

• even easier to use
• using OrbiterSDK / libUltra would be a pain: http://stackoverflow.com/questions/18150396/import-a-c-lib-and-h-file-into-a-c-sharp-project

wxWidgets:

• wxFormBuilder is... ugly? And it requires you to copy paste the code in your project unless I miss something; together with Code::Blocks it may work better but Code::Blocks still doesn't support its v.3 AFAIK.
• doing an Orbiter dialog is still a pain but maybe possible (still working on it).

Hmmm... I'm starting to miss WINAPI and .rc manual editing lol.
If anything, I've learnt to use three different frameworks. :lol:

 

[Face]

.NET (C# and Windows Forms):

• even easier to use
• using OrbiterSDK / libUltra would be a pain: http://stackoverflow.com/questions/18150396/import-a-c-lib-and-h-file-into-a-c-sharp-project

"Pain" is probably a bit too much. It is not as easy as simply importing a lib and including a header function, because you have to cross the border between managed and unmanaged code. But it is far from being a painful mission.

For the OrbiterSDK part, there is already much in the form of Orbiter.NET . The libUltra part is dependent on what you really need from it in the .NET application.

The libUltra project itself is compilable with /clr support into a DLL (just checked), so you can reference it from a .NET assembly and load/execute managed types inside it. Of course you'd have to implement those managed types/functions there first as wrappers to unmanaged code, but this is essentially force times distance, nothing overly complex.

Alternatively, you could use PInvoke to call functions in the DLL directly, without having to implement wrappers first. This however is limited to simple call signatures.

Using libUltra as a static *.lib is not possible with C# projects, though. So if you need almost every single class of the library separately, that would be a no-go for .NET IMHO. If you can access the functionality via at most 10 (to draw a number) wrapper calls, it is worth the effort.

 

[SiameseCat]

"Pain" is probably a bit too much. It is not as easy as simply importing a lib and including a header function, because you have to cross the border between managed and unmanaged code. But it is far from being a painful mission.

For the OrbiterSDK part, there is already much in the form of Orbiter.NET . The libUltra part is dependent on what you really need from it in the .NET application.

The libUltra project itself is compilable with /clr support into a DLL (just checked), so you can reference it from a .NET assembly and load/execute managed types inside it. Of course you'd have to implement those managed types/functions there first as wrappers to unmanaged code, but this is essentially force times distance, nothing overly complex.

Alternatively, you could use PInvoke to call functions in the DLL directly, without having to implement wrappers first. This however is limited to simple call signatures.

Using libUltra as a static *.lib is not possible with C# projects, though. So if you need almost every single class of the library separately, that would be a no-go for .NET IMHO. If you can access the functionality via at most 10 (to draw a number) wrapper calls, it is worth the effort.

We'll probably be using a couple of classes from libUltra, so we'll have to create .NET wrapper classes. Which is annoying, but doable.

Unless there are strong objections, my inclination is to go with Qt and require users to select 'Full Screen Window' mode.

 

[Goth]

It's not only about the fullscreen, Qt isn't working fine together with Orbiter. It doesn't update its window. It could only be used for SSUToolbox but not for a Mission Control plugin. Unless someone magically answer me here:
http://qt-project.org/forums/viewthread/39690/
or is able to have a look at my code in SVN and solve the issue.

---------- Post added at 23:48 ---------- Previous post was at 23:33 ----------

Actually I didn't even uploaded the Qt's Mission Control test because indeed it didn't work; I'll upload it soon.

---------- Post added 19-03-14 at 00:05 ---------- Previous post was 18-03-14 at 23:48 ----------

Done.

 

[SiameseCat]

It's not only about the fullscreen, Qt isn't working fine together with Orbiter. It doesn't update its window. It could only be used for SSUToolbox but not for a Mission Control plugin. Unless someone magically answer me here:
http://qt-project.org/forums/viewthread/39690/
or is able to have a look at my code in SVN and solve the issue.

---------- Post added at 23:48 ---------- Previous post was at 23:33 ----------

Actually I didn't even uploaded the Qt's Mission Control test because indeed it didn't work; I'll upload it soon.

---------- Post added 19-03-14 at 00:05 ---------- Previous post was 18-03-14 at 23:48 ----------

Done.

The Mission Control can run as a separate executable, instead of as a dialog box within Orbiter. This will probably be easier for most cases, since a MCC dialog box will take up screen space within Orbiter and could be really annoying.

 

[DaveS]

The Mission Control can run as a separate executable, instead of as a dialog box within Orbiter. This will probably be easier for most cases, since a MCC dialog box will take up screen space within Orbiter and could be really annoying.

Yes. And what is the difference in appearance between a dialog and a stand-alone executable? The important objective here is something that can communicate 2-way with Orbiter. Right now the only use for MCC is FDO, for trajectory calculations.

 

[Face]

We'll probably be using a couple of classes from libUltra, so we'll have to create .NET wrapper classes. Which is annoying, but doable.

Unless there are strong objections, my inclination is to go with Qt and require users to select 'Full Screen Window' mode.

You can also go a different route: do the heavy lifting in the native MissionControl plugin, but do the visuals in the .NET dialog. This way, you'd enforce a kind of MVC concept. I.e.: for all the things needing 2-way Orbiter contact, do the view part in the .NET and propagate value changes to the native model and controller part, where it can take full use of libUltra and OrbiterAPI. The things NOT needing 2-way connection, the model and control parts could reside in the .NET application, if only to have a valuable stand-alone functionality.

What I can see from Goth's example - and speaking from experience from OMP project - .NET interaction in Orbiter is pretty smooth. IMHO, it is "MFC Done Right(TM)". A platform choice excluding functionality of the core system right from start leaves a bitter taste OTOH.

Just my :2cents:, of course.

 

[Goth]

The Mission Control can run as a separate executable, instead of as a dialog box within Orbiter.

In that case you can't use OrbiterAPI so you would need some way to connect to Orbiter, and there is no good way compared to direct C++ Orbiter API calls.

Right now the only use for MCC is FDO, for trajectory calculations.

If that's the case, we could do as Face is suggesting in the last post. That would be perfect for MCC; still, since SSUToolbox is 100% .NET there would stille be the "libUltra code problem" for SSUToolbox. Unless you go the same route with SSUToolbox too, having e.g. a .NET window where you click a button which calls C++ code...

BTW I've not yet completed the testing with wxWidgets, so I can't exclude that option either. However, taking into account how both Qt and wxWidgets work (requiring another thread to work inside Orbiter and communicating with the main thread), maybe the .NET approach still makes more sense. I just need (yet more ) help from Face to set up at least one example of this kind of communication and then I'll be ready to go on by myself.

 

[SiameseCat]

In that case you can't use OrbiterAPI so you would need some way to connect to Orbiter, and there is no good way compared to direct C++ Orbiter API calls.

I don't think we need direct communication between MCC and Orbiter. What I was thinking is that the SSU dll will send data (state vectors, etc.) directly to MCC, and MCC could potentially send commands back to SSU.

 

[Goth]

SSU dll doesn't send anything by its own since it is loaded by (or into) Orbiter; so if it needs to send something it has to do it through Orbiter, correct me if I'm wrong; the only way to send information to another program bypassing Orbiter is using some kind of protocol e.g. HTTP messages.
An external program (SSUToolbox) has no way to talk with that DLL apart from loading it, but it can't load it because it is loaded into Orbiter. And if it isn't, well, it has no clue about the ongoing simulation.

 

[Face]

Hm. Sounds like this is more about something like Orb:Connect, not about getting some neat GUI to work in Orbiter.

OrbiterNavigator also used sockets to do the Orbiter link, BTW.

 

[Goth]

It may be the way to go, since things like shuttle internals, crew data, checklists, etc, are not known by Orbiter anyway. In that case Qt or anything C++ based would be ok for what concerns the GUI. And you solve the libUltra (or any other lib) problem.

---------- Post added at 16:13 ---------- Previous post was at 16:09 ----------

Let's say you want to retrieve crew information, you should do something like:
SSU DLL <-> Orbiter <-> MCC
Instead with a Orb:Connect/socket/whatever you would just do:
SSU DLL <-> MCC

Also, if you ever consider multiplayer you would have to go that route anyway...

 

[STS]

Instead with a Orb:Connect/socket/whatever you would just do:
SSU DLL <-> MCC
Also, if you ever consider multiplayer you would have to go that route anyway...

Not multiplayer, but "telemetry" clients connecting by orb:connect and requesting spacecraft data. For example, right now, engine status is not received by Orb:Connect when a burn is performed in SSU.

 

[Goth]

Yes, multiplayer meaning people doing the flight controllers.

Well, what should we use?

Orb:Connect may work only if you want state vectors or other Orbiter-specific stuff. After reading Orb:Connect docs I see that SSU specific information can't be passed since there isn't a generic get/send message function.

 

[GLS]

Right now the only use for MCC is FDO, for trajectory calculations.

Not necessarily: there's already some SSME/MPS data available in the GPCs, if there's a way to send it to the "MCC" we could have a "Booster display" giving additional insight about those systems. :thumbup:

 

[Urwumpe]

Not necessarily: there's already some SSME/MPS data available in the GPCs, if there's a way to send it to the "MCC" we could have a "Booster display" giving additional insight about those systems. :thumbup:

And we could also record and downlink SSME performance data after ascent, for further debugging.

I think a standalone application is the best solution, since this would also allow us more flexibility. It should just be platform independent enough to also support Linux systems, since quite many here use it as primary or secondary PC.

 

[Goth]

You're basically saying Qt. The problem is how to do the communication. I don't know where to start about this.

 

[Urwumpe]

You're basically saying Qt. The problem is how to do the communication. I don't know where to start about this.

No, thats not true. Please be correct, we can use there:

• C++ with Qt
• C++ with wxWidgets
• Python with PyQt
• Java with anything
• C#/.NET (On Linux with Mono)
• etc.

The C++ options would mean that we reduce the number of programming languages in the project, but I am strongly convinced, that Java or C# would be the better languages for the task of creating an application that is primarily a user interface for displaying and interacting with data received over a network connection. C++ simply means too much low-level programming for the task.

Especially since we would not need to recompile everything with C# or Java, but could use one package for both.

The simple problem is: I can't do it because I am too busy. So I have no base to do any decisions in SSU currently. I can only make recommendations.

 

[Goth]

Due to the problem of using libUltra explained by SiameseCat I thought that we were stuck with C++. In that case between Qt and WxWdigets it will be Qt IMHO. However, it's true that doing communication between applications may be easier in other languages.

---------- Post added at 11:44 ---------- Previous post was at 11:41 ----------

Also, on the other side you have the SSU lib code which is C++ too. So if you have to communicate with a C++ compiled app (SSU) maybe it makes sense to use C++ for the client too (SSUToolbox/MCC).