Space Shuttle Ultra development thread

[DaveS]

Wow thats good, are you going to add the soundpacks for STS-1 too, that will be great to have it.

Don't get too excited. Although STS-1 is planned, it is way, way wayx15 into the future.

Now just a friendly question: could you please stay out of this thread? This is for SSU dev stuff so it is important that it remains clean and free of off-topic stuff.

If you have any requests regarding SSU, post it in the SSU wishlist thread.

 

[Urwumpe]

Small tools

What about we add the "clutter" after reaching orbit in stages, so they don't appear all instantly? Writing a system which handles such objects would be no large problem, we just need a record to describe the current position and maybe a reference to another class to describe further behavior. Store this in a map or a vector, and we are go. Writing another software which describes where it is stored when not in use and which handles this inventory should be a simple task for any adventure fan.

I would really like to create a system to render low-quality CCTV streams and display them on the various CCTV displays. But I have absolutely no knowledge yet about how to do that, so we would go best with CameraMFD currently.

Scenario editor interface

Is somebody interested in tackling this task? We still don't have a custom interface there, and for managing the many propellant resources we have and other non-mission scenario data, we could really use this.

PGCS software

Does somebody have screen-shots or information of the RPOP software? Would be interesting to have this available during docking. The keyboard bindings in the checklists have some interesting functions.

 

[Donamy]

Here are the positions for the Aft flightdeck as they should be IMO. I'm sending you a new VC.msh that has the COAS in a better position.

MS1 Position:
x = 0.700000
y = 2.750000
z = 13.200000
Default direction:
x = 0.000000
y = 0.000000
z = 1.000000

================
COAS Position:
x = 0.400000
y = 3.150000
z = 12.600000
Default direction:
x = 0.000000
y = 0.453990
z = -0.891007
=================
RMS Position:
x = -0.400000
y = 3.150000
z = 12.500000
Default direction:
x = 0.000000
y = 0.000000
z = -1.000000
=================
port side
Position:
x = -0.600000
y = 2.950000
z = 13.000000
Default direction:
x = -1.000000
y = 0.000000
z = -0.000000
=================
Starboard side
Position:
x = 0.700000
y = 2.850000
z = 13.000000
Default direction:
x = 1.000000
y = 0.000000
z = -0.000000
=================
MS2 inverse
Position:
x = 0.000000
y = 2.950000
z = 13.200000
Default direction:
x = -0.000000
y = 0.000000
z = -1.000000

 

[ryan]

Don't get too excited. Although STS-1 is planned, it is way, way wayx15 into the future.

Now just a friendly question: could you please stay out of this thread? This is for SSU dev stuff so it is important that it remains clean and free of off-topic stuff.

If you have any requests regarding SSU, post it in the SSU wishlist thread.

Sorry.

 

[Mission_CDR]

Any idea when the next space shuttle ultra version will be out and what exactly will be in it?

 

[Donamy]

We don't really know exactly, it's under development.

 

[DaveS]

Donamy: I was playing around with the orbiter mesh in GMAX and I noticed something really wrong(or so does every photo and schematic tell me) with the mid-body and payload bay.

It is that it seems to have different width/height at the ends of it. The aft end is higher and wider than the forward end.

Every photo and schematic I have shows that the mid-body doesn't change in height/width between the forward end and the aft end.

Could you take a look at this and if possible, fix it.

BTW, could you maybe in the process make a new higher res texture for the payload bay radiator panels and make the left radiator panels different from the right payload bay radiator panels?

Attached to this post is a set of drawings from an NTRS document on the payload bay doors and radiator panels. I also threw in a schematic of the payload bay door centerline latches for good measure.

 

[Donamy]

I'll take a look.

I'm still getting, the KU swapping textures, with the RMS when I get close, and pan the view, anyone else ? Also, I have the orbiter name on half the the wing ,in big letters.

 

[Urwumpe]

it would be cool if we could animate the door latches, many of them are visible and it would be a good thing to be able to control the deployment process with the latches that way. I think i reality the astronauts also look out of the aft windows and CCTV cameras to control the indications of the OPS 202 "SM PL BAY DOORS".


BTW: Anybody having a problem with me implementing the SM OPS? I should have another area of work, but until then...

 

[Donamy]

I can beef up the doors and put some latches on them, but animated ? I doubt it. Why on Earth would you need that much detail ? Heck, we don't have working startrackers yet. And the launch sequence needs to be made right. Why don't we get what's already been done, working as it should, first?

 

[Urwumpe]

You mean animated star tracker doors? We don't even have Panel O6 for initiating this. I could do a dialog for that, but the VC panel would be nicer.

Also If I remember correctly, the launch sequence should be working now, with at least the forward MDUs working.

The latches would be good because they are visible - you can say, the only reason is, that it is possible. It is not really too important, but why not have it? At least later?

 

[Donamy]

I was refering more to the graphics sequence of the launch. A couple things that are needed.

1. It would be nice if the stack would bend before launch, and stack to translate toward the tank slightly at lift-off.

2. SRB flame trench smoke (the MLP steam is awesome)

3. Roll program start at 10 sec, without the SSME flame wiggle.

4. SRB flame and smoke continue after sep

 

[DaveS]

I was refering more to the graphics sequence of the launch. A couple things that are needed.

1. It would be nice if the stack would bend before launch, and stack to translate toward the tank slightly at lift-off.

2. SRB flame trench smoke (the MLP steam is awesome)

3. Roll program start at 10 sec, without the SSME flame wiggle.

4. SRB flame and smoke continue after sep

1: Hmm, going to be difficult to do as the the shuttle is attached to the MLP and no motion of the child(shuttle) is allowed when it is attached to the parent(MLP).

2: Will have to wait until I'm done with the hardstand. Still quite a few elements missing.

3: Maybe one for SiameseCat as he was the one who coded the launch AP? I believe along with this one, the tendency to pitch down in manual mode should be fixed.

4: Agreed. Right now the slag particles comes on waay to early.

 

[DaveS]

BTW, Donamy: have you had a chance to take a look on the mis-shaped orbiter mod-body yet?

 

[Urwumpe]

I was refering more to the graphics sequence of the launch. A couple things that are needed.

1. It would be nice if the stack would bend before launch, and stack to translate toward the tank slightly at lift-off.

2. SRB flame trench smoke (the MLP steam is awesome)

3. Roll program start at 10 sec, without the SSME flame wiggle.

4. SRB flame and smoke continue after sep

1. I am also not sure it can be done. Maybe we can manipulate the child attachment for this, but I am not convinced.

2. Is just a copy and past job with new coordinates for the SRB holes. But I am not yet happy with it, but as long as we have only a prototype, it can stay like that... I also want to visualize the many water spray nozzles around the fire holes as particle streams, when activated, so people see what happens.

3. Earlier start of the roll program can be done sure, but the wiggle will take lots of engineering work - we need to fine tune the autopilot parameters better, so they don't overcompensate. This is a hard job for NASA engineers - and not simpler for us.

4. My fault. I have still not worked on saving a bit more propellant in the final seconds of operation. But at least the total impulse of the SRBs is right on the mark, we have only very tiny errors (<20 m/s) now from the statistical data.

 

[Donamy]

1. I am also not sure it can be done. Maybe we can manipulate the child attachment for this, but I am not convinced.

2. Is just a copy and past job with new coordinates for the SRB holes. But I am not yet happy with it, but as long as we have only a prototype, it can stay like that... I also want to visualize the many water spray nozzles around the fire holes as particle streams, when activated, so people see what happens.

3. Earlier start of the roll program can be done sure, but the wiggle will take lots of engineering work - we need to fine tune the autopilot parameters better, so they don't overcompensate. This is a hard job for NASA engineers - and not simpler for us.

4. My fault. I have still not worked on saving a bit more propellant in the final seconds of operation. But at least the total impulse of the SRBs is right on the mark, we have only very tiny errors (<20 m/s) now from the statistical data.

1. You can't move a grapple point like spacecraft3 does?

2. Alot of small fixes will add up, the more features that are added. I would like see a new version out by May 1st.

3.If it's that hard, just ignore the animations for the gimbal for the first 20 sec.

4.That's cool !!


DaveS,
Can you give me a diagram with what you mean?

 

[Urwumpe]

1. You can't move a grapple point like spacecraft3 does?

2. Alot of small fixes will add up, the more features that are added. I would like see a new version out by May 1st.

3.If it's that hard, just ignore the animations for the gimbal for the first 20 sec.

4.That's cool !!

1. I am not sure if defining the orientation of the child attachment point has any effects. Have never tested it.

2. May 1st is a holiday here, would be in theory a good day for working on the Shuttle...

3. That would mean we ignore the problem. Also at the end of the 20 seconds, we would get the next jump. It would be better we correct the SSME gimbal movement correctly for the first stage - the SRBs dominate and the SSMEs just do load relief.

4. If you think that is cool, have a look at the next DLL I can send you. Included the new mesh and the new VC positions - including using annotations for showing for 5 seconds WHERE you are now. Have to fix some positions as they have bad orientations or positions.

 

[DaveS]

DaveS,
Can you give me a diagram with what you mean?

Of the mesh error? Sure. It's attached to this post.

It's a wire-frame view of the door rollers attached to the forward and aft payload bay bulkheads. Notice how the door rollers doesn't line up with each other? If you extend the door rollers, they will appear sloped in a side view and angled in a top view.

 

[Donamy]

Of the mesh error? Sure. It's attached to this post.

It's a wire-frame view of the door rollers attached to the forward and aft payload bay bulkheads. Notice how the door rollers doesn't line up with each other? If you extend the door rollers, they will appear sloped in a side view and angled in a top view.

You do realize the doors are shaped differently forward and aft ? Otherwise, I'm not getting what you mean.

edit: Slight bug found, the Endeffector does not stow with rest of RMS.

 

[SiameseCat]

Regarding the launch, I can recode the first stage gimballing to keep the SSMEs fixed and only use the SRBs. I thought I'd already fixed the pitch-down problem, but that was during the resizing and the code might have been messed up. I'll have a look at it.
EDIT: I found the problem with the pitch-down. I'll check the corrected code in.
EDIT2: Code checked-in.