SSU public release comments/bug reports

[DaveS]

not sure how to add a zip file in a pm
or do i add it to my post here?

Better to add it here.

 

[1hippienaut]

will do

 

[DaveS]

will do

Checked them out and the details are good but the colors are all distorted and warped. Not exactly a good thing for something that is supposed to look accurate and good. That's sure to cause headaches after a while.

 

[1hippienaut]

Thanks for having a look

which colors are distorted

 

[DaveS]

are you using the regular LP

No, D3D9Client. As I wrote, the details appear fine but the colors are wrong and warped compared to the original.

---------- Post added at 08:18 PM ---------- Previous post was at 08:16 PM ----------

Thanks for having a look

which colors are distorted

The labels, the flags, the logos etc. Anything that is anything but extreme white or extreme black has its colors all wrong if you compare it with the original.

---------- Post added at 08:21 PM ---------- Previous post was at 08:18 PM ----------

Also, the details are coming on a bit too strong. Here's a nice close-up of the AFRSI blankets on Endeavour during the roll-out ceremony on April 25 1991:

http://www-pao.ksc.nasa.gov/kscpao/images/large/KSC-91PC-0765.jpg

 

[1hippienaut]

i see
i was going for an aged look

guess i failed :doh:

Thank you for your time

---------- Post added at 02:24 PM ---------- Previous post was at 02:23 PM ----------

nice shot

 

[DaveS]

i see
i was going for an aged look

guess i failed :doh:

Thank you for your time

---------- Post added at 02:24 PM ---------- Previous post was at 02:23 PM ----------

nice shot

Here's one that shows the blankets of Discovery and Endeavour during the "nose-to-nose" photo opportunity during the orbiter facility swap on August 11 2011: http://www-pao.ksc.nasa.gov/kscpao/images/large/2011-6401.jpg

 

[1hippienaut]

another nice shot

 

[1hippienaut]

in light of your input DaveS and those fine shots above

test 2
dxt3 4 bit alpha non-premult
thoughts?

 

[DaveS]

Those are bit better, but the colors are not even. They're still shifted way too much into the green. This is a comparison with a nice even lit photo of Atlantis during her transfer on the OTS from OPF-2 to VAB HB-2 on October 17 2012:

 

[1hippienaut]

how do i reset the elapsed timer on the crt univ ptg
it starts at 2000/2222222:2222222:2222222
the above is a rough for instance
usually starts at 000/0.0:0.0:0.0
something odd
all other crt functions are working great

 

[SiameseCat]

You can't. The timer is supposed to show the MET. In some of the scenarios, the MET isn't defined, so the timer starts from 0.

BTW, if you haven't done this yet, you should take a look at the documents here: http://www.nasa.gov/centers/johnson/news/flightdatafiles/index.html
The Shuttle Crew Operations Manual (SCOM) and DPS Dictionary are particularly helpful. we're trying to make the simulation as realistic as possible, so these documents should describe how SSU works fairly well (although obviously we're missing a lot of things still).

 

[Donamy]

I can't turn on the left mfd in the pilot's position. Does anyone else have this ?

 

[SiameseCat]

Confirmed. I suspect this is a particularly bad case of the VC MFD clickpoints being badly defined.

 

[1hippienaut]

Thank you have both love em and it may have been you else where who recommended
link good stuff still
i have temporary fixed the issue
just added met 0000.0000
seems to work
start time still reads in the 1000s: : : no big deal as just re enter 0 values

---------- Post added at 10:34 PM ---------- Previous post was at 10:28 PM ----------

another question for yall how do i make a retro bearing in crt 202
do i need to ops 201 6 P 0.00
or maybe bodyvect
ive had the manuals about a week
if i'll find it there havent yet
:facepalm:

 

[Donamy]

Does anyone besides DaveS have a working launch scenario ? CTD every one I had working in the past.

---------- Post added at 06:57 PM ---------- Previous post was at 04:08 AM ----------

Finally got a launch to work with newest SSU (Thanks to DaveS). I would like to know, if there is a way to have a 'frozen' SSU release build, that could be refered to, when releasing a mission pack that doesn't get broken without notice. It would eliminate alot of confusion.

 

[Urwumpe]

Does anyone besides DaveS have a working launch scenario ? CTD every one I had working in the past.

---------- Post added at 06:57 PM ---------- Previous post was at 04:08 AM ----------

Finally got a launch to work with newest SSU (Thanks to DaveS). I would like to know, if there is a way to have a 'frozen' SSU release build, that could be refered to, when releasing a mission pack that doesn't get broken without notice. It would eliminate alot of confusion.

We should "simply" get SSU fixed up to a reliable state. Not perfect, but reliable, no new features for speeding things up. and then we tag this state in SVN, so we can refer to the tag (Tags are read-only reference versions in version control). And all new developments from that point on are done with feature branches, so the scenarios are not permanently broken on the main line of development.

 

[Donamy]

Could that be done with this build ?

 

[Face]

We should "simply" get SSU fixed up to a reliable state. Not perfect, but reliable, no new features for speeding things up. and then we tag this state in SVN, so we can refer to the tag (Tags are read-only reference versions in version control). And all new developments from that point on are done with feature branches, so the scenarios are not permanently broken on the main line of development.

Apologizes if this is coming through as "outsider talk", but I would advice against using feature branch work-flows with SVN. Even with newer version's "merge-tracking" feature, it just isn't worth the effort.

Also tags are not read-only implicitly in SVN. If you are not taking counter-measures on the server via hooks, users can commit in the tag directory.

regards,
Face

 

[Urwumpe]

Could that be done with this build ?

I think we should do a review there first, there are some features, which are done, others that are 99% done and could be finished, and others, which would require so much work, that they would only delay the release.

I can't decide this alone, this is a team process.

I am pretty sure, we could get to a stable build in a month, if we drop some half-finished features instead of trying to finish them. And it would mean a month without working on new features.

My personal current feeling about this is, that we need about 16 man hours for cleaning things up. With two coders, this would mean two lazy weekends.

---------- Post added at 09:22 PM ---------- Previous post was at 09:15 PM ----------

Apologizes if this is coming through as "outsider talk", but I would advice against using feature branch work-flows with SVN. Even with newer version's "merge-tracking" feature, it just isn't worth the effort.

You are right about the management effort vs coding ratio there, but I think it could solve a lot of trouble regarding the scenarios, since having functional scenarios would be first of all the job of the feature branch maintainer.

Also, the effort with SVN isn't that high. With TortoiseSVN, I need a minute to create a new branch, and merging the branch back is generally not taking longer than 30 minutes, if you merged the trunk into your branch on a regular base.

Also tags are not read-only implicitly in SVN. If you are not taking counter-measures on the server via hooks, users can commit in the tag directory.

Never had found a way to commit to a tag, unless you mess with the server directly. At least in the past two years.