Search results

Can you post a bit more information on what exactly is being changed? If you've already made all the changes required (and everything works) and the only thing left is to fix the positions to work with the new mesh, you may as well go ahead and check everything in, and DaveS can update the...

You should take a look at the shuttle rendezvous checklists and the Data Processing System Dictionary to see how the SPEC 34 displays are used. They can be downloaded from http://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html. The SPEC 34 display is used to target rendezvous burns...

The inline client is the default client used by Orbiter, and I don't want to force people to use an external graphics client so SSU works. Also, if the mesh doesn't work in the inline client, that indicates that there might be a problem somewhere with the mesh, so there might also be problems...

I'm working on fixing the ODS C/L camera and related issues (the docking port/attachment positions also need to be corrected). Once that's done, I'll merge the newmesh branch with the trunk.

The mesh issues have now been fixed.

It needs to be fixed before release, so I would consider this fairly high priority. I don't want to force people to use the DX9 client to run SSU.

There seem to be some issues with the new mesh using the default Orbiter graphics client (everything looks fine using the DX9 client):

There seem to be some issues with the new mesh.

I think all the changes needed for the new meshes have been made, and we can merge the 2.1-newmesh branch back into the trunk now. Is there anything left to do before we close the mesh branch?

The RMS elbow camera should be fixed now.

I'll take a look at this.

I think the RMS is one of the more complete parts of SSU at the moment. I know we don't have automated trajectories yet, but I don't think its a big deal to move the arm manually.

Checked in a fixed version of the elevon animation code.

Trying to replicate state by saving/loading a scenario file won't work with SSU. Among other possible issues, the GPC state isn't fully saved during launch and OMS burns, so these won't be handled correctly when the saved scenario is loaded in another Orbitersim instance.

I don't think this is a problem. clbkLoadStateEx loads the state from a scenario file during initialization. In the code you've attached, clbkLoadStateEx is called during the simulation, after initialization. This is not the time at which clbkLoadStateEx should be called, and it's not a problem...

That's a relief. I was starting to think if something had gotten really messed up on one of our computers. ---------- Post added 12-29-13 at 11:57 AM ---------- Previous post was 12-28-13 at 06:15 PM ---------- Is there any news regarding the elevon animations?

Can you try the latest revision? I fixed a bug in the ET umbilical door animation code, although I'm not sure if it's behind the animation issues.

Using this dll, the ET umbilical doors open without any issues. Can you post exactly what scenario you're using and what steps are required for the animation issues to appear? I've been testing the animations using Testing scenarios/Atlantis in orbit.scn and by opening and closing the ET...

Can someone else take a look at the ET umbilical door animations and see what's going on? Also, DaveS, can you post the SpaceShuttleUltra.dll you get after compiling the latest revision?

That's the same code I have. I've attached a compiled version of the latest revision (rev. 1576); see if this works on your computer.