Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

So the URL to use in the TortoiseSVN relocation dialog is https://svn.code.sf.net/p/shuttleultra/trunk/ ?

You should be using

svn+ssh://[email protected]/p/shuttleultra/code/trunk (replace USERNAME with your sourceforge username).

The URL you posted (https://) supposedly has corruption issues, so using svn+ssh:// would be safer.

 

[DaveS]

You should be using

svn+ssh://[email protected]/p/shuttleultra/code/trunk (replace USERNAME with your sourceforge username).

The URL you posted (https://) supposedly has corruption issues, so using svn+ssh:// would be safer.

Getting this error message:
"svn+ssh://[email protected]/p/shuttleultra/code/trunk is not the root of the repository"

 

[SiameseCat]

Getting this error message:
"svn+ssh://[email protected]/p/shuttleultra/code/trunk is not the root of the repository"

Try

svn+ssh://[email protected]/p/shuttleultra/code

 

[DaveS]

Try

svn+ssh://[email protected]/p/shuttleultra/code

That worked, thanks. The new SSUbay.dds have been checked in and here's a screenshot of the new PLB texture:

 

[SiameseCat]

It's done and ready for implementation. There's only one thing that needs to be done code-wise: Varying the LIFETIME parameter with pressure to create the longer lasting exhaust trails from the yaw jets. You can see in this video from STS-33:

STS-33 Launch and Landing - YouTube

Varying the LIFETIME parameter doesn't seem to work. I suspect Orbiter saves the LIFETIME value when the particle stream is created, and it can't be modified (without destroying & recreating the stream) after that.

 

[DaveS]

Varying the LIFETIME parameter doesn't seem to work. I suspect Orbiter saves the LIFETIME value when the particle stream is created, and it can't be modified (without destroying & recreating the stream) after that.

Well, there goes that idea. Maybe using a different but similar stream based on altitude instead? Deleting the old one and then using one with a longer lifetime?

 

[SiameseCat]

In the video you posted, are you sure the clouds are due to the yaw jets? Just after they appear, the PAO says that the shuttle is at M0.9, while the yaw jets are turned off at M1.0.

Also, I'm not sure how realistic it is to have particle streams at all in orbit. In this video, it looks more like the basic RCS texture.

 

[DaveS]

In the video you posted, are you sure the clouds are due to the yaw jets? Just after they appear, the PAO says that the shuttle is at M0.9, while the yaw jets are turned off at M1.0.

Also, I'm not sure how realistic it is to have particle streams at all in orbit. In this video, it looks more like the basic RCS texture.

Check this video: http://www.youtube.com/watch?feature=player_detailpage&v=adatQ59j6sc#t=2679s

 

[Poscik]

I also have problem with repository relocation. Doing right click -> relocate, entering new address svn+ssh://[email protected]/p/shuttleultra/code and here is what I'm receiving:

 

[SiameseCat]

I also have problem with repository relocation. Doing right click -> relocate, entering new address svn+ssh://[email protected]/p/shuttleultra/code and here is what I'm receiving:

You'll have to do a new checkout. The sourceforge update created a completely new repository, which is why you're getting an error. The relocate command only lets you use a different URL pointing to the same repository (which is why it worked for DaveS; he had alreday updated his repository and just needed to change URLs).

---------- Post added at 08:24 PM ---------- Previous post was at 06:17 PM ----------

Here's some particle stream settings that Loru and I have been working on to make the orbiter RCS exhaust look more realistic:

NAME=reaction
SRCSIZE=0.05
SRCRATE=480
V0=100
SRCSPREAD=0
LIFETIME=0.075
GROWTHRATE=40;60
ATMSLOWDOWN=0.1
LTYPE=EMISSIVE
LEVELMAP=LVL_FLAT
lmin=0.5
atmsmap=ATM_FLAT
amin=0.5
TEX=ps-rcs2

I have attached the texture that these settings make use of: ps-rcs2.dds

---------- Post added 07-31-12 at 12:00 AM ---------- Previous post was 07-30-12 at 12:04 AM ----------

How is everything else coming along? The RSS is coming nicely, with the drive trucks now done along with the twin rails on which the drive trucks moves on.

I was playing with the parameters a bit, and came up with this:

srcsize=0.001;                        
srcrate=50;                           
v0=20;                                
srcspread=0;                          
lifetime=0.50;                        
growthrate=5;                         
atmslowdown=0.5;                      
ltype=PARTICLESTREAMSPEC::EMISSIVE;   
levelmap=PARTICLESTREAMSPEC::LVL_FLAT;
lmin=0.25;                            
atmsmap=PARTICLESTREAMSPEC::ATM_FLAT; 
amin=0.25;

It looks better during entry, although the particle stream might be a bit too long for on-orbit burns. I'm still not sure if the particle stream needs to be so visible during entry, though.

 

[DaveS]

It looks better during entry, although the particle stream might be a bit too long for on-orbit burns. I'm still not sure if the particle stream needs to be so visible during entry, though.

One thing that these parameters take away is speed of the exhaust on-orbit. The exhaust really shoots away from the nozzles on-orbit as there's no real atmosphere to slow it down. That's what creates the contrail appearance of the exhaust during hypersonic flight. The atmosphere acts like a concrete wall seriously slowing the exhaust making it appear behind the orbiter.

 

[SiameseCat]

Checked in the exhaust particle stream code. The particle stream doesn't change during entry.

 

[SiameseCat]

Uploaded a new set of precompiled dlls to Sourceforge.

---------- Post added 08-12-12 at 03:21 PM ---------- Previous post was 08-11-12 at 10:16 PM ----------

Does anyone know if the velocity at which the Roll To Heads Up is performed changed between flights? SSU allows this velocity to be specified, but the only documentation I've seen (in the Intact Ascent Aborts Workbook) implies that this occurs at a fixed velocity of of 12,200 fps.

 

[DaveS]

Uploaded a new set of precompiled dlls to Sourceforge.

---------- Post added 08-12-12 at 03:21 PM ---------- Previous post was 08-11-12 at 10:16 PM ----------

Does anyone know if the velocity at which the Roll To Heads Up is performed changed between flights? SSU allows this velocity to be specified, but the only documentation I've seen (in the Intact Ascent Aborts Workbook) implies that this occurs at a fixed velocity of of 12,200 fps.

I'm pretty sure this is fixed.

 

[SiameseCat]

I'll change the mission file stuff so the Roll To Heads Up is just a boolean value, then. It should be possible to maintain backwards compatibility with old mission files.

 

[DaveS]

Here's two very interesting documents on entry and approach, landing and rollout:

Entry light Proceduies Handbook

Approach, Landing and Rollout Flight Procedures Handbook

 

[SiameseCat]

I'm thinking about changing how mission files and scenario files are handled in the SSU code. None of this should affect the actual scn/mission files, just the C++ code.

At the moment, most of the possible entries in the mission file (RMS, ascent autopilot, etc.) can have duplicates in the scenario file, which are used if a mission file is not specified. As a result, the code is a bit of mess, with a lot of duplication. I was thinking of passing any unrecognised lines from the scenario file to the Mission file class. Then we could always use the Mission class to handle these values.

Are there any problems with this idea that I've missed?

 

[Urwumpe]

I think the duplicates are for backwards compatibility. the idea was to move all mission specific constants into the mission file and store only the vessel status variables into the scenario file. The configuration file of the Orbiter should only contain orbiter constants.

 

[SiameseCat]

Do you think it's alright to just get rid of the backwards compatibility then?

 

[Urwumpe]

Do you think it's alright to just get rid of the backwards compatibility then?

Good riddance to it, let the scenario maintainers have some work. :lol:

While I am out of C++ development in the SSU project scale... what about making an SSU mission file editor in Java?