Donamy
Addon Developer
How about for all vessels ?
SSU Development Thread (2.0 to 3.0)
- Thread starter Urwumpe
- Start date
- Status
How about for all vessels ?
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 37,628
- Reaction score
- 2,345
- 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
- 37,628
- Reaction score
- 2,345
- 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
- 37,628
- Reaction score
- 2,345
- 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
- 37,628
- Reaction score
- 2,345
- 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:
GLS
Well-known member
Vehicle configuration is one thing I would like to have priority.
Here's my take on how it should be: the mission file specifies I-loads (MECO targets, 1º stage tables, landing sites, etc), "systems versions" (SSME model, GPC sw version, VC version) and also "mission kits" (the Centaur mod, OMS Kit mod, EDO mod, RMS, ODS). One mission kit being "on" just adds to the vehicle the mass of the pipes and/or the switches in the cockpit. You can then choose to have the item itself (EDO pallet, RMS, etc) or not (both Endeavour and Columbia had the EDO piping on many non EDO missions).
The scenario file would say if you had, or not, (for example) the RMS, and if yes, in what configuration would it be (along with the rest of the subsystems).
The "assembly" of those 2 files should be done by the future "SSU Toolbox", so it's easier/automated and also so we can do some "sanity" checks (probably couldn't have the Centaur and the EDO pallet together).
But, what one thinks and reality can be 2 different things. Looking at the way the modules are loaded in Orbiter, by the time we have access to the mission file, it's probably too late to "build" the systems.... so there goes my idea down the drain... :facepalm:
About the language discussion above, I did learn java about one year ago but didn't really like it, and did very very little GUI stuff. I'm probably a decade and a half too late, but I know VB6
Here's my take on how it should be: the mission file specifies I-loads (MECO targets, 1º stage tables, landing sites, etc), "systems versions" (SSME model, GPC sw version, VC version) and also "mission kits" (the Centaur mod, OMS Kit mod, EDO mod, RMS, ODS). One mission kit being "on" just adds to the vehicle the mass of the pipes and/or the switches in the cockpit. You can then choose to have the item itself (EDO pallet, RMS, etc) or not (both Endeavour and Columbia had the EDO piping on many non EDO missions).
The scenario file would say if you had, or not, (for example) the RMS, and if yes, in what configuration would it be (along with the rest of the subsystems).
The "assembly" of those 2 files should be done by the future "SSU Toolbox", so it's easier/automated and also so we can do some "sanity" checks (probably couldn't have the Centaur and the EDO pallet together).
But, what one thinks and reality can be 2 different things. Looking at the way the modules are loaded in Orbiter, by the time we have access to the mission file, it's probably too late to "build" the systems.... so there goes my idea down the drain... :facepalm:
About the language discussion above, I did learn java about one year ago but didn't really like it, and did very very little GUI stuff. I'm probably a decade and a half too late, but I know VB6
Well I've tried everything.
Basically, Qt needs to work on its own, because it's not of course a winapi wrapper, it's something totally different. So, searching on the web, the solution to make a Window working together with a native Win app (Orbiter.exe in our case) is to create a separate thread. I did it, and my Qt window indeed appears togheter with the launchpad. However there's no way to make that window an orbiter dialog. Because since Orbiter lives in a different thread than the Qt window, it simply crashes everything.
So you could find a way to make that window to always stay on top, but on full screen this will fail. And Alt+Tab IS a problem, because Orbiter goes minimized and re-tabbing doesn't bring it back, plus other problems.
So, Qt is not ok for a mission control plugin. The only way is to use standard VC++ plus some external resource editor, here this orbinaut was suggesting ResEdit).
Qt could be used for standalone apps of course, however if you want easy compatibility between all the SSU programs you may as well forget Qt completely. I mean, one program compiled with X and the other with Y sounds too messy.
Dunno.
It's a pity though, it seemed doable.
---------- Post added at 23:03 ---------- Previous post was at 22:58 ----------
I've now remembered this however:
http://orbiter-forum.com/showthread.php?t=33132
I'm going to have a look at how he did it, maybe you can apply it to Qt.
---------- Post added at 23:20 ---------- Previous post was at 23:03 ----------
It uses SetForegroundWindow() which is something I didn't think about, but it still fails in fullscreen mode.
Basically, Qt needs to work on its own, because it's not of course a winapi wrapper, it's something totally different. So, searching on the web, the solution to make a Window working together with a native Win app (Orbiter.exe in our case) is to create a separate thread. I did it, and my Qt window indeed appears togheter with the launchpad. However there's no way to make that window an orbiter dialog. Because since Orbiter lives in a different thread than the Qt window, it simply crashes everything.
So you could find a way to make that window to always stay on top, but on full screen this will fail. And Alt+Tab IS a problem, because Orbiter goes minimized and re-tabbing doesn't bring it back, plus other problems.
So, Qt is not ok for a mission control plugin. The only way is to use standard VC++ plus some external resource editor, here this orbinaut was suggesting ResEdit).
Qt could be used for standalone apps of course, however if you want easy compatibility between all the SSU programs you may as well forget Qt completely. I mean, one program compiled with X and the other with Y sounds too messy.
Dunno.
It's a pity though, it seemed doable.
---------- Post added at 23:03 ---------- Previous post was at 22:58 ----------
I've now remembered this however:
http://orbiter-forum.com/showthread.php?t=33132
I'm going to have a look at how he did it, maybe you can apply it to Qt.
---------- Post added at 23:20 ---------- Previous post was at 23:03 ----------
It uses SetForegroundWindow() which is something I didn't think about, but it still fails in fullscreen mode.
Not dialogs, but a normal window.
My last idea is to use a normal Qt window not registered as a dialog and using SetForegroundWindow() to bring it in front every step; it does work, but not in fullscreen. There may be ways around that though.
My last idea is to use a normal Qt window not registered as a dialog and using SetForegroundWindow() to bring it in front every step; it does work, but not in fullscreen. There may be ways around that though.
SiameseCat
Addon Developer
SiameseCat
Addon Developer
Otherwise, is it a big issue to tell users to avoid 'True Fullscreen Mode', and use 'Fullscreen Window' instead? This is probably the easiest solution for us.
- Status
Similar threads
