Search results

I've fixed the pushbutton issue (it's a bug in PushButton.cpp). Should I check the fix in to the trunk, or do you need in the MPS branch?

It (and VENTL/VENTR vectors) are tied to the vent arm animation, so they update as the vent arm moves. The vent direction is calculated by subtracting the position corresponding to the VENTDIR from the VENTL position. Also, the original value I posted is incorrect (I copied the old value...

Assuming the vent direction is unchanged, it should be const VECTOR3 FSS_POS_GOXVENTDIR = _V(-0.425300945173, 0.853695922526, 0.300536816213); Lines 184-186 in SSUPad.cpp should also be changed to vtx_goxvent[0] = FSS_POS_GOXVENTL; vtx_goxvent[1] = FSS_POS_GOXVENTR...

I notice that, in the clbkLoadVC code, the camera direction is along the Y axis (instead of the Z axis). I wonder if the Orbiter HUD code is drawing the HUD as if the camera is facing along the Z axis instead.

Done. I've also added the BURNT_TEX_NAME parameter.

The texture name is probably incomplete. It should look like ET_TEX_NAME SSU\SLWT_ETtex.dds Both the SSU\ folder and the .dds extension are required, otherwise the texture won't be found.

There's already a ET_TEX_NAME scenario file entry which specifies the (unburnt) ET texture. This should work for STS-1/2.

I can add a scenario file entry (BURNT_TEX_NAME) to specify the texture to be used after SRB sep.

Can you check the ET/SRB masses? ---------- Post added at 09:10 PM ---------- Previous post was at 09:04 PM ---------- Also, I think the SSME specifications (thrust & ISP) changed a bit over time. This might have some effect on the Centaur missions. It might be a good idea to test one of the...

You're right, if you use managed C++, calling C# code is easy. I was thinking in terms of calling C# from unmanaged code. I'm a little bit concerned about adding managed code to a large project like SSU which currently uses only unmanaged code, although there shouldn't be any problems...

Not sure what you mean by that. libUltra already has some orbital mechanics code, so we can start using libUltra stuff in SSUToolbox/MCC without any changes to libUltra. In general, I don't see any reason not to share algorithms. A lot of tasks (rendezvous burn targeting, state vector...

I think libUltra will be quite useful for the orbital mechanics stuff, which will be a major part of SSUToolbox/MCC. We can certainly rewrite the relevant code in C# or Java if we need to. But I don't really think there's a big advantage in using C#/Java instead of C++. As far as the UI goes...

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.

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.

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.

I'm thinking of the libUltra code, which includes some orbital mechanics stuff. At the moment, this is used in the SSU GPC code, but we can also use it in both the MCC and SSU Toolbox Flight Planner.

I've created a separate branch (branches/SSUToolbox) for SSU toolbox development. You should check the code into that branch. That way, we can try out different things without affecting SSU development. ---------- Post added at 09:47 AM ---------- Previous post was at 09:29 AM ---------- I...

You should have permission to check in code now.

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).

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.