Not yet. Are there any objections if I upload the zip file (instead of linking to Sourceforge)? We had problems last time because of the file size, but the download is much smaller this time.
This Addon has been updated; please find the new version here
Space Shuttle Ultra is an atttempt to create a realistic simulation of the space shuttle.
Some highlights of the new version:
   All MEDS displays implemented in CRTMFD
   Tunnel Adapter Assembly included
   Improved ODS...
I've checked in a clone of the MECOTool util to the SSUWorkbench project. This is meant to be a proof of concept for what can be done with WPF; the MECOTool is defined as a user control, with a separate class to store the data displayed in the controls. The code for the calculations is copied...
I can try to take a look if you check the code in. In C#, I think creating a UserControl is the standard way for grouping controls together into a custom object.
I can reproduce the issue with the OMS/MPS display using the posted scenario.
The WT (weight) seems much too low, and as a result the burn time is much shorter than it should be. The attitude control code is working as expected, and the shuttle is in the correct attitude when the burn starts.
The SSRMS is basically a separate addon; the main reason it's in the SSU repo is because the SSRMS code uses some stuff from libUltra, in the SSU codebase. We shouldn't be including any SSRMS stuff in the SSU release.
A default RCS PRI RATE of 2.0 deg/s is way too high. Looking at the DAP tables for STS-134 (https://www.nasa.gov/centers/johnson/pdf/539927main_ORB_OPS_134_F_A_1.pdf), the PRI ROT RATE is usually 0.2 deg/s, or less, with the maximum value being 0.5 deg/s.
I strongly suspect that the DAP will have issues once we start using a realistic RCS. I think we should wait until after the release to start using realistic thruster positions.
I'd prefer C# to Java, mainly so we don't have to install the JDK (and so users don't need to install the JRE). I also prefer C# to Java as a language, although I don't have particularly strong feelings there. I haven't done much GUI programming in either C# or Java, so I'm not sure if there's a...
I actually prefer Mercurial over Git for that reason; TortoiseHG is really good, better than TortoiseSVN and anything I've seen for Git. I haven't tried Git in Visual Studio, though.
I can't speak for anyone else, but I'd prefer Mercurial to SVN.
---------- Post added at 10:10 PM ---------- Previous post was at 10:03 PM ----------
If you haven't used a DVCS (like Mercurial or Git), it works by having a local repository on your computer, as well as external repositories...
Me too.
Face has been maintaining a SSU repo on Bitbucket (https://bitbucket.org/face/ssu), although it doesn't seem to have been updated in a while. If we do want to dump Sourceforge, this might be the simplest option.
I tried using the SSRMS with UCGO installed, and I didn't have any problems, so it does seem like an issue on your end. The rotation angle is calculated from the SSRMS and target attachment points, so unless something is modifying the attachment points, I'm not sure what's going on.
Are there any UCGO vessels in the scenarios where you get rotation errors? I haven't had the time to investigate this, but I'm really surprised that UCGO is interfering with the SSRMS.
I finally got round to making these changes. I haven't added a section on the MEDS displays. I think the MEDS displays are close to the actual displays, so the NASA documentation should be mostly sufficient. If you want to write something, I can add it to the tex file.
---------- Post added at...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.