SSU Development Thread (2.0 to 3.0)

[Urwumpe]

I've been monitoring this thread since pre ver1.0, and one thing rings out in my mind, the team is chasing faults that are circular in nature... i.e. a mesh is faulty, that leads to a code segment change, that leads to more mesh faults, and so on.

Thats called development and is absolutely normal. Every development, may it be software, TV sets or spacecraft is developed in iterations. It is a learning process, since you find out the UNK-UNKs, find solutions for the UNKs, handle technical debt created along the way and also develop new better solutions than you had been able to imagine before you started the project.

For SSU to continue to work and improve, IMO, a functional code base, beta tested and released twice a year, would lead to a more full featured model.

Sorry - wrong. Not wrong, that it would be much better if we could go all the Continuous Delivery way that is now commonplace in software development (which could mean weekly releases in the best case).

The error is in the assumption that a) we are not having a functional code base already and b) just having a functional code base results in better releases.

The fact is: For the amount of work to be done and the amount of developers that we have available, we are progressing well and no, we are not repeating ourself and doing the same development work all the time. We are iteratively improving SSU.

Also, we could have had about 6 releases already since September. Bad releases. With lots of bugs and lots of complaints. Public beta testing is something that we should IMHO never do again in SSU, because instead of attributing the bugs to the early beta state, downloaders will attribute bugs to the quality of SSU in general. Orbiter is a poor place for public beta testing as I observe it.

If you want to test SSU already before any half-way stable release, you are free to make your own. The source code and the artwork of SSU is open source. If you want to help the project as official tester doing real software tests (instead of just playing around with something brand new), we can sure find a way to integrate you.

Remember, this is a freetime project. We can't do 30 day sprints like it would be possible for a full-time project. We don't even have all developers available all through the year.

 

[Donamy]

I've been monitoring this thread since pre ver1.0, and one thing rings out in my mind, the team is chasing faults that are circular in nature... i.e. a mesh is faulty, that leads to a code segment change, that leads to more mesh faults, and so on.

For SSU to continue to work and improve, IMO, a functional code base, beta tested and released twice a year, would lead to a more full featured model.

Then SSU can get it's needed visual version enhancements, and unfold into the beautiful butterfly from the cocoon of conflict it's currently experiencing. I would rather have a highly accurately working model, than a buggy-pretty model.

With so many great add-on builders working on the project, and patience from the beta testers, this project has only one direction, constant improvement, and that's 24-7 from what I read here.

Finally, great things are being achieved here, don't lose sight of the fact that this project is already leaps and bounds a far better product day by day, than all the add-ons for the program put together. And there are some great add-ons out there. Remember the roots of this feature, the program itself. All hail the probe, and high gratitude to Martin for making this all possible.

Keep up the great work. I'm a button pushing, switch flipping fool for SSU!

I think the next release will be a different animal. I think the team has a better understanding (at least I do) of what everyone wants, and not just what we want as individuals, for SSU. Sometimes the blow-ups are what's needed to bring that out. The good thing is, we have a much better mesh now. IMHO

---------- Post added at 05:46 PM ---------- Previous post was at 05:40 PM ----------

Where do we stand on getting the meshes done prior to release? There's some small issues with the orbiter and the External Airlock/ODS needs to be rescaled.

What texture does the ExtAL use ? I import it to AC3D, and load textures/SSU/Airlock.dds. But the mapping is not correct.

 

[DaveS]

I think the next release will be a different animal. I think the team has a better understanding (at least I do) of what everyone wants, and not just what we want as individuals, for SSU. Sometimes the blow-ups are what's needed to bring that out. The good thing is, we have a much better mesh now. IMHO

---------- Post added at 05:46 PM ---------- Previous post was at 05:40 PM ----------



What texture does the ExtAL use ? I import it to AC3D, and load textures/SSU/Airlock.dds. But the mapping is not correct.

It uses three textures:

SSU\SSUbay.dds
SSU\STScargobay.dds
SSU\Bridgerail.dds

 

[Donamy]

So Airlock.dds isn't even used ? Weird :shrug:

 

[DaveS]

So Airlock.dds isn't even used ? Weird :shrug:

I have no such texture. It seems like that was never checked in along with the mesh that uses it.

 

[Donamy]

I have no such texture. It seems like that was never checked in along with the mesh that uses it.

Maybe a left-over from 1.25

 

[DaveS]

Maybe a left-over from 1.25

Maybe. Could you post it here for examination?

 

[Donamy]

Maybe. Could you post it here for examination?

Here it is.

 

[DaveS]

Here it is.

Looking at it, it's a texture I definitely do not recognize. So I don't think we have ever had it.

 

[SiameseCat]

I just sent SC a new Orbiter mesh, that should have the known issues fixed, and all the bridgerails. I'll take a look at the AL.

This has been checked in. I'm working on adding mission file entries which will hide/show the appropriate bridge rails.

 

[DaveS]

This has been checked in. I'm working on adding mission file entries which will hide/show the appropriate bridge rails.

How will we deal with the actual PRLAs (passive/active)?

 

[Donamy]

I assume the way it is now. No ?

 

[Urwumpe]

I would say, no urgency right now.

What about ticket #59, is that a VC mesh issue?

 

[DaveS]

I would say, no urgency right now.

What about ticket #59, is that a VC mesh issue?

I would say so.

 

[Urwumpe]

I would say so.

Well, I don't know it yet, what has to be done there, because I just didn't pay enough attention there in the past. Will try writing the ticket more accurate, if it is a mesh issue. Ideally, the ticket should contain all the information necessary to fix the issue, like references or coordinates.

Can the ticket #63 be fixed by removing transparency from the push button covers and have a hole for seeing the current button state? Or making each two mesh groups, one transparent and one opaque?

 

[DaveS]

Can the ticket #63 be fixed by removing transparency from the push button covers and have a hole for seeing the current button state? Or making each two mesh groups, one transparent and one opaque?

Well, currently they are of the wrong appearance. They should be a metal/glass mix not the current all glass config we have now.

Good overviews can found here:
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-1.swf
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-2.swf
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-3.swf
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-4.swf
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-5.swf
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-6.swf
http://www.nasa.gov/externalflash/sts-rec-panoramics/OV-103-Crew-7.swf

All taken on the Flight Deck of Discovery during her retirement processing which is why some equipment are missing. The white boxes behind the CDR/PLT seats are KSC Operational Intercommunications System (OIS) boxes used for comms with the LCC. Normal comms using the orbiter RF systems are not used while in the OPF.

 

[Urwumpe]

I know, that is why I am asking... what is needed for making the appearance work correctly again and how should they look like, if any changes to the meshes are needed?

 

[DaveS]

I know, that is why I am asking... what is needed for making the appearance work correctly again and how should they look like, if any changes to the meshes are needed?

Yes, mesh changes are required. I can put together a photo package that shows the various panels.

---------- Post added at 09:20 PM ---------- Previous post was at 09:19 PM ----------

This is a composite image showing our R2 VS the real R2 layout:

 

[Donamy]

When did it change ? Because the older one was made from a real one.

 

[DaveS]

When did it change ? Because the older one was made from a real one.

You mean the real one? Not sure. It could be that yours and our current one was made from a photo of early Columbia's R2 panel. Her and Enterprise did have quite the number of differences to the later orbiters. This included the panels.