Space Shuttle Ultra 1.25 Revision B development

New version of the pad code fixed the problem; the Crawler is now on top of the pad.

---------- Post added at 11:42 PM ---------- Previous post was at 10:35 PM ----------

I changed the position of where the ramp start and ends, which seems to fix the problem for me. If you want to adjust the positions slightly, you can change the LC39_RAMP_START/END variables.
 
@SUBSYSTEM OMSBurnSoftware always causing CTD for me when loading scenario. I have to remove this from file, and then everything load properly. Anyone can reproduce?
 
I haven't had this problem, but I think it should be fixed now. The problem was that data was being saved when it wasn't needed.
 
New version of the pad code fixed the problem; the Crawler is now on top of the pad.

---------- Post added at 11:42 PM ---------- Previous post was at 10:35 PM ----------

I changed the position of where the ramp start and ends, which seems to fix the problem for me. If you want to adjust the positions slightly, you can change the LC39_RAMP_START/END variables.
I checked in tweaked versions of those variables in Crawler.h. It fixes the pad ramp ascent/dscent issues.
 
Could someone change the T- clock in SSULCC to have a more proper hh:mm:ss format? Also change RSLS hold point for APU/Hyd not on check from the current T-31 secs, to the more correct T-4 mins?
 
I just noticed the three new parameters for the SSU_Tank vessel. Are they active?
 
Which parameters are you talking about? The SLWT/LWT/SWT parameters should work (I've already checked in config files for the different tank types).
 
Which parameters are you talking about? The SLWT/LWT/SWT parameters should work (I've already checked in config files for the different tank types).
The three scenario file parameters: BURNT_TEX, ET_TEX_NAME and EMPTY_MASS.
 
Which line(s) in the Crawler code calculates the value displayed on the Average Height gage? According to my information, the value is calculated A+B+C+D/4.
 
The three scenario file parameters: BURNT_TEX, ET_TEX_NAME and EMPTY_MASS.
These should all be working now (although I haven't tested them).
The T;4:05 APU check has also been implemented.

---------- Post added 06-07-11 at 09:25 PM ---------- Previous post was 06-06-11 at 11:30 PM ----------

Which line(s) in the Crawler code calculates the value displayed on the Average Height gage? According to my information, the value is calculated A+B+C+D/4.
At the moment, the Crawler displays the height of the front corners; I'll update it to average the heights.
 
Are the updated .dlls available yet ?
 
Are the updated .dlls available yet ?

Too available - I had seen SSU Module packs on freeware aggregator websites.

But no recent modules yet. If you need some internally for your testing, I can do some quickly, but a nightly release would better be done by somebody who can test the new modules properly.

I just had the preliminary climax of the week with a pretty good job interview, maybe I am now one step closer to get a proper machine for further SSU development.
 
I have checked in some new Crawler stuff, mainly related to new more accurate drive truck meshes.

Currently the new drive truck meshes lack the actual belts, I just wanted to get the main mesh done. One change is that I moved the A-frame from the main body mesh to the drive truck mesh, as it is welded to the drive truck and the only thing that's supposed to be animated is the cylinders.

---------- Post added 06-11-11 at 01:34 PM ---------- Previous post was 06-10-11 at 09:01 PM ----------

Donamy: Do you think you could make a RCS exhaust texture texture that looks like the one seen in this screengrab from STS-133?

ARCS_jets_exhaust.jpg
Here's another, showing the full exhaust profile, thanks ti garyw:
vlcsnap-2011-06-11-12h20m35s128.png
 
I'll do a small poster with the current work items in SSU tomorrow, initially as RFC, so we later have a map with the work that has to be done, and all the things we need to do. Thought some visualization of the project can't be bad. Maybe we can even draw a goal line, what we need to finish for the next release and work towards it.


Also: Anybody skilled in C#? Since I possibly need to learn C# quickly in the next weeks, I thought this would maybe be a good fix for the MFC and Visual Studio Express problems we have. For example the MECOTool could then finally be replaced by a proper mission editor written in C#. And we would open the gates for more developers.
 
I know C#, and I could work on coding the mission editor in C#. I won't have much time to work on SSU for a couple of weeks, though.
 
I know C#, and I could work on coding the mission editor in C#. I won't have much time to work on SSU for a couple of weeks, though.

I currently have just 2 hours per week for SSU, not really much, but I have the hope that I not only can get to 8 hours per week, but also can have the funds for a proper machine in a few months, so I could resume developing the main game parts again.

Currently I try to get the project better organized here, which in our context means: Somebody should do the project management for the rest of the team, because I doubt anybody would like to see his hobby project dominated by project management. So, lets find a way to have the project management happen silently in the background. I am not really sure how silently I can do that, but I am not really known to be a friend of the "I am your project manager, be prepared to get managed by me" style. Maybe it is enough if I just keep track of the developments and can give you a good answer on the project situation if asked.

And since I am currently no real help in coding, I am really badly marked for this task.
 
Getting a bunch of errors when compiling the Atlantis project. Most of them in GPC_old.cpp. Seems like it is complaining about ReqdRates and .data. Also some in Atlantis.cpp, TRKROT_OPTION, REQD_ATT and .data.
 
Back
Top