Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

Just to post my opinion on the priority of this: It can wait a while. It's not that urgent given the determination that the VC isn't affected.

Then lets just shove it into the next major release. Since the GFX department is idling so much, what about already starting the development of the next release as branch and putting the new graphics already there (including animation fixes), while putting priority into making the trunk bug-free?

From my side, I currently only have two important things to finish before getting into a feature freeze:

• RMS camera singularity fix
• VAB animations and processing

I would also like to include a self-testing module into SSU before release, so we can have automatic tests of the subsystems and modules. Nothing too fancy, but I would say we should get a one-track mind here and get something done that, while lacking features, is working properly. Our quality standards are getting North-Korean, if this keeps on going on, the next release will be my last here, I have not that much coding time now and can imagine better things than getting depressed about the code, which should be better than closed-source development, not much much worse.

My DPS branch is not anything near the quality that I would like to show (It is a terrible, slow mess). Should not yet get merged into the trunk or the next release branch.

From what I have read, we have the aerodynamics getting some fixes, this should also be included in the next release. Anything else that is close to completion and can be included?

 

[Donamy]

How about SSME stowing ??

 

[Urwumpe]

How about SSME stowing ??

My opinion on that depends on the effort and the effect on the timing. If it is a major changes, with major problems coming around, I don't think I would appreciate the feature that much that I want it at all costs now. If it is just a weekend job of an available coder (OK, good joke), so it is ready when we start testing the full add-on for release, I wouldn't complain.

Just remember: New features need coding time, will introduce new bugs and will require as result testing time. We have already one Pluto year of source code documentation that was not done.

And as you sure notice as well: Things are slowly getting as viscous as tar here. I am pretty sure that I am not the only one, who is getting more and more confused by the source code - and I had been guilty of the crime as well.

 

[SiameseCat]

I should be able to get the aerodynamic fixes done (most of them, at least) before the next release.

There might actually be quite a bit to work on for the mesh resize; apart from fixing animations, we'll probably have to adjust attachment points and mesh offsets. It might take a bit of time to track down everything that needs to be changed.

 

[Urwumpe]

I should be able to get the aerodynamic fixes done (most of them, at least) before the next release.

There might actually be quite a bit to work on for the mesh resize; apart from fixing animations, we'll probably have to adjust attachment points and mesh offsets. It might take a bit of time to track down everything that needs to be changed.

Would be nicer if we could get the data from the modelling tool and just parse data files for the animations... but well, you can't have it all.

The new Orbiter Dynamics Update sounds also like a major task for SSU, getting the envelopes defined properly, but luckily, we could release at least one new version for 2010P1 before it is released.

 

[Goth]

Is there something I can download, even if in alpha state?

 

[DaveS]

Is there something I can download, even if in alpha state?

Here: http://www.orbiter-forum.com/showthread.php?t=24900

 

[DaveS]

I hope it is not too interrupting by me if I ask for a status update?

 

[Urwumpe]

Here? SNAFU.

Really need badly a computer update, I suspect 80% of the SSU crashes I get during testing is caused by lack of virtual memory.

 

[SiameseCat]

I've been working on the horizontal aerodynamics upgrade and PEG4 burn targeting (used for the OMS-1/2 and deorbit burns).

 

[DaveS]

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.

 

[SiameseCat]

I'm hoping to check in the horizontal aero changes soon. The aero code has been done for a while now, but I've had to rewrite a lot of the AerojetDAP to prevent the shuttle from spinning out of control.

Do you want me to add the new RCS particle stream to the dll, or is it still a work in progress?

 

[DaveS]

Do you want me to add the new RCS particle stream to the dll, or is it still a work in progress?

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:

 

[SiameseCat]

I'm hoping to check in the horizontal aero changes soon. The aero code has been done for a while now, but I've had to rewrite a lot of the AerojetDAP to prevent the shuttle from spinning out of control.

Do you want me to add the new RCS particle stream to the dll, or is it still a work in progress?

Checked the new aerodynamics code in.

 

[DaveS]

I'm having some problem checking in a new SSUbay.dds. I had to do a new checkout when Sourceforge changed and since then I can't check in anything. Any help here would be great.

 

[Urwumpe]

I'm having some problem checking in a new SSUbay.dds. I had to do a new checkout when Sourceforge changed and since then I can't check in anything. Any help here would be great.

Did you already change the repository URL on your computer? The URL to the SVN repository changed with the sourceforge upgrade.

 

[SiameseCat]

I'm having some problem checking in a new SSUbay.dds. I had to do a new checkout when Sourceforge changed and since then I can't check in anything. Any help here would be great.

What SVN URL are you using? The svn:// URL only gives you read only access, which might be why you can't check anything in. You should be using

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

If you need to change the URL, I think you can use the Relocate option instead of doing a completely new checkout.

The sourceforge SVN access documentation is at http://sourceforge.net/p/forge/documentation/svn - Beta/

 

[DaveS]

Did you already change the repository URL on your computer? The URL to the SVN repository changed with the sourceforge upgrade.

Yes, at least I think so. This is the correct URL http://svn.code.sf.net/p/shuttleultra/code/trunk right?

 

[SiameseCat]

Yes, at least I think so. This is the correct URL http://svn.code.sf.net/p/shuttleultra/code/trunk right?

That only gives you read-only access. See my post above.

 

[DaveS]

That only gives you read-only access. See my post above.

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