SSU Development Thread (2.0 to 3.0)
- Thread starter Urwumpe
- Start date
- Status
SiameseCat
Addon Developer
I can't compile the MECOTool, because it uses MFC, which isn't included with Visual Studio Express.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes, that is why the plan was to redo it. My favorite would be a Java solution, JavaFX worked great, but then, I am pretty much the only Java guy around here, it makes no sense.
SiameseCat
Addon Developer
How easy is it to call C++ code from Java? We can probably reuse some of the libUltra code in the new SSU toolbox.
The other thing I would like to see is some sort of Mission Control, which allows for flight planning (target rendezvous burns, etc.). I'm not sure if this should run within Orbiter or as a standalone application (part of SSU toolbox?).
Donamy
Addon Developer
How about for all vessels ?
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Covering all vessels would quickly result in metaprogramming or require a minimal solution, that does not help ingame at all.
Not really the best goal for the start. What about having just one vessel supported so good, that mission control starts to be a help?
But more important is a simple architecture decision: What programming languages can we support, and what is too rarely known?
SiameseCat
Addon Developer
I'm fine with using Java. I haven't used it much in the past, but I should be able to learn pretty quickly. I'm more familiar with C#.
I think maybe we should start by figuring out what the SSU Toolbox will do, before we choose a programming language. I think C++ might be helpful for code reuse, although it isn't the best for creating a GUI.
I think maybe we should start by figuring out what the SSU Toolbox will do, before we choose a programming language. I think C++ might be helpful for code reuse, although it isn't the best for creating a GUI.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
C# would for example be a much better option for Visual Studio users. But I can't program C#, I am more familiar with Java. But since I am currently pretty busy with work and studies, I am not much help there anyway.
Well, Qt is a pretty good way to create GUIs in C++. It just requires learning another framework again, which makes not much sense if it isn't needed.
What it should do, IMHO style, ordered by priority:
Create and edit a flight plan, that an algorithm can follow, including launch and abort parameters.
Define payload bay configuration
Configure the spacecraft (subsystem settings, etc).
Record telemetry data from a session and write it to disk (compressed or human readable format).
Allow editing instruction lists for IO systems.
Allow configuring crew data.
Allow creating and editing a digital flight data file for AI crew members to follow or for in-game display for the player.
(lol) BTW... if you choose Qt and you can provide me a complete pseudo-code I could give it a try. I like making GUI stuff.
I've tried Qt recently and after you grasp signals and slots and layouts you're pretty much there. I find it pretty good. Problems are the VERY long install (no user input required though) and the infamous-well-known-crazy weight of DLLs needed to run the EXE; for a simple program I needed 9 DLL files in the EXE folder to allow it to start, for a total amount of 43 MB. However, compressed in Zip it goes down to 16 MB. Let's say the EXE won't go over 200kb, the compressed total won't be that bad anyway.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Did anybody here see anything... :lol:
The number of DLLs isn't that bad and the size of the executable is also the least of our worries there. I also know how to use PyQt to prototype an application with Python for later turning it into a proper C++ application. And the Qt Designer is really a great tool for quickly designing GUIs and turning them into C++ or Python code.
If you can do it, it means we have 1 and a half (for me, see above) Qt capable developers.
Actually, 1 hobbist programmer + 1 Qt potential capable developer. ^^
---------- Post added at 13:42 ---------- Previous post was at 13:36 ----------
Well I "just" need some pseudo-code, something more detailed than the previous Urwumpe list, especially mathematical stuff that I wouldn't be able to code by scratch. Or how you want a final output file to be, etc. Maybe starting with only one of the wanted features.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
We should maybe start with a new thread and gather user stories.
I don't want to put a full mission control into the tool box, because it would get too large to maintain. But both tools could be done by Qt (Qt also has a OpenGL Canvas)
If for a mission control plugin you mean something which monitorizes a mission in real time, it should work both within Orbiter (otherwise you would have to Alt+TAB when in fullscreen uh..) and as standalone application (for multiplayer, maybe using Orb::Connect).
If you just want flight planning, that can be just a standalone application which outputs scenario and cfg files. Basically MECOTool/SSU toolbox.
In any case, if you want to have a within-orbiter-dialog, I'm afraid you are stuck with MFC (or VS with some free .rc compiler). I don't know if it's possible/easy to compile a DLL in Qt which can open a dialog in Orbiter. Maybe it's just a matter of retrieving a window handler from a QT widget and passing that to oapiRegisterDialog etc. Or maybe not.
Anyway what programs do you guys want?
MECOTool for MECO calculations
SSU Toolbox for planning a mission (shouldn't MECOTool be part of it then)
Mission Control... which does what? Flight planning is done before anything else. So a Mission Control plugin should just monitorize what SSU Toolbox already did and maybe change something. But if you change something after the mission started, you may want the Mission Control to just be SSU Toolbox itself, to avoid duplicating stuff.
Last edited:
SiameseCat
Addon Developer
Here's my thinking:
Mission Control tool would be used mainly for calculating burn targets (rendezvous burns, deorbit, etc.), using data from Orbitersim. I'm leaning towards it just being a standalone application - I don't think Alt-tabbing is a big problem.
SSU Toolbox (which includes MECOTool) is essentially a tool for scenario creators to create the scenario file, mission file, and anything else that is required. This will also include creating a flight plan (which will have to go into some sort of .pdf/.txt doc file), so there's likely to be quite a bit of overlap between SSU Toolbox and the Mission Control tool.
How about a custom function plugin (F4)? Eliminates the need of Alt-tabbing and interfaces with Orbiter directly.
As I said in that case Qt may not work so you could only use MFC (or VS with some free .rc compiler). I'll do a test to see if it's possible to use Qt inside Orbiter.
---------- Post added at 20:42 ---------- Previous post was at 17:57 ----------
Ok, writing a DLL plugin with Qt for MSVC2010 which saves a parameter on the scenario file does work. Now the hardest part...
Last edited:
- Status
