SSU V1.25 Release

Status
Not open for further replies.
Not to sound hasty, but how near to release are we, considering the target was for the begining of November, and here in the States (and Texas, more specifically) it is almost December!:cheers:
 
As soon as we are confident, that it meets some minimal quality standards. We are all aware of the expectations of the community, and it would be pretty damaging, if we release something, that does not work as expected.

If you want to use it, with all bugs and flaws, you need to overcome safeguards: Install compiler, subversion client, checkout, building.

It is sure worth trying. But if you don't think so, you'll need to have patience with us.
 
Could we get a priority for the OBSS attatch and release on the MPMs, then we could at least use SC3 for the rest of the payloads. Or is this above our payscale right now ?
 
Could we get a priority for the OBSS attatch and release on the MPMs, then we could at least use SC3 for the rest of the payloads. Or is this above our payscale right now ?

I don't know if I can do this before the third january, if nobody claims this task item first, I will implement it this weekend, would be a good thing to get started with SSU after the break.
 
That would be great.
 
Any estimates on bug fix timelines ? I think we are close to release. What does everyone else think ?
 
Any estimates on bug fix timelines ? I think we are close to release. What does everyone else think ?

I agree. I think I will have the numeric errors in the SRB thrust function sorted out today, it took a while until I found the spreadsheet I used for modelling it.
 
I agree. I think I will have the numeric errors in the SRB thrust function sorted out today, it took a while until I found the spreadsheet I used for modelling it.
Guess once you're done with those, you'll focus on the BSMs to fix the SRB separation behaviour?
 
Guess once you're done with those, you'll focus on the BSMs to fix the SRB separation behaviour?

Yes, but I don't think the problem in this case is the BSM behavior. We currently don't use accurate BSM positions possibly, but I think the wrong rotation is actually caused by the aerodynamics.
 
Yes, but I don't think the problem in this case is the BSM behavior. We currently don't use accurate BSM positions possibly, but I think the wrong rotation is actually caused by the aerodynamics.
OK. Currently there's no rotation at all of the boosters and the BSMs seems to have no effect.
 
OK. Currently there's no rotation at all of the boosters and the BSMs seems to have no effect.

The BSMs have a lot of effect - we just don't have a initial speed difference to the ET when the booster vessels are created. Most difference to the shuttle stack comes from the BSMs, the rest are aerodynamics and the little acceleration by the SSMEs.

If you can get me the accurate BSM positions and orientations, I can implement these more detailed. If the positions and thrust profile of them is correct, all we can do wrong is aerodynamics.
 
Aft BSMs:
-1.724, -13.018, -7.058, vectors: 0, 0.999, -0.032

FWD BSMs:
-0.951, 26.861, -6.07, vectors: -0.609, 0.089, -0.787
 
That is roughly what we already have... but one of the BSMs aft is pointing in a slightly different direction, this aspect is not yet modeled.
 
Urwumpe: I'll start work on the OBSS stuff, since you're currently working on the launch bugfixes.
 
Urwumpe: I'll start work on the OBSS stuff, since you're currently working on the launch bugfixes.

Fine for me, I'll concentrate on the SRBs for the next days.


-----Post Added-----


SRB thrust profile is now fixed a bit, but I would like somebody verify if the performance of the SRBs until separation is now still good enough, I think we lost about 30-50 m/s by the fixes as we now longer burn the SRBs completely empty, but more important are the real flight velocities, and I think we are still roughly in the correct range... would be nice if somebody can verify the performance before we release 1.25.

Another one I noticed, goes to all developers: Please check that all textures, you paint on during run-time are marked dynamic (D behind the texture in the mesh file). I fixed a few to improve the biggest bottlenecks, but I likely missed a few.

I recommend we add a "dynamic textures.txt" to the development docs, where we remember these textures.
 
I've got to go out for a few a hours, but I'd be happy to test it out when I get back.
 
Compiled and tested the new SRB thrust profile, didn't not any changes if there was supposed to be any visual ones.

The slag effect still comes on too early.
 
Compiled and tested the new SRB thrust profile, didn't not any changes if there was supposed to be any visual ones.

The slag effect still comes on too early.

Strange, I had continuous flames, but I also had bad frame rates in the test
 
Status
Not open for further replies.
Back
Top