Search results

I've checked in fixes for all the scenarios except for the ET white texture issues.

I'd prefer to restrict the SSU sources to stuff that we're developing, and leave external addons to be downloaded separately. As long as we make it clear that external addons are required, I'm not sure there's a real benefit to including them as part of SSU. ---------- Post added at 02:47 PM...

I'm using the 2013 files. They should be identical to the 2010 files, except for some settings changes needed to compile on VS 2013.

Both the Release and Debug configurations work for me (also using VS 2013).

What branch are you using? I haven't checked all the scenarios you listed, but at least some of them work for me (using either the default or Mesh-Rev1463 branches).

That explains a lot. What scenario is this? We should delete it if it's still in the SVN repository.

Let me ask again: have you actually tried using this version? I just downloaded and extracted it. The RMS works. Payload latching works. I don't know what you're talking about.

What's wrong with it?

Yes (Space Shuttle Ultra V2.0)

Have you tried the version I just linked to? The RMS VC is working. The Entry & TAEM DAP is implemented.

What's wrong with the version on Orbithangar (http://orbithangar.com/searchid.php?ID=6389)? Anyone who wants the latest, potentially buggy version, can checkout the source from SVN and compile it. Otherwise, just download the formal release and use that. ---------- Post added at 06:00 PM...

I don't think the installation procedure is a significant issue; we do have a public release, which be downloaded and extracted. I think the biggest problem might be the lack of documentation. If you just start one of the scenarios without the checklists in front of you, you'll have a hard time...

I've always wanted SSU to provide a detailed simulation of the actual shuttle systems. I think that's the main difference between SSU and Shuttle Fleet. So far, I think we've done a good job. If you don't like the current path, what would you like to see next? The last release of SSU was about...

What Urwumpe said. There are payloads, etc. that will be affected if the shuttle mesh dimensions are incorrect. If the mesh matches the real-life dimensions, we can easily follow the real-life documentation and checklists. If we have to add fudge factors to account for inaccuracies in the mesh...

David413 sent me a scan from the Space Shuttle Systems Handbook (Rev. E, dated April 1995) which has the aft tip of the vertical stabilizer at 1702 inches, which matches the value in the SCOM. Do you have any idea why there are 2 different values for the aft tip position? The only thing I can...

The only things I'd add are the Ku-band antenna and the OBSS/MPMs (this can be considered part of the RMS system).

The SSME animations (using the Rev. 1462 mesh) look fine to me. GLS: Look at the UpdateSSMEGimbalAnimations functions in Atlantis.cpp. Every time the SSMEs gimbal, the GOX vent positions are updated. ---------- Post added at 02:51 PM ---------- Previous post was at 12:20 PM ----------...

The MPS dump locations need to be fixed in the Mesh-Rev1463 branch. Apart from that, I think we're ready for a release using the old (Rev. 1462) mesh. I would also appreciate it if someone could look at the code changes in the Mesh-Rev1463 branch, and make sure that I haven't removed any other...

I've been using GDI/DirectX, but it still freezes if I use GDI Only. The freeze also occurs in both the VC and glass cockpit views. ---------- Post added at 11:17 AM ---------- Previous post was at 10:59 AM ---------- One other thing I noticed is that, even if the new font is never selected...

I though you said (in post #601) that changing meshes would affect scenarios, because attachment points on payloads, etc. would have to be tweaked. If the scenarios aren't affected by the mesh changes, then we can release a version using the Rev. 1462 mesh.