SSU Development Thread (2.0 to 3.0)

[GLS]

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

 

[Goth]

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.

 

[Urwumpe]

It uses SetForegroundWindow() which is something I didn't think about, but it still fails in fullscreen mode.

Dialogs and DX-client in fullscreen mode is no good combination.

 

[Goth]

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.

 

[SiameseCat]

Has anyone tried using wxWidgets in Orbiter? I've never used it myself, but it supposedly uses WinAPI. I'm not sure if this will actually solve the fullscreen issues.

 

[Urwumpe]

Has anyone tried using wxWidgets in Orbiter? I've never used it myself, but it supposedly uses WinAPI. I'm not sure if this will actually solve the fullscreen issues.

Not yet, but I am also not sure, if it is possible to combine wxWidgets with Orbiter, because of the macros that it requires.

 

[Goth]

it uses the platform's native API rather than emulating the GUI

Which is where Qt problems lie. We should give it a try.

 

[SiameseCat]

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.

 

[Urwumpe]

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.

That is what I use here.

 

[DaveS]

That is what I use here.

I use windowed mode, so no loss here.

---------- Post added at 01:06 AM ---------- Previous post was at 12:18 AM ----------

Anyone besides GLS having Orbiter mesh troubles(ticket# 45)?

 

[GLS]

Anyone besides GLS having Orbiter mesh troubles(ticket# 45)?

Just posted a couple of pictures of the "effect" in the ticket

 

[DaveS]

Just posted a couple of pictures of the "effect" in the ticket

I don't know what to tell you. I just don't have that problem. Everything is stable on my end, so I really need to know if anyone else is experiencing this problem.

 

[SiameseCat]

Just posted a couple of pictures of the "effect" in the ticket

I can't reproduce this either. Can you post the Orbiter.log file and your Orbiter.exe graphics settings (preferably in the ticket, otherwise in this thread).

 

[GLS]

I can't reproduce this either. Can you post the Orbiter.log file and your Orbiter.exe graphics settings (preferably in the ticket, otherwise in this thread).

settings posted in ticket

 

[Goth]

Otherwise, is it a big issue to tell users to avoid 'True Fullscreen Mode'

Not that great.. Anyway I'm still fighting againts Qt crashes and stuff so even Qt isn't 100% "go" yet (for what concerns running together with Orbiter).

---------- Post added at 23:49 ---------- Previous post was at 01:59 ----------

About ticket #45: this effect is the same I was getting in some videogames years ago when my PC was about to die. It's a CPU/GPU overheating effect. I don't think it's a SSU issue, but more a PC issue. Maybe using the graphic clients there is less workload on the CPU and it doesn't overheat, that's why it works. Try cleaning fans. Just my 0.2$.

---------- Post added 16-03-14 at 00:52 ---------- Previous post was 15-03-14 at 23:49 ----------

How can I commit changes?
I want to upload my Toolbox prototype.

 

[DaveS]

How can I commit changes?
I want to upload my Toolbox prototype.

1. Get yourself an account on Sourceforge
2. Post the username of your Sourforge account here so it can be added to the developers list, as only developers can check in items
3. If you already haven't, download and install TortoiseSVN and perform a checkout as detailed here

 

[Goth]

orbinautgoth

 

[GLS]

About ticket #45: this effect is the same I was getting in some videogames years ago when my PC was about to die. It's a CPU/GPU overheating effect. I don't think it's a SSU issue, but more a PC issue. Maybe using the graphic clients there is less workload on the CPU and it doesn't overheat, that's why it works. Try cleaning fans. Just my 0.2$.

Actually it's the other way around: it runs well in D3D9, has problems in the default client. Anyway, a hardware problem is highly unlikely. This problem occurs on 2 (completely) different laptops, one around 8 years old, the other brand new. And this only happens in the default client, D3D9 is flawless (as well as everything else I ran on those 2 computers).
One thing I noticed is that the "effect" goes away when some parts of the orbiter are not in the FOV. Can't give an exact location, but looks like if I zoom in, until about half of the first forward "section" of PLBDs is out of the FOV, the "effect" stops. Zoom out and it returns. That and the textures being from the PLB, I put my money on the source of the "effect" being somewhere in there.

 

[DaveS]

Actually it's the other way around: it runs well in D3D9, has problems in the default client. Anyway, a hardware problem is highly unlikely. This problem occurs on 2 (completely) different laptops, one around 8 years old, the other brand new. And this only happens in the default client, D3D9 is flawless (as well as everything else I ran on those 2 computers).
One thing I noticed is that the "effect" goes away when some parts of the orbiter are not in the FOV. Can't give an exact location, but looks like if I zoom in, until about half of the first forward "section" of PLBDs is out of the FOV, the "effect" stops. Zoom out and it returns. That and the textures being from the PLB, I put my money on the source of the "effect" being somewhere in there.

I checked in a debug version of the orbiter mesh with has the PLB meshgroup hidden. Please try it and report back.

Since I can't reproduce it, I'll have to do this in the blind.

 

[SiameseCat]

orbinautgoth

You should have permission to check in code now.