Search results

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.

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

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

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

I can't compile the MECOTool, because it uses MFC, which isn't included with Visual Studio Express.

To change MFDs, hold down the PG button; eventually the MFD selection screen appears. For posting bug reports, the SF ticket system is preferred.

Checked the scenarios into the Testing Scenarios folder. I'm not sure it's worth the effort involved to simulate the STA. I think it's more important to keep working on the Space Shuttle simulation.

Checked in the EDW landing site. The SITE ID (ITEM 41) number is 45. I also have some entry/TAEM scenarios for Edwards. I can check these in if someone's interested. They don't correspond to any specfic mission, but they're useful to try out an entry to Edwards.

Problems are fixed now.

I do mean orbiter.exe. I deleted some groups that seemed to be causing problems in MeshWizard, and everything now works for me. There doesn't seem to be any difference in appearance between the edited mesh and the original version. The modified RWY23 mesh is at...

Orbiter CTDs when I start any SSU scenario. It doesn't seem to like the RWY23 mesh - if I remove it from EDW.cfg, everything works. Also, this problem only seems to occur when using the default graphics client; using the DX9 client, I don't have any problems.

Yes. I think the only change needed will be to add Edwards to the list of available landing sites in the AerojetDAP code. At some point we should start reading this from a config/mission file instead of hard coding the list of landing sites.

Everything looks good.

There aren't any problems with using the old VC mesh in Orbiter, so in that sense it is fine. I don't have a problem with replacing the VC mesh, but I don't think it's particularly urgent, and I certainly don't want to stop all other work on SSU until we update all the VC animation definitions...

The VC mesh visible in external views is different from the VC mesh used in internal views). The mesh visible in the picture above is SSU/Cockpit.msh. If the only problem is the external views, then let's leave the VC mesh alone and fix SSU/Cockpit.msh.

I'm in the process of creating a new branch for VC development and reverting to the old VC mesh in the trunk. Once that's done, you can create the MPS branch from the HEAD revision.

No. I don't want to delay development indefinitely until we fix every switch in the VC. The existing VC meshes are perfectly fine; we can continue with the current VC for the moment, and work on the new VC in a branch.

The new VC breaks most of the existing VC code/animations. We should either keep the original VC or move the new VC into a branch and gradually fix the VC and merge it into the trunk.

When creating the branch, I think the best thing would be to create a copy of the HEAD revision, then commit your new changes to the branch. You should be able to use TortoiseSVN->Switch to switch between the branch and trunk files. I forgot to delete the 2.1-newmesh branch, which is why it's...

That's definitely enough for a branch. Given the number of changes involved, we should probably keep the new MPS stuff out of the 2.1 release and include it in release after that. One thing that I'm not sure about is removing the '*' keyboard shortcut for shutting down the SSMEs. In real life...