SSU Development Thread (2.0 to 3.0)

[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.

 

[GLS]

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.

I don't think that is needed. All the stuff in the ShuttleCentaur branch is coming to the trunk anyway. Unless it's something critical for development, it can wait for the Centaur in the trunk.

 

[Urwumpe]

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:

That's not the same person as me. That person was way more stupid 4 weeks ago. (Sorry, but I can hardly remember what happened three days ago. 2008 feels like there must have been knights and dragons around.)

 

[Donamy]

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.

All vertices were welded I hope. :thumbup:

 

[DaveS]

All vertices were welded I hope. :thumbup:

Does it even matter since the vertices get unwelded when you import it? But to answer your question directly, yes the vertices have been welded. In fact, there's no vertices to be welded as I used the technique used to create the star trackers and the ARCS jet nozzles. So there's no cutting (boolean operation) at all involved.

 

[GLS]

I need the coordinates (the ones that need 3D software) for the gear arm and deploy covers on both panels F6 and F8 please...

 

[DaveS]

I need the coordinates (the ones that need 3D software) for the gear arm and deploy covers on both panels F6 and F8 please...

CDR ARM cover: -0.92, 1.99996, 14.68735
CDR DN cover: -0.87370, 1.99996, 14.68735

Dir vectors for both covers: 0, 0.965408, 0.260745

PLT is identical except for mirrored X axis.