SSU Development Thread (2.0 to 3.0)

[DaveS]

I posted a Galileo probe a couple of months ago that I put on your original Centaur it worked fine, but I don't know what you mean by the wrong shader for SSU ? Mine is fully animated and a bit more accurate than the other ones in OH it also has deployable probe with heat shield and top cover

The shade GLS is talking about is the large disc-shaped sun-shade that covers the instruments just below the Hi-Gain Antenna (HGA). Originally that was not in the design. It was added after cancellation of the Shuttle/Centaur program in June 1986. The first VEEGA (Venus-Earth-Earth Gravity Assist) changes including the sun-shade were logged in Feb. 88.

The sun-shade was for protecting the sensitive instruments against the high temperatures that spacecraft would encounter at Venus. With the direct trajectory that the Centaur would have provided, no Venus GA would have been necessary. Another change was the delayed deployment of the HGA to until after the Venus GA instead of shortly after separation from the Centaur.

 

[GLS]

It's just like DaveS said. Here's 2 images showing the "original version" and the "flown version", where the shade (or whatever it's called) is very noticeable.

The flown version image is missing another shade from the top of the HGA, that would shade it.

 

[Wolf]

The Scrub Simulation Unit. It allows you to renact the emotional terror of the Space Shuttle Program.

Guys I have the (bad) feeling something is hiding behind your sarcasm...
Tell me you did not give up:nono:

 

[Urwumpe]

Guys I have the (bad) feeling something is hiding behind your sarcasm...
Tell me you did not give up:nono:

No, giving up inches from the finish line is no option, at least for me.

But the real life is really a big annoyance for such projects, like always. We are already seeing the release in front of us, but somehow, we can't yet just simply press to release and get it done.

I would sure love to do a lot of things different in the future, but I know my real-life, I have a really bad negotiation position there.

 

[DaveS]

No, giving up inches from the finish line is no option, at least for me.

But the real life is really a big annoyance for such projects, like always. We are already seeing the release in front of us, but somehow, we can't yet just simply press to release and get it done.

I think it might have something to do with the experience of the previous release (v1.25). It was really a bad experience, fraught with mistakes. Not only that, I think that as things get more complex with the introduction of more systems, more detailed simulation of the systems we already have, we're going to get flooded with questions like "how do I do this, how do I take off?". This is just going to steal time from genuine bug fixing and development.

This is just my opinion on why we're not doing public releases.

 

[BenSisko]

Perhaps the release of v1.25 was a headache for you as developers but it wasn't a bad experience for the Orbiteers who used it. It's level of immersion was great :thumbup::thumbup: That's why we're anxious for SSU's rollout.

 

[Urwumpe]

Perhaps the release of v1.25 was a headache for you as developers but it wasn't a bad experience for the Orbiteers who used it. It's level of immersion was great :thumbup::thumbup: That's why we're anxious for SSU's rollout.

Thats not just you, its also the same feeling in the development team.

But as DaveS said - we don't want to annoy you with too many bugs (A bug free release will be unthinkable), and we still want to make sure that the release was worth waiting for by adding some features.

But for the next release, there should also be some tighter control on what the core development team does and what should be kept out of the release for keeping the process controllable. We don't gain much by doing everything at once. Also, I would like to see things like a requirement definition workshop and task planning be done in advance again.

 

[-Pv-]

Requirements documentation rocks.
"Requires" someone on the team being trusted enough to have final say what goes in it after discussion.

If, after the requirements are locked down, and there are requirements no one on the team volunteers for, then it's a sign the requirement list is flawed or too long and there needs to be another brain drain meeting. Never be concerned a requirements list will be too short. I've never seen that happen.

It's never too late to draw up a requirement doc. Start with what's done, add what's not done (but being actively worked on by someone- regardless of working time frame) then add the dream stuff which have been discussed, then start pairing it down. Give someone final say even if it's only temporary (until release x) or a date. If this means the leadership changes hands once in a while, it's a good thing. Eventually, the person who most fulfills the role (no one is perfect) will stand out.

My experience is when you have a working product in distribution people are able to use, incremental releases with relatively few new stable features are well received by the community. Volunteers can only sprint for so long. Getting some features behind you lets the team release some brain cells to get the real life stuff done with less stress.

Big, comprehensive fat feature releases are also well received, but usually require more tech support and longer periods between satisfaction rewards for the team.

The community will (and has no choice) wait for anything. The sooner a stable feature release is possible, the sooner devoted and talented end users will step up in the forums and provide some of the tech support (how toos) to new users.

I see no reason a freeware dev team should provide 100% of the support for a product after a reasonable number of people are using it reasonably well (successfully.)
Instead, planning for directing new users to community forum resources for common new user problems can reduce dev time (contact us directly for missing files, textures, crashes, etc.) but let the community take on the howto stuff.)

Since passion can be a great motivator and obstacle, an objective requirements leader outside the dev team can come in handy to preserve the team passion, yet focus on reasonable objectives. It's never too late on a freeware, open-ended dev cycle to do these things.

-Pv-

 

[Donamy]

Seems reasonable.

 

[DaveS]

Can someone verify the attachment point numbers in the manual? Are they correct that 5 through 7 are for active payloads that can be unberthed by the RMS? Also, how does PayloadZPos[N] work? Does the [N] correspond to the attachment point number in the scenario file?

 

[spacman]

release date

Are we still go for April 12, 2016???:lol:

 

[Urwumpe]

Are we still go for April 12, 2016???:lol:

Make it April 12, 2018. Though I am still sure, we should have been able to do a release on April 12, 2015. But that's my opinion.

 

[GLS]

Back from the most brutal semester in recorded history. :lol:

So, I just did some cleanup work on the release file list, and I have to ask anyone who deletes and/or creates a file that should go in the release (so, only files in the trunk), please add/remove it from the releasefilelist.txt file in the trunk/Utils/SSU folder. Otherwise is a pain to maintain an up-to-date list.

Can someone verify the attachment point numbers in the manual? Are they correct that 5 through 7 are for active payloads that can be unberthed by the RMS? Also, how does PayloadZPos[N] work? Does the [N] correspond to the attachment point number in the scenario file?

I'll see what I can learn about this.

---------- Post added 07-05-15 at 01:51 AM ---------- Previous post was 07-04-15 at 04:11 PM ----------

So, the payload "situation" is as follows: there is a difference in the attachment numbering between the mission file PayloadZPos# entries (and its documentation) and the scenario entries (and the diagram in the "main" manual). The numbering on the scenario takes into account the existence of every attachment, but the scenario file just refers to the "payload" attachments (the numbers on the documentation seem to be somewhat in error). IMO, we should change the numbering system in the mission files so they match the scenario numbering, so instead of starting at 0 they would start at 5, which is the first "payload" attachment. That way it becomes much easier for the user as there's only one set of numbers.
Now, I'm here writing instead of making the changes because I see the code has arrays for 16 "payload" attachments, but only uses the 15 mentioned in the manual. I didn't write this code so I don't know what the intention was. I can make the numbering change in no time, but I'd like to know if I should trim the arrays to 15 or leave as is or something else.




BTW SiameseCat, would you please remove the following entries from the manual (page 1), as they no longer exist.
CONCRETE_014
CONCRETE_015
CONCRETE_016

 

[GLS]

So I did the changes to have the numbers in the mission file match the numbers on the scenario file (which are the attachment numbers), and then I found these lines in the scenarios:

   PAYLOAD CACTIVE1 8.000000 0.000000 0
   PAYLOAD CACTIVE2 0.000000 0.000000 0
   PAYLOAD CACTIVE3 -8.000000 0.000000 0
   PAYLOAD CPASSIVE1 4.000000 0.000000 0
   PAYLOAD CPASSIVE2 2.000000 0.000000 0
   PAYLOAD CPASSIVE3 -6.000000 0.000000 0
   PAYLOAD CPASSIVE4 7.000000 0.000000 0
   PAYLOAD PORT1 3.000000 0.000000 0
   PAYLOAD PORT2 -2.000000 0.000000 0
   PAYLOAD PORT3 -8.000000 0.000000 0
   PAYLOAD PORT4 7.000000 0.000000 0
   PAYLOAD STBD1 3.000000 0.000000 0
   PAYLOAD STBD2 -2.000000 0.000000 0
   PAYLOAD STBD3 -8.000000 0.000000 0
   PAYLOAD STBD4 0.000000 0.000000 0

The first number is the same Z-position parameter of the mission file, the second is the payload mass, and the third is the "payload type" (which I don't know what it means). I checked the code and the last 2 parameters are not used anywhere, and the first one seems to be overwritten by the mission file Z-position parameter, but on exit it still saves the value it read from the scenario. Removed the calls to the functions that read and write those scenario file entries and it all seems to work, so.... what should I do? Keep as is or delete those (apparently) redundant scenario file entries?

 

[DaveS]

Well, I created a ticket that mentioned the PAYLOAD parameters in the scenario file back in December 2013 as unused: https://sourceforge.net/p/shuttleultra/tickets/41/

 

[GLS]

Well, I created a ticket that mentioned the PAYLOAD parameters in the scenario file back in December 2013 as unused: https://sourceforge.net/p/shuttleultra/tickets/41/

Hmm, I guess this code is not under active development then. :lol:
I'm going to comment those parts out then, check all the scenarios and, if all checks out, commit the changes.

 

[Urwumpe]

Hmm, I guess this code is not under active development then. :lol:
I'm going to comment those parts out then, check all the scenarios and, if all checks out, commit the changes.

Can somebody with more knowledge verify, that those parameters have not been implemented for eventual Shuttle Fleet compatibility (not that we have much of that, geometrically)?

 

[DaveS]

Can somebody with more knowledge verify, that those parameters have not been implemented for eventual Shuttle Fleet compatibility (not that we have much of that, geometrically)?

I think those date way back, I don't think we ever had much concern for Shuttle Fleet/SSU compatibility. We have always been going our own ways, staying separate.

 

[GLS]

Can somebody with more knowledge verify, that those parameters have not been implemented for eventual Shuttle Fleet compatibility (not that we have much of that, geometrically)?

I did a bit of archaeology and found that this code was added in revision 250 (19/07/2008) by a certain "Urwumpe" user... so that "somebody with more knowledge" would be you.:lol:

---------- Post added at 07:48 PM ---------- Previous post was at 06:39 PM ----------

Just committed the discussed changes. Please check if all works fine.
I also fixed the attachment number for the STS-1 payload, as in some scenarios it was using an active attachment point. I didn't correct the CISS attachment points as those scenarios are going to be overwritten by the one on the ShuttleCentaur branch. The attachment corrections will be made when the merge is done.

 

[DaveS]

I did a bit of archaeology and found that this code was added in revision 250 (19/07/2008) by a certain "Urwumpe" user... so that "somebody with more knowledge" would be you.:lol:

---------- Post added at 07:48 PM ---------- Previous post was at 06:39 PM ----------

Just committed the discussed changes. Please check if all works fine.
I also fixed the attachment number for the STS-1 payload, as in some scenarios it was using an active attachment point. I didn't correct the CISS attachment points as those scenarios are going to be overwritten by the one on the ShuttleCentaur branch. The attachment corrections will be made when the merge is done.

Thanks. Just a heads up: A while ago I checked in an updated Orbiter mesh that has a few changes required for the Centaur namely the midbody T0 cavities in Bay 13. These now have the appropriate covers over them by default. I think these changes need to be merged into the ShuttleCentaur branch.